Selective reporting systems for functional status information that include integrated diagnostic models providing information about the least and most possible causes.

Abstract

First network device that includes: a transmitter / receiver (142) configured to receive an integrated model (130) from a second network device, the second network device being separate from the first network device; a memory (146) configured to store the integrated model (130), diagnostic problem code data, most probable cause data, and least probable cause data, wherein the diagnostic problem code data, the most probable cause data, and the least probable cause data contain corresponding information about the cause of a problem in a vehicle (102); and a control module (140) that is configured to execute the integrated model (130), and which during the execution of the integrated model (130) compares the information on the cause of the problem, which corresponds to the diagnostic problem code data, the most likely cause data, and the least likely cause data, to determine whether the information on the cause of the problem is consistent, so that the same cause of the problem is indicated. in response to the fact that the information regarding the cause of the problem is consistent, indicating the same cause of the problem, and In response to the fact that the information regarding the cause of the problem is inconsistent, and based on a set of conditions, it displays a selective section of functional state-related information while omitting to display another selective section of functional state-related information, the set of conditions includes whether: a component has failed a non-empty set of data of the most probable cause is available and a non-empty set of data of the least probable cause is available, the data of the most probable cause and the data of the least probable cause are consistent with at least one of the technician observations or verbatim technician reports, or Historical data for the most likely cause and historical data for the least likely cause are available.

Description

INTRODUCTION

[0001] The present invention relates to monitoring, evaluation, reporting and reaction systems of the vehicle's functional state.

[0002] Features are continuously being added to vehicles, making vehicle systems more complex. Additionally, electronic systems and modules are becoming more interconnected and interdependent, sometimes making it difficult to pinpoint the root cause of a problem. A technician servicing a vehicle has several tools and / or information sources to consult when determining the cause(s) of a problem. The tools may include a service tool for generating diagnostic trouble codes, a multimeter, and / or other instruments. The sources may include Failure Mode and Effects Analysis (FMEA) documents, Design Failure Mode and Effects Analysis (DFMEA) documents, historical data, current data, verbatim notes from a vehicle operator, and so on. Verbatim notes contain observations and descriptions of the problems experienced by the vehicle operator.

[0003] For general background information, reference is made here to the publications US 2018 / 0 082 492 A1 and US 2010 / 0 256 861 A1. SUMMARY

[0004] According to the invention, a first network device is presented which is characterized by the features of claim 1.

[0005] According to other characteristics, the integrated model is at least one heuristic model or one machine learning model.

[0006] According to other characteristics, the control module is configured: to determine whether a component has failed; in response to the determination that the component has not failed, to determine whether to display historical data or to refrain from displaying a vehicle functional status report; and in response to the determination that the component has failed, to determine whether to display selective functional status-related information or to refrain from displaying a vehicle functional status report.

[0007] According to other characteristics, the control module is configured to: determine whether a non-empty set of most probable cause data and a non-empty set of least probable cause data are available; in response to determining that an empty set of most probable cause data and an empty set of least probable cause data are available, refrain from displaying a status report; and in response to determining that a non-empty set of most probable cause data and a non-empty set of least probable cause data are available, display the most probable cause data and the least probable cause data.

[0008] According to other features, the control module is configured to: determine whether the most probable cause data and the least probable cause data are consistent with at least one technician observation or verbatim technician report; in response to determining that the most probable cause data and the least probable cause data are consistent with at least one technician observation or verbatim technician report, display the most probable cause data and the least probable cause data; and in response to determining that the most probable cause data and the least probable cause data are inconsistent with at least one technician observation or verbatim technician report, display the most probable cause data, the least probable cause data, and other functional state-related data.

[0009] According to other characteristics, the control module is configured: to determine whether the historical most probable cause data and the historical least probable cause data are available; in response to the fact that the historical most probable cause data and the historical least probable cause data are not available, to refrain from displaying a functional status report; and in response to the fact that the historical most probable cause data and the historical least probable cause data are available, to determine whether the historical most probable cause data and / or the historical least probable cause data match verbatim customer reports or whether verbatim customer reports are available.

[0010] According to other characteristics, the control module is configured: to display trend data in response to the fact that the historical data of the most probable cause and / or the historical data of the least probable cause are consistent with verbatim customer reports, or that no verbatim customer reports are available; and to display the historical data of the most probable cause and the historical data of the least probable cause in response to the fact that the historical data of the most probable cause and / or the historical data of the least probable cause are not consistent with verbatim customer reports, or that verbatim customer reports are available.

[0011] According to other features, the functional state-related information includes the most likely cause data, the least likely cause data, trend data, system schema data, and a recommendation for repair.

[0012] According to other features, the control module is configured: the transmitter / receiver is configured to receive integrated information generated by the vehicle, the second network device, or another network device, the integrated information containing a green power decision; to generate decisions about the least likely cause based on the integrated information; and to display the decision about the least likely cause.

[0013] According to other features, a system is provided that includes the first network device and the second network device. The second network device contains a second transmitter / receiver, a second memory, and a second control module. The second transmitter / receiver is configured to receive diagnostic problem code data, most probable cause data, and least probable cause data from the first network device. The second memory is configured to store, for a vehicle program, the integrated model, effective fault mode analysis data, diagnostic problem code data, most probable cause data, least probable cause data, verbatim data of the vehicle operator, and repair actions.The second control module is configured to: train and / or update the integrated model based on the data from the effective fault mode analysis, the diagnostic problem code data, the most probable cause data, the least probable cause data, the verbatim data of the vehicle operator, and the repair actions; and subsequently, after at least one of the training or updating of the integrated model, to transmit the integrated model to the first network device via the second transmitter / receiver.

[0014] According to other characteristics, the integrated model is at least one of a heuristic model or a machine learning model and is configured to report selective maintenance information while excluding other maintenance information based on the consistency of the cause statements and the availability of the non-empty set of data for the most probable cause and the non-empty set of data for the least probable cause.

[0015] According to other features, the second control module is configured to train and / or update the integrated model based on the diagnostic problem code data, the most likely cause data, or the least likely cause data for another vehicle in the vehicle program.

[0016] According to other criteria, the vehicle program refers to a specific type, model, and year of vehicle. The diagnostic problem codes are derived from several vehicles manufactured according to the vehicle program.

[0017] According to other characteristics, the second control module is configured to remove, during at least one of the training or updating of the integrated model, the repair measures that have not solved the problem.

[0018] According to other features, the second control module is configured to: extract at least one symptom, root cause, or candidate data of the problem from selective word-for-word data and effective fault mode analysis data; combine a guarantee working code with the extracted selective word-for-word data and the effective fault mode analysis data; and train or update the integrated model based on the guarantee working code combined with the extracted selective word-for-word data and the effective fault mode analysis data.

