Patent Application
20230419743
Not Applicable
Not Applicable
The present disclosure relates generally to automotive diagnostics, and more specifically, to automotive diagnostics which utilize known vehicle communication architecture(s) to facilitate identification of a possible fault on the vehicle.
As a result of increased air pollution in large cities, many vehicles have utilized on-board computers to facilitate operation of electrical emission control devices since the early 1980s. However, as vehicle manufacturers have been required to comply with new emission and fuel efficiency standards, customers have also developed a desire for advanced technological features. As such, the on-board computer has evolved to accommodate these advancements.
For instance, many current on-board computer control systems are capable of providing control over many different vehicle functions and systems, such as the transmission, anti-lock brakes, electronic skid control, climate control, air bags, electric power steering, tire pressure monitoring, automatic headlights controls, keyless entry, telematics, body controls and suspension systems. Many current on-board computers include diagnostic programs to monitor input sensors, switches, actuators and facilitate communication between on-board electrical systems. Since vehicle operating conditions may quickly change, the on-board computers may continuously monitor, adjust or makes corrections with the goal of maintaining system operation within acceptable operational ranges.
Due to the increased responsibilities of the on-board computers, it became apparent that traditional hard-wired electrical systems were too heavy, bulky and expensive. Consequently, on-board computer networks were adopted, with the computer networks being capable of passing data back and forth between each other. The enhanced capabilities of on-board computer networks allowed for additional control functionalities, such as operation of exterior and interior lighting, door locks, power windows, heating and air conditioning, etc.
The on-board computers included in the computer networks are typically located throughout the vehicle, such as behind the dashboard, under the passenger's seat or the driver's seat, behind the knee and kick panels, and or at other locations that may be difficult to access. Wherever these computers are located, they may be connected to each other in some fundamental network layout and communication protocols. The incorporation of computer networks into the vehicle typically resulted in a reduction of wires, thereby reducing the complexity of the wiring commonly required to share data between the on-board computers and the vehicle's sensors and actuators. However, the interconnectedness of the computer networks resulted in an emphasis on the need for networks to remain healthy and capable of passing mission-critical data between vehicle systems. Accordingly, the diagnosis of the physical and data link layers of network communication is typically performed with expensive and complicated oscilloscopes or OEM-level scan tools. Attempting to diagnose network communication faults may be dependent on all ECUs (e.g., on board computers) being capable of detecting an issue and recording a fault code prior to being rendered unable to communicate.
While on-board computer networks vary from vehicle to vehicle, many on-board computer networks diagnose themselves in similar manners. For instance, each on-board computer may be assigned a diagnostic trouble code (DTC) set related to network DTCs, and each on-board computer may monitor communications that may occur over the network. The on-board computer may share these DTCs with querying scan tools requesting network health information. The retrieved DTCs may be displayed for the operator, although network diagnostic solutions are typically not provided. In fact, many of these tools require the user to have in-depth technical knowledge to sort through the DTCs, service information and diagnostic troubleshooting charts to arrive at a diagnostic solution. As noted above, the ability to sort through such information typically requires the end-user to be well-versed in the use the scan tool.
Therefore, there is a need in the art to be able to determine a vehicle onboard computer's operational state by interrogating, querying, parsing and classifying on-board computer network DTCs. By performing predefined programmatic calculations based off the retrieved data, a reasonable and logical diagnostic strategy and fault origin may be identified. Thus, the need for an end-user possessing vehicle on-board network fault diagnostic expertise may be vastly reduced. Furthermore, the need for multiple scan tools capable of providing level of OEM network diagnostics may be lessened. Various aspects of the present disclosure address this particular need, as will be discussed in more detail below.
In accordance with one embodiment of the present disclosure, there is provided a vehicle diagnostic method based on an analysis of communication signals on a vehicle having a plurality of electronic control units (ECUs). The vehicle diagnostic method includes transmitting an ECU status request signal to the vehicle and receiving a status response signal from the vehicle. The status response signal includes a plurality of ECUs on the vehicle that are responsive to the transmitted ECU status request signal. A state of health report is generated and includes a comprehensive listing of all ECUs associated with the vehicle. Each ECU in the state of health report responsive to the transmitted ECU status request signal is associated with an active status, while the remaining ECUs in the state of health report being associated with an inactive status. The method additionally includes receiving communication DTCs from the vehicle, with each communication DTC being associated with at least one ECU. Identifying a primary probable cause ECU as being one of the ECUs associated a received communication DTC that is also associated with an inactive status.
The method may additionally include receiving historical DTCs from the vehicle. A secondary probable may be determined based on an analysis of the historical DTCs.
The method may additionally include generating the state of health report includes organizing all of the ECUs according to associated communication networks on the vehicle. The associated communication networks may include a powertrain network, a body network, a chassis network, and a multi-media network.
The step of receiving communication DTCs may include receiving a message error DTC, a time-out DTC and a bus-off DTC. The step of identifying a primary probable cause may include identifying a communication network or an ECU associated with a highest number of received communication DTCs.
The method may include receiving non-communication DTCs and filtering the received communication DTCs from the non-communication DTCs.
The method may also comprise requesting data associated with the probable cause.
According to another embodiment, there is provided a handheld automotive diagnostic device comprising a memory circuit having computer executable instructions stored thereon, which when executed, cause the diagnostic device to: send a status request signal to a vehicle network including a plurality of on-board computers and having a known communication architecture; receive a response signal from the vehicle network, the response signal including response information from active ones of the plurality of on-board computers; identify inactive ones of the plurality of on-board computers by comparing the active ones of the plurality of on-board computers to a comprehensive listing of the plurality of on-board computers; classify each of the plurality of on-board computers into one of a plurality of network groups, the plurality of network groups being arranged on the vehicle network to at least partially define the known communication architecture; receive fault codes from the plurality of on-board computers; categorize a network status of each fault code as being either a network type fault code or a non-network type fault code based on an origin of the fault code; and identify a probable cause based on an assessment of the network status, and the known communication architecture.
According to another embodiment, there is provided a vehicle diagnostic method based on an analysis of communication signals on a vehicle having a plurality of electronic control units (ECUs). The vehicle diagnostic method includes transmitting an ECU status request signal to the vehicle and receiving a status response signal from the vehicle. The status response signal includes a first group of ECUs on the vehicle that have responded to the transmitted ECU status request signal. The method additionally includes receiving communication DTCs from the vehicle, with the communication DTCs being associated with a second group of ECUs. A primary probable cause ECU is identified by comparing the second group of ECUs to the first group of ECUs, the primary probable cause ECU being included in the second group of ECUs and not in the first group of ECUs.
The method may additionally include the steps of receiving historical DTCs from the vehicle, and determining a secondary probable cause based on an analysis of the historical DTCs.
The present disclosure will be best understood by reference to the following detailed description when read in conjunction with the accompanying drawings.
These and other features and advantages of the various embodiments disclosed herein will be better understood with respect to the following description and drawings, in which:
Common reference numerals are used throughout the drawings and the detailed description to indicate the same elements.
The detailed description set forth below in connection with the appended drawings is intended as a description of certain embodiments of a vehicle diagnostic system and method and is not intended to represent the only forms that may be developed or utilized. The description sets forth the various structure and/or functions in connection with the illustrated embodiments, but it is to be understood, however, that the same or equivalent structure and/or functions may be accomplished by different embodiments that are also intended to be encompassed within the scope of the present disclosure. It is further understood that the use of relational terms such as first and second, and the like are used solely to distinguish one entity from another without necessarily requiring or implying any actual such relationship or order between such entities.
Various aspects of the present disclosure generally relate to the analysis of communication signals on the various vehicle communication networks included on a vehicle under test to try and identify a possible cause of an issue on the vehicle. In this regard, diagnostic data received from the vehicle may be analyzed in the context of the known electrical architecture of the vehicle to try and pinpoint where a root fault or problem may be occurring. When data is received from the vehicle, the data may reflect several different issues, such as network level faults, component level faults, time-out errors, etc. In some instances, there may be interaction between various systems or components, and thus, if one component or system has an issue, there may be a trickle-down effect on the downstream components or systems. In this regard, otherwise healthy components or systems may be associated with error codes or messages due to issues occurring in upstream or related components/systems.
Referring now to
According to various aspects of the present disclosure, the method entails requesting diagnostic data from a vehicle network using a data acquisition and transfer device (DAT) 10. The DAT 10 may refer to any device capable of communicating with a vehicle network, either directly or indirectly (e.g., such as through a diagnostic port). The DAT 10 may include, but is not limited to a scan tool, a code reader, a dongle, a handheld communication device, or other hardware known by those skilled in the art. The DAT 10 may include a connector port (e.g., an OBD-2 connector port) that is configured to be operatively connectable, through wired or wireless communication, to a corresponding communication port on the vehicle. The DAT 10 may additionally include a processor and a memory with computer executable instructions stored thereon, that when executed by the processor facilitate the various functionalities described herein. For more information regarding the DAT 10, please refer to U.S. Pat. No. 9,824,507, entitled MOBILE DEVICE BASED VEHICLE DIAGNOSTIC SYSTEM, and U.S. Pat. No. 11,158,141, entitled SYSTEM AND METHOD FOR PROACTIVE VEHICLE DIAGNOSIS AND OPERATIONAL ALERT, both of which are owned by Innova Electronics Corp., the assignee of the present disclosure, and the contents of which are expressly incorporated herein by reference. Furthermore, examples of a DAT 10 include, but are not limited to, the 5510 CarScan Tech, the 7111 Smart Diagnostic System—OBD2 Tablet, and the 1000 CarScan Mobile, all sold by Innova Electronics Corp.
An ECU status request signal may be generated by the DAT 10 and transmitted to the vehicle network via the diagnostic port on the vehicle once the DAT 10 is operatively connected to the vehicle. The ECU status request signal may include instructions or commands executable by the vehicle to collect information regarding the status of active or responsive on-board computers (e.g., ECUs) included in the vehicle network. Subsequently, a status response signal may be received by the DAT 10 from the vehicle network, with the response signal including response information from active on-board computers. The on-board computers included in the status response signal may be referred to as a first group of on-board computers In this regard, any on-board computer that may be inactive for any reason may send no response signal due to their inactive status.
The data received from the vehicle may be used to compile, derive, or construct a network state-of-health, which may identify all on-board computers as having either an active status or an inactive status. The active computers may be identified using the response signal received from the vehicle. The inactive computers may be identified using a comprehensive list of all on-board computers associated with the vehicle under test and comparing that list with a list of active computers. The comprehensive list may be obtained using vehicle identification information (e.g., year, make, model, engine; vehicle identification number; etc.) that may be retrieved from the vehicle, such as an electronic vehicle identification number (VIN), acquired by the user, such as scanning a barcode on the vehicle associated with the vehicle's VIN or taking a picture of the VIN or license plate which may be used to derive vehicle identification information. It is also contemplated that the vehicle identification information may be entered by the user into a user interface on the DAT 10 or via a kiosk 12 associated with the DAT 10 or via a smartphone or other handheld communication device 14 in communication with the DAT 10 or one or more remote servers 16 having access to software and/or data needed to implement the functionalities described herein. For more information regarding the use of a kiosk 12 or handheld communication device 14 in connection with a vehicle diagnostic process, please refer to U.S. Patent Application Publication No. 2021/0279978 entitled KIOSK BASED VEHICLE DIAGNOSTIC SYSTEM, owned by Innova Electronics Corporation, the contents of which are expressly incorporated herein by reference. The vehicle identification information may be used to access a database having comprehensive lists sorted by vehicle identification information to identify the comprehensive list associated with the vehicle under test. In this regard, the database may be located on the DAT 10, on a handheld communication device in communication with the DAT 10, or on a remote server in communication with the DAT 10. It is also contemplated that the vehicle may supply the comprehensive list.
Those on-board computers that are on the comprehensive list, but not on the list of active computers may be considered the inactive on-board computers. Properties, such as function and location of each on-board computer may be known, and thus, both the active and inactive computers may be sorted into their respective network groups in a state-of-health report. The state-of-health report may serve as a reference point for subsequent data queries.
Looking in more detail again at
Looking in more detail now at
Looking in more detail now at
The Chassis ECUs that responded include a combination of some ECUs with no reported DTCs, while other ECUs responded with 1 DTC. The CGW ECU appears again in the same manner as the Powertrain portion of the state-of-health, due to the CGW also being associated with the Chassis network.
Looking in more detail now at
Once the state-of-health report is generated, fault codes may be retrieved from the vehicle using the DAT 10. The received fault codes may be sorted or categorized based on the origin (e.g., location) of each fault code as well as the time when each fault code was triggered. With regard to origin, each fault code may be categorized as being either a network type fault code or a non-network type fault code. With regard to timing, each fault code may be classified as being either active, pending, or historical. For purposes of further analysis in the diagnostic method and system disclosed herein, it is the active network type fault codes that may be of particular interest, and thus, those fault codes may be filtered or separated from the rest. Moreover, the active fault codes may be further classified or categorized into one of the following groups: Message Error, Time-Out, or Bus-Off. Each received active fault code may be associated with an on-board computer, with the group of on-board computers associated with the received active fault codes being referred to as a second group of on-board computers.
The Message Error group may include fault codes recorded when one ECU receives a response from another ECU, with the data in the received response being invalid or corrupt. The Time-Out group may include fault codes recorded when an ECU did not receive a response from another ECU. The Bus-Off group may include fault codes that have been recorded when an ECU no longer can maintain communication and stops sending and receiving messages.
After having received the DTCs associated with the Powertrain network, the Powertrain state-of-health may be referenced review the DTC status for those Powertrain ECUs. This comparison reveals that all of the Powertrain ECUs that received Time-Out DTCs were also listed in the State of Health as being non-responsive. Thus, it can be concluded that these ECUs are indeed located on the vehicle based on those ECUs being associated with specific Time-Out DTCs received by the DAT. However, each of those DTCs is associated with one or more underlying issues. Given that many of the Powertrain ECUs were associated with a Time-Out DTC, it is indicative of a possible problem associated with the Powertrain network being inoperative.
According to one embodiment, a primary probable cause may be found by using an algorithm that queries probability based off frequency of faults, the number of faults, and the types of faults. The active DTCs may be initially evaluated and then historical DTCs may be evaluated. The historical DTCs may be associated with a “secondary” probable cause, which may be used to place higher probability on the primary probable cause results.
It is contemplated that the primary probable cause may be categorized by a component and/or a network.
The secondary probable cause may be found using an algorithm that queries probability based off frequency of faults, the number of faults, and the types of faults. Identifying a secondary probable cause may strengthen the primary probable cause. Consequently, historical DTC results or secondary probable causes may enhance or strengthen the probability of the primary probable cause results.
Therefore, in summary, the state-of-health query reports: P-CAN is down—no ECU responded with CGW ECU responding with 7 DTCs. B-CAN is operational—all ECUs responded with CGW ECU responding with 7 DTCs. C-CAN is operational—15 ECUs' responded, 3 down or NOT equipped, CGW with 7 DTCs. M-CAN is operational—all ECUs responded. CAN DTC message query and parsing algorithm applied, the probable cause is either the ECM is defective, and/or, the power source to the Powertrain Network is dead.
The particulars shown herein are by way of example only for purposes of illustrative discussion, and are not presented in the cause of providing what is believed to be most useful and readily understood description of the principles and conceptual aspects of the various embodiments of the present disclosure. In this regard, no attempt is made to show any more detail than is necessary for a fundamental understanding of the different features of the various embodiments, the description taken with the drawings making apparent to those skilled in the art how these may be implemented in practice.
