|Publication number||US20050038581 A1|
|Application number||US 10/709,500|
|Publication date||Feb 17, 2005|
|Filing date||May 10, 2004|
|Priority date||Aug 18, 2000|
|Also published as||CA2478176A1, EP1485878A2, US7092803, US20040138790, WO2003077205A2, WO2003077205A3|
|Publication number||10709500, 709500, US 2005/0038581 A1, US 2005/038581 A1, US 20050038581 A1, US 20050038581A1, US 2005038581 A1, US 2005038581A1, US-A1-20050038581, US-A1-2005038581, US2005/0038581A1, US2005/038581A1, US20050038581 A1, US20050038581A1, US2005038581 A1, US2005038581A1|
|Inventors||Michael Kapolka, Sam Chang, Brian Crull, Andrew Ditchfield, William Bromley|
|Original Assignee||Nnt, Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (99), Referenced by (51), Classifications (9), Legal Events (1)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This application is a continuation-in-part claiming the benefit of commonly assigned, co-pending U.S. patent application. Ser. No. 09/640,785, filed Aug. 18, 2000 entitled “System, Method and Computer Program Product for Remote Vehicle Diagnostics, Monitoring, Configuring and Reprogramming” to Bromley et al., the disclosure of which is incorporated by reference in its entirety. This application also claims the benefit of U.S. Provisional Application No. 60/351,165 (Attorney Docket No. 65855-0060), entitled “Wireless Communication Framework,” filed Jan. 23, 2002.
1. Technical Field
The present invention relates generally to computer data and information systems, and more particularly to computer tools for storing, processing, and displaying vehicle information.
2. Related Art
It is common for companies to own a large number, or fleet, of commercial motor vehicles. Typical examples of such companies include commercial courier services, moving companies, freight and trucking companies, truck leasing companies, as well as passenger vehicle leasing companies and passenger carriers. To maintain profitability, a company owning a vehicle fleet ideally minimizes the time spent in vehicle maintenance and repair. Maintaining optimum vehicle performance often involves removing vehicles from service to conduct fault analysis, scheduled maintenance, diagnostics monitoring and parameter modifications.
Further, companies that manufacture vehicle components may wish to have a central database to access information for product improvements, warranty service, diagnostics, and other component data after components have been installed on the vehicle. Because different companies and different industries have different vehicle data gathering and reporting needs, current solutions involve constructing specialized systems for each particular user application.
There is a desire for a system that can monitor, configure, program and diagnose vehicles and/or vehicle components while allowing customization of the vehicle data to accommodate the different needs of different users and different.
Accordingly, one embodiment is directed to a system for monitoring, configuring, programming and/or diagnosing operation of at least one vehicle, comprising an on-board unit disposed on the vehicle to send and receive data corresponding to at least one vehicle operating characteristic, a plurality of modular applications, each application having an associated function that processes the data corresponding to said at least one vehicle operating characteristic obtained via the on-board unit, and an interface that allows selection among the plurality of modular applications to create a customized system.
Another embodiment is directed to an on-board unit disposed on a vehicle for use in a system for monitoring, configuring, programming and/or diagnosing operation of at least one vehicle, comprising at least one on-board unit interface to support communication between the on-board unit and at least one device outside the on-board unit, a processor that manages the data sent and received by the on-board unit via said at least one interface, and a memory coupled to the processor.
A further embodiment is directed to a method for monitoring, configuring, programming and/or diagnosing operation of at least one vehicle, comprising obtaining data corresponding to at least one vehicle operating characteristic from an on-board unit on the vehicle, providing a plurality of modular applications that are selectable by the user to create a customized system, and processing the data corresponding to at least one vehicle operating characteristic obtained via the on-board unit according to at least one function associated with at least one selected modular application.
Yet another embodiment is directed to a computer system having an application program, wireless communication framework for processing messages provided by the application program, and a plurality of transport modules that link the wireless communication framework to a respective plurality of networks for transporting the message to a second unit.
A method directed for transporting such messages from a first unit is also provided. This method may include the following. The message is first transported from an application program to a wireless communication framework. The message is then processed in the wireless communication framework to select one of a plurality of transport modules that correspond with one of a plurality of networks. The message is then transported through the selected network to a second unit.
In another embodiment, a method for dispatching a message from a first unit and receiving a message at a second unit is provided. Here, the first unit includes a first application program and a first part of a wireless communication framework. The second unit includes a second application program and a second wireless communication framework. The message is dispatched from the first application program and received in the first part of the wireless communication framework. The message is processed to select one of a plurality of transport modules that correspond to one of a plurality of networks. The message is transported through the network to the second unit. The message is received in a second part of the wireless communication framework and processed for the second application program. The message is provided to the second application program by the second part of the wireless communication framework.
Further embodiments and variations of the invention will be apparent from the drawings and description below.
Exemplary embodiments are described below in conjunction with the appended drawing figures, wherein like reference numerals refer to like elements in the various figures, and wherein:
1. System Functionalities and Architecture
For example, as illustrated in
Further, in an embodiment of the inventive system using an ASP-based model, an application service provider provides and allows access, on a subscriber basis, to a remote vehicle diagnostics, monitoring, configuration and reprogramming tool via the Internet. That is, the application service provider provides the hardware (e.g., servers, an on-vehicle computer) and software (e.g., database) infrastructure, application software, customer support, and billing mechanism to allow its customers (e.g., fleet managers, vehicle distributors, vehicle dealers, original equipment manufacturers (“OEMs”), leasing/rental companies, and the like) to remotely access the vehicles within a fleet. The tool can be used by subscribers to select and access the modular applications 108, 110.
Note that an ASP-based model can eliminate the need to physically distribute software to users. Instead, new features and updates can be immediately available to users because the system resides and runs on an application server. In one embodiment, applications that are not on the application server can reside on the OBU 105. The on-board unit applications can be loaded onto the OBU 105 during vehicle installation, and additional applications or application updates can be downloaded onto the OBU 105 through a wireless network connection.
The interface 106 can be, for example, a user interface and/or a machine interface that allows a human or machine to access the infrastructure 102, which includes the system server 202. The system server 202 may include, for example, a series of servers that perform web page hosting, run applications, perform data storage, and/or perform wireless communications network management. In this example, the system server 202 includes a web/application server 202 a, a vehicle server 202 b, and a communications server 202 c, all of which are linked to a database server 202 d. As shown in
The OBU 105 accesses data from various vehicle components and may also generate vehicle data of its own to provide to the system server 202. The OBU 105 may include a wireless communication module 105 a to provide a communication link to a wireless network, a vehicle data processing module 105 b to process data obtained from the vehicle components, and a vehicle interface 105 c connected to, for example, the vehicle data bus to gather data from the vehicle components for processing and managing time or process-critical functions with the vehicle systems, such as electronic control units. The OBU 105 may also include a global positioning system and a driver display interface.
Each of the system architecture components will be described in greater detail below.
The interface 106 may be a standard browser interface and/or a machine-to-machine interface. In the browser interface, a human user accesses the system via a standard web browser. In one embodiment, the user gains access to the specific set of their authorized vehicles and functions after login and password authorization. In a machine-to-machine interface, server and vehicle data and functions may be accessible via a secure application program interface (API). A machine-to-machine interface allows other applications access to the system's 100 capabilities so they can gain remote access to the vehicle and the capabilities offered by the system. This allows the system 100 to interface with existing or planned back office applications and operations, making the system 100 suitable for integration with, for example, overall fleet operations or other systems.
The server system 202 is the fixed-based component of the system 100, and as explained above, can be an Internet-based system and use an ASP model. The end user can access the system from the interface 106, such as any commercially available web browser. As noted above, the server system 202 in this embodiment includes the web application server 202 a, the vehicle server 202 b, and the communications server 202 c, and the database server 202 d. Each of these will be described in greater detail below.
(I) Application Server
The web application server 202 a contains the logic defining one or more applications to an end user. All the data needed for a specific user application is requested and sent to the OBU 105 via one of the wireless communication networks 206(1-3). As will be explained in greater detail below, applications perform the necessary calculations and then package the results for presentation in a defined format to the user. Further, the web application server 202 is responsible for running business applications related to user activities, which may include performing business logic, interfacing to the systems databases for fleet, vehicle, component, and transaction activity, knowledge-base storage, and sending user requested vehicle queries or functions to the vehicle server 202 b and the communications server 202 c.
(II) Vehicle Server
The vehicle server 202 b stores and processes vehicle-specific data and acts as a translator between the applications 108, 110 and the specific vehicle and/or vehicle component. More particularly, the vehicle server 202 b is responsible for processing data requests and vehicle responses and converting the outbound and inbound data into translated vehicle information.
The vehicle server 202 b translates user requests from the interface 106 into formats specific to the vehicle 104 to which the request is directed. The vehicle server 202 b conducts this translation without any user interaction or property selections. For example, the vehicle server 202 b may evaluate a message being sent to a particular vehicle and detect the vehicle type, the vehicle bus type, and the vehicle component or sub-component that is intended as the message recipient. The vehicle server 202 b then packages the message according to the specific communication protocol mandated by the recipient component. As a result, the vehicle server 202 b allows monitoring and control of different vehicles having different components through the same interface 106 for a given user and application.
(III) Communication Server
As shown in
In one embodiment, the communications server 202 c utilizes a wireless communications framework (WCF) that provides a communication link between the system server 202 and the vehicle 104. Although any wireless mobile communication system can be used in the inventive system 100, a flexible wireless communication infrastructure that is capable of handling multiple platforms and/or multiple communication providers is preferred. One possible embodiment of such a framework is described in U.S. Provisional Application No. 60/351,165 (Attorney Docket No. 65855-0060), entitled “Wireless Communication Framework”, filed Jan. 23, 2002, the disclosure of which is incorporated herein by reference in its entirety and described in more detail below.
To handle multiple communication providers and/or platforms, the flexible wireless communication infrastructure may abstract the needs of a specific wireless communication provider, such as the message size, message format, and specific protocol details, into a standard messaging API understandable by multiple systems and platforms. In one embodiment, the communication server 202 c abstracts messages, and stores and forwards messages to ensure later delivery of messages to vehicles that are temporarily outside a wireless communication coverage area, and may even include least cost routing rules to select among multiple wireless networks to prioritize message routing based on cost and/or criticality of the message.
(iv) Database Server
The system server 202 also includes a database server 202 d containing relational data tables designed to retain information pertaining to a user, a vehicle, a fleet, system transaction history and other relationships associated with a given vehicle 104. The database server 202 d also may be designed to retain the data resulting from any vehicular transaction, such as transactions between the OBU 105 and the system server 202. In one embodiment, the database is structured such that authorized users can access vehicles in a number of ways, for example, by fleet ownership, leasing fleet, vehicle manufacturer, and component manufacturer. This structure enables the system 100 to provide each of these beneficiaries with specific, customized data and access in a format meaningful to each user.
(C) Communication Networks
As noted above, the server system 202 and OBU 105 can communicate via one or more communication networks. Each of the communication networks may be a partial or full deployment of most any communication or computer network, and thus, can include a few or many network elements, most of which are not shown. Each communication network may include circuit-switched as well as packet-data elements to provide transport of at least data communications between server system 202 and OBU 105. It can be public or private, terrestrial wireless or satellite, and/or wireline, such as the wireless communication networks 206 (exemplified by wireless communication networks 206(1-3).
Public wired and/or wireless networks typically provide telecommunications and other networking services in a particular geographic coverage area to its subscribers. And generally, any interested member of the public meeting minimal criteria may become a subscriber of public network. In the case of wireless or satellite networks, public networks typically provide coverage to other wireless networks” subscribers who are roaming within the coverage area of network as well.
Additionally, the coverage area of public network is typically wide-ranging. For example, the coverage area of a wireless public network may encompass a metropolitan area, a substantial part of a metropolitan area, numerous metropolitan areas, or an entire nation or region. When integrated with public wired and satellite networks, the combined networks provide national along with international coverage. Thus, each of the wireless communication systems 206 may include portions of a Public Switch Telephone Network (PSTN), the Internet, core and proprietary public networks, and/or wireless voice and packet-data networks (e.g., 1G, 2G, 2.5G and 3G telecommunication networks).
Each communication network may be a private or “enterprise” wired or wireless network as well. Unlike public networks, private networks advantageously provide the enterprise with greater control over the network, which in turn allows vast customization of the services (e.g., localized abbreviated dialing) provided to the network's users and/or subscribers.
These networks are “private” in that the networks” coverage areas are more geographically limited. Typically, but not necessarily, subscription to such private networks is limited to a select group of subscribers. Networks deployed by many enterprises that only allow their employees, customers, vendors, and suppliers to subscribe exemplify these private networks.
Many enterprises, Small Office/Home Office (SOHO) entities, and private individuals have private-wireline-switching systems. These private-wireline-switching systems may include, for example, private branch exchanges (PBXs) and/or media gateways. The private-wireline-switching systems switch, couple or otherwise connect communications (i) internally, i.e., among the subscribers of the network and (ii) externally, i.e., between the subscribers of the private network and subscribers of public networks.
In addition to the wireline networks, enterprises, SOHOs and private individuals are increasingly deploying private wireless communication systems, such as wireless office telephone systems (“WOTS”) and/or wireless local area networks (WLANs), e.g., Bluetooth and/or IEEE 802.11 WLANs, in lieu of or in addition to wireline switching systems. Similar to public networks, private networks may be integral to or integrated with other private and public satellite, terrestrial wireless, and wireline networks to provide national and international coverage.
Accordingly, each of the wireless communication networks 206 can be any of a private and/or public terrestrial, satellite and/or other wireless network. And each of the wireless communication networks 206 can be incorporated into a wide-area network (WAN), thereby creating a Wireless WAN (WWAN); a local area network (LAN), thereby creating Wireless LAN (WLAN); and/or other wired network. Alternatively, each of wireless communication networks can be a standalone WLAN.
At times, a single wireless service or technology may not provide a desirable messaging cost structure or geographical coverage to support all the features and users of the system 100 (
(D) On Board Unit (OBU)
As noted above, the OBU 105 provides the vehicle-side, real-time computing base for the system. In one embodiment, the OBU 105 is responsible for data stream processing, discrete measurements, vehicle position information, wireless communications, and real-time analysis of data. Within the system's overall framework, the OBU 105 acts as a vehicle server, providing vehicle specific data and functionality. In one embodiment, the OBU 105 may be an expandable custom hardware platform designed and manufactured to reside on a wide variety of vehicles with different component specifications and needs and is preferably capable of running multiple applications while acting as a vehicle data gateway for others.
The wireless interface 302 in one embodiment sends and receives data from the system server 202 to and from the OBU 105 and abstracts communication operating parameters from different wireless network devices to allow the OBU 105 to communicate with a flexible wireless communication infrastructure, such as the type described above with respect to the system server 202. More particularly, the wireless interface 302 may encapsulate protocol differences among various wireless network devices to provide a standard output to the processor 300. In one embodiment, wireless network messages are routed from the system server 202 to the wireless interface 302 for error checking and filtering. After filtering, commands are passed to the processor 300 and then routed to their respective vehicle components.
The processor 300 acts as the central processing unit (CPU) of the OBU 105 by managing the sending and receiving of requests between the system server 202 and the vehicle 104 via the wireless interface 302. In one embodiment, the processor 300 has the logic and intelligence to carry out vehicle specific services such as diagnostic requests and processing. For example, the processor 300 may run specific applications that are loaded into the OBU's memory 315, 316, 318 (
The vehicle interface 304 allows the OBU 105 to support a wide variety of vehicle components and subcomponents. Possible interfaces that can be supported by the OBU include SAEJl708, SAEJ1939, SAE OBDII/CAN, ISO-9141, discrete I/O, proprietary interfaces, and other interfaces (e.g., discrete or instrumentation interfaces). Further, the vehicle interface 304 provides a single point of contact for all vehicle components and control devices on the vehicle 104, allowing the communication between OBU software with the vehicle's actual data bus line as well as wireless communication devices, such as a satellite-based communications system.
In one embodiment, the vehicle interface 304 may include a data parser/requester module 310 that contains software code logic that is also responsible for handling direct interfacing between the processor 300 and the vehicle data bus 307 for non-application specific (i.e., “generic” SAEJ1708 or SAE1939 discrete measurement points) parameter readings, alerts, configuration or reprogramming data, as explained in greater detail below.
The vehicle interface 304 may also include, for example, one or more application specific modules 312, such as one for each manufacturer specific controller 308 within the vehicle 104, each containing software code logic that is responsible for handling interfacing between the processor 300 and the vehicle data bus 307 (via data parser/requestor module 310 in this example) for application/specific parameter readings, alerts, configuration or reprogramming data.
Note that the OBU 105 may act as a server and/or data gateway for an application that places data directly on the vehicle data bus 307. In one embodiment, the OBU 105 uses an interface standard, such as TMC RP 1210A, as an element of the data gateway. Regardless of the specific standard used, any activity using the OBU 105 as a data gateway will involve data going through the processor 300.
In an embodiment of the present invention, the OBU 105 is designed to be compliant with the SAE's Joint SAE/TMC Recommended Environmental Practices for Electronic Equipment Design (Heavy-Duty Trucks), Document No. J1455 (August 1994) standard, which is incorporated herein by reference in its entirety, because it will be a component included (or installed) within vehicles 104. As indicated above, the OBU 105 is not limited to be compliant with any particular standard and can accommodate any on-board electronic system standard (e.g., SAEJl708, SAEJl939, SAEJ1850, ISO 9141, proprietary data streams, etc.) for any sub-system (e.g., engines, transmissions, braking systems, instrument clusters, etc.) as long as the system 100 is capable of converting commands between the interface 106 and the OBU 105 according to whatever standard is used by a given vehicle electronic system. If the vehicle electronic system uses a proprietary standard, for example, the vehicle server 202 b and the associated application specific module 312 on the OBU 105 may be adapted to accommodate the proprietary standard.
The application software and the application framework are built with both a software and hardware abstraction layer. This approach makes the framework adaptable to a number of alternative operating system and hardware platforms. One embodiment of the OBU 105 may use any known real-time operating system.
(E) Wireless Communication Framework
The WCF architecture may be concentrated on either the server system 202 or a remote unit that is operable to communicate with the server system 202, such as the OBU 105. In such case, the device having server portions of the WCF architecture may act as a server in a client/server relationship and the device having the client portions may act as the client. Because the server and client responsibilities may change depending on the function to be carried out, the server system 202 can be a server for one function, yet a client for another. Similarly, the remote unit may be a client for one function, and a server for another.
Alternatively, the WCF may be distributed among one or more server-system elements 402 and one or more remote-unit elements 404. In a distributed embodiment, the remote-unit elements 404 may be included within a remote unit, such as the OBU 105, and the server-system elements 402 may be deployed in the server system 202.
In addition to the OBU 105, it is understood that the remote unit may a Personal Digital Assistant (PDA) and/or another computer that can be communicatively coupled with server-side elements 402. As such, the remote unit may contain server-system elements 402 in addition to or in lieu of the remote-unit elements 404, thereby enabling communications between itself, the server-system 202 and/or another remote unit, such as another OBU (not shown).
The remote-unit elements 404 may include (i) remote-unit application programs 406 a (e.g., full or partial application programs that reside on the remote unit) such as those as described above, (ii) remote-unit transport modules 410 a, and (iii) one or more intermediary remote-unit WCF modules 408 a.
Similarly, the server-system elements 402 may include (i) server-system application programs 406 b, which may or may not be counterparts to the remote-unit application programs 406 a; (ii) server-system transport modules 410 b, and (iii) one or more server-system WCF modules 408 b, which may or may not be the same as the remote-unit WCF modules 408 a.
With reference to
In doing so, each of the transport modules 410 a, 410 b may be configured to (i) execute protocols to access its corresponding communication network, (ii) initialize, maintain, and shut down server-system and/or remote unit communication adapters (e.g., modems), respectively, (iii) test the server-system and/or remote unit communication adapters, and/or (iv) perform any other functions and/or procedures to carry out communications with the corresponding communication network for which the particular transport module 410 a or 410 b is associated.
Each of transport modules 410 a, 410 b may be tailored (e.g., abstracted or otherwise configured) for access to a specific implementation and/or format of a communication network. If, for example, each of the wireless communication networks 206(1-3) are different from each other, then a first of the transport modules 410 a, 410 b may be configured to access wireless communication network 206(1), a second may be configured to access wireless communication network 206(2), a third may be configured to access wireless communication network 206(3), and so on. Other transport modules 410 a, 410 b can be included to access additional network services, such as those provided by WLANs or WWANs.
The number of transport modules 410 a, 410 b deployed in the remote-unit and/or server-system elements 402, 404 may be a function of the number, configuration and/or format of the communication networks 206(1-3) that the server-system 202 and/or the remote unit may have access to. For instance, the remote unit might not need to have access to the Internet. And thus, having a transport module 410 a for Internet access may be omitted. On the other hand, the server-system elements 402 may have access to a host of networks that the remote unit elements 404 do not. Accordingly, the server-system elements 402 may have transport modules 410 b configured to carry out communication with these networks.
If, for example, remote-unit elements 402 are deployed in a number of remote units in a fleet of vehicles that travel in a specific geographical region where access is available to wireless communication networks 206(1), 206(2), but not wireless communication network 206(3), then the remote-unit transport modules 410 a may be configured to access the wireless communication networks 206(1), 206(2).
The server-system elements 404, which may or may not be co-located in the same specific geographical region as the remote units, may have access to the wireless communication network 206(3) (e.g., a WLAN) in addition to the other communication networks. Thus, the server-system transport modules 410 b may be configured to access wireless communication network 206(3) as well.
Thus, the server-system elements 404 may have access to a host of networks to communicate with each of the remote unit elements 402, even though not all of the remote unit elements 402 have the corresponding access. For instance, one of the remote unit elements 402 may have access to only network 206(1), while another of the remote unit elements 402 may have access to only network 206(2), but the server system elements 404 may have the transport modules 410 a, 410 b to support both networks 206(1-2).
Moreover, the number of transport modules 410 a, 410 b may be a function of the monetary and overhead costs of subscribing to multiple communication networks. For instance, the number of transport modules 410 a, 410 b may be limited when monetary cost savings (e.g., discounted delivery rates) in using more networks cannot be justified. Other non-monetary costs, such as memory usage and processing losses, may also limit the number of transport modules 410 a, 410 b.
Conversely, the number of transport modules 410 a, 410 b may be greater when non-monetary and monetary cost savings can be obtained by the use multiple networks. These cost savings may be embodied as discounted rates, which can be apportioned by time, volume of calls; time of day, month, etc; geographical region; and other metrics.
2. Wireless Communication Modules
Regardless of whether the WCF is distributed among or concentrated on a remote unit and/or server system 202, some or all of the functions of WCF modules 408 a, 408 b may be deployed in both the remote-unit and server-system elements 402, 404. In the case of a concentrated system, however, function calls may be used to establish communication between the concentrated elements.
In some instances, the remote-unit WCF module 408 a might not perform the same functions that are carried out by the server-system module 408 b, but rather it may perform functions that complement and/or accompany functions carried out by the server-system elements 408 b.
Similarly, the server-system WCF module 408 b might not perform the functions that are carried out by the remote-unit module 408 a, but rather functions that complement and/or accompany functions carried out by the remote-unit elements 408 a. Further, some of the functions of the WCF modules 408 a, 408 b may be applicable to only a remote unit or server system 202. Thus, some of the functions carried out by WCF modules 408 a, 408 b may only exist in either the remote unit or server-system elements 402, 404. Further detail of the wireless communication framework modules 408 a, 408 b is provided below.
(A) Messaging API
The messaging API 512 may provide the functionality to receive, send, and process messages sent to or coming from multiple application programs. This functionality can be carried out by the messaging API 512 even if the application programs 406 a, 406 b use program and data structures different from rest of the WCF architecture.
As such, the messaging API 512 may allow many different application programs to use a common and/or “standardized” messaging format provided by the WCF modules 408 a, 408 b. This beneficially allows the development of application programs without the need for custom or tailored programming. For instance, the WCF architecture and the messaging API 512 may provide the messaging system, bridge (gateway, and/or conduit), storage, and programming that allow an application program to be developed and implemented independent of the communication network used by the WCF architecture.
In facilitating such application development independence, the messaging API 512 may abstract the differences between transport providers (e.g., the providers of wireless communication networks 206(1-3)) and the differing technologies of the wireless communication networks to allow applications to be written independently of the services and transport providers selected. Accordingly, when a new application program is to be added, the messaging API 512 may provide hooks or other access interfaces to the application programs to achieve communication without substantial custom programming.
(B) Message Manager
The message manger 514 may manage the delivery and acceptance of messages to and from the application programs 406 a, 406 b. The message manager 514 may also manage a reliable delivery function that insures messages are not dropped or lost. The reliable-message delivery performed by the message manager 514 may be accomplished using message-delivery verification, which will be discussed in greater detail below.
(C) Transport Manager
The transport manager 516 manages the selection of transport modules 410 a, 410 b available to the remote unit and/or server system elements 402, 404. The transport manager 516 may work in conjunction with other components of the WCF modules 408 a, 408 b, such as the least-cost routing manager 524 (discussed below) for determining which of the transport modules 410 a, 410 b to select.
(D) Ordered Delivery Manager
The ordered delivery manager 518 manages an ordered delivery of messages sent by any of the application programs 406 a, 406 b. Ordered delivery may be any predefined order in which messages are to be sent, and can be configured as an ordered delivery service. This provides a significant advantage when performing database edits or other information that is order dependent.
When ordered delivery is desired or requested by any of the application programs 406 a, 406 b, the order delivery manager 518 may arrange the messages in any of the plurality of predefined orderings irrespective of when the WCF modules 408 a, 408 b receive the messages from the application programs 406 a, 406 b. Under the WCF messaging system, messages can be configured to specify a given delivery queue using, for example, a queue identifier or other notation. Under this scheme, messages with a given queue identifier may be sent to a particular queue, as indicated by the queue identifier. Before transmission, the messages may be arranged in the particular ordering selected.
(E) Least-cost-Routing Manager
The least-cost-routing manager 524 may be responsible for selecting one or more of the transport modules 410 a, 410 b based on a plurality of factors, such as the cost and timeliness of message delivery. This WCF module may be expanded using custom routing factors as desired.
In addition to cooperating with other WCF modules 408 a, 408 b, the least-cost-routing manager 524 may operate in combination with the transport manager 516 to determine which of the transport modules 410 a, 410 b to select. The least-cost routing manger 524 may, for example, link or relay information to the transport manager 516 after determining the low cost provider so that the messages may be transmitted via the low cost service provider.
(F) Multi-Part Message Manager
The multi-part message manager 526 may manage disassembly (and reassembly of previous disassembly) of large messages for transport among the server system 202 and any of the remote units. This is particularly advantageous when the message to be sent exceeds the maximum allowable message size for the selected one of the networks 203(1-3). The multi-part message manager 526 may be invoked to ensure that the message adheres to the set maximum message size by disassembling the message into groups of smaller chunks.
The chunk size may be, for example, 16 or 32 byte chunks. Chunk size selection may also depend upon the maximum allowable size message that can be sent over the selected one of the wireless communication networks 206(1-3) without degradation or loss of the contents of the message. The chunk size may be based upon satisfactory transmission accuracy returned from error-control algorithms, for instance. The multi-part manager 526 may be equipped with intelligence, e.g., dynamic and/or statistical algorithms, for selecting a proper chunk size for maximizing throughput, bandwidth and/or other transmission parameter.
The following describes, by way of a simple, non-limiting example, of how the multi-part manager handles such overage. Assume for this example that the wireless communication networks 206(1) may have a maximum allowable message size of about 100 bytes per message, and the network 206(2) may have an allowable message size of about 512 bytes per message. In either case, however, a certain number of bytes per chunk, e.g., 2 bytes, may be allocated to overhead, reducing the number of available bytes for transmission of content over wireless communication networks 206(1-3).
Assume for this example that a message having content equaling about 100 bytes is destined for transmission across the wireless communication networks 206(1). Since the content of the message exceeds the 100 byte maximum allowable message size, the multi-part message manager 526 can disassemble the message into the smaller 16 and/or 32 byte chunks.
If, for example, the 16 byte chunk is selected, the chunk size dictates that the message will be first broken down into five 16-byte chunks, totaling 80 bytes (16×5=80)+10 bytes overhead. At this chunk size, another 16 byte chunk cannot be sent because the sixth 16-byte chunk causes the accumulated byte size to equal 106 bytes (plus 2 bytes overhead), thereby exceeding the maximum allowable message size of 100 bytes by 8 bytes. The multi-part message manager 526 can reassemble the five chunks into a first-part message, leaving the 10 remaining bytes (100 90) for a second-part message, which may be have other content added to optimize available band-width. In such case, the first-part message will only have 10 unused bytes.
If, on the other hand, the larger 32 byte chunk size was selected, then the chuck size dictates that the first-part message will be broken down into only two chunks (2×32=64)+4 bytes overhead. A third chunk will cause the accumulated byte size to exceed the maximum allowable message size of 100 bytes by 2 bytes ((3×32)+(3×2)=102). Consequently, the first-part message would have 32 bytes of unused space, which is 22 bytes more than when using the 16 byte chunk size. Accordingly, the smaller chunk size allows more of the available message size to be utilized.
The added number of smaller chunks, however, may cause more chunks to be sent. This may increase the amount of overhead, which may accumulate as a function of the number of chunks. With smaller message sizes, not many chunks need to be sent. In some circumstances, an optimization penalty resulting from overhead incurred when sending a smaller message with smaller chunks might not outweigh the reduction of unused bytes accomplished with the smaller chunk size.
When using the second wireless communication networks 206(2), for example, the multi-part message manager 526 may more optimally disassemble the message using the larger 32 byte chunks. As noted, the increased number of chunks required to be sent to accommodate the 512 byte size message increases the amount of corresponding overhead needed to send the message. Such an increase may fail to outweigh the reduction of unused bytes that accompanies the use of smaller chunks. As is apparent, larger chunk size may be beneficial for larger message sizes, the smaller chunk size may be more beneficial for smaller available message sizes. As such, a programmer or user of the WCF can flexibly pick a predetermined maximum byte size limit of a network at which the multi-part message manager 526 will disassemble a message into smaller or larger chunk sizes. The user, for example, could select a prescribed threshold of 200 bytes, which may allow a message to be disassembled into smaller chunks only when the maximum allowable limits falls below this threshold. Messages otherwise may be disassembled into larger chunks when the maximum allowable limits rises above this level.
The multi-part message manager 526 can also break messages into chunks for other reasons than to accommodate large messages. For instance, the chunk size may be set to a size slightly smaller than the maximum allowable byte size of the wireless communication networks 206(1-3) regardless of actual message size. With this alternative and with smaller chunk sizes in general, the probability that a message will get through a network without unacceptable retry attempts increases.
Additionally, the multi-part message manager 526 might not need to re-send already-acknowledged message chunks even if a partially complete message is re-routed through another network (e.g., from network 206(1) to network 206(2)). Accordingly the chunk size may be changed to another size based on which networks are available. If, for example, the message is rerouted from a network 206(2) to network 206(1), the chunk size may change from 32 bytes to 16 bytes. However, the chunk size in one network may be compatible with another, and thus, need not to be changed. Other variations on the size of the chunk in relation to the network may be utilized as well.
(G) Message Storage Manager
The message-storage manager 518 may be responsible for keeping a queue of messages that are waiting to be sent, have been sent or are awaiting an acknowledgement.
In the former case, the message-storage manager 518 may operate in conjunction with other WCF modules 408 a, 408 b to maintain the message in the queue until one of the transport module 410 a, 410 b connects to the chosen network.
In the latter case, the message-storage manager 518 may maintain a record (e.g., a table) of sent messages. This record may be used to ensure reliable delivery of the message in case of a failure of system 100, an out-of-coverage area error, and/or other error. With the record, a message is able to be resent from the message store 520 in response to such a failure.
At the receiving end, the message-storage manager 518 may also maintain a copy of the message as a handshaking mechanism. This copy may be maintained until the message is successfully delivered to the target application. If, for example, the server system 202 sends to OBU 105 a message when the vehicle 104 is outside the coverage area of any of the networks 206(1-3), then the message-storage manager 518 may store the message in the message store 520. After the vehicle 104 enters the coverage area of one or more of the networks 206(1-3) the message may then be sent.
If the multi-part message manager 526 has disassembled the message into chunks, then the chunks already sent may be stored at the message store 520 of the OBU 105, and the chunks not sent may be maintained at the server system 202. This beneficially prevents unnecessary and costly retransmission of already sent chunks in the case of, for example, system failure, out-of-coverage area errors or other connectivity failure. Such benefit may be realized because only the chunks maintained in the message store 520 of the server system 202 are sent to the OBU 105. Since the chunks that have been already sent may be maintained in the message store 520 of the OBU 105, the message can be reassembled using the earlier stored chunks and the chunks sent after reconnection.
(H) Message Services, WCF Extensibility, and WCF Portability
The WCF may also carry out certain message services such as encryption, compression and packaging. The WCF may use standard as well as custom encryption algorithms and cryptography over the entire communication route. Different types of encryption services may be used over different segments of the communication route. The encryption services may be used in addition to or in lieu of any encryption provided by the network service providers. Conversely, the WCF may use the encryption services provided by the network service providers in lieu of the services provided by the WCF.
To limit bandwidth that is required for transmission, messages can be compressed using standard and custom compression algorithms. Different types of compression services may be used over different segments of the communication route. The compression services may be used in addition to or in lieu of any compression provided by the network service providers. Alternatively, the WCF may use the compression services provided by the network service providers in lieu of the services provided by the WCF.
As noted, the WCF may carry out packaging, which allows one or more messages to be packed together to reduce the cost of transmission over transports that support large message sizes. Thus, instead of incurring the overhead and/or acknowledgement costs for each message, these costs may be incurred only once for several messages.
The WCF may be extended in various ways so as to provide extension interfaces that allow the system and/or application designer to customize and extend the WCF for the particular computing platform capabilities and behavior. Included in the extension capabilities are message store, transport modules, least-cost-routing manager, compression, and encryption extensions.
The message store 520 provides the storage for messaging functions, including message persistence in which messages are maintained message information over a system or component reset, reliable message delivery, order delivery processing, and multi-part messaging. The message store 520 may be customized according to platform capabilities and system requirements.
In addition to customizing the message store 520, new transport modules 410 a, 410 b may be added to support additional communication services and providers. The least-cost routing manager 524 may be customized to provide sophisticated routing and escalation logic.
As new standards and protocols are developed for message compression and encryption, the WCF may be extended to incorporate the changes. New compression and encryption modules may be used to support non-standard and proprietary protocols.
In addition to being extensible, the WCF may be ported to between platforms and systems. In one exemplary embodiment, an operating-system-thin layer isolates the WCF from operating system differences, thereby allowing portability between platforms. The message store 520 may abstract the file system, memory structures, and/or database structures in which messages are stored. The WCF may be deployed as dynamic-link libraries or shared libraries on platforms that support such libraries. Alternatively, the WCF may be deployed as static-linked libraries on platforms that support such libraries. The WCF may make use of Computer Object Model (COM) and can be integrated with COM+ on a Windows 2000 platform. As such, the WCF may use the transactional and security features of COM+.
(I) Reliable Message Delivery
As noted, the WCF modules 408 a, 408 b may bridge or provide a gateway between the application programs 406 a, 406 b and the transport modules 410 a, 410 b. In an exemplary embodiment, the WCF modules 408 a, 408 b can bridge or otherwise couple the remote-unit application programs 404 a with the server-system application programs 404 b, the transport modules 410 a, 410 b using standardized and/or proprietary messaging system.
As noted, the API 512 may manage the acceptance of messages from remote-unit application program 406 a and the delivery of messages to server-system application programs 406 b. The message manager 514 may also manage a process for carrying out a function for ensuring that messages are reliably delivered (i.e., reliable-message delivery). The reliable-message delivery may include the process for verifying that a sent message was properly received (hereinafter “message-delivery verification”). The response time and deployment of message-delivery verification can be based on the urgency of the message, for example.
(J) Exemplary Message Dispatch
In block 604, one or more of the messages is dispatched to the WCF from one of the application programs 406 a. This dispatch may be carried out via messaging API 512. As noted, the messaging API 512 can receive and process messages coming from one or more application programs 406 a, 406 b. Since the messaging API 512 can select and provide a corresponding interface for the one or more of the transport modules 410 a, the applications 406 a can be written to communicate with the messaging API 512, thereby allowing a programmer to focus on the vehicle application at hand and not the code for carrying out communications over the wireless communication networks 206(1-3).
In block 606, the messages are configured and formatted for dispatch. The desired transport module 410 b that corresponds to the selected one of the wireless communication networks 206(1-3) may be selected. The selection may be based on many factors, such as those described hereinafter. The process of selecting one or more of the transport modules 410 b (and in the reverse direction, transport modules 410 a) may include reviewing and/or determining network services that are available to the OBU 105. The server system 202 may contain a library of the network services available to one or more of the remote units, such as OBU 105, to assist in the selection of the desired transport module 410 b. After determining the available network services, the WCF architecture can proceed to select one or more of the available transport modules 410 b for each available network 206(1-3). Other factors, such as cost or transmission speed, may be like-wise included in making the determination.
In block 608, the messages are dispatched through the selected transport module 410 b for the desired wireless communication networks 206(1-3). In block 610, the messages are received by the OBU 105 via one of the transport modules 410 a that corresponds with the wireless service selected by the server system 202.
In block 612, the messages are processed by the WCF architecture of the OBU 105. This may include the multi-part message manager 526 reassembling messages that may have been disassembled by the server-system elements 404 of multi-part message manager 526. Also, the message storage manager 518 or message manager 514 may store the messages in the message store 520 for later processing. The WCF architecture may also perform other desired processing, as noted above, including formatting the messages for delivery to and receipt by one or more of the application programs 406 b. Since many application programs 406 b may be run simultaneously or concurrently in the OBU 105, the WCF architecture and functionality has the ability to format the messages to suit a number of different possible application programs 406 b. Such formatting may be accomplished through the messaging API 512.
In block 614, the messages are sent to one or more of the application programs 406 b via the messaging API 512. As noted in block 606 described above, the message manager 514 may be used to provide reliable-message delivery. To facilitate the reliable-message delivery, the messages may be assigned a delivery option by one or more of the application programs 406 b. This delivery option may be either unreliable or reliable status. If unreliable status is applied to one or more of the messages, then the message manager 513 may cause the message to be delivered without requiring the OBU 105 to return a confirmation acknowledgement or receipt. In the simplest case, the delivered messages are sent and forgotten. If, however, one or more of the application programs 406 b assigns a reliable status to one or more of the messages, then these messages may be repeatedly sent to the OBU 105 until the application programs 406 b and/or server system 202 receive a return confirmation acknowledgement or receipt.
Also noted in above, ordered delivery manager 518 can provide order delivery processing of the messages or message chunks. To facilitate the order delivery, one or more of the application programs 406 b may assign a particular order to a plurality of the messages. In this case, the particular assigned order is the order in which the messages are to be sent. The OBU 105 may use the order delivery processing to properly process transmitted information. The ordered delivery manager 518 may collect the messages until the ordered-delivery processing is complete, and then forward the messages to the application programs 406 b. Then, the ordered delivery manager 518 dispatches the messages according to the assigned order. The WCF architecture and functionality supports multiple, independent, ordered delivery queues.
Referring now to
If, for example, the OBU 105 is within range of network 206(1) and/or network 206(2), then the messages may be sent in block 704. If the vehicle is not within range, then block 702 is repeated until the vehicle becomes within range of the corresponding network. During this wait time, messages may be stored within the message store 520 by message-storage manager 518, thereby freeing up the application program 410 a to perform other tasks.
With continued reference to
If one or more of the messages are smaller than the limit, then multiple messages can be packaged to reduce overhead for a number of messages. This may be accomplished by placing a number of smaller messages into a packet for transmission over the selected network 206(1-3). This reduces the cost and latency for sending messages over networks that have an overhead cost or additional latency cost for each packet.
If, on the other hand, the size of one or more of the messages exceeds the maximum allowable limit, then the oversized messages may be disassembled as shown in block 710. To carry out block 710, the oversized messages may be compared to a prescribed message size to determine the more optimum method for disassembly. The prescribed message size may be used to the balance between efficiencies of sending larger chunks and disassembling the message into smaller chunks, as described previously. This prescribed message size may be an arbitrary or learned byte size specified by the system or it may be a maximum allowable limit dictated by the network on which the message is to be transmitted. Over-sized messages that exceed the prescribed message size may be disassembled using the larger or smaller chunk size as shown in blocks 712, 714.
In block 716, the oversized messages are disassembled according to the determination of which chunk size to use. Disassembly may be carried out using identification coding or otherwise marking the order in which the portions of the disassembled messages should be reassembled at the OBU 105. The disassembled messages may then be transmitted to the OBU 105 as shown in block 718.
The multi-part message manager 526 keeps track of the portions of dissembled messages that have been transmitted and the portions that have not been transmitted. This allows only the un-transmitted portions of the messages can be later transmitted in case of a failure of system 100 or an out-of-range fault during message transmission. Accordingly, when the system 100 comes back on-line or the OBU 105 comes re-enters the coverage area of one of the wireless communication networks 206(1-3), then entire messages not need to be re-transmitted even if the messages are subsequently routed onto a different one of the wireless communication networks 206(1-3).
In block 720, the messages along with re-assembly information are received in the multi-part message manager 526 of the OBU 105. Like the multi-part message manager 526 in the system server 202, the multi-part message manager 526 also maintains a record of the portions of messages that have been received in case of a failure of the system 100 or an out-of-range fault. Once re-assembled, the messages are sent to the application program 410 a of the OBU 105 as shown in block 722. As noted, the above-described communication are for exemplary purposes only and carried out by in the reverse direction and/or with devices other than the server-system 202 and OBU 105.
At block 802, the server-system portion of the WCF architecture receives one or more messages from one or more of the application programs 410 b. Before sending the messages, however, the application programs 410 b may assign a particular priority to each of the messages. This priority, for example, may be set to a low priority, which indicates that the message or messages need not be sent with urgency. Alternatively, the priority may be set to a high priority, which indicates that the message or messages need to be sent with some degree of urgency and be delivered soon.
The priority may also be set to a batch priority. The batch priority may indicate to the WCF architecture that the messages may be held in a queue, e.g., the message store 520, until other messages with the same priority level are accumulated. Once accumulated, the group of messages can be then sent as one batch.
At block 804, the API 512 may determine which of wireless communication networks 206(1-3) are available to the OBU 105. Each of the messages” priority is reviewed to determine whether high, low, multi-formatted (mixed processing) or batch priority conditions exist, as shown in block 806.
High priority processing is carried out for messages having a high priority, as shown in block 808. Low priority processing is executed for messages having a low priority, as shown in block 810. Batch priority processing is executed for messages having a batch priority as shown in block 812. In block 814, multi-formatted or mix processing may be carried out if the message priority is assigned by the application programs 410 b. As noted, the above-described communication flow 800 is for exemplary purposes only and carried out by in the reverse direction and/or with devices other than the server-system 202 and OBU 105.
3. System Operation Examples
The overall system 100 can support many possible services and applications, examples of which are described below and illustrated in
In one embodiment, the applications may assemble the core services to perform specific functions. For example, one of the core services 350 may capture measured values and/or change parameters or operational settings in the vehicle 104 while the applications 108, 110 organize and process information from the core services 350 into groupings that are meaningful to a given user. A service outlet, for example, may want different data and/or data organized in a different manner than a leasing organization or a component manufacturer.
As noted above and as shown in
As noted above, the core services 350 provided by the system 100 acts as building blocks that can be assembled by applications in a variety of ways that can best serve the user. Possible core services 350 include:
The list of core services 350 above is not meant to be exhaustive, but are simply examples of possible services that can be available directly to users or supplied to applications for further processing. Note that although the explanations below focus on obtaining data from a vehicle ECU 308, the system and functions described below are applicable for any vehicle data.
The “Parameters” service may include a simple parameter retrieval service as well as more sophisticated parameter retrieval services that address limitations in obtaining vehicle data when, for example, the vehicle is turned off.
To carry out the snapshot process 1000, the system 100 first initializes at block 1002 by, for example, storing the diagnostic parameters to monitor, setting the time intervals at which parameter values are captured, selecting the number of captured values to be included in a single report, and selecting the event that will trigger reporting of the captured values. This information can be inputted into the OBU 105 via the interface 106. The parameter values to be captured can be any parameters accessible on the vehicle's electronic controllers by means of a diagnostic data stream or from discrete inputs on the OBU 105. The triggering event can be any non-continuous event that is monitored on the vehicle, such as the capture of an active trouble code from a vehicle controller or a parameter moving outside an established acceptable range.
Once the OBU 105 has been configured (block 1002), the OBU 105 maintains a number of historical value sets at block 1004 by caching a selected number of parameter readings during normal vehicle operation. While the OBU 105 captures the parameter readings, it also waits for the triggering event to occur. Once the trigger event occurs (block 1006), the OBU 105 continues caching the configured parameter readings occurring after the event (block 1008). The number of historical value sets can be, for example, half the number of captures to be included in the final report, while the number of value sets taken after the triggering event can make up the other half. Note that the OBU 105 may, in another embodiment, capture parameter readings only before or after the triggering event as well or capture different numbers of values on either side of the event.
After all of the desired value sets have been captured and collected, all of the captured readings, both before and after the event, are combined into a final report at block 1010. The report can be stored on the OBU 105 for later retrieval or sent via wireless connection to the application server 202 a for immediate viewing.
Another possible process that can be offered as a “Parameters” service is a “get stored values” (GSV) process 1100, as illustrated in
For the GSV process 1100 to be effective, the OBU 105 should be designed to allow continuous remote access so that the OBU 105 is always ready for receiving and sending messages. The OBU 105 is initialized by receiving an instruction to periodically collect specified parameter data at a selected query time interval (block 1102). After receiving this command, the OBU 105 will periodically collect data at the specified query time intervals (block 1104). The values gathered by the OBU 105 are stored in the on-board unit's memory, such as a flash memory, at block 1106 before the OBU 105 is shut down when the vehicle 104 is turned off.
If the OBU 105 receives a GSV “retrieve” command from the application server 202 a (block 1108), the OBU 105 checks the state of the vehicle controller 308 at block 1110. If the vehicle controller 308 is accessible, then the OBU 105 collects the current values from the vehicle controller 308 at that time and sends the collected current values to the system server 202 (block 1112). If the vehicle controller 308 is not available at the time of the command (e.g., if the vehicle is turned off), making the current values of the controller 308 irretrievable, the saved values in the OBU 105 are sent back to the system server 202 as the retrieved values (block 1114).
By periodically collecting data at selected intervals while the vehicle controller is operational, the OBU 105 can at least obtain recent vehicle controller parameter readings before the controller 308 is inaccessible at some later time. As a result, the GSV process 110 allows the system server 202 to obtain the most recent controller data if current data is not available at the time of the query. In short, the GSV process 1100 returns the last known value in memory to the system server 202 if the vehicle is turned on and will retrieve a backup value, which may still be the last known value in memory, if the vehicle is turned off.
Multiple “Alerts” services may also be provided as a core service in the system 100. In its simplest form, the “Alert” service monitors vehicle trouble codes and transmits a message to the OBU 105 when the trouble code occurs. For example, a fault code may come as solicited or unsolicited, depending on how the controller 308 in the OBU 105 is instructed to handle faults. To obtain an unsolicited fault, the OBU 105 monitors the vehicle data bus 307 for the occurrence of a fault and notifies the system server 202 if a fault occurs. If only a set of individual faults are monitored, additional parsing shall be performed to filter out unwanted faults. For example, if a user only wishes to be informed of fault codes corresponding to a component breakdown, as opposed to being informed of all fault codes, the user can indicate this preference via the interface 106.
To obtain a solicited fault, the user may set up periodic queries to the OBU processor 300 in addition to setup notification. Note that the response message may match the message template even if no fault actually existed; in this case, additional parsing of the response message may be necessary to obtain useful information. For example, if the user solicits a request for information, the user may obtain a response based upon the criteria of that request, which may be different than the criteria for unsolicited notifications.
If desired, the “Alert” service may include additional functions such as providing the ability to add/remove individual faults, canceling the alert function for a given fault when a fault alert is fired so that only the first fault occurrence (and not subsequent fault occurrences) trigger a notification message, or configuring the “Alert” service to be stored permanently in, for example, the database server 202 d until the user removes the service or until the service is cancelled by a fault occurrence.
With respect to the example shown in
As an example of an “Alert” service that monitors over time,
As shown in
The “Alert” services may also include a tamper alert feature that, as shown in
The actual tamper check process is conducted when, for example, the vehicle is initially turned on. At this point, the OBU 105 checks the parameter again to get its current value at the time the vehicle ignition is turned on (block 810). If the current value is different than the saved value (block 1312), a tamper alert message will be returned to the user (block 1314). If the compared values are the same at block 1312, however, the vehicle continues operation as usual without transmitting any tamper alert signal (block 1316). In one embodiment, the user may add/remove individual tamper alerts, and the tamper alert may be cancelled at block 1318 once the alert is fired.
A “Change Parameters” function may also be included as part of a configuration core service, as shown in
The core services can be accessed by one or more applications, as noted above. The system 100 may include the ability to leverage other services that it may or may not have, such as, Fuel Tax Reporting/State Line Crossing applications, Asset tracking/utilization programs, Driver Performance applications, On-line Vehicle Documentation, detailed mapping applications, etc. This flexibility, coupled with modular services and applications 108, 110 that can be added, subtracted, and combined at will, provides for a very flexible and adaptable platform.
As described above, the system 100 allows users to customize their own vehicle monitoring, programming and diagnostics systems based on their own specialized needs by offering a plurality of applications that can be selected and combined in a modular fashion as desired by the user. The applications may include service offerings such as Remote Diagnostics, Fuel Economy, Trip Reporting, Automatic Vehicle Location based upon GPS or satellite based system information, and others. The applications listed here and described in greater detail below are only examples and are not meant to be limiting or comprehensive in any manner. Those of skill in the art will understand that other applications may also be included as possible application options.
A “Remote Diagnostics application for example, provides the ability to perform component analysis before or during a vehicle breakdown and allows vehicle maintenance locations to receive parametric information from a vehicle prior to its arrival, or prior to dispatching a technician to the vehicle. Further, the “Remote Diagnostics” application allows a technician to perform selected diagnostic tests on the vehicle or system, with the test process being managed by the OBU 105. In one embodiment, the “Remote Diagnostics” application allows a user to view parameters, active and inactive fault codes, and vehicle configurations, for example, and may also allow authorized users to perform functional tests and configuration changes on the vehicle. Remote Diagnostics may be initiated when, for example, a vehicle notifies a fleet manager about a series of established alerts or when the diagnostics are requested manually by a fleet authorized user. In practice, the application may provide diagnostic applications via the inventive system 100. When the user logs on to the system 100 via the interface 106, for example, he or she may be presented with a list of vehicles that have reported alerts or notifications that may need attention. If no alerts are active, the user is provided a list of vehicles for which he or she is responsible. At this point the user may elect to use a remote diagnostics application, such as the remote diagnostics application described below and shown in
A “Leased Vehicle Management” (LVM) application is another possible option to generate periodic status reports summarizing selected parameters for each vehicle in a fleet, such as total vehicle distance, total idle fuel, total idle time, total fuel used, and/or total fuel economy.
An “Engine Management” application may also be an option to target fleets whose vehicles encounter varying road and traffic conditions, and varying load types and weights. The objective of the “Engine Management” application is to improve overall fleet fuel economy via dynamic control of a vehicle”’ operational characteristics, in particular, horsepower ratings and maximum road speed limits. Traditionally such operating parameters have been established once at a fleet wide level, not taking into consideration some of the variables listed above. In addition, making these changes required physical contact with the vehicle, necessitating undesirable vehicle downtime. Dynamic adjustments based upon operating conditions can provide reductions in vehicle operational costs, thus resulting in significant savings at a fleet level. With this application the user will be able to dynamically configure the vehicle wherever it may be; tailoring its operational characteristics based upon route, load, and other vehicle operation factors. The “Engine Management” application may include both measured parameters and programmable parameters. Examples of programmable parameters include Vehicle Road Speed Limit, Engine Horsepower/Torque, Engine Idle Shutdown Time and Cruise Control Settings.
A “Trip Report” application may also be provided as an option. This application allows the fleet manager to obtain trip information from the vehicle on a near-real-time basis. The user can analyze trip information for single vehicles as well as any increment of their fleet. This application primarily uses measured parameters such as odometer readings, total trip fuel, idle fuel, average fuel economy, vehicle route taken, and others. It also uses some parameters to derive data, such as total idle hours and the type of idle hours recorded. The output from this application can also be used as input to the billing systems of leasing companies who charge customers based upon mileage.
A “Maintenance Alert” application allows the fleet manager to establish a series of maintenance triggers based upon key parameters. When a parameter threshold is encountered, the fleet manager will be notified automatically by the system, thus initiating a maintenance event without physical contact with the vehicle. For example, a fleet may establish a preventive maintenance cycle based upon odometer reading. If the system server 202 is made aware of the interval, it can notify the fleet of the precise moment when that interval occurs. Alerts may provide notification on parameters such as diagnostic codes, fluid levels and parameter ranges as well as unauthorized tampering with the vehicle.
A “Vehicle Configuration” application may be offered to allow a fleet manager to set certain parameters for multiple vehicles in a fleet so that the selected vehicles will operate within its established standards. Examples of parameters include horsepower ratings, maximum road speed limits, maximum and minimum cruise control set speeds and maximum engine idle time before shutdown. Traditionally, this step has required a physical connection of a diagnostic application or tool to the vehicle, but physical connections are time-consuming and require the same step to be repeated on every vehicle that is serviced. The wireless nature of the “Vehicle Configuration” application allows operational settings and alerts for several vehicles within a fleet at one time by allowing the user to identify selected vehicles, set parameters, and initiate an automated process where each vehicle is systematically configured with the same parameter settings.
A “WarrantyManagement” application may also be offered as part of a data mining strategy used by, for example, original equipment manufacturers (OEMs) to help diagnose warranty relationships between major components or to assess warranty claims for validity. This application would, for example, obtain detailed vehicle data from the database server 202 d, using both fleet specific and system-wide data mining, and then correlate the data with warranty requirements.
As noted above, the possible modular applications described herein are meant as illustrative examples only. Further, as noted above, the applications 108, 110 accessed by the infrastructure 102 can be generated by third parties and offered as modules for incorporating into a particular user”’ interface 106 and accessing the OBU 105 and other system-supported core services and applications. The modular functionality offered by independent applications 108, 110 allows disparate users to access the same vehicle data via the same OBUs 105 and the same infrastructure 102, but be offered customized data, functionalities, and interfaces that are meaningful to that user”’ industry as determined by the particular modular applications selected by the user. The specific manner for implementing the applications via, for example, computer programs, is within those of skill in the art.
The inventive system therefore provides a modular wireless vehicle diagnostics, command and control system that is customizable to a user”’ specifications. More particularly, the modular applications 108, 110 provide much versatility and allow users from disparate industries to use the same overall inventive system 100 by selecting the applications 108, 110 relevant to their particular industry. Further, by creating a wireless diagnostics and command and control service, the invention provides real-time remote access to vehicles and vehicle systems via, for example, the Internet and wireless networks. In one embodiment, the inventive system allows users to connect to multiple data points on any given vehicle to interpret and analyze the vehicle data in real time, change vehicle parameters as needed and create historical databases to guide future decisions. Further, by monitoring vehicle operation in real time and providing customized reports for each vehicle, the inventive system achieves high operating efficiency, lowered maintenance costs and downtime, and even allows pre-ordering of parts as vehicles approach scheduled maintenance.
Note that the capabilities described above are meant to be illustrative and not limiting. The system 100 can be adapted to, for example, establish a setting that is applied to selected group of vehicles with a single command rather than individually establishing a setting for each vehicle. The aspects of the request, including authorization, vehicle/component differences, password differences, and configuration limitations of the specific request, may be managed by, for example, the system server 202. In another embodiment, the system 100 can view each vehicle 104 as a single entity to allow the user to communicate with multiple ECU”’ on the same vehicle 104 at the same time. For example, data can be obtained from an Engine ECU and Transmission ECU at the same time, with the resultant data from each controller correlated to the other to add more detail to the data offered to the user.
Variations of the system described above are possible without departing from the scope of the invention. For example, selected applications may be run locally on proprietary equipment owned by the customers (i.e., the fleet managers, vehicle distributors, vehicle dealers and the like) as a stand alone software application instead of over the Internet. Further, the OBU 105 can be equipped with, for example, a bar code scanner and/or other human user interface to facilitate data capture. Other user interfaces and functions, such as a handheld diagnostics tool, work-flow integration tool, links between data captured by different applications, and tools to provide advance warning of vehicle faults or pre-arrival diagnostics information may also be included as application modules or core services or even integrated within the application modules themselves. Note that one or more additional servers can also be incorporated into the system to, for example, accommodate additional data management functions and/or provide interfaces for integrating with existing applications.
Information obtained via the inventive system can also be used to, for example, re-calibrate vehicle components, perform firmware downloads, perform component failure analysis, determine wear characteristics, analyze quality of components used in their manufacturing processes, retrieve and manage warranty information, receive indications of vehicle maintenance needs, monitor vehicle use and abuse, and/or monitor lessee trip information, perform proactive data analysis, perform pre-arrival diagnostics, re-calibrate vehicle components, and/or perform firmware downloads. Note that this list of options is not exhaustive and those of skill in the art will understand that other variations in the data obtained via the inventive system and how the data is presented and used can vary without departing from the scope of the invention.
It should be understood that various alternatives to the embodiments of the invention described herein may be employed in practicing the invention. It is intended that the following claims define the scope of the invention and that the method and apparatus within the scope of these claims and their equivalents be covered thereby.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US4067061 *||Mar 18, 1975||Jan 3, 1978||Rockwell International Corporation||Monitoring and recording system for vehicles|
|US4258421 *||Mar 14, 1979||Mar 24, 1981||Rockwell International Corporation||Vehicle monitoring and recording system|
|US4630292 *||Aug 13, 1984||Dec 16, 1986||Juricich Ronald A||Fuel tax rebate recorder|
|US4677429 *||Dec 1, 1983||Jun 30, 1987||Navistar International Transportation Corp.||Vehicle information on-board processor|
|US4809177 *||Aug 14, 1987||Feb 28, 1989||Navistar International Transportation Corp.||Multiplexed electrical wiring system for a truck including driver interface and power switching|
|US4926331 *||Dec 20, 1988||May 15, 1990||Navistar International Transportation Corp.||Truck operation monitoring system|
|US4939652 *||Mar 14, 1988||Jul 3, 1990||Centrodyne Inc.||Trip recorder|
|US4979170 *||Jan 19, 1988||Dec 18, 1990||Qualcomm, Inc.||Alternating sequential half duplex communication system|
|US5157610 *||Feb 15, 1990||Oct 20, 1992||Hitachi, Ltd.||System and method of load sharing control for automobile|
|US5337236 *||May 21, 1990||Aug 9, 1994||Taurean Electronics, Inc.||System for categorizing and recording vehicle trip distance|
|US5359528 *||Feb 19, 1993||Oct 25, 1994||Rockwell International Corp.||System for accurately determining the mileage traveled by a vehicle within a state without human intervention|
|US5426585 *||May 28, 1992||Jun 20, 1995||Cummins Electronics Company, Inc.||Method and apparatus for generating calibration information for an electronic engine control module|
|US5442553 *||Nov 16, 1992||Aug 15, 1995||Motorola||Wireless motor vehicle diagnostic and software upgrade system|
|US5579233 *||Jan 9, 1995||Nov 26, 1996||Burns; Robert R.||Method of on-site refueling using electronic identification tags, reading probe, and a truck on-board computer|
|US5581464 *||Oct 11, 1994||Dec 3, 1996||Vorad Safety Systems, Inc.||Recording of operational events in an automotive vehicle|
|US5612875 *||Oct 24, 1994||Mar 18, 1997||Rockwell Science Center Inc.||System for accurately determining the mileage traveled by a vehicle within a state without human intervention|
|US5619412 *||Oct 19, 1994||Apr 8, 1997||Cummins Engine Company, Inc.||Remote control of engine idling time|
|US5648768 *||Dec 30, 1994||Jul 15, 1997||Mapsys, Inc.||System and method for identifying, tabulating and presenting information of interest along a travel route|
|US5680328 *||May 22, 1995||Oct 21, 1997||Eaton Corporation||Computer assisted driver vehicle inspection reporting system|
|US5682317 *||Jul 23, 1996||Oct 28, 1997||Pavilion Technologies, Inc.||Virtual emissions monitor for automobile and associated control system|
|US5694322 *||May 9, 1995||Dec 2, 1997||Highwaymaster Communications, Inc.||Method and apparatus for determining tax of a vehicle|
|US5708308 *||May 8, 1996||Jan 13, 1998||Mitsubishi Denki Kabushiki Kaisha||Apparatus for protecting automobile against unauthorized operation|
|US5721678 *||Mar 10, 1994||Feb 24, 1998||Mannesmann Aktiengesellschaft||Arrangement for a use billing system|
|US5729458 *||Dec 29, 1995||Mar 17, 1998||Etak, Inc.||Cost zones|
|US5732074 *||Jan 16, 1996||Mar 24, 1998||Cellport Labs, Inc.||Mobile portable wireless communication system|
|US5742915 *||Dec 13, 1995||Apr 21, 1998||Caterpillar Inc.||Position referenced data for monitoring and controlling|
|US5787373 *||Jun 13, 1997||Jul 28, 1998||Datatrac International, Inc.||Travel expense tracking system|
|US5803043 *||Aug 1, 1996||Sep 8, 1998||Bayron; Harry||Data input interface for power and speed controller|
|US5815071 *||Dec 12, 1996||Sep 29, 1998||Qualcomm Incorporated||Method and apparatus for monitoring parameters of vehicle electronic control units|
|US5815822 *||Mar 12, 1996||Sep 29, 1998||Iu; Howard||Apparatus for remotely controlling a vehicle in motion|
|US5831519 *||Nov 21, 1995||Nov 3, 1998||Pedersen; Heine Ewi||Traffic supervision system for vehicles|
|US5835376 *||Oct 27, 1995||Nov 10, 1998||Total Technology, Inc.||Fully automated vehicle dispatching, monitoring and billing|
|US5835868 *||Aug 30, 1996||Nov 10, 1998||Mcelroy; Alejandro S.||Automated system for immobilizing a vehicle and method|
|US5864831 *||Feb 17, 1994||Jan 26, 1999||Daimler Benz Ag||Device for determining road tolls|
|US5917434 *||Jun 15, 1995||Jun 29, 1999||Trimble Navigation Limited||Integrated taximeter/GPS position tracking system|
|US5919239 *||Jun 28, 1996||Jul 6, 1999||Fraker; William F.||Position and time-at-position logging system|
|US5928291 *||Mar 27, 1997||Jul 27, 1999||Rockwell International Corporation||Mileage and fuel consumption determination for geo-cell based vehicle information management|
|US5931877 *||May 30, 1996||Aug 3, 1999||Raytheon Company||Advanced maintenance system for aircraft and military weapons|
|US5937421 *||Aug 19, 1997||Aug 10, 1999||International Business Machines Corporation||Methods, systems and computer program products for performing interactive applications in a client-server based dialog system|
|US5938716 *||Sep 8, 1997||Aug 17, 1999||Cummins Engine Company, Inc.||System for customizing vehicle engine control computer operation|
|US5953706 *||Oct 21, 1997||Sep 14, 1999||Orissa, Inc.||Transportation network system|
|US5954773 *||Dec 13, 1996||Sep 21, 1999||Eaton Corporation||Vehicle state mileage determination system|
|US5974356 *||Oct 15, 1997||Oct 26, 1999||Qualcomm Incorporated||System and method for determining vehicle travel routes and mileage|
|US5974396 *||Jul 19, 1996||Oct 26, 1999||Moore Business Forms, Inc.||Method and system for gathering and analyzing consumer purchasing information based on product and consumer clustering relationships|
|US6026384 *||Oct 21, 1997||Feb 15, 2000||Etak, Inc.||Cost zones|
|US6060981 *||Apr 23, 1999||May 9, 2000||Caterpillar Inc.||Vehicle security system for unattended idle operations|
|US6064929 *||Jul 28, 1998||May 16, 2000||Datatrac International, Inc.||Travel expense tracking system|
|US6078873 *||Oct 2, 1997||Jun 20, 2000||Cummins Engine Company, Inc.||Method and apparatus for real-time data stamping via datalink and volatile ECM timer/clock|
|US6085725 *||May 21, 1999||Jul 11, 2000||Cummins Engine Co., Inc.||Throttle control response selection system|
|US6087965 *||Apr 29, 1999||Jul 11, 2000||Trimble Navigation Limited||Vehicle mileage meter and a GPS position tracking system|
|US6088650 *||Mar 1, 1999||Jul 11, 2000||Trimble Navigation, Ltd.||Vehicle tracker, mileage-time monitor and calibrator|
|US6089207 *||Sep 18, 1998||Jul 18, 2000||Cummins Engine Company, Inc.||Throttle control response selection system|
|US6091340 *||Nov 25, 1997||Jul 18, 2000||Lee; Brian||Remote on/off disable parts and system|
|US6108591 *||Jan 22, 1998||Aug 22, 2000||Qualcomm Incorporated||Method and apparatus for validating vehicle operators|
|US6111539 *||Mar 12, 1998||Aug 29, 2000||British Telecommunications Public Limited Company||Navigation information system|
|US6169515 *||Sep 1, 1995||Jan 2, 2001||British Telecommunications Public Limited Company||Navigation information system|
|US6181995 *||Sep 20, 1999||Jan 30, 2001||Eaton Corporation||Vehicle state mileage determination system|
|US6185501 *||Aug 6, 1998||Feb 6, 2001||Intellectual Property Development Associates Of Connecticut, Inc.||Methods and apparatus for loading or modifying a vehicle database from a remote computer via a communications network and a fuel or current dispenser|
|US6195023 *||Dec 10, 1998||Feb 27, 2001||Daimlerchrysler Ag||Communication based vehicle positioning reference system|
|US6204772 *||Dec 16, 1999||Mar 20, 2001||Caterpillar Inc.||Method and apparatus for monitoring the position of a machine|
|US6226577 *||Dec 17, 1999||May 1, 2001||Hyundai Motor Company||Method for searching trip log of vehicle|
|US6232874 *||Mar 13, 2000||May 15, 2001||Trimble Navigation Limited||Vehicle use control|
|US6253129 *||Mar 27, 1997||Jun 26, 2001||Tripmaster Corporation||System for monitoring vehicle efficiency and vehicle and driver performance|
|US6259988 *||Jul 20, 1998||Jul 10, 2001||Lockheed Martin Corporation||Real-time mission adaptable route planner|
|US6263268 *||Aug 26, 1998||Jul 17, 2001||Transcontech Corporation||System and method for providing mobile automotive telemetry|
|US6275585 *||Apr 28, 1998||Aug 14, 2001||Motorola, Inc.||Method for reprogramming a vehicle system or a user system in a vehicle|
|US6278935 *||Jul 23, 1999||Aug 21, 2001||Navigation Technologies Corp.||Method and system for providing instructions about tollways with a navigation system|
|US6292724 *||Oct 12, 1999||Sep 18, 2001||Micrologic, Inc.||Method of and system and apparatus for remotely monitoring the location, status, utilization and condition of widely geographically dispresed fleets of vehicular construction equipment and the like and providing and displaying such information|
|US6295492 *||Jan 27, 2000||Sep 25, 2001||Infomove.Com, Inc.||System for transmitting and displaying multiple, motor vehicle information|
|US6317668 *||Jul 29, 1999||Nov 13, 2001||Qualcomm Incorporated||Paperless log system and method|
|US6370449 *||Jun 14, 1999||Apr 9, 2002||Sun Microsystems, Inc.||Upgradable vehicle component architecture|
|US6389337 *||May 3, 2000||May 14, 2002||H. Brock Kolls||Transacting e-commerce and conducting e-business related to identifying and procuring automotive service and vehicle replacement parts|
|US6430164 *||Nov 1, 1999||Aug 6, 2002||Cellport Systems, Inc.||Communications involving disparate protocol network/bus and device subsystems|
|US6516192 *||Jun 5, 2000||Feb 4, 2003||Cellport Systems, Inc.||Communications channel selection|
|US6636790 *||Feb 1, 2001||Oct 21, 2003||Reynolds And Reynolds Holdings, Inc.||Wireless diagnostic system and method for monitoring vehicles|
|US6714857 *||Feb 26, 2002||Mar 30, 2004||Nnt, Inc.||System for remote monitoring of a vehicle and method of determining vehicle mileage, jurisdiction crossing and fuel consumption|
|US6775267 *||Dec 30, 1999||Aug 10, 2004||At&T Corp||Method for billing IP broadband subscribers|
|US7084735 *||Aug 28, 2002||Aug 1, 2006||Idsc Holdings, Llc.||Remote vehicle security system|
|US20010018628 *||Feb 22, 2001||Aug 30, 2001||Mentor Heavy Vehicle Systems, Lcc||System for monitoring vehicle efficiency and vehicle and driver perfomance|
|US20010020204 *||Feb 28, 2001||Sep 6, 2001||David Runyon||System for tracking vehicle and driver location and mileage and generating reports therefrom|
|US20020007237 *||Jun 13, 2001||Jan 17, 2002||Phung Tam A.||Method and system for the diagnosis of vehicles|
|US20020016655 *||Jul 31, 2001||Feb 7, 2002||Joao Raymond Anthony||Apparatus and method for processing and/or for providing vehicle information and/or vehicle maintenance information|
|US20020049523 *||Nov 20, 2001||Apr 25, 2002||Diaz R. Gary||Land vehicle communications system and process for providing information and coordinating vehicle activities|
|US20020133273 *||Mar 14, 2001||Sep 19, 2002||Lowrey Larkin Hill||Internet-based vehicle-diagnostic system|
|US20020156588 *||Mar 5, 2001||Oct 24, 2002||Arndt G. Dickey||Sensor and method for detecting a superstrate|
|US20020173885 *||Mar 13, 2001||Nov 21, 2002||Lowrey Larkin Hill||Internet-based system for monitoring vehicles|
|US20020177926 *||Oct 9, 2001||Nov 28, 2002||Lockwood Robert Farrell||Customer service automation systems and methods|
|US20030004624 *||Dec 20, 2001||Jan 2, 2003||Wilson Bary W.||Diagnostics/prognostics using wireless links|
|US20030055912 *||Aug 17, 1998||Mar 20, 2003||Bruce K. Martin||Method and apparatus for controlling network connections based on destination locations|
|US20030093199 *||Nov 15, 2001||May 15, 2003||Michael Mavreas||Remote monitoring and control of a motorized vehicle|
|US20030105565 *||May 22, 2002||Jun 5, 2003||Loda David C.||Integrated internet portal and deployed product microserver management system|
|US20030105825 *||Jan 25, 2002||Jun 5, 2003||Profluent, Inc.||Method and system for policy based management of messages for mobile data networks|
|US20030158656 *||Mar 30, 2001||Aug 21, 2003||Zvi David||Locating and controlling a remote device through a satellite location system|
|US20030162523 *||Feb 27, 2002||Aug 28, 2003||Michael Kapolka||Vehicle telemetry system and method|
|US20040039504 *||Aug 25, 2003||Feb 26, 2004||Fleet Management Services, Inc.||Vehicle tracking, communication and fleet management system|
|US20040138790 *||Mar 4, 2002||Jul 15, 2004||Michael Kapolka||Remote monitoring, configuring, programming and diagnostic system and method for vehicles and vehicle components|
|US20050060070 *||Apr 12, 2004||Mar 17, 2005||Nnt, Inc.||Wireless communication framework|
|US20050085963 *||Apr 12, 2004||Apr 21, 2005||Nnt, Inc.||Vehicle-interactive system|
|US20050203673 *||May 24, 2004||Sep 15, 2005||Hassanayn Machlab El-Hajj||Wireless communication framework|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7165015 *||Mar 29, 2005||Jan 16, 2007||Cryovac, Inc.||Handheld device for retrieving and analyzing data from an electronic monitoring device|
|US7634259 *||Mar 17, 2006||Dec 15, 2009||Orange Sa||Applications server and method|
|US7668653||May 31, 2007||Feb 23, 2010||Honda Motor Co., Ltd.||System and method for selectively filtering and providing event program information|
|US7681201 *||Aug 6, 2007||Mar 16, 2010||Lectronix||Method and system for integrating and controlling components and subsystems|
|US7711522||Aug 31, 2006||May 4, 2010||Caterpillar Inc.||Systems and methods for monitoring a machine|
|US7818380||Jun 30, 2006||Oct 19, 2010||Honda Motor Co., Ltd.||Method and system for broadcasting safety messages to a vehicle|
|US7849149||Apr 6, 2005||Dec 7, 2010||Honda Motor Co., Ltd.||Method and system for controlling the exchange of vehicle related messages|
|US7885599||Mar 12, 2010||Feb 8, 2011||Honda Motor Co., Ltd.||System, method and computer program product for receiving data from a satellite radio network|
|US8041476 *||Mar 8, 2011||Oct 18, 2011||Spx Corporation||Error message details for debug available to end user|
|US8091014||Aug 20, 2008||Jan 3, 2012||Denso Corporation||Electronic apparatus in which functioning of a microcomputer is monitored by another microcomputer to detect abnormal operation|
|US8161454 *||Jan 22, 2007||Apr 17, 2012||Ford Motor Company||Software architecture for developing in-vehicle software applications|
|US8239251||Oct 17, 2011||Aug 7, 2012||Crown Equipment Corporation||Fleet management system|
|US8239252||Oct 17, 2011||Aug 7, 2012||Crown Equipment Corporation||Fleet management system|
|US8249910 *||Dec 13, 2007||Aug 21, 2012||Crown Equipment Corporation||Fleet management system|
|US8397228 *||Nov 14, 2007||Mar 12, 2013||Continental Automotive Systems, Inc.||Systems and methods for updating device software|
|US8462793 *||May 25, 2007||Jun 11, 2013||Caterpillar Inc.||System for strategic management and communication of data in machine environments|
|US8484266 *||Feb 19, 2009||Jul 9, 2013||Hitachi, Ltd.||Embedded control system with floating-point conversion|
|US8564253 *||Dec 22, 2009||Oct 22, 2013||Sinautec Automobile Technologies, Llc||City electric bus powered by ultracapacitors|
|US8594933 *||Feb 9, 2006||Nov 26, 2013||Sap Ag||Transmission of sensor data based on geographical navigation data|
|US8615773||Mar 31, 2011||Dec 24, 2013||Honeywell International Inc.||Systems and methods for coordinating computing functions to accomplish a task using a configuration file and standardized executable application modules|
|US8688313||Dec 23, 2010||Apr 1, 2014||Aes Technologies, Llc.||Remote vehicle programming system and method|
|US8718632||Aug 26, 2010||May 6, 2014||Ford Global Technologies, Llc||Service delivery network|
|US8726084 *||Oct 14, 2011||May 13, 2014||Honeywell International Inc.||Methods and systems for distributed diagnostic reasoning|
|US8726188||Oct 29, 2010||May 13, 2014||Nissan North America, Inc.||Method for presenting information to a host vehicle having a user interface|
|US8744668 *||May 9, 2012||Jun 3, 2014||Bosch Automotive Service Solutions Llc||Automotive diagnostic server|
|US8751777||Jan 28, 2011||Jun 10, 2014||Honeywell International Inc.||Methods and reconfigurable systems to optimize the performance of a condition based health maintenance system|
|US8832649||May 22, 2012||Sep 9, 2014||Honeywell International Inc.||Systems and methods for augmenting the functionality of a monitoring node without recompiling|
|US8832716||Aug 10, 2012||Sep 9, 2014||Honeywell International Inc.||Systems and methods for limiting user customization of task workflow in a condition based health maintenance system|
|US8909466 *||Jul 31, 2009||Dec 9, 2014||Environmental Systems Research Institute, Inc.||System and method for hybrid off-board navigation|
|US8924071 *||Apr 26, 2013||Dec 30, 2014||Ford Global Technologies, Llc||Online vehicle maintenance|
|US8990770||May 25, 2011||Mar 24, 2015||Honeywell International Inc.||Systems and methods to configure condition based health maintenance systems|
|US9026304 *||Apr 7, 2009||May 5, 2015||United Parcel Service Of America, Inc.||Vehicle maintenance systems and methods|
|US9081648||Mar 15, 2012||Jul 14, 2015||Ford Motor Company||Software architecture for developing in-vehicle software applications|
|US20050132024 *||Dec 15, 2003||Jun 16, 2005||Masayuki Habaguchi||Method and system for facilitating the exchange of information between a vehicle and a remote location|
|US20070185646 *||Feb 9, 2006||Aug 9, 2007||Mario Neugebauer||Transmission of sensor data based on geographical navigation data|
|US20080154691 *||Dec 13, 2007||Jun 26, 2008||Wellman Timothy A||Fleet management system|
|US20090249040 *||Feb 19, 2009||Oct 1, 2009||Hitachi, Ltd.||Embedded Control System|
|US20100030466 *||Jul 31, 2009||Feb 4, 2010||Environmental Systems Research Institute, Inc.||System and Method for Hybrid Off-Board Navigation|
|US20100190439 *||Jan 29, 2009||Jul 29, 2010||Ford Global Technologies, Llc||Message transmission protocol for service delivery network|
|US20100270983 *||Oct 28, 2010||Zhengda Gong||City Electric Bus Powered by Ultracapacitors|
|US20110161138 *||Jun 30, 2011||Trapeze Software Inc.||System and Method for Analyzing Performance Data in a Transit Organization|
|US20110225228 *||Sep 15, 2011||Ford Global Technologies, Llc||Method and systems for queuing messages for vehicle-related services|
|US20120110466 *||Oct 29, 2010||May 3, 2012||Nissan North America, Inc.||Method for presenting information to a host vehicle having a user interface|
|US20130097459 *||Oct 14, 2011||Apr 18, 2013||Honeywell International Inc.||Methods and systems for distributed diagnostic reasoning|
|US20130325248 *||May 21, 2013||Dec 5, 2013||Horiba, Ltd.||Test system|
|US20140200760 *||May 25, 2012||Jul 17, 2014||Augmentation Industries Gmbh||Method for vehicle communication by means of a vehicle-implemented vehicle diagnostic system, vehicle diagnostic interface, interace module, user communication terminal, data connection system, and diagnostic and control network for a plurality of vehicles|
|US20140324275 *||Apr 26, 2013||Oct 30, 2014||Ford Global Technologies, Llc||Online vehicle maintenance|
|US20150112584 *||Nov 7, 2014||Apr 23, 2015||Environmental Systems Research Institute, Inc.||System and method for hybrid off-board navigation|
|EP2115692A2 *||Dec 13, 2007||Nov 11, 2009||Crown Equipment Corporation||Fleet management system|
|EP2115692A4 *||Dec 13, 2007||Nov 16, 2011||Crown Equip Corp||Fleet management system|
|WO2008019333A2 *||Aug 6, 2007||Feb 14, 2008||Thomas Bayerl||Method and system for integrating and controlling components and subsystems|
|International Classification||B60R16/02, G08G1/13, G06Q10/08, G07C5/00|
|Cooperative Classification||G07C5/008, G06Q10/08|
|European Classification||G06Q10/08, G07C5/00T|
|Jul 13, 2007||AS||Assignment|
Owner name: IDSC HOLDINGS LLC, WISCONSIN
Free format text: MERGER;ASSIGNOR:NNT, INC.;REEL/FRAME:019554/0870
Effective date: 20051222