[0019] According to other features, the second control module is configured to: normalize the warranty working code combined with the extracted selective word-for-word data and the effective fault mode analysis data; and train or update the integrated model based on the normalized warranty working code combined with the extracted selective word-for-word data and the effective fault mode analysis data.

[0020] According to other features, the second control module is configured to: share the normalized warranty working code combined with the extracted selective word-for-word data and the effective fault mode analysis data to provide training data, validation data, and test data; train the integrated model based on the training data; determine a hyperparameter of the integrated model based on the validation data; and determine the performance of the integrated model using the test data.

[0021] According to other features, a maintenance procedure is created which includes: receiving an integrated model via a transmitter / receiver of a first network device from a second network device; and storing the integrated model, diagnostic problem code data, most probable cause data and least probable cause data in the first network device, wherein the diagnostic problem code data, the most probable cause data and the least probable cause data contain corresponding information on the problem cause for a problem of a vehicle.The procedure further includes executing the integrated model and, during the execution of the integrated model: comparing the problem cause information with the diagnostic problem code data, the most likely cause data, and the least likely cause data to determine whether the problem cause information is consistent, so that the same problem cause is indicated; in response to the problem cause information being consistent, displaying the same problem cause; and in response to the problem cause information being inconsistent, and based on a set of conditions, displaying a selective section of the functional state-related information while omitting the display of another selective section of the functional state-related information.

[0022] According to other features, the method further includes: receiving the diagnostic problem code data, the most probable cause data, and the least probable cause data from the first network device to the second network device; storing the integrated model, the effective fault mode analysis data, the diagnostic problem code data, the most probable cause data, the least probable cause data, the verbatim vehicle operator data, and the repair actions for a vehicle program in the second network device; and at least one of the following: training or updating the integrated model based on the effective fault mode analysis data, the diagnostic problem code data, the most probable cause data, the least probable cause data, the verbatim vehicle operator data, and the repair actions.and subsequently, at least one of the training or updating of the integrated model is transferred to the first network device.

[0023] Further areas of application of the present invention will become apparent from the detailed description, the claims, and the drawings. The detailed description and the specific examples are provided for illustrative purposes only. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The present invention will be more fully understood from the detailed description and the accompanying drawings; these show: Fig. 1 a functional block diagram of an exemplary functional state monitoring system configured to implement an integrated heuristic and / or machine learning model according to the present invention; Fig. 2 a functional block diagram of an exemplary vehicle system comprising a functional state module according to the present invention; Fig. 3 a functional block diagram of an exemplary customer service office according to the present invention; Fig. 4 a maintenance reporting method implemented using the integrated heuristic and / or machine learning model according to the present invention; Fig. 5 an adaptation process for updating the integrated heuristic and / or machine learning model according to the present invention; Fig. 6 an exemplary maintenance tool screen containing a trend graph and a system functional status information report with information on the most probable cause (MPC) and the least probable cause (LPC) according to the present invention; Fig. 7 an exemplary maintenance tool screen comprising a schematic system diagram and a system functional status information report containing MPC and LPC information according to the present invention; Fig. 8 a functional block diagram illustrating a first exemplary architecture that includes the integration of current vehicle data into a maintenance tool and the integration of Green Performance (POG) cause indication data into a customer service office according to the present invention; Fig. 9 a functional block diagram illustrating a second exemplary architecture that includes the integration of current vehicle data and POG cause indication data on the maintenance tool according to the present invention; Fig. 10 a functional block diagram illustrating a third exemplary architecture that includes the integration of current vehicle data in the maintenance tool and the integration of POG cause indication data in a vehicle according to the present invention; and Fig. 11 a functional block diagram illustrating a fourth exemplary architecture that includes the integration of current vehicle data and POG cause indication data in a vehicle according to the present invention.

[0025] Reference symbols may be used multiple times in the drawings to identify similar and / or identical elements. DETAILED DESCRIPTION

[0026] When a vehicle operator experiences a problem within a vehicle (e.g., the vehicle has difficulty starting), the vehicle is taken to a repair shop for servicing and / or repair. A service technician typically connects the vehicle to a diagnostic service tool to determine if any diagnostic trouble codes (DTCs) have been set. The technician may also review various other collected and / or accessible information, such as FMEA documents, DFMEA service manual documents, historical data, current measurement data, verbatim notes (referred to below as verbatim reports) from the vehicle operator, etc. When certain problems arise, the collected information may be inconsistent and indicate different causes of a problem, particularly for intermittent malfunctions.As a result, diagnostic results from different tools and sources can confuse a maintenance technician, leading to distrust of the service tools, incorrect diagnosis and / or prognosis of problems, and increased maintenance and warranty costs. Furthermore, if multiple diagnostic trouble codes (DTCs) are set for a single problem, this can increase the difficulty in determining the true root cause of the issue.

[0027] The No Problem Found (NTF) rate and the Customer Issue Not Reproduced (CCND) rate can be high for certain problems. For example, if a vehicle is experiencing starting difficulties, the cause of the problem could be one or more of several things: a faulty battery, a faulty starter, a faulty electronic control module, a faulty connection, a faulty electronic component, and so on. A service technician, after reviewing all the information gathered, may have difficulty pinpointing the exact cause of the problem. This can lead to the technician incorrectly determining, for example, that the battery is faulty when the battery is actually not. As a result, the customer's warranty costs and / or repair costs increase.When a malfunction occurs, a maintenance technician who distrusts the available maintenance tools and / or the information gathered may replace a component based on knowledge gained from a previous experience. This can also lead to the replacement of the wrong component.

[0028] For example, if the problem is intermittent and there is no reported diagnostic trouble code from the service tool, no illuminated malfunction indicator lamp in the vehicle, and no service office report from an active remote functional status monitoring system, the technician may mistakenly determine that there is no fault. This results in the customer having to pick up the vehicle, wait until the problem worsens, and then return the vehicle to the repair shop, potentially leading to a dissatisfied customer and further increased maintenance and / or warranty costs. As an example, a service office report may be provided that includes a green, yellow, or red (GYR) rating indicating whether a problem exists. The GYR rating can provide a confidence level for a component's state of health (SOH). A green rating indicates that the component is functioning as expected.A yellow label indicates that the component is operating with reduced functionality and / or is deteriorating. A red label indicates that the component has failed or will fail within a short, determined timeframe.

