Patent Application
20130325203
The present disclosure generally relates to methods and systems for diagnosing a vehicle, and more particularly relates to methods and systems for diagnosing faults in a vehicle using net-motifs.
Vehicle technician tools connect to a vehicle's communication system to monitor and retrieve data from the vehicle. The technician tools are most commonly used to aid the technician in diagnosing problems of the vehicle. For example, diagnostic trouble codes can be retrieved from the vehicle's communication system through the technician tool. Due to the large variation in vehicle configurations, a technician must follow through a service diagnostic tree to retrieve the code and determine the fault. Such a method can be time consuming and error prone. In addition, intermittent faults in hardware, software, and communication links can be difficult to identify because they may not always be represented by a code.
Accordingly, it is desirable to provide improved methods and systems for monitoring a vehicle and detecting faults in the vehicle. Furthermore, other desirable features and characteristics of the present invention will become apparent from the subsequent detailed description and the appended claims, taken in conjunction with the accompanying drawings and the foregoing technical field and background.
Methods and systems are provided for monitoring a vehicle. In one embodiment, the method includes, but is not limited to, receiving traffic data from a vehicle communication bus. The method further includes, but is not limited to, identifying, by a processor, net-motifs from the traffic data. The method still further includes, but is not limited to, detecting a mode of components of the vehicle based on the net-motifs.
In another embodiment, a system for monitoring a vehicle is provided. The system includes, but is not limited to, a first module that receives traffic data from a vehicle communication bus. The system further includes, but is not limited to, a second module that identifies net-motifs from the traffic data. The system still further includes, but is not limited to, a third module that detects a mode of components of the vehicle based on the net-motifs.
The present invention will hereinafter be described in conjunction with the following figures, wherein like numerals denote like elements, and:
The following detailed description is merely exemplary in nature and is not intended to limit the invention or the application and uses of the invention. Furthermore, there is no intention to be bound by any expressed or implied theory presented in the preceding technical field, background, brief summary or the following detailed description. It should be understood that throughout the drawings, corresponding reference numerals indicate like or corresponding parts and features. As used herein, the term module refers to any hardware, firmware, electronic control component, processing logic, and/or processor device, individually or in any combination, including without limitation: application specific integrated circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) and memory that executes one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality.
Referring now to
In
The vehicle 14 includes one or more control modules 18-26 that are communicatively coupled via a vehicle communication bus 28. The control modules 18-26 process signals from one or more components (not shown) of the vehicle 14 and/or control one or more components (not shown) of the vehicle 14 (e.g., an engine control module, a transmission control module, a body control module, etc.). The control modules 18-26 communicate messages on the vehicle communication bus 28 based on the processing and/or controlling. The vehicle communication bus 28 may include one or more networks such as a Controller Area Network (CAN) bus, a FlexCAN bus, a Local Interconnect Network (LIN) bus, a GMLAN bus, and/or a FlexRay bus. However, other networks besides those commonly found in automotive environments may also be used.
The computing device 12 can be any computing device including, but not limited to, a laptop computer (as shown), a handheld device (such as a technician tool), a desktop computer, a workstation, or any other device that includes a data storage device and a processor. The processor can be, for example, any custom made or commercially available processor, a central processing unit, an auxiliary processor among several processors associated with the computer, a semiconductor based microprocessor, a macroprocessor, or generally any device for executing instructions. The data storage device can be, for example, at least one of the random access memory, read only memory, a cash, a stack, or the like which may temporarily or permanently store electronic data. As can be appreciated, the computing device 12, in various embodiments, can be a single computing device (as shown) or a combination of computing devices that communicate data using one or more defined communication protocols.
The computing device 12 includes a monitoring module 30 in accordance with exemplary embodiments. The monitoring module 30 processes traffic data on the vehicle communication bus 28 to differentiate failure modes within the vehicle 14. The monitoring module 30 processes the traffic data by establishing traffic patterns and evaluating the traffic patterns to determine a particular failure mode. The failure mode may be due to a software failure (i.e., failure of the software logic in a control module 18-26), or a hardware failure such as a wiring failure (i.e., faulty wires (not shown) connected to the control modules 18-26 and/or the vehicle communication bus 28), or a connector failure (i.e., faulty connectors (not shown) between the wires and the control modules 18-26 and/or the vehicle communication bus 28). The monitoring module 30 then presents the failure mode and other failure information to a service technician or product developer through a graphical or textual user interface.
In
Referring now to
The data collection module 40 receives as input traffic data 52 from the vehicle communication bus 28. The traffic data 52 includes messages that have been communicated between the control modules 18-26 and/or information about the communication of messages between the control modules 18-26 on the vehicle communication bus 28. As can be appreciated, depending on the implementation of the monitoring module 30 (e.g., on the computing device 12 associated with the vehicle 14, or as a module of the vehicle 14) the traffic data 52 can be received based on a request initiated by the data collection module 30 and/or based on a scheduled event to retrieve the traffic data 52 from the vehicle communication bus 28. The data collection module 40 may optionally format and/or store the traffic data 52 for further processing.
The message network constructor module 42 receives as input the stored/formatted traffic data 54. The message network constructor module 42 constructs a message network 56 from the traffic data 54. As shown in
When constructing the message network 56, the message network constructor module 42 evaluates each message (M1-M5), constructs a direct mapping 55 of the messages (M1-M5) between control modules 18-26 and then from the direct mapping 55, constructs the message network 56. As can be appreciated, the message network constructor module 42 may construct the message network 56 using various network construction methods. In one exemplary embodiment, the following method may be used to construct the direct mapping 55 and the message network 56:
The net-motif identification module 44 receives as input the message network 56. Based on the message network 56, the net-motif identification module 58 identifies net-motifs 58. As shown in
The motif distribution determination module 46 receives as input the net-motifs 58. Based on the net-motifs 58, the motif distribution determination module 46 computes motif distributions vectors 60. For example, a motif distribution vector 60 can be computed for each net-motif 48 by counting the number of occurrences of that net-motif 48 and normalizing by the total number of occurrences. The motif distribution vectors 60 represent the probability that the net-motif is present in the message network 56.
The fault mode detection module 48 receives as input the motif distribution vectors 60 and topological data 62. The topological data 62 includes information on the topology of the vehicle 14. The fault mode detection module 48 detects and reports a particular fault mode 64 or a normal mode 66 by comparing the determined motif distribution vectors 60 with other motif distribution vectors. The other motif distribution vectors may be motif distribution vectors that represent known failure modes or distribution vectors that represent known normal modes. The other motif distribution vectors may be predetermined by performing the same methods as discussed above on known faulty systems or known normal systems and stored in the motif distribution vector datastore 50 for the comparison. The fault mode 64 and the normal mode 66 can then be used to generate the reporting signals. The fault mode detection module 48 may associate the particular fault mode 64 or normal mode 66 with a particular component (e.g., hardware or software) of the vehicle based on the topological data 62.
Referring now to
In one example, the method may begin at 100. The traffic data 52 is received and stored at 110. The message network 56 is constructed by evaluating the stored traffic data 54 at 120, for example, using the methods described above. The net-motifs 58 are identified at 130, for example, using the methods described above. The motif distribution vectors 60 are computed at 140 and compared with predetermined motif distribution vectors at 150. If the motif distribution vector 60 is the same as or similar to a predetermined motif distribution that represents a fault at 150, then the fault mode 64 is reported by generating a warning signal and/or a fault message that is presented graphically and/or textually at 160. Using the topological data 62, the fault message includes an indication of whether the fault is associated with software, communication, or hardware. Thereafter, the method may end at 190.
If, however, the motif distribution vector 60 does not match a predetermined motif distribution that represents a fault at 150, rather the motif distribution vector 60 is the same or similar to a predetermined motif distribution that represents normal operation at 170, the normal operation mode 66 is reported at 180, similar to step 160. Thereafter, the method may end at 190.
While at least one exemplary embodiment has been presented in the foregoing detailed description, it should be appreciated that a vast number of variations exist. It should also be appreciated that the exemplary embodiment or exemplary embodiments are only examples, and are not intended to limit the scope, applicability, or configuration of the invention in any way. Rather, the foregoing detailed description will provide those skilled in the art with a convenient road map for implementing the exemplary embodiment or exemplary embodiments. It should be understood that various changes can be made in the function and arrangement of elements without departing from the scope of the invention as set forth in the appended claims and the legal equivalents thereof.
