Patent Application
20050085964
1. Field of the Invention
The present invention relates to the general field of maintenance and more particularly to a remote diagnostic and maintenance system that uses a network such as the Internet to provide remote diagnostics and services to a plurality of wheel alignment locations or other maintenance locations.
1. Description of the Prior Art
It is known in the art of vehicle wheel alignment to attach alignment heads to vehicle wheels where these heads are in communication with a local computer that performs alignment calculations and displays alignment data on a screen to a technician. The same is known in the art of engine analysis.
In addition, it is known to allow the local computer to communicate with one or more remote computers over a network that can be a private network or the Internet. In fact, the remote computer can in some cases provide the alignment calculations rather than the local computer. In addition, the results of the alignment process can be displayed at the remote computer. An example of this in the wheel alignment art can be found in International Application WO 99/23783 where raw data from wheel alignment sensors is received on a local computer and then transmitted over a network to a remote computer which performs alignment calculations and then returns wheel alignment angles back over the network to the local computer for display to a technician.
It is also known in the art to provide a wheel alignment system or engine analyzer system with sensing devices, sensor interface circuits and a host computer in communication with the sensor interface circuits where the host computer can access other computers over the internet using generalized systems such as dot.NET (or .NET) developed by Microsoft Corporation. An example of this in the wheel alignment art is U.S. Pat. No. 6,442,460 where the host computer can access a plurality of remote software applications using dot.NET. The host computer can provide integrated internet access for transmission of electronic commerce and statistical information, alignment logs, error messages, status messages, or diagnostic information to a remote system, and for the receipt of information including updated software applications, diagnostic commands, and remote information queries.
The prior art, while allowing the communication of diagnostics and data to one or more remote computers, does not teach exactly how problems with wheel alignment systems, engine analyzers or other maintenance systems can be solved by such remote computers. What is badly needed is a system and method for using the Internet to allow a remote service location to diagnose and determine solutions to problems in such systems.
The present invention relates to a system for correcting problems in a wheel alignment system, wheel balancing system, engine analyzer system or any other maintenance system that includes at least one local computer in communication via a network with at least one remote computer. The remote computer can transmit one or more diagnostics to the local computer with the local computer returning diagnostic data from running one or more of the diagnostics. The remote computer can contain a decision algorithm that uses the diagnostic data to determine a correction for the problem and send the correction to the local computer. The system can also include a database at the remote computer where the database can contain histories of previous alignment system problems. The database can also contain service histories for particular alignment systems, engine analyzers or other maintenance systems as well as solutions to past problems. Finally the database can also contain component information for alignment systems in the field.
The system shown in
The remote computer 6 can contain a database 7 that can use a decision tree to perform the diagnosis. This database 7 can be constantly updated to reflect the results of previous cases.
In this manner, the algorithm can “learn” new problems. Of course, a static database could also be employed; however, a static database is not as powerful a dynamic one that is continually being updated with new problems and fixes.
Every maintenance system that leaves the factory can have all of its major elements entered into the database 7. In addition, the entire service history of every such system and each of its components can be recorded in the database 7 and made available to the maintenance algorithm running on the remote computer 6.
In this way, a technician at the remote computer 6 can aid a technician in the field (at the local computer 3) trying to fix a problem. A possible operating scenario is that when a user working with a maintenance system 1 experiences a problem, they can activate a remote service interface program on the local computer (which can be a PC) (the remote service interface program might self-activate upon detecting a problem).
If the local system is authorized (under warranty or service contract), the remote computer 6 or server can download the latest test sequence onto the local computer 3 and call for the local computer 3 to execute it. One of the first tasks for this test sequence would be to make sure that all of the software is up to date with the latest service packs and latest vehicle specifications. If any of those files were out of date, they could be downloaded and installed.
A second possible task could be to perform a checksum against many or all of the executable files in the system to see if there is any program corruption. The remote computer 6 could access the correct checksums for each executable from the data-base 7. Any corrupt software could be replaced (downloaded and installed).
A third possible task could be to execute various hardware test procedures on both the local computer 3 and on maintenance hardware 1 to attempt to detect errors. As an example of this, a communications board might have a loopback switch that could be software activated to test for a bad communications cable. Of course, the nature of the original problem and the decision tree algorithm would determine which hardware tests would be run and in what order.
The system and method of the present invention can be used for any type of maintenance system including maintenance systems other than those used with vehicles.
The present invention allows diagnosis and repair to take place over a network, in particular over the Internet. Once the problem is diagnosed, a text message and/or video could be displayed at the local computer that could tell the user how to fix the problem. This could include how to replace a defective component or module or certain commands that could be given to local software.
The present invention envisions different fixes in some cases for the same problem. For example, some wheel alignment manufacturers do not want technicians to open a wheel alignment head to replace a board or component. In that case, the entire head would be replaced. On the other hand, a different manufacturer might allow field replacement of boards or components. In this case, the system might direct the user to do that. The system would have these maintenance constraints stored it its database (7 in
In any case, text or video could show a user how to carefully pack a component that was being returned to the manufacturer into a shipping container. In addition, the user may be given a number to include in their packaging (such as a manufacturers RMA number). If a component is field replaceable, a video clip playing on the local computer could show how to open covers and to remove and replace the component. The videos could be pre-stored in the local computer or could be downloaded from the remote computer as needed. Any video technique could be used including known Internet techniques including Flash, AVI, REAL and others.
Field systems can be equipped with an optional video camera (18
The present invention thus provides a convenient way to perform complex field diagnosis and repair of maintenance systems remotely without the necessity of sending out a specialized technician or having the entire system returned to the factory for repair. The ability to store numerous previous problems with similar systems and specific data on the particular system being diagnosed aids the problem considerably.
It was mentioned that an algorithm at a remote computer can provide diagnosis of problems with local systems. In particular, symptoms can be standardized and can be selected from a list of complaints that the user can interactively choose from (in the case a fault was recognized by a user and not by a self-check). Symptoms can be mapped to a specific test relating to that symptom. The result of the test can either lead to another test or a failure code. Once a failure code is reached, the symptom can be deemed diagnosed. The failure code can be mapped to an action code which can be different depending on the distribution channel that the unit was sold through. This process can be repeated until all complaints (symptoms) have been resolved.
There may be results which cause the system to contact the remote service technician.
Some activities (in the diagnostic sequence) may take place regardless of what symptom code/s have been recorded. These activities are currently done first.
1. Some major subsystems include an electronic serial number. This along with the service history of the unit can be used to determine if any hardware needs to be updated. If this is the case a failure code can be logged.
2. Software can checked for necessary updates—if any are needed, a failure code can be logged and the software can be updated.
3. Software can be checked for corrupt files—if any are corrupt they can be replaced and a failure code can be logged.
4. Some subsystems have self tests that can be activated (some may have down-loadable routines while others may have built in routines). Self checks can be activated in any subsystem that has them as long, as the test requires little or no user interaction. Results can be recorded and if a fault is found then failure code can be logged.
After this is done then work can be done on the complaint generated by the end user.
For example:
1. Take first (or next) complaint code and look up corresponding test to perform.
2. Result from test is recorded. This result points to either another test or a failure code.
3. After reaching a failure code we go back to step one and repeat until all complaints have been examined.
4. All failure codes will generate action codes depending on the customer type. Action codes tell customer what to replace and how to replace it or advise customer of proper operation or advise that the problem has been taken care of by virtue of a software update.
As can be seen, the algorithm can be a simple decision tree. It is also possible to use other techniques such as using a “goal based” or “rule based” inference engine.
The present invention has been described using various illustrations and explanations. It should be noted that only example embodiments of the invention have been presented to aid in understanding. It will be recognized by one skilled in the art that many changes and variations can be made and are within the scope of the present invention.