[0029] The examples presented here include functional state monitoring systems that incorporate adaptive and integrated diagnostic models and systems, providing a maintenance technician with selective information based on specific conditions. Other selective maintenance and / or functional state-related information is not reported. This is done to minimize and / or prevent confusion when determining the root cause of a problem. Several different adaptive integrated architectures and procedures are disclosed. Examples are provided for handling permanent and intermittent faults. Permanent faults refer to faults associated with a failed component.Intermittent faults refer to malfunctions that are reported sporadically and can be attributed to a deteriorating component, a loose connection, and / or another problem for which a fault is not reported continuously. The systems incorporate the use of heuristic and machine learning models and feature unique graphical user interfaces for quick, clear, and easy problem identification. These systems enable a maintenance technician to quickly and easily diagnose and / or predict a problem.

[0030] Fig. Figure 1 shows a functional state monitoring system 100 configured to implement an integrated heuristic and / or machine learning model. The functional state monitoring system 100 includes a vehicle 102, a service office 104, and a maintenance tool 106. The vehicle 102 may contain a body control module (BCM) 110, a transmitter / receiver 112, a memory 114, and the vehicle systems 116. The BCM 110, or another control module hosting the functional state module 118, may contain a functional state module 118 to provide functional state-related information to a vehicle operator. The functional state-related information may be provided via an infotainment system, as shown in Figure 1. Fig. Figure 2 shows that the memory 114 can store various data 119. Examples of vehicle systems 116 are shown in Fig. Figure 2 shows that the data can contain functional status-related information, maintenance information, etc. The functional status-related information can include a POG cause statement and related information, as well as system and / or component status information (e.g., functional state, operating time, performance data, etc.).

[0031] The customer service office 104 can be implemented as part of a cloud-based network and may contain one or more servers 120, a transmitter / receiver 122, and a memory 124. The servers 120 may contain a control module 126, which may contain a model module 128. The model module 128 can generate, train, and update an integrated heuristic model and / or machine learning model 130 (hereinafter referred to as the integrated diagnostic model or simply the integrated model 130), which is stored in the memory 124 along with the data 132. The customer service office is referred to below with regard to Fig. 3 further described.

[0032] The maintenance tool 106 can be implemented in a repair shop and used as a functional tester when servicing the vehicle 102. The maintenance tool 106 can include a control module 140, a transmitter / receiver 142, a user interface 144, and a memory 146. The control module 140 contains a maintenance module 148. The user interface 144 can include a touchscreen and / or a keypad. The memory 146 can store the integrated model 130 and the data 150. The maintenance tool 106 can be connected to the vehicle 102 wirelessly or via one or more wires. The maintenance tool 106 can, for example, B. can be used to obtain, receive and / or generate current DTCs (referred to as DTCs), historical DTCs (HDTCs), current MPCs (referred to as MPCs), current LPCs (referred to as LPCs) and / or other maintenance-related information.The data 150 can contain the DTCs, HDTCs, MPCs and LPCs.

[0033] In some embodiments, the maintenance tool 106 is implemented on or as part of another network device, such as a mobile phone, an in-vehicle device, or a service provider's server. The service provider and / or customer service office 104 may provide a website that displays maintenance and / or operational status information output by the maintenance tool 106. The website may be accessible via the mobile phone, the in-vehicle device, and / or another network device. A user and / or technician with access to the mobile phone, the in-vehicle device, and / or the other network device may access the website and / or the maintenance and / or operational status information. The operational status information may include any of the reported information set out below.The maintenance and / or operational status information may include any of the maintenance and / or operational status information disclosed herein. In these embodiments, the maintenance module 148 is implemented in the mobile phone, in the vehicle's in-vehicle network device, or in the service provider's server. These embodiments are applicable to all of the embodiments according to the [references to be added]. Fig. 1-11 and / or corresponding features described herein are applicable.

[0034] Control modules 110, 128, and 140 can share various functional status-related information. Control modules 126 and 140 share the integrated model 130. Control module 126 can train and / or update the integrated model 130 based on data received from the vehicle 102 and / or the maintenance tool 106.

[0035] Fig. Figure 2 shows an exemplary vehicle system 200 of vehicle 102 according to Fig. 1. The vehicle system 200 includes the BCM 110, a telematics module 206, a powertrain control module 208, a braking system 210, a navigation system 212, an infotainment system 214, an air conditioning system 216, and other vehicle systems and modules 218. The BCM 110 includes the functional status module 118. The modules and systems 110, 118, 206, 208, 212, 214, 216, and 218 can communicate with each other via a controller area network (CAN) bus 219. This communication can include other systems, such as the braking system 210. A power source 220 can be included and supply power to the BCM 110 and other systems, modules, devices, and / or components. The power source 220 can include one or more batteries and / or other power sources.

[0036] The telematics module 206 can contain the transmitter / receiver 230 and a telematics control module 232. The drive control module 208 can control the operation of a drive system 236, which may contain a power unit 238 and / or one or more electric motors 240. The power unit 238 may contain a starter motor 242, a fuel system 244, an ignition system 246, and a throttle system 248.

[0037] The BCM 110 can control modules and systems 118, 206, 208, 210, 212, 214, 216, 218, and other devices and systems based on data from sensors 260. These other devices and systems can include window and door actuators 262, interior lights 264, exterior lights 266, trunk motor and lock 268, seat position motors 270, seat temperature control systems 272, and vehicle mirror motors 274. Sensors 260 can include temperature sensors, pressure sensors, flow sensors, position sensors, etc.

[0038] The functional status module 118 can monitor the states of the systems, modules, devices, and components shown and provide functional status information, e.g., about the infotainment system 214, which may contain one or more displays, lights, an audio system, etc. The functional status module 118 can transmit the functional status information to the control modules 126 and 140. Fig. 1 and / or various status information. The functional status module 118 can also receive functional status-related information from the control modules 126 and 140 and report the functional status-related information to a vehicle operator.

[0039] Fig. Figure 3 shows the exemplary customer service office 104, which contains the server 120, the transmitter / receiver 122, and the memory 124. The server 120 contains the control module 126 with the model module 128. The model module 128 can receive the FMEA and DFMEA information 300, the historical data 302, the DTCs, HDTCs, MPCs, and LPCs 304, verbatim reports, and repair actions 306, and, based on this information, generate, train, update, and deploy the integrated model 130. The integrated model 130 can then be sent to the maintenance tool 106. Fig. 1 will be provided.

[0040] The FMEA and DFMEA information 300 after Fig. 3 can contain relationships between symptoms and problems. The FMEA and DFMEA information 300 can be received from a remote data center 310. The historical data 302 can contain the HLPCs and HMPCs previously performed for the current model of the vehicle (i.e., the model of vehicle 102 after Fig. 1) were recorded. A different integrated model can be generated for vehicles of different models. The historical data 302 can contain historical data for the specific vehicle 102 and / or other vehicles of the same model and / or type.

