Data processing: vehicles – navigation – and relative location – Vehicle control – guidance – operation – or indication – Vehicle diagnosis or maintenance indication
Reexamination Certificate
1997-10-31
2003-01-28
Nguyen, Tan (Department: 3661)
Data processing: vehicles, navigation, and relative location
Vehicle control, guidance, operation, or indication
Vehicle diagnosis or maintenance indication
C701S029000, C701S035000
Reexamination Certificate
active
06512968
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to a system and method for an improved computer automotive service equipment system.
BACKGROUND OF THE INVENTION
Computerized automotive service and diagnostic equipment systems for measuring or testing various parameters and for providing maintenance or repair procedure instructions to an operator are generally known. Such systems utilize a central control processor residing within a data input computer, and various data input and storage means are connected to that computer, for example, vehicle mounted instruments sensors, manual data input keyboards and electronic database storage media.
Systems that utilize vehicle mounted sensors utilize those sensors to transmit raw signals representing measured quantities to a central control processor for comparison with stored specification data. From this comparison, the central processor computes a vehicle diagnostic state. In addition to providing input or measured data, such sensors also enable the central processor to conduct live real-time monitoring of the vehicle diagnostic state. Representative vehicle wheel alignment systems are disclosed in U.S. Pat. Nos. 4,383,370 and 5,208,646, whose teachings and disclosures are hereby incorporated by reference.
In operation, the measured data derived from the raw signals (or alternatively measured data derived from operator keyboard input) is compared to pre-stored specification parameters. Such specification parameters correspond to specific makes and models of vehicles or parts. A vehicle diagnostic state is obtained from the aforementioned comparison between measured and specification values, and the central processor provides an output perceptible by the operator on an output device. Such output devices usually comprise a CRT display, but many possibilities are evident, for instance sound or voice output or a paper hardcopy printout. From the information on the output device, an operator may thereby diagnose problems with the vehicle or part under inspection. In automotive service equipment in general, such as engine analyzers, brake testers, suspension testers, wheel balancers and the like, sensors are not necessarily vehicle mounted.
In addition to diagnostic procedures, existing systems allow operators to perform corrections once problems are detected from the vehicle diagnostic state output. Such systems can include step-by-step adjustment or repair procedure instructions to assist in such corrections. In such cases, the output functions to guide an operator or technician through a repair or adjustment procedure.
Various shortcomings exist among currently known systems of the type described above. For one thing, such computerized automotive service equipment usually comprises proprietary, closed computer systems. A manufacturer of such systems typically spends years developing software. The manufacturer has to customize the software to run on a single dedicated computer, and the resulting product has little or no flexibility to interchange and update different hardware and software elements. Each system runs different software, often on completely different operating systems designed for completely different hardware platforms. Each individual system also is incapable of being conveniently or easily updated. If a new development or improvement occurs, the manufacturer of the individual system typically has to issue an entirely new version release of the software and/or hardware in order to bring that improvement to market. The new release requires a complete rewrite. Not only do new versions often take years to complete. It is often so costly to release a new system that, as a practical matter, the manufacturer has to wait until enough improvements occur in order to justify the financial burdens of a new version release. This hampers the ability of the end user, the automotive service professional, to bring the latest technological improvements to the customer, the typical car driver.
In some instances, personal computers (PC's) have been implemented in automotive service applications in an attempt to overcome the aforementioned problems. For instance, some vehicle wheel alignment systems have been implemented that use standard IBM-based PC's in combination with the MICROSOFT WINDOWS 3.1 operating system. While such systems do represent a departure from the traditional monolithic closed systems of the past, a number of disadvantages remain. For instance, on a programming level, WINDOWS 3.1 does not support 32-bit addressing; it only supports 16-bit addressing using a 16-bit segmented addressing mode. This memory model is an idiosyncratic remnant of the old DOS 16-bit segmented addressing mode. Also, WINDOWS 3.1 uses only a primitive form of multitasking. WINDOWS 3.1 multitasking is process-based. That is, while multiple programs can run at the same time on the system, the operating system cannot run multiple parts of the same program at one time. One consequence of this is that it has previously been impossible to place videographic computer animation (for instance, an instructional video) on a display screen at the same time as the real-time live sensor readings are displayed. It has also not been possible to utilize particular sensor inputs as a prompt to initiate and execute portions of an automotive service application while the rest of the automotive service application continues to execute at the same time.
While in some fields it has been appreciated to overcome the limitations of a WINDOWS 3.1 based computer system with the implementation of newer 32-bit operating systems, such as WINDOWS 95, the same cannot be said of the automotive service equipment field. The WINDOWS 95 operating system utilizes 32-bit flat addressing. Furthermore, WINDOWS 95 utilizes not only process-based multitasking, but also thread based multitasking. Thread based multitasking allows several parts of the same program to run at the same time. All of the pertinent advances of WINDOWS 95 over the WINDOWS 3.1 operating system are being retained in the newer WINDOWS 98 operating system, and ought to remain through future versions as well. It would be advantageous to apply such features to the automotive service equipment field.
FIG. 1
is a stylized schematic showing a general overview of how an application interacts with the computer hardware in a WINDOWS 95 or WINDOWS NT operating system. Here, the kernal interface to the hardware is represented by a series of rings. Ring
0
is the hardware, or the core. For instance, this might include the CPU, video card, serial ports, et cetera. In Ring
1
resides the WINDOWS operating system kernal and virtual device drivers. Virtual device drivers are software objects that contain code which understands how to communicate with the underlying hardware. The WINDOWS kernal handles all calls and passing of information back and forth between the operating system and the various application programming interfaces (API's). Ring
2
is where all WINDOWS application programming interfaces (API's) reside and execute. Ring
3
is where all old DOS applications execute. In Ring
2
also resides self contained reusable software objects, called “DLL's.” A DLL (“Dynamic Link Library”) is a small computer program that may be shared by many different processes at the same time.
Other features of 32-bit operating systems such as WINDOWS 95 have heretofore been unappreciated in the automotive service equipment arts. WINDOWS 95 supports enhanced object oriented programming and object oriented design (“OOP/OOD”). OOP involves the creation of software “objects.” Software objects may be thought of as self-contained mini-programs within a program. Before OOP, programs primarily consisted of two basic elements, data and program instructions. Data elements are storage locations. Program instructions are commands the computer will follow to make decisions or manipulate data. A data element such as a variable, constant or structure had only one function—to hold information. Instructions had only one function
Brennan John C.
Casby Alan David
de Bellefeuille Jean
Gill George Michael
O'Mahoney Patrick
McDermott & Will & Emery
Nguyen Tan
Snap-On Technologies Inc.
LandOfFree
Computerized automotive service system does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Computerized automotive service system, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Computerized automotive service system will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3061002