Data processing: vehicles – navigation – and relative location – Vehicle control – guidance – operation – or indication – Vehicle diagnosis or maintenance indication
Reexamination Certificate
2002-05-31
2004-03-02
Marc-Coleman, Marthe Y. (Department: 3661)
Data processing: vehicles, navigation, and relative location
Vehicle control, guidance, operation, or indication
Vehicle diagnosis or maintenance indication
C701S029000, C701S032000, C340S939000
Reexamination Certificate
active
06701233
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates generally to the field of electronic testing devices, and more specifically to an improved “off-board device,” such as an OBD II scan tool, having dropped communications detection and recovery and further having improved protocol selection.
BACKGROUND OF THE INVENTION
“Off-board devices,” such as scan tools, are known in the art and are testing devices that interface with vehicle diagnostic systems to access, display, and/or print vehicle diagnostic information. OBD II (On-Board Diagnostics version II) Scan Tools are one commonly known type of scan tool and are governed by a number of standards, e.g., SAE J1978 Rev. 1988-02 and SAE J1979 Rev. 1997-09.
There are a number of problems with the existing scan tools and scan tool specifications. For example, in certain vehicles, e.g., various model years of HYUNDAI, VW, DODGE, and VOLVO vehicles, the known scan tools have communications drop-outs. One minute the user will be using a scan tool and be examining e.g., 28 different parameters, and the next instant there is no response for all but e.g., three, of the parameters. What the user does not know is that one or more controllers, e.g., the engine controller, which is typically the main ODB II controller, has dropped out, leaving only a secondary controller, e.g., a transmission controller, talking with the scan tool. The known scan tools must begin the entire session over again, which can take half a minute or more and must be prompted by the user. As another example, sometimes following the specifications for determining the proper protocol does not result in using the protocol that provides the most relevant information (e.g., the most emissions information). Following the specifications, a scan tool might select a protocol that ends up with far less emissions data than another protocol.
More specifically, protocol determination is automatic (hands off) determination of which communication protocol the vehicle is using for the OBD II functions. Some vehicles have multiple modules and these modules may use different communication protocols. But only one of these protocols contains all the OBD II information for the vehicle. Therefore, the scan tool must be able to determine which protocol is the correct one to use for OBD II purposes. This automatic determination is specified in a SAE J1978. Furthermore in section 6.4.1 and 6.4.2 the SAE has spelled out a procedure for trying the four (4) protocols and determining which one is the OBD II protocol supported by the vehicle to relate the appropriate functions. In section 6.4.1 the specification spells out that only one protocol is allowed to be used in any one vehicle to access all the supported OBD II functions. This does not mean than a vehicle cannot support more that one protocol, but that only one may be used as the OBD II link. The SAE has published a suggested method for determining the OBD II protocol in J1978 section 6.4.2.
Through on-vehicle testing the inventors of the present invention discovered that this recommended way has flaws: one ends up selecting the wrong protocol as the OBD II link. Therefore a scan tool following the recommendation is unable to determine the correct protocol and therefore unable to use all the covered OBD II functions and read all the available information from the vehicle. One of the vehicles in question, for example, is one that supports both ISO 9141-2 (ISO) and ISO 14230-4 (Keyword 2000). The engine control module uses ISO 14230-4 as its protocol and the transaxle control module uses ISO 9141-2. The engine controller is the module that supports the OBD II functions for the vehicle. But the SAE suggested procedure directs that one test for ISO 9141-2 first and if one receives a reply, then that was the protocol to use for the link. It is the same with ISO 14230-4, if it replies. This causes the scan tool to incorrectly choose the protocol being used by the transaxle as the OBD II protocol for this type of vehicle rather than the protocol being used by the engine controller. Now that the scan tool is using the wrong protocol, ISO 9141-4, it is only talking to the transaxle controller. The engine controller (and all the emissions information it has to offer) is not found. This type of problem can happen in other protocol combinations also.
Also, certain vehicles employ multiple modules that communicate using the same protocol. This type of system is subject to one or more of the modules to losing their active communication with off-board devices, like scan tools. If the scan tool does not realize that one or more of the modules has dropped the link, it will not be showing complete/correct data.
Once again during on-vehicle testing the inventors discovered that multiple module vehicles present certain problems. For example certain VW models that use an engine control module and a transaxle control module presented a problem. After determining the OBD II protocol and initializing both modules for communications, it was noticed that one or the other module would occasionally stop communicating. This problem could be seen while requesting information on several functions, such as the “View Data” function (also known as the “Live Data” function). For example, user might notice during one View Data session that two modules report the state of the Malfunction Indicator Lamp (“MIL”) and might notice on a subsequent View Data session on the same vehicle that only one module reports the MIL's state. The MIL's state from the other modules is now unknown. What happened is that, unknown to the user, one of the controllers dropped the communications link, so it did not respond to the request for the state of the MIL. These problems can result in OBD II information being misreported.
There is a need, therefore, for an improved scan tool.
SUMMARY OF THE INVENTION
The present invention is directed toward an improved “off-board device.” In one embodiment, the “off-board device” of the present invention is a scan tool. According to one aspect of the present invention, the improved scan tool uses a novel method of determining the proper protocol to use to communicate with a vehicle computer network. According to another aspect of the present invention, the improved scan tool determines and automatically recovers from a communications drop-out. The scan tool of the present invention preferably, but not necessarily, includes both the novel method of determining the proper protocol to use to communicate with a vehicle computer network and the determination and automatic recovery from a communications drop-out.
It is therefore an advantage of the present invention to provide an improved scan tool that determines the protocol that provides the most relevant vehicle information (e.g., the protocol that provides the most emissions information).
It is also an advantage of the present invention to provide an improved scan tool that determines when a module has had a communications drop-out.
It is another advantage of the present invention to provide an improved scan tool that automatically recovers from a communications drop-out.
It is a further advantage of this invention to provide an improved scan tool that automatically recovers from a communications drop-out without requiring that the protocol be re-determined.
It is yet another advantage of the present invention to provide an improved scan tool that determines when a module has had a communications drop-out and that automatically recovers from a communications drop-out.
These and other advantages of the present invention will become more apparent from a detailed description of the invention.
REFERENCES:
patent: 6526340 (2003-02-01), Reul et al.
patent: 2002/0007237 (2002-01-01), Phung et al.
patent: 2002/0070851 (2002-06-01), Raichle et al.
Bertosa Thomas J.
Gessner Michael F.
Namaky Hamid
Roberts Robert A.
Rodemann Donald J.
Actron Manufacturing Company
Calfee Halter & Griswold LLP
Marc-Coleman Marthe Y.
LandOfFree
Scan tool with dropped communications detection and recovery... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Scan tool with dropped communications detection and recovery..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Scan tool with dropped communications detection and recovery... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3225014