[0041] The DTCs, HDTCs, MPCs and LPCs 304 can be removed by the maintenance tool 106. Fig. 1. The DTCs, HDTCs, MPCs, and LPCs 304 can also or alternatively be generated at vehicle 102 and transmitted to customer service office 104. The DTCs, HDTCs, MPCs, and LPCs 304 can also or alternatively be generated at customer service office 104 after processing the original signals collected by vehicle 102. The verbatim reports and repair actions 306 according to Fig. Memory 3 can contain verbatim reports from the vehicle operator, verbatim reports from the maintenance technician, and actual repair actions performed with corresponding repair action labels that identify the action performed. Memory 124 can store the integrated model 130, the FMEA and DFMEA information 300, the historical data 302, the verbatim reports and repair actions 306, the current data 320 (e.g., the DTCs, MPCs, LPCs), and the HDTCs 322, which can also be referred to as historical data.

[0042] Model Module 128 can adapt the integrated Model 130 for any vehicle program, which may refer to a vehicle type, model, year, and / or other vehicle identification information. Model Module 128 can implement a neural network, such as a convolutional neural network (CNN) and / or a recurrent neural network (RNN). Model Module 128 also, or alternatively, operates as a support vector machine (SVM). Model Module 128 can also, or alternatively, implement a random forest learning algorithm while training the integrated Model 130. Model Module 128 can also, or alternatively, implement a statistical inference algorithm, such as Bayesian inference, to update a hypothesis probability as data becomes available.

[0043] The integrated Model 130, once trained, will follow the Maintenance Tool 106. Fig. 1 provided. The maintenance tool 106 executes the integrated model 130 to generate functional status report information, as further described below.

[0044] Fig. Figure 4 shows a maintenance reporting procedure implemented using the integrated heuristic and / or machine learning model. The operations of Fig. The four steps can be executed iteratively. The procedure can start at 400 and can be executed by the maintenance module 148 of the maintenance tool 106. At 402, the maintenance module 148 loads the available historical data (e.g., the HMPC, HLPC, and HDTC data) for a currently tested vehicle into memory 146.

[0045] At 404, the maintenance module 148 can generate MPC and LPC data and, depending on the time period for which the data is being generated, can also generate HMPC and HLPC data. MPC and LPC data can be generated based on parameter identifiers (IDs), DTCs, and vehicle functional state management (VHM) information. HMPC, HLPC, MPC, and LPC data can include empty quantity indicators if HMPC, HLPC, MPC, and / or LPC data cannot be generated due to insufficient data. VHM information can include a GYR value and / or other functional state-related information. VHM information can be based on the continuous evaluation, over an extended period, of various parameters that indicate a functional state.For example, a battery's state of charge, open-circuit voltage, minimum starting voltage, starting time, battery internal resistance, and / or other parameters can be evaluated. Problem symptoms (deviations from normal) in the monitored parameters are identified to diagnose and predict malfunctions (e.g., a battery malfunction). The MPC data, VHM information, DTCs, etc., can be related to or associated with cause statements (sometimes referred to as decisions) that indicate possible, probable, and / or unlikely cause(s) for each problem.

[0046] In case of error 406, maintenance module 148 determines whether the loaded and generated data and information are consistent and therefore indicate the same cause of a problem. If the loaded and generated data are consistent, operation 408 is executed; otherwise, operation 410 is executed.

[0047] For error code 408, maintenance module 148 reports and displays a consistent description of the problem's cause and a corresponding recommendation for resolving it. This can be done via a maintenance tool screen. The maintenance tool screen can be accessed similarly to those described in the Fig. 6 and Fig. The 7 screens shown may be configured, but contain different information than what is shown in the Fig. 6 and Fig. The 7 figures shown are included.

[0048] In operation 410, maintenance module 148 determines whether a component associated with the specified cause of the problem has failed (e.g., is inoperative and / or cannot function as intended). If so, a permanent fault has occurred and operation 412 is executed; otherwise, an intermittent fault has occurred and operation 430 is executed.

[0049] At operation 412, the maintenance module 148 determines whether a non-empty set of MPC and LPC data is available. If not, the maintenance tool 106 and / or the integrated model may not be configured to diagnose (or cover) the fault (or problem), executing operation 414; otherwise, the maintenance tool 106 and the integrated model 130 are configured to diagnose the fault (or problem), executing operation 424.

[0050] In operation 414, maintenance module 148 determines whether a non-empty set of HMPC and HLPC data is available. If not, the fault is not covered and operation 416 is executed; otherwise, operation 418 is executed.

[0051] The execution of operation 416 can be described as a proactive alert.

[0052] In case 416, the maintenance module 148 fails to report functional status-related information, including failing to display a functional status report.

[0053] At operation 418, maintenance module 148 determines at least one of (i) whether the HMPC and HLPC data are consistent with the verbatim customer reports, or (ii) whether no verbatim customer reports are available. If neither is true, operation 420 is executed; otherwise, operation 422 is executed. At 420, maintenance module 148 displays the historical data (e.g., the HMPC and HLPC data). At 422, maintenance module 148 reports and displays the HMPC data, the HLPC data, and the trend data. As an example, the problem might be a non-start condition, where the integrated model can determine that a fuel pump is the cause of the non-start condition and can report the HMPC, HLPC, and trend data, which may indicate that the fuel pump is faulty.

[0054] At operation 424, maintenance module 148 determines whether the MPC and LPC data are consistent with the technician's observations and verbatim reports. If so, operation 426 is executed; otherwise, operation 428 is executed. At operation 426, maintenance module 148 reports and displays the MPC and LPC findings (or decisions) regarding the root cause of the problem. To continue with the same example of a non-start problem, operation 426 can be executed and indicate that the non-start problem is due to a faulty battery.

[0055] At operation 428, Maintenance Module 148 displays functional status information, which may include the MPC, LPC, a recommendation, the DTC, trend data, system diagrams, and / or other functional status data. The displayed information may indicate that the non-start problem is due to a leaking battery. This may be indicated by an MPC stating that the most likely cause of the problem is the leaking battery. The conditions of a leaking battery can be difficult to detect and identify. If operation 424 is not performed, an MPC may indicate that the MPC is not the battery, even though the battery is leaking. Operation 424 is performed to enable a technician to more easily make this determination.

