Patent Application
20080016207
Reference will now be made in detail to the preferred embodiments of the invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with the preferred embodiments, it will be understood that they are not intended to limit the invention to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims. Furthermore, in the following detailed description of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be obvious to one of ordinary skill in the art that the present invention may be practiced without these specific details. In other instances, well known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the present invention.
The information sent by host 100 to central station 104 may contain voice or data information that is directed to one or more vehicles in the communication system. Information may also originate from central station 104 independently of host 100. In the case of information being transmitted from host 100, central station 104 receives the information and attempts to forward it to the identified vehicle or vehicles, as the case may be. The particular vehicle or vehicles for which the message is intended is identified by specifying an alpha-numeric code, typically a code corresponding to a serial number which has been pre-assigned to mobile communication terminal 106 installed on vehicle 102. However, any known method may be used to uniquely identify vehicles in the communication system.
In one embodiment, the system includes a Vehicle Interface Module (VIM). The VIM is installed in the vehicle through a plug-in SAE J1962 connector. The VIM includes a microcontroller and memory, a Bluetooth radio, and an SDIO slot for the addition of an optional Key FOB. The VIM provides full access to the vehicle's ECU data and allows the system to access Diagnostic Trouble Codes reported by the vehicle's ECU. The VIM helps users to service and maintain the vehicle with live sensor display. The VIM also reads and displays reason for Check Engine Light or MIL (Malfunction Indicator Light) which indicates presence of fault codes (DTC, Diagnostic Trouble Codes). The VIM can collect data such as Throttle position, Engine RPM, Vehicle speed, Calculated load value, Ignition timing advance, Intake air flow rate, Short term fuel trim, Long term fuel trim, Air temperature, Coolant temperature, Oxygen sensors. The VIM can also display diagnostics trouble codes (DTC), clear Check Engine lamp, retrieve and clear Generic and Manufacturer specific diagnostic trouble codes (DTC), display live sensor data and freeze frame data, and communicates with Engine Management System and Emissions Systems.
The VIM communicates with the handheld device 106, which can be a cell phone or PDA capable of running the J2ME, Windows Mobile, or BREW operating systems. The handheld device 106 is also equipped with Bluetooth and GSM/GPRS, CDMA/1X, or iDEN voice and data communications. Exemplary handheld device 106 can be the Java J2ME cell phones, Nextel i730, i850, i355, i605, Blackberry, Nextel, Verizon Wireless, Cingular, Sprint MS Windows Mobile Smartphone Edition, Nextel, Verizon Wireless, Cingular, Sprint MS Windows Mobile Pocket PC Edition, Nextel, Verizon Wireless, Cingular, Sprint BREW cell phones. The handheld device 106 runs mobile software components 108 such as a Consumer Application (CA). The CA serves as the user interface to vehicle control and configuration functions and OBDII (SAE standard for On Board Diagnostics II for cars and light trucks) data access on the VIM via Bluetooth. The CA also supports the ability to transmit the data, manually or automatically, and receive commands remotely via standard wide area wireless networks.
The VIM can run an OBDII Application Platform (OAP) or SAE J1708/J1939 Adapter (for heavy trucks) written for the VIM that accepts and responds to requests for OBDII/J1708/J1939 data and configuration settings from the consumer application. The OAP or J1708/J1939 adapter implements a range of OBDII/J1708/J1939 protocols for access to vehicle systems such as the engine, transmission, safety, and chassis. The handheld device also supports an API that enables 3rd party developers to access the VIM.
The handheld device 106 communicates with a server over a wide area network (WAN) such as the Internet. Wireless access to the Internet can be provided through cellular towers 108 that access the Internet through the cellular wireless carriers or service providers that own the towers 108.
In one embodiment, the position of vehicle 102 is provided to central station 104 at predetermined time intervals, such as once per hour, and is commonly referred to as a position report. The position of vehicle 102 may be provided generally in one of two ways. In the exemplary embodiment, the position of vehicle 102 is determined at central station 104 using a positioning unit such as GPS, GLONASS or GALILEO position receiver. These systems are well-known in the art for providing accurate, real time position information, generally in the form of latitude and longitude coordinates, to a GPS receiver located onboard vehicle 102. The position of vehicle 102 as provided by the GPS receiver is transmitted to central station 104 at predetermined intervals. The GPS information may be transmitted alone, or it may be appended to voice or text messages.
Updates from Enterprise Systems can also be sent to the e-log application. For example, if an alert from the Asset Management System needs to be sent to the driver, the Asset Management System creates a message and sends it to the server-side Messaging System (3.5) which then forwards it on to the client-side Messaging System (3.3). The e-log application (3.1) implements an interface (in the case of the Java programming language) that is called when a message is sent from the server. It then processes the message; typically by updating the Database (3.2) and any screens in the e-log application (3.1).
The Messaging System consists of the main server (3.5) which stores all messages into persistent storage (eg. disk) so that if any part of the system goes down, the message is not lost. It implements a reliable “once and only once protocol” for handing off messages. The Messaging systems can implement several policies. The “best effort” policy states that the messaging system will make its best attempt to send a message but offers no guarantees whether the message makes it, or whether it gets delivered multiple times. The “at least once” policy will guarantee that the message gets delivered, but it might be sent multiple times; this might happen for example if an acknowledgement from the receiving end is lost but the message actually made it, so in resending the message, it gets received twice. As each message is considered a legal and binding record of a driver's activities, the strictest “one and only once” policy is preferred over the other two policies, but in certain applications, other policies can be used. The “once and only once” policy can be implemented in a manner similar to the “at least once” messaging system, where a message is re-sent until confirmed with a positive acknowledgement by the recipient. In addition, the policy keeps track of which message was sent or received by stamping each one with a unique identifier. If a positive acknowledgement was lost for some reason, the recipient will receive a duplicate from the sender but because it knows that it already received the message, it simply deletes the duplicate and sends another acknowledgement.
The Transaction Monitor (3.6) implements a two-phase commit operation similar or the same as the XA standard. This method first sets up a transaction envelope with a “begin transaction” when all Enterprise Systems are told to accept a transaction; this is the first phase. If any of the transactions fail, the previous systems will be issued a rollback command from the Transaction Monitor. If the transactions succeed, the systems are issued a commit command from the Transaction Monitor telling them that the transaction is complete. This is where the “end transaction” occurs.
In the process of
Although specific embodiments of the present invention have been illustrated in the accompanying drawings and described in the foregoing detailed description, it will be understood that the invention is not limited to the particular embodiments described herein, but is capable of numerous rearrangements, modifications, and substitutions without departing from the scope of the invention. The following claims are intended to encompass all such modifications.
