FIELD OF THE INVENTION  
       [0001]     The present invention relates to vehicle software installation, upgrade, and diagnostic systems and methods, and particularly relates to an open architecture for transferring vehicle software and diagnostic information between vehicle processors and an external processor using a portable memory device.  
       BACKGROUND OF THE INVENTION  
       [0002]     Today&#39;s vehicles typically have a specialized assembly line diagnostic link (ALDL) provided under the dash. Today&#39;s vehicle software installation process during assembly typically requires that a cable be inserted into the ALDL and that the vehicle remain in place for some time. Alternatively, a portable, external processor temporarily attaches to the vehicle steering wheel as the vehicle moves down the assembly line and connects to the ALDL. Post-assembly vehicle software upgrade processes therefore require dealers to have a dedicated external processor with a specialized communication port. Similarly, repair procedures typically require technicians to have portable, handheld diagnostic processors with specialized communication ports. These standard systems and methods suffer from utilization of a slow speed proprietary serial bus that must be physically connected to the on-board communications port for a potentially lengthy period of time.  
         [0003]     The need remains for a system and method that lower costs while increasing flexibility. The need also remains for a smooth migration path as newer, faster, cheaper vehicle buses become the industry standard. The present invention fulfills these needs.  
       SUMMARY OF THE INVENTION  
       [0004]     A vehicle software installation, upgrade, and diagnostic system for use in vehicle assembly, upgrade, and repair, includes a portable memory device, such as a USB flash disk. The device receives diagnostic information via an open architecture communications port of a vehicle, such as a USB port. An external processor has a complimentary open architecture communications port and is adapted to receive and analyze the diagnostic information from the portable device. According to various aspects, analysis of the diagnostic information verifies successful installation and testing of vehicle software transferred from the portable device to vehicle processors, identifies software versions resident on the vehicle and related upgrade history for download and installation of an appropriate software upgrade, and/or diagnoses vehicle problems in accordance with sensed vehicle conditions and predetermined fault detection criteria.  
         [0005]     Further areas of applicability of the present invention will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description and specific examples, while indicating the preferred embodiment of the invention, are intended for purposes of illustration only and are not intended to limit the scope of the invention. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0006]     The present invention will become more fully understood from the detailed description and the accompanying drawings, wherein:  
         [0007]      FIG. 1  is a combination functional block and entity relationship diagram illustrating the vehicle and the vehicle software installation, upgrade, and diagnostic system according to the present invention; and  
         [0008]      FIG. 2  is a flow diagram illustrating the vehicle software installation, upgrade, and diagnostic method according to the present invention. 
     
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0009]     The following description of the preferred embodiment(s) is merely exemplary in nature and is in no way intended to limit the invention, its application, or uses.  
         [0010]     Referring to  FIG. 1 , the vehicle  10  according to the present invention has an open architecture communications port  12 A in communication with an interface processor  14 . The open architecture communications port  12 A is selected based on high speed, low price, and compatibility with inexpensive and commonly available processors. The present invention leverages the high speed and low cost of the port along with its compatibility to widely deployed and available personal computers. Thus, the selection of the specific port may, for example, be matched to the most common port being deployed with personal computers. A typical and currently preferred example is the conventional universal serial bus (USB) port. However, this port could instead be replaced by other yet-to-be-designed standard interfaces. Alternative ports could be firewire or any future ports not yet widely in use. The USB or other port is provided to the vehicle and may be located in any convenient location. For example, the port  12 A may be located underneath the dash board on the driver&#39;s side of the vehicle. The port  12 A is preferably mounted so that the port  12 A remains hidden from everyday view, and yet is easily accessible without difficulty in locating or reaching the port  12 A. The port may be added onto to the vehicle in addition to the conventional ALDL computer port on that kind of vehicle. Ultimately, however, the port is intended to become the only such external port on the vehicle. The possibility of having two data ports is offered only to provide a graceful transition in the deployment of the invention.  
         [0011]     The interface processor  14  is connected to a system bus of the vehicle, and is adapted to load software received over the port  12 A onto multiple processors  16 A- 16 C that are also connected to the system bus. For example, interface processor  14  may be adapted to parallel flash program multiple processors  16 A- 16 C using a frame interleaving technique. It is envisioned that a portable memory device  18  is employed to communicate vehicle software  20  to interface processor  14 . Thus, interface processor  14  has the bootstrapping software necessary to utilize portable memory device  18 . In a preferred embodiment, portable memory device is selected based on speed, capacity, price, availability, and ability to interface with the port  12 A. Therefore, portable memory device corresponds to a USB flash disk in a currently preferred embodiment where port  12 A is a USB port. These disks are currently available in very large data capacities (64 MB, 128 MB, 256 MB, 512 MB). Also, these devices are very inexpensive relative to storage capacity. For example, 128 MB of storage space may be purchased in single quantity for under thirty dollars, and the disk fits into a small package the size of a small cigarette lighter. The USB flash memory disks are further extremely compatible with current personal computers. For example, a user can typically plug a USB flash disk into a USB port on any reasonably current PC or Macintosh computer and the disk will self mount. Special software is not usually required at all. Thus, the present invention can effectively employ a standard off-the-shelf USB flash disk or equivalent. All of the special handshaking software is similarly integrated into the vehicle interface processor&#39;s  14  initial memory. Thus, interface processor&#39;s  14  bootstrapping software corresponds to a driver that supports a USB flash memory device in a currently preferred embodiment. However, it is envisioned that other types of memory devices may be employed with the present invention as new types of memory devices and/or ports become available and market forces change.  
         [0012]     The present invention reduces price and increases speed and convenience in vehicle assembly, upgrade, and repair procedures by utilizing portable memory device  18  to provide a convenient, high speed, low cost mechanism for transferring vehicle software  20  and diagnostic information  22  between onboard vehicle processors and external processor  24 . As a result, an expensive, portable, dedicated external processor does not have to be provided to each vehicle on the line during vehicle assembly. Instead, external processor  24  may load vehicle software  20 A onto device  18  via open architecture communications port  12 B of external processor  24  based on the type of vehicle  10 . It is envisioned that external processor  24  may maintain a carousel of devices  18  as vehicles  10  approach on an assembly line during an assembly process  26 . Thus, it is only necessary to have one external processor on the assembly line, with several inexpensive, portable memory devices  18 .  
         [0013]     It is envisioned that an operator disconnects the next portable memory device  18  from external processor  24  and reconnects it to the port  12 A of the vehicle  10 . Then, as the vehicle  10  either remains in place or moves down the assembly line, interface processor  14  loads the software  20  onto the multiple processors  16 A- 16 C. It is envisioned that the files of software  20  may be encrypted such that only the interface processor  14  program on-board a target vehicle  10  would be able to access the software and install it. It is also envisioned that software for multiple types of vehicles may be stored on one falsh disk, and that interface processor  14  may be adapted to identify the and load the appropriate files based on vehicle type. The multiple processors are adapted to automatically test the newly installed software  20  and transmit test results as diagnostic information  22  to interface processor  14 . The testing function may be resident on the multiple processors as a result of installation of software  20 , or it may be a function of software already resident on the multiple processors  16 A- 16 C. In turn, interface processor  14  is adapted to transfer the diagnostic information  22  embodying the test results to the portable memory device  18 .  
         [0014]     It is also envisioned that, once the testing has finished, an operator disconnects the portable memory device  18  from the port  12 A of the vehicle and reconnects it to the port  12 B of the external processor  24 . It is further envisioned that external processor  24  may in actuality be two separate processors in different locations on the assembly line that together from the external processor  24 . Thus, external processor  24  accesses the diagnostic information  22  on the portable memory device  18  and uses diagnostic information analysis module  28  to verify that the software installation and testing procedure was successful. This verification  30  is provided as feedback to the assembly process  26 .  
         [0015]     Dealers and other software upgrade service providers similarly benefit from the ability to employ a personal computer or equivalent as an external processor  24  to provide upgrades to the vehicle  10  using a portable memory device  18 . At the least, the need is eliminated for specialized, handheld devices that network with a server and are capable of interfacing with the ALDL. Thus, it is envisioned that an operator transfers a diagnostic program to the device  18  from the external processor  24  that is designed to determine what type of software is resident on the multiple processors  16 A- 16 C as well as the entire software upgrade history. Then, the operator disconnects the memory device  18  from the external processor  24  and reconnects it to the vehicle  10 . Interface processor  14  responds by communicating the software  20  to the multiple processors  16 A- 16 C, which respond by writing out via interface processor  14  to the device  18  diagnostic information  22  indicating their software versions and update history. It is envisioned, however, that this function may be equivalently accomplished by allowing interface processor  14  to maintain a record of software installations and to provide the information to the device  18  upon request.  
         [0016]     Once the diagnostic information  22  is obtained, the operator disconnects the device  18  from the vehicle and reconnects it to the external processor  24 . In turn, external processor  24  sends a query  32  over communications system  34 , such as the Internet, to a manufacturer&#39;s server  36 . The query  32  preferably indicates the vehicle type, software versions, and update history so that the server  36  can determine an appropriate software upgrade  20 B and communicate it to the external processor  24 . Then, external processor  24  stores the new software on the device  18 , and the operator essentially follows the same procedure as in the assembly process to install the software upgrade on the vehicle. It is envisioned that the appropriate software update may equivalently be identified by the external processor  24 , rather than the server  36 , so that query  32  merely needs to identify the needed upgrade to server  36 . It is also envisioned that processor  24  may store and acquire the upgrades locally. It is further envisioned that the results of the software test may be communicated back to the manufacturer server  36 . Appropriate encryption and security codes are preferably employed to prevent people other than authorized service providers from performing this function.  
         [0017]     Dealers and other repair services providers also benefit from the ability to use the portable memory device to diagnose problems with the vehicle  10 . In particular, repair service providers may dispense with expensive, specialized hand-held devices having ALDL connection capability. Instead, the diagnostic information  22  resulting from on-board vehicle fault detection can be transferred to external processor  24  for analysis via portable memory device  18 . As a result, the same kind of open architecture port  12 A on the vehicle and the same kind of portable memory device  18  may be used to extract diagnostic information from the vehicle&#39;s on-board computers for diagnosing problems. In the preferred embodiment, a flash disk would be preset via a standard PC to initiate a diagnosis function with the on-board multiple processors  16 A- 16 C to generate and/or acquire pre-generated fault detection results based on sensed vehicle conditions and predetermined fault detection criteria. The on-board multiple processors  16 A- 16 C write out all the diagnostic information into the flash disk via the interface processor  14 . The flash disk is then read out by a standard personal computer being used as the external processor  24 . Encryption and appropriate security codes may be employed to allow the manufacturer to control the process. The manufacturer might then sell the PC software to the dealership or other type of service group. As a result, the manufacturer retains control over the process, but still generates a profit from providing the advanced diagnostic capability to the end service provider. It is envisioned that some of the diagnostic information might be left readable by any PC as a normal text file, whereas the complex and more valuable information may only be interpreted by authorized users having purchased the package. This solution completely eliminates the expensive, custom hardware typically employed to provide this kind of function. It also allows for a very user friendly display  38  of the fault detection results to the person using the tool.  
         [0018]     Referring now to  FIG. 2 , the method according to the present invention typically begins with transferring vehicle software to the portable memory device via the external processor at step  40 . It should be readily understood that the type of software stored on the device in step  40  may vary depending on the mode of operation of the present invention. For example, in an assembly mode, the vehicle software may correspond to supplemental software operable to adapt the multiple processors of the vehicle to properly operate their respective vehicle component systems. Also, in a first recursion of the method in an upgrade mode, hereinafter referred to as a pre-upgrade mode, the vehicle software may correspond to a driver, routine, or other trigger information adapted to cause interface processor  14  and/or multiple processors  16 A- 16 C to write out their current software versions and entire upgrade history. Further, in a post-upgrade mode during a second recursion of the method, vehicle software may correspond to an upgrade to supplemental software operable to adapt the multiple processors of the vehicle to properly operate their respective vehicle component systems. Finally, in a repair mode, the vehicle software may correspond to a driver, routine, or other trigger information adapted to cause interface processor  14  and/or multiple processors  16 A- 16 C to perform diagnostic functions according to sensed vehicle conditions and predetermined fault detection criteria, and/or to write out previously generated fault detection results.  
         [0019]     At step  42 , the method continues with establishing communication between the portable memory device and vehicle interface processor via the open architecture communications port of the vehicle. For example, this step typically involves disconnecting the portable memory device from the open architecture communications port of the external processor. Also, this step may be performed by an individual, such as a vehicle assembly line worker or repair and/or upgrade technician. Further, it is envisioned that this step may be performed by an automated system, such as a robot on an assembly line.  
         [0020]     At step  44 , the vehicle software is transferred from the portable memory device to multiple processors of the vehicle via the interface processor of the vehicle. For example, in an assembly mode or post-upgrade mode, the interface processor loads identifies the appropriate files for each of the multiple processors and loads them onto the respective processors. Also, in a pre-upgrade mode or repair mode, the interface processor may load the files onto the multiple processors; alternatively, it is envisioned that the interface processor may equivalently access the software for the multiple processors.  
         [0021]     At step  46 , diagnostic information is generated based on a new software autotest, current software versions and upgrade history, and/or fault detection results. For example, in an assembly mode or post-upgrade mode, the multiple processors autotest the newly installed software or software version to generate the diagnostic information. Also, in a pre-update mode, the current software versions and upgrade history are accessed by the multiple processors and/or interface processor to generate the diagnostic information. Further, in a repair mode, fault detection results are generated by the multiple processors based on sensed vehicle conditions and predetermined fault detection criteria; equivalently, it is envisioned that pre-generated and stored fault detection results may be accessed to generate the diagnostic information.  
         [0022]     At step  48 , the diagnostic information is transferred from the multiple processors to the portable memory device via the interface processor. For example, the multiple processors may write out to the portable memory device their auto-test results, fault detection results, and/or current software versions and upgrade history. Equivalently, it is envisioned that in a pre-upgrade or repair mode the interface processor may write out pre-stored information that may have been received from the multiple processors, or may have been stored during transfer to the multiple processors.  
         [0023]     At step  50 , the method continues with establishing communication between the portable memory device and the external interface processor via the open architecture communications port of the external processor. For example, this step typically involves disconnecting the portable memory device from the open architecture communications port of the vehicle. Also, this step may be performed by an individual, such as a vehicle assembly line worker or repair and/or upgrade technician. Further, it is envisioned that this step may be performed by an automated system, such as a robot on an assembly line.  
         [0024]     At step  52 , the external processor analyzes the diagnostic information stored on the portable memory device. For example, in an assembly or post-update mode, the external processor verifies successful installation and testing of the newly installed software and provides feedback to an assembly or upgrade process at step  54 . Also, in a pre-update mode, the external processor formulates a query for transmission over a communications network to a manufacturer&#39;s server, thereby identifying and downloading one or more appropriate software upgrades at step  56 ; equivalently, it is envisioned that the external processor may identify the appropriate upgrades based on the current software versions and update history, and/or access the appropriate upgrades on local memory. Further, in a repair mode external processor decrypts and displays fault detection results at step  58 . Finally, the method ends after steps  54  and  58 , but not after step  56 ; instead, a second recursion is enjoined and the mode switches from pre-update to post-update.  
         [0025]     Those skilled in the art can now appreciate from the foregoing description that the broad teachings of the current invention can be implemented in a variety of forms. Therefore, while this invention has been described in connection with particular examples thereof, the true scope of the invention should not be so limited since other modifications will become apparent to the skilled practitioner upon a study of the drawings, the specification and the following claims.
A vehicle software installation, upgrade, and diagnostic system for use in vehicle assembly, upgrade, and repair, includes a portable memory device, such as a USB flash disk. The device receives diagnostic information via an open architecture communications port of a vehicle, such as a USB port. An external processor has a complimentary open architecture communications port and is adapted to receive and analyze the diagnostic information from the portable device. According to various aspects, analysis of the diagnostic information verifies successful installation and testing of vehicle software transferred from the portable device to vehicle processors, identifies software versions resident on the vehicle and related upgrade history for download and installation of an appropriate software upgrade, and/or diagnoses vehicle problems in accordance with sensed vehicle conditions and predetermined fault detection criteria.