[0056] At operation 430, maintenance module 148 determines whether the HMPC and HLPC data are available. If not, operation 432 is executed; otherwise, operation 434 is executed. At operation 432, maintenance module 148 refrains from reporting any functional status information, including refraining from displaying a functional status report.

[0057] At operation 434, maintenance module 148 determines at least one of (i) whether the HMPC and HLPC data are consistent with the verbatim customer reports, or (ii) whether no verbatim reports are available. If neither is true, operation 436 is executed; otherwise, operation 438 may be executed. At 436, maintenance module 148 displays the historical data (e.g., the HMPC and HLPC data). At 438, maintenance module 148 reports and displays the HMPC data, the HLPC data, and the trend data. Continuing the same nonstart example, maintenance module 148 may indicate that an intermittent nonstart fault occurred due to a low battery state of charge.

[0058] The procedure can end at 440. This can occur following operations 416, 420, 422, 426, 428, 432, 436, 438.

[0059] Fig. Figure 5 shows an adaptation process for updating the integrated heuristic and / or machine learning model 130 according to Fig. 1. Model 130 can be a long short-term memory (LSTM) model. The LSTM model can process time series data and make decisions based on current and historical data. The operations according to Fig. 5 can be executed iteratively. The procedure can be carried out by the model module 128 of the customer service office 104 according to Fig. 1 will be executed and start at 500.

[0060] At 502, model module 128 loads historical data, which may include HMPC and HLPC data for a specified period, and current test results, which may include DTCs and MPC and LPC data. This can be performed for each repair performed on the vehicles in a vehicle program. The vehicle program can refer to a vehicle make, model, and year, as well as other vehicle identification information. The historical data and the current data, which include MPC, LPC, and diagnostic trouble codes, may be from and / or correspond to multiple vehicles produced according to the vehicle program.

[0061] At error code 504, model module 128 removes the data associated with a repair that did not resolve the problem and / or corrects the data to indicate the appropriate repair that will resolve the problem. This can be done based on a verbatim report from a vehicle operator and / or technician. It can also be done based on a verbatim report from a field service technician who, for example, evaluates a component (such as a battery) that a technician has identified as faulty. The data can also be removed if an additional subsequent repair is performed to correct the same problem that was not resolved by the previously performed repair.

[0062] At 506, the Model Module 128 loads a verbatim report, the FMEA and DFMEA data, extracting selected information such as symptoms, root causes, and / or a candidate subsystem associated with the problem. At 508, the Model Module 128 combines a warranty work code with the extracted selected information and uses the combined result as the label data for each repair case. The warranty work code can refer to a number indicating the type of repair being performed (for example, replacing a battery might have a specific warranty work code).

[0063] In 510, model module 128 replaces all fields of the combined result that are unavailable (or an empty set) with a constant number. The constant number can be zero, a negative number, or a high number that distinguishes it from other actual data. In 512, model module 128 normalizes the combined result data. This can include scaling the data so that it has values ​​between, for example, 0 and 1.

[0064] At 514, the model module 128 divides the normalized data into training, validation, and test datasets.

[0065] At 516, the model module 128 presents the training data set as an input to the integrated model 130. Fig. 1. It uses the validation set to find the best hyperparameter and the test dataset to determine a performance level of the integrated model. The hyperparameter specifies the optimal number of layers in the corresponding neural network to provide the best result. Too few or too many layers can lead to a poorer result. Each layer of the neural network can contain weights that are trained during the training described above.

[0066] At 518, the model module 128 saves the trained resulting integrated model with the selected number of layers to memory 124. The model can be transferred to one or more maintenance tools, such as maintenance tool 106. This can be performed as an initial transfer to the maintenance tools or to replace and / or update integrated models already stored in the maintenance tools. The procedure can terminate at 520.

[0067] Fig. Figure 6 shows a maintenance tool screen 600, which includes a vehicle information window 602 and a system function status information report window 604. The exemplary maintenance tool screen 600 is presented as an example for operation 438 according to Fig. 4. The vehicle information window 602 can contain vehicle information such as color, vehicle maintenance tag, body type data, delivery data, and other vehicle information. The vehicle information can include free-field actions 606 and maintenance information 608. The free-field actions 606 can contain action types, original part numbers, and descriptions. The maintenance information 608 can contain maintenance types, numbers, descriptions, dates, etc.

[0068] The System Functional Status Information Report window 604 can contain a trend graph 610 and a System Functional Status Information Report 612. The trend graph 610 can contain a historical data trend and / or other trend data associated with a problem over time. The trend graph 610 can indicate when a customer noticed a problem (for example, a non-starting problem), as shown by line 614 in the sample graph. The System Functional Status Information Report 612 can, as shown, provide a Medical Problem Correction (MPC), a Low Problem Correction (LPC), and a recommendation. In the example shown, a non-starting problem occurred, and the integrated model provides an MPC, which is the starter, an LPC, which is the battery, and a recommendation to replace the starter. The integrated model can provide similar information for other problems and their causes.In one embodiment and for cases of intermittent malfunctions, the maintenance tool 106 indicates . Fig. 1 of the possible functional state information to be provided is only a correlation and a trend of the historical data in the system functional state information report.

[0069] The operations described above are intended as illustrative examples. Depending on the application, the operations can be executed sequentially, synchronously, concurrently, continuously, during overlapping time periods, or in any other order. Furthermore, any of the operations may not be executed or may be skipped, depending on the implementation and / or the sequence of events.

[0070] Fig. Figure 7 shows a maintenance tool screen 700, which contains a vehicle information window 702 and a system function status information report window 704. The exemplary maintenance tool screen 700 is shown as an example for operation 426 according to Fig. 4. The vehicle information window 702 can contain vehicle information such as color, vehicle maintenance tag, body type data, delivery data, and other vehicle information. The vehicle information can include free-field actions 706 and maintenance information 708. The free-field actions 706 can contain action types, original part numbers, and descriptions. The maintenance information 708 can contain maintenance types, numbers, descriptions, dates, etc.

[0071] The System Functional Status Information Report window 704 can contain a schematic system diagram 710 and a system functional status information report 712. The schematic system diagram 710 can contain blocks that identify modules, devices, components, and corresponding interconnections to illustrate a hierarchical arrangement and the relationships between the modules, devices, and components.

[0072] Various modules, devices, and components can be highlighted and / or colored differently to indicate modules, devices, and / or components of a specific subsystem and / or those that may be associated with a specific problem. The schematic system diagram 710 enables a technician to quickly identify the modules, devices, and components that may be involved and / or a cause of a problem. This can be done based on the information in the System Functional Status Information Report. The technician can verify the information in the System Functional Status Information Report based on the schematic system diagram 710 and / or the highlighting and / or coloring of the various modules, devices, and / or components.The system function status information report, provided through the System Function Status Information Report window 704, can, as shown, specify an MPC, an LPC, and a recommendation. In the example shown, a non-start has occurred, and the integrated model specifies: an MPC that is a CAN bus, a Passive Access Passive Start Module (PEPS module), a BCM, or a key fob (or key fob module); an LPC that is the battery, the starter, or the power unit; and a recommendation to check the bus connection. The integrated model can provide similar information for other problems and causes of the problem. In one embodiment, and for cases of permanent faults, Maintenance Tool 106 indicates... Fig. Of the possible functional status information available to be displayed, only the current test results and the MPC and LPC results from the integrated model are shown (or reported). Maintenance Tool 106 does not display any other available status and / or functional status-related information.

[0073] The examples outlined above include the use of an adaptive architecture to update the integrated model. A heuristic model is used to integrate diverse pieces of information. A machine learning model is used to generate an integrated outcome (or decision). FMEA and DFMEA can be used to label symptoms, root causes, and candidates.

[0074] Various architectures can be implemented for generating LPCs based on real-time vehicle data, diagnostic and predictive results, technician observations, and verbatim customer reports, and for displaying the LPC results to the service technician for vehicle repair. Providing LPC information to technicians can help them avoid unnecessary repairs. These architectures and the corresponding systems include (i) data collection and processing on board the vehicle and in the service office, and (ii) service tool integration and display for the technicians.

[0075] Fig. Figure 8 shows an initial exemplary architecture (or system) 800, which incorporates the integration of real-time vehicle data at a maintenance tool and the integration of Problem Root Cause (POC) data from the Green Performance (GR) system at a service office. The VHM ratings are designed to predict the onset of defined field fault modes. The POC decisions are based on VHM information and generated using LPC heuristics. The more consecutive Green ratings from the GYR data for a specific subsystem, module, device, and / or component within a specified time period, the more confident the system is that the subsystem, module, device, and / or component is functioning correctly (i.e., operating normally and / or within the specified normal parameter operating ranges).The more consecutive yellow and / or red ratings from the GYR data for a specific subsystem, module, device and / or component within a specified period, the more certain the system is that the subsystem, module, device and / or component is faulty (i.e., operating anomalously and / or outside the normal specified parameter operating ranges).

[0076] The first system 800 comprises the vehicle 102, a customer service office 804, and the maintenance tool 106. The vehicle 102 comprises the BCM 110, the transmitter / receiver 112, the memory 114, and the vehicle systems 116. The BCM 110 comprises the functional status module 118. The functional status module 118 can perform data collection from the vehicle systems, modules, devices, and components and report the collected data to the customer service office 804 and / or the maintenance tool 106. The functional status module 118 can be implemented by a vehicle module, a module of a mobile network device (e.g., a mobile phone), a copy protection plug, and / or another vehicle device. The functional status module 118 can be implemented as an application. In one embodiment, the functional status module 118 is implemented by an onboard telematics system.

[0077] The Customer Service Bureau 804 contains one or more Servers 820, a Transmitter / Receiver 822, and a Memory 824. The Servers 820 contain a Control Module 826, which includes the Model Module 128. The Control Module 826 may also contain a Diagnostic and Predictive Module 830, a GYR Module 832, and a POG Module 834. The Diagnostic and Predictive Module 830 can determine, based on data received from the Functional State Module 118: the cause of an existing problem; predict a problem expected to occur in the future; and / or the causes of problems predicted to occur. This can be done based on historical and currently collected data from one or more vehicles, including the vehicle exhibiting the existing problem. The operations performed in the Customer Service Bureau 804 can be described as cloud computing.The GYR module 832 can provide GYR readings based on historical and currently collected data. These GYR readings can be based on diagnostics and prognosis. For example, the GYR readings can be provided to the vehicle 102 and / or to a mobile network device of the vehicle operator as proactive alerts. The POG module 834 can generate POG decisions and historical data, such as HMPC and HLPC data, based on the GYR readings and / or the output of the GYR module 832. The POG decisions can include LPCs and can provide confidence levels for the MPC and LPC decisions made. The memory 824 stores the integrated model 130 and the data 132.

[0078] The maintenance tool 106 includes a control module 140, a transmitter / receiver 142, a user interface 144, and a memory 146. The control module 140 contains a maintenance module 148. The maintenance module 148 can integrate POG decisions, vehicle data, and technician and customer reports, and generate MPC and LPC data (or decisions) based on this integration. The vehicle data can include data collected by the functional status module 118. This can be done using the integrated model. The MPC and LPC decisions can be provided back to the service office for continued customization of the integrated model. The memory 146 stores the integrated model 130 and the data 150.

[0079] Fig. Figure 9 shows a second exemplary architecture (or second system) 900, which includes the integration of the current vehicle data and the POG problem cause indication data at the maintenance tool. The second system 900 includes the vehicle 102, a customer service office 904, and a maintenance tool 906. The vehicle 102 includes the BCM 110, the transmitter / receiver 112, the memory 114, and the vehicle systems 116. The BCM 110 includes the functional status module 118.

[0080] The Customer Service Bureau 904 contains one or more Servers 920, a Transmitter / Receiver 922, and a Memory 924. The Servers 920 contain a Control Module 926 with a Model Module 128. The Control Module 926 may also contain the Diagnostic and Predictive Module 830 and the GYR Module 832. The Diagnostic and Predictive Module 830 can determine, based on collected data: the cause of an existing problem; predict a problem expected to occur in the future; and / or the causes of predicted problems. This can be done based on historical and current data collected from one or more vehicles, including the vehicle exhibiting the existing problem. The operations performed in the Customer Service Bureau 804 can be described as cloud computing operations. The GYR Module 832 can provide GYR information based on historical and current data.The GYR data can be based on the diagnosis and the prognosis. The GYR data can be provided to the vehicle operator, for example, by signaling it to the vehicle 102 and / or a mobile network device, as proactive alarms. Memory 924 stores the integrated model 130 and the data 132.

[0081] The 906 maintenance tool includes a 940 control module, a 942 transmitter / receiver, a 944 user interface, and a 946 memory. The 940 control module contains the 148 maintenance module and a 950 POG module. The 950 POG module can generate POG decisions and historical data, such as HMPC and HLPC data. The POG decisions can include LPCs and can provide confidence levels for the MPC and LPC decisions made.

[0082] Maintenance module 148 can integrate POG decisions, vehicle data, and technician and customer reports, and generate MPC and LPC data (or decisions). This can be done using the integrated model. The MPC and LPC decisions can be provided back to the service office for continued customization of the integrated model. Memory 146 stores the integrated model 130 and the data 150.

[0083] Fig. Figure 10 shows a third exemplary architecture (or third system) 1000, which includes the integration of current vehicle data at the service tool and the integration of POG problem cause indication data at a vehicle. The third system 1000 includes a vehicle 1002, the customer service office 104, and the service tool 106. The vehicle 1002 includes a BCM 1010, a transmitter / receiver 1012, a memory 1014, and the vehicle systems 1016. The BCM 1010 includes the functional status module 118 and may further include a diagnostic and prognostic module 1030, a GYR module 1032, and a POG module 1034. The diagnostic and prognostic module 1030, the GYR module 1032 and the POG module 1034 can be used similarly to the diagnostic and prognostic module 830, the GYR module 832 and the POG module 834 according to Fig. 8. The diagnostic and predictive module 830 can provide diagnostic and predictive information based on data collected by the vehicle, including the status of the vehicle's systems, modules, devices, and components. In one embodiment, the diagnostic and predictive module 1030, the GYR module 1032, and the POG module 1034 are implemented using an edge computing device, which may be located on board the vehicle 102 or included in a network device between the vehicle 1002 and the service office 104. The POG module 1034 provides the POG decisions to the maintenance module 148 of the maintenance tool 106.

[0084] The customer service office 104 contains one or more servers 120, the transmitter / receiver 122, and the memory 124. The servers 120 contain the control module 126 with the model module 128 and train and update the integrated model 130 as described above. The memory 124 stores the integrated model 130 and the data 132. The maintenance tool 106 contains the control module 140, the transmitter / receiver 142, the user interface 144, and the memory 146. The control module 140 contains the maintenance module 148. The maintenance module 148 can receive the POG decision from the POG module 1034 and the edge computing device instead of receiving it from the customer service office 104. The memory 146 stores the integrated model 130 and the data 150.

[0085] Fig.Figure 11 shows a fourth exemplary architecture (or fourth system) 1100, which includes the integration of current vehicle data and POG problem cause indication data on a vehicle. The fourth system 1100 includes a vehicle 1102, the customer service office 104, and the maintenance tool 106. The vehicle 1102 includes a BCM 1110, a transmitter / receiver 1112, a memory 1114, and the vehicle systems 1116. The BCM 1110 includes the functional status module 118 and may further include a diagnostic and prognostic module 1030, a GYR module 1032, and a POG module 1034. The BCM 1110 may also include an integration module 1136. The integration module 1036 can integrate the POG decisions, such as the LPC decisions, with other vehicle data, such as... B. integrate the current MPC and LPC data. The other vehicle data can include HMPC and HLPC data.

[0086] In one embodiment, the diagnostic and predictive module 1030, the GYR module 1032, the POG module 1034, and the integration module 1136 are implemented using an edge computing device, which may be located on board the vehicle 102 or included in a network device between the vehicle 1102 and the service office 104. The integration module 1136 provides the combined POG decisions and other vehicle data to the maintenance module 148 of the maintenance tool 106.

[0087] The customer service office 104 contains one or more servers 120, the transmitter / receiver 122, and the memory 124. The servers 120 contain the control module 126 with the model module 128 and train and update the integrated model 130 as described above. The memory 124 stores the integrated model 130 and the data 132. The maintenance tool 106 contains the control module 140, the transmitter / receiver 142, the user interface 144, and the memory 146. The control module 140 contains the maintenance module 148. The maintenance module 148 can receive the combined POG decisions and other vehicle data from the integration module 1136 and the edge computing device.Maintenance module 148 integrates the verbatim reports / reports from technicians and customers (or vehicle operators) and onboard integration results received from vehicle 1102, and, based on this integration, provides an LPC decision that can be displayed on a maintenance tool screen. Memory 146 stores the integrated model 130 and data 150.

[0088] The examples described above include architectures for implementing LPC decision generation. This is achieved through the vehicle's onboard and service center data collection, diagnostics, and prognosis; POG decision generation; and information integration within the vehicle, service tool, and / or service center. Several architectural variations are provided for implementing LPC decision generation. In one embodiment, the vehicle's onboard data collection and the generation of POG decisions in the service center are based on the diagnostic and prognostic results. The integration of service tool information is based on the POG decisions, vehicle data, and technician and customer reports.

[0089] In another embodiment, the vehicle's onboard data collection and the updating of the service office database for diagnostic and prognostic results are performed. POG decision generation is provided based on the diagnostic and prognostic (D and P) results. The D and P results are used for POG decisions in a maintenance tool. The POG decisions, vehicle data, and technician and customer reports are integrated.

[0090] In a further embodiment, the vehicle's onboard POG decisions are generated based on the vehicle's onboard D and P decisions. The maintenance tool integration of the POG decisions, vehicle data, and technician and customer reports is implemented in the maintenance tool. In another embodiment, the vehicle's onboard POG decisions are generated based on the vehicle's onboard D and P decisions. The vehicle's onboard information integration is performed and includes the integration of the POG decisions and the vehicle data. The maintenance tool information integration includes the integration of the vehicle's onboard results and the technician and customer reports. Different maintenance information integrations are described for the various variants.

[0091] In this application, including the definitions below, the term "module" or "controller" may be replaced by the term "circuit". The term "module" may refer to, be part of, or include: an application-specific integrated circuit (ASIC); a digital, analog, or mixed analog / digital discrete circuit; a digital, analog, or mixed analog / digital integrated circuit; a combinational logic circuit; a field-programmable gate array (FPGA); a processor circuit (shared, dedicated, or grouped) that executes code; a memory circuit (shared, dedicated, or grouped) that stores the code executed by the processor circuit; other suitable hardware components that provide the described functionality; or a combination of some or all of the above, such as in a system-on-a-chip.

[0092] The module may contain one or more interface circuits. In some examples, the interface circuits may include wired or wireless interfaces connected to a local area network (LAN), the internet, a wide area network (WAN), or combinations thereof. The functionality of any given module of this disclosure may be distributed among several modules connected via interface circuits. For example, multiple modules may enable load balancing. In another example, a server module (also known as a remote or cloud module) may perform some functionality on behalf of a client module.

[0093] The term "code," as used above, can include software, firmware, and / or microcode, and can refer to programs, routines, functions, classes, data structures, and / or objects. The term "shared processor circuit" refers to a single processor circuit that executes some or all of the code from multiple modules. The term "group processor circuit" refers to a processor circuit that, in combination with additional processor circuits, executes some or all of the code from one or more modules. References to multiple processor circuits include multiple processor circuits on discrete dies, multiple processor circuits on a single die, multiple cores of a single processor circuit, multiple threads of a single processor circuit, or a combination of the above.The term shared memory circuit refers to a single memory circuit that stores some or all of the code from multiple modules. The term group memory circuit refers to a memory circuit that, in combination with additional memory, stores some or all of the code from one or more modules.

[0094] The term memory circuit is a subset of the term computer-readable medium. The term computer-readable medium, as used here, does not include transitory electrical or electromagnetic signals that propagate through a medium (such as on a carrier wave); the term computer-readable medium can therefore be considered tangible and non-transient. Non-restrictive examples of a non-transient, tangible computer-readable medium are non-volatile memory circuits (such as a flash memory circuit, an erasable programmable read-only memory circuit, or a mask read-only memory circuit), volatile memory circuits (such as a static read / write memory circuit or a dynamic read / write memory circuit), magnetic storage media (such as analog or digital magnetic tape or a hard disk drive), and optical storage media (such as...a CD, a DVD or a Blu-ray Disc).

[0095] The devices and procedures described in this application may be partially or fully implemented by a specialized computer created by configuring a general-purpose computer to perform one or more specific functions embodied in computer programs. The functional blocks, flowchart components, and other elements described above serve as software specifications that can be translated into computer programs through the routine work of a trained technician or programmer.

[0096] The computer programs contain processor-executable instructions stored on at least one non-transient, tangible, computer-readable medium. The computer programs may also contain or rely on stored data. The computer programs may include a basic input / output system (BIOS) that interacts with the hardware of the specialized computer, device drivers that interact with specific devices of the specialized computer, one or more operating systems, user applications, background services, background applications, and so on.

[0097] The computer programs may contain: (i) descriptive text to be parsed, such as... B. HTML (Hypertext Markup Language), XML (Extensible Markup Language), or JSON (JavaScript Object Name), (ii) assembly code, (iii) object code generated from source code by a compiler, (iv) source code for execution by an interpreter, (v) source code for compilation and execution by a just-in-time compiler, etc. For illustrative purposes only, the source code may be written using the syntax of languages ​​including C, C++, C#, Objective-C, Swift, Haskell, Go, SQL, R, Lisp, Java®, Fortran, Perl, Pascal, Curl, OCaml, Javascript®, HTML5 (Hypertext Markup Language, 5th Revision), Ada, ASP (Active Server Pages), PHP (PHP: Hypertext Preprocessor), Scala, Eiffel, Smalltalk, Erlang, Ruby, Flash®, Visual Basic®, Lua, MATLAB, SIMULINK, and Python®.

Claims

[1] First network device comprising: a transmitter / receiver (142) configured to receive an integrated model (130) from a second network device, the second network device being separate from the first network device; a memory (146) configured to store the integrated model (130), diagnostic problem code data, most probable cause data, and least probable cause data, wherein the diagnostic problem code data, the most probable cause data, and the least probable cause data contain corresponding information about the cause of a problem in a vehicle (102); and a control module (140) that is configured to execute the integrated model (130), and which during the execution of the integrated model (130) compares the information on the cause of the problem, which corresponds to the diagnostic problem code data, the most likely cause data, and the least likely cause data, to determine whether the information on the cause of the problem is consistent, so that the same cause of the problem is indicated. in response to the fact that the information regarding the cause of the problem is consistent, indicating the same cause of the problem, and In response to the fact that the information regarding the cause of the problem is inconsistent, and based on a set of conditions, it displays a selective section of functional state-related information while omitting to display another selective section of functional state-related information, the set of conditions includes whether: a component has failed a non-empty set of data of the most probable cause is available and a non-empty set of data of the least probable cause is available, the data of the most probable cause and the data of the least probable cause are consistent with at least one of the technician observations or verbatim technician reports, or Historical data for the most likely cause and historical data for the least likely cause are available. [2] First network device according to claim 1, wherein the integrated model (130) is at least one of a heuristic model (130) or a machine learning model (130). [3] First network device according to claim 1, wherein the control module (140) is configured as follows: to determine whether a component has failed; in response to the finding that the component has not failed, to determine whether to display historical data or to refrain from displaying a vehicle operating status report (102); and in response to the determination that the component has failed, to determine whether to display selective functional state-related information or to refrain from displaying a vehicle functional state report (102). [4] First network device according to claim 1, wherein the control module (140) is configured as follows: to determine whether a non-empty set of most probable cause data and a non-empty set of least probable cause data are available; In response to the finding that an empty set of most probable cause data and an empty set of least probable cause data are available, to refrain from displaying a functional status report; and In response to determining that a non-empty set of most probable cause data and a non-empty set of least probable cause data are available, display the most probable cause data and the least probable cause data. [5] First network device according to claim 1, wherein the control module (140) is configured as follows: to determine whether the most probable cause data and the least probable cause data are consistent with at least one of the technician observations or verbatim technician reports; in response to the determination that the most probable cause data and the least probable cause data are consistent with at least one of the technician observations or verbatim technician reports, to display the most probable cause data and the least probable cause data; and In response to the finding that the most probable cause data and the least probable cause data are inconsistent with at least one of the technician observations or verbatim technician reports, display the most probable cause data, the least probable cause data, and other functional state-related data. [6] First network device according to claim 1, wherein the control module (140) is configured as follows: to determine whether historical data for the most probable cause and historical data for the least probable cause are available; In response to the lack of historical most probable cause and historical least probable cause data, to refrain from displaying a functional status report; and In response to the availability of historical data for the most likely cause and historical data for the least likely cause, to determine whether the historical data for the most likely cause and / or the historical data for the least likely cause are consistent with verbatim customer reports or whether no verbatim customer reports are available. [7] First network device according to claim 1, wherein the functional state-related information includes the most probable cause data, the least probable cause data, trend data, system schema data and a recommendation for repair. [8] System that includes: the first network device according to claim 1; and the second network device, which includes: a second transmitter / receiver (122) configured to receive the diagnostic problem code data, the most likely cause data, and the least likely cause data from the first network device, a second memory (124) configured to store, for a vehicle program, the integrated model (130), the effective fault mode analysis data, the diagnostic problem code data, the most probable cause data, the least likely cause data, the verbatim data of the vehicle operator and repair actions, and a second control module (126) that is configured, to train and / or update the integrated model (130) based on the effective fault mode analysis data, the diagnostic problem code data, the most probable cause data, the least likely cause data, the verbatim vehicle operator data, and the repair actions, and Following at least one of the training or updating of the integrated model (130), the integrated model (130) is transmitted via the second transmitter / receiver to the first network device.

Images