US20050038581A1 - Remote Monitoring, Configuring, Programming and Diagnostic System and Method for Vehicles and Vehicle Components - Google Patents

Remote Monitoring, Configuring, Programming and Diagnostic System and Method for Vehicles and Vehicle Components Download PDF

Info

Publication number
US20050038581A1
US20050038581A1 US10/709,500 US70950004A US2005038581A1 US 20050038581 A1 US20050038581 A1 US 20050038581A1 US 70950004 A US70950004 A US 70950004A US 2005038581 A1 US2005038581 A1 US 2005038581A1
Authority
US
United States
Prior art keywords
message
vehicle
network
communication framework
networks
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US10/709,500
Inventor
Michael Kapolka
Sam Chang
Brian Crull
Andrew Ditchfield
William Bromley
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
IDSC Holdings LLC
Original Assignee
NNT Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NNT Inc filed Critical NNT Inc
Priority to US10/709,500 priority Critical patent/US20050038581A1/en
Publication of US20050038581A1 publication Critical patent/US20050038581A1/en
Assigned to IDSC HOLDINGS LLC reassignment IDSC HOLDINGS LLC MERGER (SEE DOCUMENT FOR DETAILS). Assignors: NNT, INC.
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/08Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07CTIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00Registering or indicating the working of vehicles
    • G07C5/008Registering or indicating the working of vehicles communicating information to a remotely located station

Definitions

  • the present invention relates generally to computer data and information systems, and more particularly to computer tools for storing, processing, and displaying vehicle information.
  • 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.
  • a method for dispatching a message from a first unit and receiving a message at a second 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.
  • FIG. 1 is a representative functional block diagram illustrating an overall system according to one embodiment of the present invention
  • FIG. 2 is a representative block diagram illustrating a system architecture according to one embodiment of the present invention
  • FIGS. 3A and 3B are representative block diagrams of one embodiment of an on-board unit in one embodiment of the present invention.
  • FIG. 4 is a representative block diagram of a wireless communication system according to one embodiment of the present invention.
  • FIG. 5 is a representative block diagram of a wireless communication framework for a wireless communication system according to one embodiment of the present invention.
  • FIG. 6 is a flow chart depicting the operation of a wireless communication system according to one embodiment of the present invention.
  • FIG. 7 is another flow chart depicting the operation of a wireless communication system according to one embodiment of the present invention.
  • FIG. 8 is yet another flow chart depicting the operation of a wireless communication system according to one embodiment of the present invention.
  • FIG. 9 is a block diagram of a parameter retrieval process according to one embodiment of the present invention.
  • FIG. 10 is a block diagram of a parameter retrieval process according to another embodiment of the present invention.
  • FIG. 11 is a block diagram of a parameter retrieval process according to yet another embodiment of the present invention.
  • FIG. 12 is a graph illustrating the operation of a threshold alert process according to one embodiment of the present invention.
  • FIG. 13 is a block diagram illustrating the operation of a tamper alert process according to one embodiment of the present invention.
  • FIG. 14 is a block diagram illustrating a parameter change process according to one embodiment of the invention.
  • FIG. 15 is a block diagram illustrating one possible architecture for a remote diagnostics application to be used in one embodiment of the present invention.
  • FIG. 16 is a block diagram illustrating one possible architecture of a leased vehicle management application to use in one embodiment of the present invention.
  • FIG. 1 is a representative functional diagram of a vehicle monitoring and diagnostics system 100 according to an exemplary embodiment.
  • the inventive system 100 allows monitoring and control of a vehicle fleet by displaying and controlling data according to a user's customized specifications.
  • the system 100 is designed with modular applications that interact with core data and services so that vehicle parameters can be monitored, analyzed and displayed in a format that is meaningful to a particular user and/or a particular industry. This flexibility allows different users and/or industries to use the same overall system 100 for vehicle and component monitoring despite their disparate vehicle data requirements.
  • the system 100 may include an application service provider (ASP) infrastructure 102 that acts as a gateway between a plurality of vehicles 104 , each vehicle having an associated on-vehicle computer (e.g., an on-board unit or “OBU” 105 ) and customizable interface 106 .
  • the interface 106 allows a user or machine 106 a to select among various applications, such as third-party applications 108 as well as original, system-supplied applications 110 , to obtain and analyze various data from the vehicles 104 .
  • the applications may include, for example, tools for obtaining real-time fleet characteristics, trend analysis and diagnostics, to perform manual, dynamic or rule-based configuration, as well as allow fleet managers to provide real-time driver/fleet notification.
  • the user interface 106 can be customized to operate applications selected by the user.
  • different types of users 106 a may select different applications as a customized application group 112 to accommodate their specific data monitoring and reporting needs applicable to their own business.
  • a dealer/repair facility may select from the offered applications 108 , 110 , vehicle configuration, scheduled maintenance, remote diagnostics, and concierge services as its application group 112 , while a truck manufacturer may select a different collection of applications 112 , such as warranty service/campaign support, vehicle history, and guided diagnostics.
  • a truck manufacturer may select a different collection of applications 112 , such as warranty service/campaign support, vehicle history, and guided diagnostics.
  • 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 .
  • 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.
  • FIG. 2 is a representative block diagram of system architecture 200 according to an exemplary embodiment.
  • the system architecture shown in FIG. 2 is one possible way for carrying out the functionalities described above and shown in FIG. 1 .
  • the architecture includes three primary components: the interface 106 , a system server 202 , and the on-board unit (OBU) 105 . All three components 106 , 202 , 105 are designed to communicate with each other through any known means, such as via wireless networks 206 ( 1 - 3 ).
  • 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.
  • 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 .
  • the system server 202 acts as a link between a web based client (user) 106 with the OBU 105 , allowing user access and control to a vehicle data stream via the Internet 210 or other Internet working system.
  • 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.
  • the interface 106 may be a standard browser interface and/or a machine-to-machine interface.
  • a human user accesses the system via a standard web browser.
  • the user gains access to the specific set of their authorized vehicles and functions after login and password authorization.
  • server and vehicle data and functions may be accessible via a secure application program interface (API).
  • API application program interface
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • one embodiment of the inventive system allows communication between at least the vehicles 104 and the server 202 via a wireless network, such as a satellite or terrestrial based network.
  • a communication server 202 c may be included in the server 202 to support wireless communications and provide a central location for supporting changes and improvements in wireless technology.
  • the communication server 202 c manages the communications activities between the OBU 105 and the vehicle server 202 b and processes vehicle/component specific requests between the OBU 105 and the vehicle server 202 b.
  • 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 .
  • WCF wireless communications framework
  • 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.
  • 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.
  • 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.
  • 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 .
  • 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.
  • 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.
  • 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).
  • PSTN Public Switch Telephone Network
  • the Internet 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.
  • 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.
  • 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.
  • private-wireline-switching systems may include, for example, private branch exchanges (PBXs) and/or media gateways.
  • PBXs private branch exchanges
  • 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.
  • wireline 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.
  • WOTS wireless office telephone systems
  • WLANs wireless local area networks
  • WLANs wireless local area 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.
  • 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.
  • WAN wide-area network
  • WLAN local area network
  • WLAN Wireless LAN
  • WLAN Wireless LAN
  • each of wireless communication networks can be a standalone WLAN.
  • 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 ( FIG. 1 ).
  • Multiple services might be used to provide for dynamic balancing between messaging costs and message timeliness.
  • different wireless services and technologies may have different application program interfaces (APIs) and/or require custom interfaces for given computing environments.
  • APIs application program interfaces
  • messaging capabilities may differ across different services and technologies.
  • the OBU 105 provides the vehicle-side, real-time computing base for the system.
  • the OBU 105 is responsible for data stream processing, discrete measurements, vehicle position information, wireless communications, and real-time analysis of data.
  • the OBU 105 acts as a vehicle server, providing vehicle specific data and functionality.
  • 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.
  • FIGS. 3A and 3B are representative high-level block diagrams of the OBU 105 .
  • One embodiment of the OBU 105 may include a data processor 300 and one or more interfaces 302 , 304 , and 306 . Included among the interfaces is a wireless interface 302 that may control communication between the OBU 105 and the system server 202 via one of the wireless networks 206 ( 1 - 3 ), a vehicle interface 304 that allows the OBU 105 to transmit to and receive from, for example, electronic control units (ECUs), vehicle controllers, and/or other vehicle components 308 , and an optional user interface 306 that allows a user to read and/or enter information into the OBU 105 .
  • ECUs electronice control units
  • vehicle controllers vehicle controllers
  • FIGS. 3A and 3B are representative high-level block diagrams of the OBU 105 .
  • FIGS. 3A and 3B are representative high-level block diagrams of the OBU 105 .
  • 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 .
  • the processor 300 has the logic and intelligence to carry out vehicle specific services such as diagnostic requests and processing.
  • the processor 300 may run specific applications that are loaded into the OBU's memory 315 , 316 , 318 ( FIG. 3B ) and coordinates activities between the vehicle datastream, GPS unit 313 ( FIG. 3B ), wireless communications 302 , and the system server 202 .
  • the processor 300 can be updated through the one of the wireless networks 206 ( 1 - 3 ) to add and enhance its functionality. This capability eliminates requiring the vehicle to be at the service bay for software updates that enhance features and functionality.
  • 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.
  • 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.
  • a data parser/requester module 310 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.
  • 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.
  • 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 .
  • the OBU 105 uses an interface standard, such as TMC RP 1210 A, 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 .
  • 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 (March 1994) standard, which is incorporated herein by reference in its entirety, because it will be a component included (or installed) within vehicles 104 .
  • 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.
  • 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
  • FIG. 3B illustrates another embodiment of the OBU 105 and explicitly shows the capability to interface with other devices via, for example, a parallel interface, serial interface, universal serial bus (USB), satellite, terrestrial wireless (e.g., 802 . 11 b ), and/or a global positioning system (GPS). More particularly, the embodiment of the OBU 105 shown in FIG. 3B includes a GPS circuit 313 that receives signals from a GPS antenna and a serial interface 314 that communicates with a driver interface or other on-vehicle devices (not shown), such as a handheld device, a cellular telephone, voice messaging system, data logger, or other devices.
  • FIG. 3B illustrates another embodiment of the OBU 105 and explicitly shows the capability to interface with other devices via, for example, a parallel interface, serial interface, universal serial bus (USB), satellite, terrestrial wireless (e.g., 802 . 11 b ), and/or a global positioning system (GPS). More particularly, the embodiment of the OBU 105 shown in FIG. 3
  • FIGS. 3A and 3B also explicitly illustrates a flash memory 315 , a dynamic random access memory 316 , and an optional compact flash memory 318 coupled to the processor 300 as well as a power supply 320 coupled to the vehicle battery and ignition switch (not shown).
  • a flash memory 315 a dynamic random access memory 316
  • an optional compact flash memory 318 coupled to the processor 300 as well as a power supply 320 coupled to the vehicle battery and ignition switch (not shown).
  • 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.
  • FIG. 4 illustrates exemplary architecture 400 of the wireless communication framework (WCF) in accordance with an exemplary embodiment.
  • the WCF may encompass a number of software and/or hardware program and/or application elements for carrying our wireless communications between two wireless nodes.
  • 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 .
  • 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.
  • the server system 202 can be a server for one function, yet a client for another.
  • the remote unit may be a client for one function, and a server for another.
  • the WCF may be distributed among one or more server-system elements 402 and one or more remote-unit elements 404 .
  • 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 .
  • the remote unit may a Personal Digital Assistant (PDA) and/or another computer that can be communicatively coupled with server-side elements 402 .
  • 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.
  • remote-unit application programs 406 a e.g., full or partial application programs that reside on the remote unit
  • remote-unit transport modules 410 a e.g., full or partial application programs that reside on the remote unit
  • intermediary remote-unit WCF modules 408 a e.g., one or more intermediary remote-unit WCF modules 408 a.
  • 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.
  • the transport modules 410 a , 410 b may be deployed as one or more different software programs, software modules, and/or hardware modules for connecting and interacting with various communication networks, such as the wireless communication networks 206 ( 1 - 3 ).
  • the transport modules 410 a , 410 b provide one or more interfaces through which the application programs 406 a , 406 b couple to the WCF modules 408 a , 408 b.
  • 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.
  • server-system and/or remote unit communication adapters e.g., modems
  • 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.
  • 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.
  • 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 may have access to the wireless communication network 206 ( 3 ) (e.g., a WLAN) in addition to the other communication networks.
  • the server-system transport modules 410 b may be configured to access wireless communication network 206 ( 3 ) as well.
  • 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 ).
  • 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.
  • 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.
  • FIG. 5 illustrates the WCF modules 408 a , 408 b in greater detail.
  • the WCF modules 408 a , 408 b may be deployed with a messaging Application Program Interface (messaging API) 512 , a message manager 514 , a transport manager 516 , message-storage manager 518 , a message store 520 , ordered delivery manager 522 , a least-cost routing manager 524 , and a multi-part message manager 526 .
  • messages API messaging Application Program Interface
  • WCF modules 408 a , 408 b may be deployed in both the remote-unit and server-system elements 402 , 404 .
  • function calls may be used to establish communication between the concentrated elements.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • transport providers e.g., the providers of wireless communication networks 206 ( 1 - 3 )
  • the messaging API 512 may provide hooks or other access interfaces to the application programs to achieve communication without substantial custom programming.
  • 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.
  • 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.
  • 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.
  • 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 .
  • 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.
  • 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.
  • 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.
  • 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 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 ).
  • the multi-part message manager 526 can disassemble the message into the smaller 16 and/or 32 byte chunks.
  • 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.
  • the added number of smaller chunks 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.
  • the multi-part message manager 526 may more optimally disassemble the message using the larger 32 byte chunks.
  • 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.
  • larger chunk size may be beneficial for larger message sizes, the smaller chunk size may be more beneficial for smaller available message sizes.
  • 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 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.
  • 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.
  • the probability that a message will get through a network without unacceptable retry attempts increases.
  • 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.
  • 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.
  • 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.
  • 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.
  • a record e.g., a table
  • 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.
  • 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 .
  • 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.
  • 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.
  • the WCF may use the encryption services provided by the network service providers in lieu of the services provided by the WCF.
  • 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.
  • the WCF may use the compression services provided by the network service providers in lieu of the services provided by the WCF.
  • 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.
  • 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.
  • the WCF may be extended to incorporate the changes.
  • New compression and encryption modules may be used to support non-standard and proprietary protocols.
  • the WCF may be ported to between platforms and systems.
  • 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+.
  • COM Computer Object Model
  • 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 .
  • 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.
  • 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.
  • FIG. 6 illustrates a flow chart depicting a communication flow 600 between the service server 202 and the OBU 105 .
  • the following describes the flow 600 of one or more messages originating from the system server 202 and terminating at the OBU 105 .
  • the flow 600 may also be carried out in the reverse direction, i.e., originating from the OBU 105 and terminating at the system server 202 .
  • other devices besides the server system 202 and the OBU 105 may carry out the following flow 600 .
  • 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 .
  • 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 ).
  • 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 .
  • 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.
  • the messages are dispatched through the selected transport module 410 b for the desired wireless communication networks 206 ( 1 - 3 ).
  • 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 .
  • 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 .
  • 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 .
  • the messages are sent to one or more of the application programs 406 b via the messaging API 512 .
  • the message manager 514 may be used to provide 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.
  • 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.
  • ordered delivery manager 518 can provide order delivery processing of the messages or message chunks.
  • one or more of the application programs 406 b may assign a particular order to a plurality of the messages.
  • 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.
  • the messaging API 512 communicates with the transport module 410 b of a desired network 206 ( 1 - 3 ) via a transport-send agent of the transport manager 516 to query whether the transport module 410 b is allowed to send messages as shown in block 702 . This ensures that the OBU 105 is within range to receive messages before any message is dispatched. Determining whether the OBU 105 is within range of the network 206 ( 1 - 3 ) may be facilitated using capabilities of the communication hardware and software of the OBU 105 , as is known to one skilled in the art.
  • 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.
  • the multi-part message manager 526 may disassemble large messages that exceed the maximum allowable size of the selected network 206 ( 1 - 3 ).
  • messages sent to the messaging API 512 from the application program 406 b are tested to determine whether they exceed the maximum allowable size for the selected network 206 ( 1 - 3 ). If the message size does not exceed this limit, the messages are dispatched according to the flow described in FIG. 6 as shown in block 708 .
  • 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.
  • the oversized messages may be disassembled as shown in 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 .
  • 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 ).
  • the messages along with re-assembly information are received in the multi-part message manager 526 of the OBU 105 .
  • 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.
  • the messages are sent to the application program 410 a of the OBU 105 as shown in block 722 .
  • 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 .
  • FIG. 8 illustrates a flow chart depicting another communication flow 800 between the service server 202 and the OBU 105 .
  • communication flow 800 one or more messages are dispatched from the server system 202 to a remote unit, such as OBU 105 .
  • the flow 800 may also be carried out by in the reverse direction, i.e., originating from the OBU 105 and terminating at the server system 202 .
  • other devices besides the server system 202 and the OBU 105 may carry out the following flow.
  • the server-system portion of the WCF architecture receives one or more messages from one or more of the application programs 410 b .
  • 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.
  • 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 .
  • multi-formatted or mix processing may be carried out if the message priority is assigned by the application programs 410 b .
  • 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 .
  • the overall system 100 can support many possible services and applications, examples of which are described below and illustrated in FIGS. 9 through 13 .
  • the system 100 shown in FIGS. 1 and 2 illustrate one possible relationship between services and applications for a system 100 using an ASP-based model.
  • a group of core services 350 that perform vehicle-specific operations are available to the applications 108 , 110 .
  • the applications 108 , 110 allow a user to customize the interpretation and display of the vehicle-specific operations based on the user's own requirements.
  • the core services 350 act as building blocks of services that can be selected or combined in any desired manner, and can be accessed by or with any applications 108 , 110 in the system 100 ; in other words, the applications 108 , 110 act as a functional layer over the more primitive core services 350 .
  • the core services 350 may be accessed by a help desk application to obtain vehicle location along with parametric data or by a service application to obtain parametric data and to perform functional tests. Because the system 100 can leverage other applications and services that the system 100 itself may not have and couple them with its own applications and services, the system 100 provides a flexible and adaptable platform that can accommodate many different needs.
  • the applications may assemble the core services to perform specific functions.
  • 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.
  • the interface 106 can be a browser interface or graphical user interface (GUI) that allows a human user to access the system 100 , or a machine-to-machine application programming interface (API).
  • GUI graphical user interface
  • API application programming interface
  • the user interface 106 allows the system 100 to act as a gateway between the user and the vehicle(s) 104 via the applications and services.
  • 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.
  • FIG. 9 illustrates one simple process 900 for obtaining a parameter.
  • the OBU 105 receives a command from the system server 202 to retrieve a data value at block 902 , the OBU 105 sends a query message to the ECU 308 to obtain the ECU's current reading at block 904 . Once the ECU 308 returns a parameter value at block 906 , the OBU 105 retrieves the value and forwards it to the system server 202 at block 908 .
  • frequently used parameters may be packaged and transmitted to the system server 202 as a single message as a more efficient way of transferring data.
  • the specific means for getting a particular data item may depend on the specific requirements of a given ECU 308 . For example, as is known in the art, data points corresponding to an anti-lock brake system may be obtained in a different manner than data corresponding to engine coolant temperature.
  • FIG. 10 is a flowchart illustrating one possible process to be offered as a “Parameters” service that is more sophisticated that the simple parameter retrieval service explained above.
  • the “Parameters” service can also provide more sophisticated parameter data capture methods such as the type shown in FIG. 10 .
  • FIG. 10 illustrates a “snapshot” process 1000 for obtaining a set of parameter values over a period of time, where the reporting of the parameter values is triggered by a specified event. Offering this service as an on-vehicle diagnostic tool is particularly helpful for intermittent fault diagnosis and vehicle performance analysis. Further, gathering data sets at prescribed periodic intervals minimizes negative effects caused by inherent problems in wireless communication systems, such communications drop-out and lack of coverage, which would normally make remote diagnostics ineffective.
  • 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.
  • 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.
  • 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.
  • GSV get stored values
  • FIG. 11 Another possible process that can be offered as a “Parameters” service is a “get stored values” (GSV) process 1100 , as illustrated in FIG. 11 , for collecting parameter values from a vehicle even if the vehicle is unable to provide current parameter values at the time of the query.
  • the GSV process 1100 addresses a situation where the vehicle controllers 308 are unable to respond to a query by the OBU 105 (e.g., while the vehicle is turned off) to respond to a query.
  • This process is particularly useful in applications requiring remote retrieval of time-sensitive data, such as an odometer reading at the end of a scheduled period, or in any application where the vehicle operating state is unknown at the time of the query.
  • 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.
  • 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 ).
  • the OBU 105 can at least obtain recent vehicle controller parameter readings before the controller 308 is inaccessible at some later time.
  • 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.
  • 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.
  • the “Alert” service monitors vehicle trouble codes and transmits a message to the OBU 105 when the trouble code occurs.
  • a fault code may come as solicited or unsolicited, depending on how the controller 308 in the OBU 105 is instructed to handle faults.
  • 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 .
  • the user may set up periodic queries to the OBU processor 300 in addition to setup notification.
  • 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.
  • 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.
  • the “Alerts” service may include among its functions the detection of a particular event by checking whether a monitored value exceeds a selected threshold. Note that although this example focuses on one diagnostic parameter, any number of diagnostic parameters may be combined into an algorithm to detect threshold limit boundaries. Further, values may be monitored over time, rather than as one single alert-triggering event, to monitor patterns and trends and to detect events more accurately.
  • FIG. 12 shows an “Over RPM” threshold alert example that detects if a vehicle driver is abusing the vehicle engine.
  • the Over RPM threshold alert considers the amount of time that the RPM level exceeds a specified limit (6000 RPM in this example) rather than simply generating an alert each time the RPM exceeds the level. The time delay ensures that alerts are generated only for events that may cause genuine concern.
  • the “Alert” service does not generate an alert. However, if the RPM does exceed 6000 RPM for more than two seconds (at 1204 ), the service fires an alert 1206 and resets itself (at 1208 ) when the RPM drops back below 6000 RPM.
  • the actual circuitry for monitoring RPM and implementing this example of the “Alert” service in the system 100 is well within the skill of those in the art. Further, the time delay concept shown in FIG. 12 can be used for any parameter where undesirable operation is preferably detected via time and value thresholds.
  • the “Alert” services may also include a tamper alert feature that, as shown in FIG. 13 , allows the user to monitor any unauthorized alteration of configurable parameters.
  • This feature 1300 generally contains a setup process 1302 and a tamper check process 1304 .
  • the OBU 105 captures the value of the parameter at the time of the request and saves the parameter value to a file in the OBU's memory (e.g., OBU's flash memory 315 or DRAM 316 ) at block 1308 .
  • this parameter retrieval process may involve using the “Parameters” service as explained above to query the ECU or other vehicle controller or component 308 .
  • the actual tamper check process is conducted when, for example, the vehicle is initially turned on.
  • 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 ).
  • 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 FIG. 14 .
  • This feature may allow a user to remotely insert or update, for example, a parameter or message definition in the vehicle.
  • the function 1400 includes receiving a parameter change request (block 1402 ), receiving the specific parameter to be changed in the vehicle (block 1404 ), changing the parameter (block 1406 ), and saving the parameter in memory (block 1408 ).
  • the updated parameter definitions are stored permanently in memory until the next change request. Further, in one embodiment, the updated definition takes effect as soon as the update is completed.
  • 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.
  • 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.
  • the application may provide diagnostic applications via the inventive system 100 .
  • 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.
  • the user may elect to use a remote diagnostics application, such as the remote diagnostics application described below and shown in FIG. 15, 1513 , to perform further analysis on the vehicle to determine the severity of the problem.
  • FIG. 15 is a block diagram illustrating one possible overall web site architecture 1500 that includes a remote diagnostics application.
  • a user may log into the application (block 1502 ) to reach an application home page 1504 . From the home page, the user may access a range of information, such as fuel economy 1506 or leased vehicle information 1508 , or access utilities 1510 or a remote diagnostics application (RDA) page 1512 to monitor, diagnose, and/or reprogram vehicle parameters.
  • the utilities 1510 allow the user to define and/or modify vehicle groups 1514 , specific vehicles 1516 , and alerts 1518 .
  • the RDA page 1512 provides users with access to, for example, vehicle information and parameters 1520 , including pages that allowing parameter viewing 1522 and reprogramming 1524 . Note that other architectures and implementations are possible for this application as well as other applications without departing from the scope of the invention.
  • FIG. 16 is a block diagram illustrating one possible example architecture for the Leased Vehicle Management application 1600 .
  • the user reaches a main page 1602 that allows the user to choose between a group details page 1602 and the task details page 1606 .
  • Group details 1604 correspond to all information for a selected vehicle group, while task details 1606 correspond to all information for a selected task.
  • the group details page 1604 may allow the user to, for example, create new tasks (e.g., the timing of data collection for a selected vehicle group) 1608 , generate a report list 1610 , or generate more detailed reports listing specifying, for example, parameter values for a selected report 1612 .
  • the task details page 1606 includes similar options, allowing the user to view reports for a selected task 1614 and generate more detailed reports 1616 .
  • the task details page 1606 also allows a user to stop a task 1618 or delete a task 1620 .
  • 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.
  • operational characteristics in particular, horsepower ratings and maximum road speed limits.
  • Such operating parameters have been established once at a fleet wide level, not taking into consideration some of the variables listed above.
  • 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.
  • 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.
  • the possible modular applications described herein are meant as illustrative examples only.
  • 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.
  • 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 .
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.

Abstract

A system and method for monitoring, configuring, programming and/or diagnosing operation of at least one vehicle includes 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.

Description

    CROSS REFERENCE TO RELATED APPLICATIONS
  • 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.
  • BACKGROUND
  • 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.
  • SUMMARY
  • 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.
  • BRIEF DESCRIPTION OF DRAWINGS
  • 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:
  • FIG. 1 is a representative functional block diagram illustrating an overall system according to one embodiment of the present invention;
  • FIG. 2 is a representative block diagram illustrating a system architecture according to one embodiment of the present invention;
  • FIGS. 3A and 3B are representative block diagrams of one embodiment of an on-board unit in one embodiment of the present invention;
  • FIG. 4 is a representative block diagram of a wireless communication system according to one embodiment of the present invention;
  • FIG. 5 is a representative block diagram of a wireless communication framework for a wireless communication system according to one embodiment of the present invention;
  • FIG. 6 is a flow chart depicting the operation of a wireless communication system according to one embodiment of the present invention;
  • FIG. 7 is another flow chart depicting the operation of a wireless communication system according to one embodiment of the present invention;
  • FIG. 8 is yet another flow chart depicting the operation of a wireless communication system according to one embodiment of the present invention;
  • FIG. 9 is a block diagram of a parameter retrieval process according to one embodiment of the present invention;
  • FIG. 10 is a block diagram of a parameter retrieval process according to another embodiment of the present invention;
  • FIG. 11 is a block diagram of a parameter retrieval process according to yet another embodiment of the present invention;
  • FIG. 12 is a graph illustrating the operation of a threshold alert process according to one embodiment of the present invention;
  • FIG. 13 is a block diagram illustrating the operation of a tamper alert process according to one embodiment of the present invention;
  • FIG. 14 is a block diagram illustrating a parameter change process according to one embodiment of the invention;
  • FIG. 15 is a block diagram illustrating one possible architecture for a remote diagnostics application to be used in one embodiment of the present invention; and
  • FIG. 16 is a block diagram illustrating one possible architecture of a leased vehicle management application to use in one embodiment of the present invention.
  • DETAILED DESCRIPTION
  • 1. System Functionalities and Architecture
  • FIG. 1 is a representative functional diagram of a vehicle monitoring and diagnostics system 100 according to an exemplary embodiment. Generally, the inventive system 100 allows monitoring and control of a vehicle fleet by displaying and controlling data according to a user's customized specifications. The system 100 is designed with modular applications that interact with core data and services so that vehicle parameters can be monitored, analyzed and displayed in a format that is meaningful to a particular user and/or a particular industry. This flexibility allows different users and/or industries to use the same overall system 100 for vehicle and component monitoring despite their disparate vehicle data requirements.
  • Referring to FIG. 1, the system 100 may include an application service provider (ASP) infrastructure 102 that acts as a gateway between a plurality of vehicles 104, each vehicle having an associated on-vehicle computer (e.g., an on-board unit or “OBU” 105) and customizable interface 106. The interface 106 allows a user or machine 106 a to select among various applications, such as third-party applications 108 as well as original, system-supplied applications 110, to obtain and analyze various data from the vehicles 104. The applications may include, for example, tools for obtaining real-time fleet characteristics, trend analysis and diagnostics, to perform manual, dynamic or rule-based configuration, as well as allow fleet managers to provide real-time driver/fleet notification. To ensure that the user receives data that is meaningful to the user's specific application, the user interface 106 can be customized to operate applications selected by the user. In the example shown in FIG. 1, different types of users 106 a may select different applications as a customized application group 112 to accommodate their specific data monitoring and reporting needs applicable to their own business.
  • For example, as illustrated in FIG. 1, a dealer/repair facility may select from the offered applications 108, 110, vehicle configuration, scheduled maintenance, remote diagnostics, and concierge services as its application group 112, while a truck manufacturer may select a different collection of applications 112, such as warranty service/campaign support, vehicle history, and guided diagnostics. By offering a variety of modular applications 108, 110 that can be selected and combined according to the needs of a particular user, the same infrastructure 102 can be customized and used by different users for different purposes with little or no modification of the infrastructure 102 itself. Further, by allowing users to access third-party applications 108 through the same infrastructure as system supplied applications 110, the system 100 can leverage services not provided by the system 100 itself, further increasing flexibility and adaptability.
  • 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.
  • FIG. 2 is a representative block diagram of system architecture 200 according to an exemplary embodiment. The system architecture shown in FIG. 2 is one possible way for carrying out the functionalities described above and shown in FIG. 1. In this example, the architecture includes three primary components: the interface 106, a system server 202, and the on-board unit (OBU) 105. All three components 106, 202, 105 are designed to communicate with each other through any known means, such as via wireless networks 206(1-3).
  • 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 FIG. 2, the system server 202 acts as a link between a web based client (user) 106 with the OBU 105, allowing user access and control to a vehicle data stream via the Internet 210 or other Internet working system.
  • 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.
  • (A) Interface
  • 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.
  • (B) Server
  • 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 FIG. 2, one embodiment of the inventive system allows communication between at least the vehicles 104 and the server 202 via a wireless network, such as a satellite or terrestrial based network. A communication server 202 c may be included in the server 202 to support wireless communications and provide a central location for supporting changes and improvements in wireless technology. In one embodiment, the communication server 202 c manages the communications activities between the OBU 105 and the vehicle server 202 b and processes vehicle/component specific requests between the OBU 105 and the vehicle server 202 b.
  • 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 (FIG. 1). Multiple services might be used to provide for dynamic balancing between messaging costs and message timeliness. In addition, different wireless services and technologies may have different application program interfaces (APIs) and/or require custom interfaces for given computing environments. Moreover, messaging capabilities may differ across different services and technologies.
  • (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.
  • FIGS. 3A and 3B are representative high-level block diagrams of the OBU 105. One embodiment of the OBU 105 may include a data processor 300 and one or more interfaces 302, 304, and 306. Included among the interfaces is a wireless interface 302 that may control communication between the OBU 105 and the system server 202 via one of the wireless networks 206(1-3), a vehicle interface 304 that allows the OBU 105 to transmit to and receive from, for example, electronic control units (ECUs), vehicle controllers, and/or other vehicle components 308, and an optional user interface 306 that allows a user to read and/or enter information into the OBU 105.
  • 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 (FIG. 3B) and coordinates activities between the vehicle datastream, GPS unit 313 (FIG. 3B), wireless communications 302, and the system server 202. Further, in one embodiment, the processor 300 can be updated through the one of the wireless networks 206(1-3) to add and enhance its functionality. This capability eliminates requiring the vehicle to be at the service bay for software updates that enhance features and functionality.
  • 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.
  • FIG. 3B illustrates another embodiment of the OBU 105 and explicitly shows the capability to interface with other devices via, for example, a parallel interface, serial interface, universal serial bus (USB), satellite, terrestrial wireless (e.g., 802.11 b), and/or a global positioning system (GPS). More particularly, the embodiment of the OBU 105 shown in FIG. 3B includes a GPS circuit 313 that receives signals from a GPS antenna and a serial interface 314 that communicates with a driver interface or other on-vehicle devices (not shown), such as a handheld device, a cellular telephone, voice messaging system, data logger, or other devices. FIG. 3B also explicitly illustrates a flash memory 315, a dynamic random access memory 316, and an optional compact flash memory 318 coupled to the processor 300 as well as a power supply 320 coupled to the vehicle battery and ignition switch (not shown). Those of skill in the art will understand that the elements and concepts shown in FIGS. 3A and 3B can be combined in any manner without departing from the scope of the present embodiment.
  • 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
  • FIG. 4 illustrates exemplary architecture 400 of the wireless communication framework (WCF) in accordance with an exemplary embodiment. The WCF may encompass a number of software and/or hardware program and/or application elements for carrying our wireless communications between two wireless nodes.
  • 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 FIG. 4, the transport modules 410 a, 410 b, alone or as a complementary pair, may be deployed as one or more different software programs, software modules, and/or hardware modules for connecting and interacting with various communication networks, such as the wireless communication networks 206(1-3). The transport modules 410 a, 410 b provide one or more interfaces through which the application programs 406 a, 406 b couple to the WCF modules 408 a, 408 b.
  • 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
  • FIG. 5 illustrates the WCF modules 408 a, 408 b in greater detail. The WCF modules 408 a, 408 b may be deployed with a messaging Application Program Interface (messaging API) 512, a message manager 514, a transport manager 516, message-storage manager 518, a message store 520, ordered delivery manager 522, a least-cost routing manager 524, and a multi-part message manager 526.
  • 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
  • FIG. 6 illustrates a flow chart depicting a communication flow 600 between the service server 202 and the OBU 105. The following describes the flow 600 of one or more messages originating from the system server 202 and terminating at the OBU 105. The flow 600, however, may also be carried out in the reverse direction, i.e., originating from the OBU 105 and terminating at the system server 202. Moreover, other devices besides the server system 202 and the OBU 105 may carry out the following flow 600.
  • 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 FIG. 7, a communication flow 700 illustrating a dispatch of one or more messages via the messaging API 512 is described in greater detail. The messaging API 512 communicates with the transport module 410 b of a desired network 206(1-3) via a transport-send agent of the transport manager 516 to query whether the transport module 410 b is allowed to send messages as shown in block 702. This ensures that the OBU 105 is within range to receive messages before any message is dispatched. Determining whether the OBU 105 is within range of the network 206(1-3) may be facilitated using capabilities of the communication hardware and software of the OBU 105, as is known to one skilled in the art.
  • 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 FIG. 7, the operation of the multi-part message manager 526 is described in greater detail. As noted, the multi-part message manager 526 may disassemble large messages that exceed the maximum allowable size of the selected network 206(1-3). In block 706, messages sent to the messaging API 512 from the application program 406 b are tested to determine whether they exceed the maximum allowable size for the selected network 206(1-3). If the message size does not exceed this limit, the messages are dispatched according to the flow described in FIG. 6 as shown in block 708.
  • 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.
  • FIG. 8 illustrates a flow chart depicting another communication flow 800 between the service server 202 and the OBU 105. In communication flow 800, one or more messages are dispatched from the server system 202 to a remote unit, such as OBU 105. Like above, the flow 800 may also be carried out by in the reverse direction, i.e., originating from the OBU 105 and terminating at the server system 202. Moreover, other devices besides the server system 202 and the OBU 105 may carry out the following flow.
  • 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 FIGS. 9 through 13. As noted above, the system 100 shown in FIGS. 1 and 2 illustrate one possible relationship between services and applications for a system 100 using an ASP-based model. In one embodiment, a group of core services 350 that perform vehicle-specific operations are available to the applications 108, 110. As noted above, the applications 108, 110 allow a user to customize the interpretation and display of the vehicle-specific operations based on the user's own requirements. The core services 350 act as building blocks of services that can be selected or combined in any desired manner, and can be accessed by or with any applications 108, 110 in the system 100; in other words, the applications 108, 110 act as a functional layer over the more primitive core services 350. For example, the core services 350 may be accessed by a help desk application to obtain vehicle location along with parametric data or by a service application to obtain parametric data and to perform functional tests. Because the system 100 can leverage other applications and services that the system 100 itself may not have and couple them with its own applications and services, the system 100 provides a flexible and adaptable platform that can accommodate many different needs.
  • 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 FIGS. 1 and 2, the interface 106 can be a browser interface or graphical user interface (GUI) that allows a human user to access the system 100, or a machine-to-machine application programming interface (API). The user interface 106 allows the system 100 to act as a gateway between the user and the vehicle(s) 104 via the applications and services.
  • 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:
      • Parameters: obtains discrete or data stream-based vehicle parameters, including standard and proprietary messages, upon user request;
      • Alerts: notification of the occurrence of a particular event (e.g., receipt of a trouble code or a notification of a parameter value occurring outside an acceptable parameter range);
      • Functions: runs functional tests on vehicle components and generates result reports;
      • Configuration: performs remote configuration of a vehicle or component by, for example, changing one or more vehicle parameters;
      • Reprogramming: performs complete reprogramming, or “re-flashing” of a selected on-vehicle controller;
      • Geographic location: provides vehicle location through, for example, a GPS system.
  • 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. FIG. 9 illustrates one simple process 900 for obtaining a parameter. When the OBU 105 receives a command from the system server 202 to retrieve a data value at block 902, the OBU 105 sends a query message to the ECU 308 to obtain the ECU's current reading at block 904. Once the ECU 308 returns a parameter value at block 906, the OBU 105 retrieves the value and forwards it to the system server 202 at block 908. Note that frequently used parameters may be packaged and transmitted to the system server 202 as a single message as a more efficient way of transferring data. Further, the specific means for getting a particular data item may depend on the specific requirements of a given ECU 308. For example, as is known in the art, data points corresponding to an anti-lock brake system may be obtained in a different manner than data corresponding to engine coolant temperature.
  • FIG. 10 is a flowchart illustrating one possible process to be offered as a “Parameters” service that is more sophisticated that the simple parameter retrieval service explained above. Although parameter data can simply be read from the vehicle's electronic controllers and provided to the user on demand, the “Parameters” service can also provide more sophisticated parameter data capture methods such as the type shown in FIG. 10. FIG. 10 illustrates a “snapshot” process 1000 for obtaining a set of parameter values over a period of time, where the reporting of the parameter values is triggered by a specified event. Offering this service as an on-vehicle diagnostic tool is particularly helpful for intermittent fault diagnosis and vehicle performance analysis. Further, gathering data sets at prescribed periodic intervals minimizes negative effects caused by inherent problems in wireless communication systems, such communications drop-out and lack of coverage, which would normally make remote diagnostics ineffective.
  • 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 FIG. 11, for collecting parameter values from a vehicle even if the vehicle is unable to provide current parameter values at the time of the query. The GSV process 1100 addresses a situation where the vehicle controllers 308 are unable to respond to a query by the OBU 105 (e.g., while the vehicle is turned off) to respond to a query. This process is particularly useful in applications requiring remote retrieval of time-sensitive data, such as an odometer reading at the end of a scheduled period, or in any application where the vehicle operating state is unknown at the time of the query.
  • 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 FIG. 12 and as noted above, the “Alerts” service may include among its functions the detection of a particular event by checking whether a monitored value exceeds a selected threshold. Note that although this example focuses on one diagnostic parameter, any number of diagnostic parameters may be combined into an algorithm to detect threshold limit boundaries. Further, values may be monitored over time, rather than as one single alert-triggering event, to monitor patterns and trends and to detect events more accurately.
  • As an example of an “Alert” service that monitors over time, FIG. 12 shows an “Over RPM” threshold alert example that detects if a vehicle driver is abusing the vehicle engine. In this example, the Over RPM threshold alert considers the amount of time that the RPM level exceeds a specified limit (6000 RPM in this example) rather than simply generating an alert each time the RPM exceeds the level. The time delay ensures that alerts are generated only for events that may cause genuine concern.
  • As shown in FIG. 12, if the RPM exceeds 6000 RPM for a brief period that is less than 2 seconds (at 1202), the “Alert” service does not generate an alert. However, if the RPM does exceed 6000 RPM for more than two seconds (at 1204), the service fires an alert 1206 and resets itself (at 1208) when the RPM drops back below 6000 RPM. The actual circuitry for monitoring RPM and implementing this example of the “Alert” service in the system 100 (e.g., on the OBU 105) is well within the skill of those in the art. Further, the time delay concept shown in FIG. 12 can be used for any parameter where undesirable operation is preferably detected via time and value thresholds.
  • The “Alert” services may also include a tamper alert feature that, as shown in FIG. 13, allows the user to monitor any unauthorized alteration of configurable parameters. This feature 1300 generally contains a setup process 1302 and a tamper check process 1304. When a user requests the tamper alert service (block 1306), the OBU 105 captures the value of the parameter at the time of the request and saves the parameter value to a file in the OBU's memory (e.g., OBU's flash memory 315 or DRAM 316) at block 1308. Note that this parameter retrieval process may involve using the “Parameters” service as explained above to query the ECU or other vehicle controller or component 308.
  • 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 FIG. 14. This feature may allow a user to remotely insert or update, for example, a parameter or message definition in the vehicle. As shown in FIG. 14, the function 1400 includes receiving a parameter change request (block 1402), receiving the specific parameter to be changed in the vehicle (block 1404), changing the parameter (block 1406), and saving the parameter in memory (block 1408). In one embodiment, the updated parameter definitions are stored permanently in memory until the next change request. Further, in one embodiment, the updated definition takes effect as soon as the update is completed.
  • 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.
  • 4 Applications
  • 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 FIG. 15, 1513, to perform further analysis on the vehicle to determine the severity of the problem.
  • FIG. 15 is a block diagram illustrating one possible overall web site architecture 1500 that includes a remote diagnostics application. In this example, a user may log into the application (block 1502) to reach an application home page 1504. From the home page, the user may access a range of information, such as fuel economy 1506 or leased vehicle information 1508, or access utilities 1510 or a remote diagnostics application (RDA) page 1512 to monitor, diagnose, and/or reprogram vehicle parameters. In this example, the utilities 1510 allow the user to define and/or modify vehicle groups 1514, specific vehicles 1516, and alerts 1518. The RDA page 1512 provides users with access to, for example, vehicle information and parameters 1520, including pages that allowing parameter viewing 1522 and reprogramming 1524. Note that other architectures and implementations are possible for this application as well as other applications without departing from the scope of the invention.
  • 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. FIG. 16 is a block diagram illustrating one possible example architecture for the Leased Vehicle Management application 1600. In this example, the user reaches a main page 1602 that allows the user to choose between a group details page 1602 and the task details page 1606. Group details 1604 correspond to all information for a selected vehicle group, while task details 1606 correspond to all information for a selected task. The group details page 1604 may allow the user to, for example, create new tasks (e.g., the timing of data collection for a selected vehicle group) 1608, generate a report list 1610, or generate more detailed reports listing specifying, for example, parameter values for a selected report 1612. The task details page 1606 includes similar options, allowing the user to view reports for a selected task 1614 and generate more detailed reports 1616. The task details page 1606 also allows a user to stop a task 1618 or delete a task 1620.
  • 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.

Claims (37)

1-44 (Cancelled)
45. A system comprising:
at least one application program operable to originate to and terminate from a target unit electronic messages;
at least one transport module for exchanging with the target unit the electronic messages originated to and terminated from the at least one application program, the at least one transport module adapted to provide connectivity to the target unit via at least one of a plurality of networks; and
a communication framework adapted to select one of the at least one transport module based on dynamic-delivery policies, and in turn, to pass between the selected at least one transport modules and the application program the electronic messages originated to and terminated from the target unit.
46. The system of claim 45, wherein the at least one application program specifies delivery parameters for carrying out electronic messaging with the target unit.
47. The system of claim 45, wherein each of the plurality of networks is of a different communication format type, wherein each of the at least one transport module abstracts parameters indicative of one of the different communication format types to provide connectivity to the target unit via at least one of the plurality of networks, and wherein when the communication framework selects one of the at least one transport module of a given communication format type based on dynamic-delivery policies, it passes between the selected one of the at least one transport module and the application program the electronic messages originated to and terminate from the target unit according to the communication format corresponding to the given communication format type.
48. The system of claim 45, wherein the communication framework includes a multi-part message manager adapted to disassemble messages from the application program and reassemble incoming messages received across one of the plurality of networks from the target unit.
49. The system of claim 45, wherein the wireless communication framework is adapted to determine which of the plurality of networks are available to the target, and wherein the wireless communication framework is adapted to select the one or more of the plurality of transport modules that corresponds to the plurality of networks that are available to the target.
50. The system of claim 45, wherein the communication framework includes a message storage manager adapted to store the message until the message has been successfully transferred or delivered.
51. The system of claim 45, wherein the at least one of the plurality of networks is a wireless network.
52. A method for effectuating messaging between a computer and a target unit, the method comprising:
providing a computer including an application program and a communication framework;
dispatching the message from the application program to the communication framework;
processing the message in the communication framework to select at least one of a plurality of transport modules based dynamic-delivery processes, each of the plurality of transport modules being configured to connect to a respective one of a plurality of networks to establish messaging across the respective one of the plurality of networks; and
dispatching the message across a respective one of the networks to the target unit via the selected at least one of the plurality of transport modules.
53. The method of claim 52, wherein the step of processing the message in the communication framework includes:
identifying a priority assigned to the message by the application program; and
selecting the transport module based on the priority assigned by the application program.
54. The method of claim 53, wherein the step of processing the message further comprises:
selecting at least one transport module corresponding to a reliable network when the priority of the message is high; and
selecting at least one transport module corresponding to a low cost network when the priority of the message is low.
55. The method of claim 53, further comprising:
selecting a first of the least one the transport module that corresponds to a low cost network when the priority of the message is mix processing;
attempting to dispatch the message through the low cost network over a predetermined time period;
selecting a second of the at least one transport module that corresponds to a higher-cost network if the message is unable to be dispatched through the low cost network by a completion of the predetermined time period; and
dispatching the message across the higher-cost network.
56. The method according to claim 53, further comprising:
batching the message with a plurality of other messages when the priority of the message is batch priority; and
dispatching the message in the dispatching step when a predetermined number of the other messages are batched with the message.
57. The method of claim 53, wherein the step of processing the message further comprises:
determining which of the plurality of networks are available to the target unit; and
selecting at least one of the plurality of transport modules in the processing the message step that corresponds to one of the available networks.
58. The method of claim 53, further comprising the steps of:
maintaining the message in a storage area hosted by the communication framework when the message is unable to be transmitted to the target unit; and
transmitting the message to the target unit when the target unit is available for transmission.
59. The method of claim 52, further comprising:
disassembling the message into a plurality of chunks during the step of processing the message; and
transmitting the plurality of the chunks to the target unit during the step of dispatching.
60. The method of claim 59, wherein the step of disassembling comprises:
disassembling the message into a first predetermined chunk size if an available message size of the network corresponding to the selected transport module is greater than a prescribed size; and
disassembling the message into a second predetermined chunk size if the available message size of the network corresponding to the selected transport module is less than the prescribed size.
61. The method of claim 59, further comprising maintaining a record of what portion of the plurality of chunks has been sent to the target unit.
62. The method of claim 52, further comprising:
receiving a disassembled message in the communication framework across one of the plurality of networks from the target unit;
reassembling chunks of the disassembled message to form an assembled message; and
transmitting the assembled message to the application program.
63. The method of claim 52, further comprising:
determining if the message is to be sent using reliable delivery in the step of processing the message;
dispatching the message without requiring an acknowledgement when the message is to be sent using non-reliable delivery; and
requiring an acknowledgement from the target unit to verify receipt of the message after the dispatching step when the message is to be sent using reliable delivery.
64. The method of claim 52, further comprising:
assigning an order to the message, by the application program, with respect to at least one other message to form a plurality of prioritized messages in a priority order;
maintaining the message in the communication framework until all of the plurality of prioritized messages are received in the communication framework; and
dispatching each of the prioritized messages according to the priority order.
65. The method of claim 52, wherein the network is a wireless network.
66. The method of claim 52, wherein the network is a satellite network.
67. A method for effectuating messaging between a first unit and a second unit, the method comprising the steps of:
providing the first unit including a first plurality of application programs and a first communication framework, the first communication framework adapted to provide messaging capabilities for each of the first plurality of application programs;
providing the second unit including a second plurality of application programs and a second communication framework, the second communication framework adapted to provide messaging capabilities for each of the second plurality of application programs;
dispatching a message from one of the first application programs to the first communication framework;
processing the message with the first communication framework;
dispatching the message from the first communication framework to the second communication framework via a network;
processing the message with the second communication framework; and
dispatching the message to one of the second application programs.
68. The method of claim 67, wherein the step of processing the message with the first communication framework further comprises selecting at least one of a plurality of transport modules corresponding to the network based on dynamic-delivery policies, each of the plurality of transport modules configured to connect to a respective one of a plurality of networks to establish messaging across the respective one of the plurality of networks.
69. The method of claim 68, wherein the step of processing the message in the first communication framework includes:
identifying a priority assigned to the message by the application program;
selecting at least one transport module corresponding to a reliable network when the priority of the message is high; and
selecting the transport module corresponding to a low cost network when the priority of the message is low.
70. The method of claim 69, further comprising:
selecting a first of the plurality of transport modules that corresponds to a low cost network when the priority of the message is mix processing;
attempting to dispatch the message through the low cost network over a predetermined time period;
selecting a second of the plurality of transport modules that corresponds to a reliable network when the message is unable to be dispatched through the low cost network by a completion of the predetermined time period; and
dispatching the message across the reliable network.
71. The method of claim 68, wherein the step of processing the message further comprises:
determining which of the plurality of networks are available to the target unit; and
selecting at least one of the plurality of transport modules in the processing the message with the first communication framework step to correspond to one of the available networks.
72. The method of claim 67, further comprising:
maintaining the message in a storage area hosted by the first communication framework when the message is unable to be transmitted to the second unit; and
transmitting the message to the second unit when the second unit is available for transmission.
73. The method of claim 67, further comprising:
disassembling the message into a plurality of chunks during the step of processing the message with the first communication framework;
dispatching the disassembled message to the second unit in the dispatching step; and
reassembling the disassembled message in the step of processing the message by the second communication framework.
74. The method of claim 73, further comprising:
disassembling the message into a first predetermined chunk size if an available message size of the network corresponding to the selected transport module is greater than a prescribed size; and
disassembling the message into a second predetermined chunk size if the available message size of the network corresponding to the selected transport module is less than the prescribed size.
75. The method according to claim 67, further comprising:
determining if the message is to be sent using reliable delivery in the step of processing the message with the first communication framework;
dispatching the message without requiring an acknowledgement when the message is to be sent using non-reliable delivery; and
requiring an acknowledgement from the target unit to verify receipt of the message after the dispatching step when the message is to be sent using reliable delivery.
76. The method according to claim 67, further comprising:
assigning an order to the message, by the first application program, with respect to at least one other message to form a plurality of prioritized messages in a priority order;
maintaining the message in the first communication framework until all of the plurality of prioritized messages are received in the first communication framework; and
dispatching each of the prioritized messages according to the priority order in the dispatching step.
77. The method according to claim 67, wherein the processing in the processing step includes formatting the message for the one of the second plurality of application programs.
78. A computer system comprising:
an application program means;
a plurality of transport module means for connecting to a respective one of a plurality of network means, the plurality of network means for providing a transport medium for sending and receiving electronic messaging to a target unit; and
a communication framework means for selecting one of the transport module means based on dynamic-delivery policies.
79. The computer system of claim 78, wherein the communication framework means includes a multi-part message manager means for disassembling messages from the application program means and reassembling incoming messages received from the target unit.
80. The system of claim 45, wherein the system is operable to monitor, configure, program and/or diagnosis at least one vehicle, and wherein the system further comprises:
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 target unit; and
an interface that allows selection among the plurality of modular applications to create a customized system.
US10/709,500 2000-08-18 2004-05-10 Remote Monitoring, Configuring, Programming and Diagnostic System and Method for Vehicles and Vehicle Components Abandoned US20050038581A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/709,500 US20050038581A1 (en) 2000-08-18 2004-05-10 Remote Monitoring, Configuring, Programming and Diagnostic System and Method for Vehicles and Vehicle Components

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US64078500A 2000-08-18 2000-08-18
US10/091,096 US7092803B2 (en) 2000-08-18 2002-03-04 Remote monitoring, configuring, programming and diagnostic system and method for vehicles and vehicle components
US10/709,500 US20050038581A1 (en) 2000-08-18 2004-05-10 Remote Monitoring, Configuring, Programming and Diagnostic System and Method for Vehicles and Vehicle Components

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US10/091,096 Division US7092803B2 (en) 2000-08-18 2002-03-04 Remote monitoring, configuring, programming and diagnostic system and method for vehicles and vehicle components

Publications (1)

Publication Number Publication Date
US20050038581A1 true US20050038581A1 (en) 2005-02-17

Family

ID=27804098

Family Applications (2)

Application Number Title Priority Date Filing Date
US10/091,096 Expired - Fee Related US7092803B2 (en) 2000-08-18 2002-03-04 Remote monitoring, configuring, programming and diagnostic system and method for vehicles and vehicle components
US10/709,500 Abandoned US20050038581A1 (en) 2000-08-18 2004-05-10 Remote Monitoring, Configuring, Programming and Diagnostic System and Method for Vehicles and Vehicle Components

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US10/091,096 Expired - Fee Related US7092803B2 (en) 2000-08-18 2002-03-04 Remote monitoring, configuring, programming and diagnostic system and method for vehicles and vehicle components

Country Status (7)

Country Link
US (2) US7092803B2 (en)
EP (1) EP1485878A2 (en)
JP (1) JP2005520725A (en)
AU (1) AU2003224647A1 (en)
CA (1) CA2478176A1 (en)
TW (1) TWI237758B (en)
WO (1) WO2003077205A2 (en)

Cited By (113)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030162523A1 (en) * 2002-02-27 2003-08-28 Michael Kapolka Vehicle telemetry system and method
US20050132024A1 (en) * 2003-12-15 2005-06-16 Masayuki Habaguchi Method and system for facilitating the exchange of information between a vehicle and a remote location
US20060028323A1 (en) * 2004-07-19 2006-02-09 Honda Motor Co., Ltd. Method and system for broadcasting audio and visual display messages to a vehicle
US20060068700A1 (en) * 2004-09-22 2006-03-30 Honda Motor Co., Ltd. Method and system for broadcasting data messages to a vehicle
US20060212515A1 (en) * 2005-03-18 2006-09-21 Shienbrood Eric R Applications server and method
US20060229850A1 (en) * 2005-03-29 2006-10-12 Cryovac, Inc. Handheld device for retrieving and analyzing data from an electronic monitoring device
US20070022173A1 (en) * 2003-12-15 2007-01-25 Honda Motor Co., Ltd. Method and system for broadcasting safety messages to a vehicle
US20070142940A1 (en) * 2005-12-21 2007-06-21 Ferguson Alan L Processes for monitoring user-selected parameters
US20070185646A1 (en) * 2006-02-09 2007-08-09 Mario Neugebauer Transmission of sensor data based on geographical navigation data
US20070192012A1 (en) * 2006-02-14 2007-08-16 Detroit Diesel Corporation Method and system of enhanced vehicle road speed limiting
US20070250228A1 (en) * 2006-04-19 2007-10-25 Snap-On Incorporated Configurable method and system for vehicle fault alert
US20080005281A1 (en) * 2006-06-29 2008-01-03 Microsoft Corporation Error capture and reporting in a distributed computing environment
US20080016207A1 (en) * 2006-07-14 2008-01-17 Wesley Homer Cheng Electronic driver log application with bi-directional messaging to multiple backend systems
US20080015748A1 (en) * 2006-07-14 2008-01-17 David Nagy System for monitoring, controlling, and reporting vehicle operation through onboard diagnostic port
US20080016504A1 (en) * 2006-07-14 2008-01-17 Wesley Homer Cheng Dynamically programmable electronic data collection system combining declarative programming and native coding
US20080034379A1 (en) * 2006-08-04 2008-02-07 Lectronix, Inc. Method and System for Integrating and Controlling Components and Subsystems
US20080059411A1 (en) * 2006-08-31 2008-03-06 Caterpillar Inc. Performance-based job site management system
US20080059005A1 (en) * 2006-08-31 2008-03-06 Jonny Ray Greiner System and method for selective on-board processing of machine data
US20080059080A1 (en) * 2006-08-31 2008-03-06 Caterpillar Inc. Method and system for selective, event-based communications
US20080059081A1 (en) * 2006-08-31 2008-03-06 Gualandri J Joseph Systems and methods for monitoring a machine
US20080059339A1 (en) * 2006-08-31 2008-03-06 Gualandri J Joseph Systems and methods for identifying attachments
US20080082345A1 (en) * 2006-09-29 2008-04-03 Caterpillar Inc. System and method for evaluating risks associated with delaying machine maintenance
US20080082221A1 (en) * 2006-07-14 2008-04-03 David Nagy System for monitoring, controlling, and reporting vehicle operation through onboard diagnostic port
US20080147571A1 (en) * 2006-09-29 2008-06-19 Caterpillar Inc. System and method for analyzing machine customization costs
US20080154691A1 (en) * 2006-12-13 2008-06-26 Wellman Timothy A Fleet management system
US20080177554A1 (en) * 2007-01-22 2008-07-24 Ford Motor Company Software architecture for developing in-vehicle software applications
US20080262848A1 (en) * 2005-01-06 2008-10-23 Eric Shienbrood Applications Server and Method
US20080270074A1 (en) * 2007-04-30 2008-10-30 Caterpillar Inc. User customized machine data acquisition system
US20080291918A1 (en) * 2007-05-25 2008-11-27 Caterpillar Inc. System for strategic management and communication of data in machine environments
US20090055685A1 (en) * 2007-08-22 2009-02-26 Denso Corporation Electronic apparatus in which functioning of of a microcomputer is monitored by another microcomputer to detect abnormal operation
US20090089134A1 (en) * 2007-10-02 2009-04-02 Robert Uyeki Method and system for vehicle service appointments based on diagnostic trouble codes
US20090106036A1 (en) * 2007-10-22 2009-04-23 Kazuya Tamura Method and system for making automated appointments
US20090125900A1 (en) * 2007-11-14 2009-05-14 Continental Teves, Inc. Systems and Methods for Updating Device Software
WO2008019333A3 (en) * 2006-08-04 2009-05-22 Lectronix Inc Method and system for integrating and controlling components and subsystems
US20090249040A1 (en) * 2008-03-31 2009-10-01 Hitachi, Ltd. Embedded Control System
US20090254240A1 (en) * 2008-04-07 2009-10-08 United Parcel Service Of America, Inc. Vehicle maintenance systems and methods
US20100030466A1 (en) * 2008-08-01 2010-02-04 Environmental Systems Research Institute, Inc. System and Method for Hybrid Off-Board Navigation
US7668653B2 (en) 2007-05-31 2010-02-23 Honda Motor Co., Ltd. System and method for selectively filtering and providing event program information
US20100169432A1 (en) * 2008-12-30 2010-07-01 Ford Global Technologies, Llc System and method for provisioning electronic mail in a vehicle
US20100190439A1 (en) * 2009-01-29 2010-07-29 Ford Global Technologies, Llc Message transmission protocol for service delivery network
US20100250881A1 (en) * 2009-03-31 2010-09-30 Joseph Bernard Steffler Systems and method for data recovery
US20100270983A1 (en) * 2009-04-24 2010-10-28 Zhengda Gong City Electric Bus Powered by Ultracapacitors
US7849149B2 (en) 2004-04-06 2010-12-07 Honda Motor Co., Ltd. Method and system for controlling the exchange of vehicle related messages
US20110010432A1 (en) * 2009-07-07 2011-01-13 Robert Uyeki Method For Scheduling And Rescheduling Vehicle Service Appointments
US7885599B2 (en) 2003-03-27 2011-02-08 Honda Motor Co., Ltd. System, method and computer program product for receiving data from a satellite radio network
US20110106374A1 (en) * 2010-12-23 2011-05-05 Margol Lonnie E Remote vehicle programming system and method
US20110161138A1 (en) * 2009-12-31 2011-06-30 Trapeze Software Inc. System and Method for Analyzing Performance Data in a Transit Organization
US20110160953A1 (en) * 2007-10-31 2011-06-30 Spx Corporation Error message details for debug available to end user
US20110225228A1 (en) * 2010-03-11 2011-09-15 Ford Global Technologies, Llc Method and systems for queuing messages for vehicle-related services
US20120110466A1 (en) * 2010-10-29 2012-05-03 Nissan North America, Inc. Method for presenting information to a host vehicle having a user interface
US20120179331A1 (en) * 2008-10-30 2012-07-12 International Business Machines Corporation Mechanic certification tracking validation
US20130097459A1 (en) * 2011-10-14 2013-04-18 Honeywell International Inc. Methods and systems for distributed diagnostic reasoning
CN103425578A (en) * 2012-05-18 2013-12-04 日立汽车系统株式会社 Test support system, test support method, method and program for testing support
CN103424263A (en) * 2012-05-23 2013-12-04 株式会社堀场制作所 Test system
US8615773B2 (en) 2011-03-31 2013-12-24 Honeywell International Inc. Systems and methods for coordinating computing functions to accomplish a task using a configuration file and standardized executable application modules
US8718632B2 (en) 2010-08-26 2014-05-06 Ford Global Technologies, Llc Service delivery network
US8726188B2 (en) 2010-10-29 2014-05-13 Nissan North America, Inc. Method for presenting information to a host vehicle having a user interface
US8744668B2 (en) * 2012-05-09 2014-06-03 Bosch Automotive Service Solutions Llc Automotive diagnostic server
US8751777B2 (en) 2011-01-28 2014-06-10 Honeywell International Inc. Methods and reconfigurable systems to optimize the performance of a condition based health maintenance system
US20140200760A1 (en) * 2011-05-27 2014-07-17 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
US8832716B2 (en) 2012-08-10 2014-09-09 Honeywell International Inc. Systems and methods for limiting user customization of task workflow in a condition based health maintenance system
US8832649B2 (en) 2012-05-22 2014-09-09 Honeywell International Inc. Systems and methods for augmenting the functionality of a monitoring node without recompiling
US20140324275A1 (en) * 2013-04-26 2014-10-30 Ford Global Technologies, Llc Online vehicle maintenance
US8897953B2 (en) 2011-07-26 2014-11-25 United Parcel Service Of America, Inc. Systems and methods for managing fault codes
US20140380442A1 (en) * 2011-01-14 2014-12-25 Cisco Technology, Inc. System and method for enabling secure transactions using flexible identity management in a vehicular environment
US8990770B2 (en) 2011-05-25 2015-03-24 Honeywell International Inc. Systems and methods to configure condition based health maintenance systems
US20150193326A1 (en) * 2014-01-06 2015-07-09 Ford Global Technologies, Llc Method and apparatus for error identification and data collection
US9279697B1 (en) * 2014-09-23 2016-03-08 State Farm Mutual Automobile Insurance Company Student driver feedback system allowing entry of tagged events by instructors during driving tests
CN105657037A (en) * 2016-02-04 2016-06-08 金龙联合汽车工业(苏州)有限公司 New energy vehicle and charging facility data acquisition method
US20160203653A1 (en) * 2014-08-07 2016-07-14 Launch Tech Co., Ltd. Method and apparatus for processing realtime vehicle operating data
WO2016185360A1 (en) 2015-05-19 2016-11-24 Hex Microsystems (Pty) Ltd System and method for transferring diagnostic commands to a vehicle
US20160364310A1 (en) * 2015-06-15 2016-12-15 International Business Machines Corporation Managing a set of tests based on other test failures
US9586591B1 (en) 2015-05-04 2017-03-07 State Farm Mutual Automobile Insurance Company Real-time driver observation and progress monitoring
RU2623676C2 (en) * 2009-04-03 2017-06-28 Краун Эквайпмент Корпорейшн Information system for vehicles of industrial purpose
US20170200333A1 (en) * 2005-12-08 2017-07-13 Smartdrive Systems, Inc. System and method to detect execution of driving maneuvers
US9751535B1 (en) 2014-09-23 2017-09-05 State Farm Mutual Automobile Insurance Company Real-time driver monitoring and feedback reporting system
US20170322791A1 (en) * 2016-05-04 2017-11-09 General Motors Llc Providing vehicle system module updates
US9928749B2 (en) 2016-04-29 2018-03-27 United Parcel Service Of America, Inc. Methods for delivering a parcel to a restricted access area
DE102016224193A1 (en) * 2016-12-06 2018-06-07 Robert Bosch Gmbh Method for monitoring a control device for a vehicle
US10146521B2 (en) 2014-09-09 2018-12-04 Airpro Diagnostics, Llc Device, system and method for updating the software modules of a vehicle
US10246104B1 (en) 2013-11-11 2019-04-02 Smartdrive Systems, Inc. Vehicle fuel consumption monitor and feedback systems
US10249105B2 (en) 2014-02-21 2019-04-02 Smartdrive Systems, Inc. System and method to detect execution of driving maneuvers
US10339732B2 (en) 2006-11-07 2019-07-02 Smartdrive Systems, Inc. Vehicle operator performance history recording, scoring and reporting systems
US10353691B2 (en) 2016-09-30 2019-07-16 Cummins Inc. Updating electronic controller through telematics
US10360739B2 (en) 2015-04-01 2019-07-23 Smartdrive Systems, Inc. Vehicle event recording system and method
US20190232959A1 (en) * 2016-06-20 2019-08-01 Jaguar Land Rover Limited Activity monitor
US10373523B1 (en) 2015-04-29 2019-08-06 State Farm Mutual Automobile Insurance Company Driver organization and management for driver's education
US10404951B2 (en) 2006-03-16 2019-09-03 Smartdrive Systems, Inc. Vehicle event recorders with integrated web server
US10476933B1 (en) 2007-05-08 2019-11-12 Smartdrive Systems, Inc. Distributed vehicle event recorder systems having a portable memory data transfer system
US10471828B2 (en) 2006-11-09 2019-11-12 Smartdrive Systems, Inc. Vehicle exception event management systems
US10682969B2 (en) 2006-11-07 2020-06-16 Smartdrive Systems, Inc. Power management systems for automotive video event recorders
US10706645B1 (en) * 2016-03-09 2020-07-07 Drew Technologies, Inc. Remote diagnostic system and method
US10719813B1 (en) 2010-09-29 2020-07-21 Bluelink Diagnostic Solutions, Inc. Remote diagnostic system for vehicles
US10730626B2 (en) 2016-04-29 2020-08-04 United Parcel Service Of America, Inc. Methods of photo matching and photo confirmation for parcel pickup and delivery
US10775792B2 (en) 2017-06-13 2020-09-15 United Parcel Service Of America, Inc. Autonomously delivering items to corresponding delivery locations proximate a delivery route
US10818112B2 (en) 2013-10-16 2020-10-27 Smartdrive Systems, Inc. Vehicle event playback apparatus and methods
WO2021001776A1 (en) * 2019-07-03 2021-01-07 Telepass S.P.A. System comprising an on-board unit for telematic traffic services
DE102019211154A1 (en) * 2019-07-26 2021-01-28 Volkswagen Aktiengesellschaft Method of a network server for servicing vehicle components
DE102019211155A1 (en) * 2019-07-26 2021-01-28 Volkswagen Aktiengesellschaft Method of a vehicle and a network server for servicing vehicle components
US10963825B2 (en) 2013-09-23 2021-03-30 Farmobile, Llc Farming data collection and exchange system
US11030560B1 (en) 2012-10-31 2021-06-08 Brandt Vx Llc Dispatch system
US11069257B2 (en) 2014-11-13 2021-07-20 Smartdrive Systems, Inc. System and method for detecting a vehicle event and generating review criteria
US11225404B2 (en) 2006-12-13 2022-01-18 Crown Equipment Corporation Information system for industrial vehicles
US11257307B1 (en) 2019-06-24 2022-02-22 Opus Ivs, Inc. Adaptive vehicle diagnostic system and method
US11348382B1 (en) 2019-10-30 2022-05-31 Opus Ivs, Inc. System and method for detecting remote vehicle diagnosis
US11355031B2 (en) * 2003-07-07 2022-06-07 Insurance Services Office, Inc. Traffic information system
US20220240064A1 (en) * 2019-06-19 2022-07-28 Sigfox Vehicle-sharing system and method for accessing a vehicle from such a system
US11423715B1 (en) 2019-12-03 2022-08-23 Opus Ivs, Inc. Vehicle diagnostic device
US11501634B2 (en) 2018-08-03 2022-11-15 Honda Motor Co., Ltd. Information management apparatus, vehicle, and method
US11508191B1 (en) 2019-12-03 2022-11-22 Opus Ivs, Inc. Vehicle diagnostic interface device
US11538290B1 (en) 2020-01-31 2022-12-27 Opus Ivs, Inc. Automated vehicle diagnostic navigation system and method
US11823502B2 (en) 2006-12-13 2023-11-21 Crown Equipment Corporation Impact sensing usable with fleet management system
US11861954B2 (en) 2019-08-27 2024-01-02 Opus Ivs, Inc. Vehicle diagnostic system and method

Families Citing this family (194)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8140358B1 (en) 1996-01-29 2012-03-20 Progressive Casualty Insurance Company Vehicle monitoring system
US8090598B2 (en) 1996-01-29 2012-01-03 Progressive Casualty Insurance Company Monitoring system for determining and communicating a cost of insurance
US20020173885A1 (en) 2001-03-13 2002-11-21 Lowrey Larkin Hill Internet-based system for monitoring vehicles
WO2004093409A2 (en) * 2003-04-11 2004-10-28 Nnt, Inc. Wireless communication framework
US20060025907A9 (en) * 2000-08-18 2006-02-02 Nnt, Inc. Vehicle-interactive system
US7092803B2 (en) * 2000-08-18 2006-08-15 Idsc Holdings, Llc Remote monitoring, configuring, programming and diagnostic system and method for vehicles and vehicle components
WO2002090669A1 (en) * 2001-05-08 2002-11-14 Hitachi Construction Machinery Co., Ltd Working machine, trouble diagnosis system of working machine, and maintenance system of working machine
US7155321B2 (en) 2001-08-06 2006-12-26 Idsc Holdings Llc System, method and computer program product for remote vehicle diagnostics, monitoring, configuring and reprogramming
JP2003122426A (en) * 2001-10-16 2003-04-25 Keihin Corp Remote maintenance system
US20030093199A1 (en) * 2001-11-15 2003-05-15 Michael Mavreas Remote monitoring and control of a motorized vehicle
US7957509B2 (en) * 2002-04-30 2011-06-07 At&T Intellectual Property I, L.P. Voice enhancing for advance intelligent network services
US7325135B2 (en) * 2002-06-28 2008-01-29 Temic Automotive Of North America, Inc. Method and system for authorizing reconfiguration of a vehicle
US7356393B1 (en) * 2002-11-18 2008-04-08 Turfcentric, Inc. Integrated system for routine maintenance of mechanized equipment
JP3828484B2 (en) * 2002-11-29 2006-10-04 株式会社ザナヴィ・インフォマティクス Data access method and data access apparatus for in-vehicle information equipment
US8086771B2 (en) * 2002-12-19 2011-12-27 International Business Machines Corporation TCET expander
GB2400175B (en) * 2003-02-26 2007-11-28 Tomtom Bv Navigation device and method for exchanging data between resident applications
US7421334B2 (en) * 2003-04-07 2008-09-02 Zoom Information Systems Centralized facility and intelligent on-board vehicle platform for collecting, analyzing and distributing information relating to transportation infrastructure and conditions
JP2004322740A (en) * 2003-04-22 2004-11-18 Toyota Motor Corp Failure diagnosis device for vehicular control device
US7209813B2 (en) 2003-05-13 2007-04-24 Spx Corporation Cellular phone configured with off-board device capabilities and starter/charger and battery testing capabilities
US9520005B2 (en) 2003-07-24 2016-12-13 Verizon Telematics Inc. Wireless vehicle-monitoring system
US7113127B1 (en) * 2003-07-24 2006-09-26 Reynolds And Reynolds Holdings, Inc. Wireless vehicle-monitoring system operating on both terrestrial and satellite networks
US7349794B2 (en) * 2003-09-03 2008-03-25 Malone Specialty, Inc. Engine protection system
WO2005039927A2 (en) * 2003-10-08 2005-05-06 General Motors Corporation Captured test fleet
US7225064B2 (en) * 2003-10-31 2007-05-29 Snap-On Technologies, Inc. Wireless communication for diagnostic instrument
US7487019B2 (en) * 2003-12-12 2009-02-03 United States Postal Service Intelligent vehicle fleet systems and methods
US7584029B2 (en) * 2003-12-31 2009-09-01 Teradyne, Inc. Telematics-based vehicle data acquisition architecture
US20060030983A1 (en) * 2004-01-06 2006-02-09 Textron Inc. Apparatus and methods for facilitating vehicle maintenance
US7020545B2 (en) * 2004-01-28 2006-03-28 General Motors Corporation Method and system for managing registration requests of telematics units
WO2005072458A2 (en) * 2004-01-28 2005-08-11 Delorme Publishing Company, Inc. Method and device for processing raw gps data
DE102004015163A1 (en) * 2004-02-13 2005-08-25 Volkswagen Ag Vehicle diagnosis procedure uses processor to filter operating and failure data against manufacturer supplied data
JP4306510B2 (en) * 2004-03-29 2009-08-05 三菱自動車エンジニアリング株式会社 Vehicle inspection management system
JP4370960B2 (en) * 2004-03-29 2009-11-25 三菱自動車エンジニアリング株式会社 Vehicle inspection management system
JP4270017B2 (en) * 2004-04-15 2009-05-27 三菱自動車工業株式会社 Vehicle inspection management system
SE527692C2 (en) * 2004-05-12 2006-05-09 Hans Ekdahl Med Hg Ekdahl Kons Procedure in a communication network to distribute driving information for vehicles and systems implementing the procedure
US7366589B2 (en) * 2004-05-13 2008-04-29 General Motors Corporation Method and system for remote reflash
US7877176B2 (en) * 2004-06-24 2011-01-25 General Motors Llc Method and system for remote telltale reset
US7340331B2 (en) 2004-08-12 2008-03-04 Snap-On Incorporated Vehicle data recorder using digital and analog diagnostic data
US20060047419A1 (en) * 2004-09-02 2006-03-02 Diendorf John R Telematic method and apparatus for managing shipping logistics
JP4956894B2 (en) * 2004-10-19 2012-06-20 三菱電機株式会社 Communication terminal and storage medium removable from communication terminal
DE102004055573A1 (en) * 2004-11-18 2006-05-24 Robert Bosch Gmbh Diagnostic interface for applications on a service gateway
US7272475B2 (en) * 2004-12-02 2007-09-18 General Motors Corporation Method for updating vehicle diagnostics software
US20060271255A1 (en) * 2004-12-30 2006-11-30 Teradyne, Inc. System and method for vehicle diagnostics and prognostics
US7355509B2 (en) 2005-02-25 2008-04-08 Iwapi Inc. Smart modem device for vehicular and roadside applications
US9601015B2 (en) 2005-02-25 2017-03-21 Concaten, Inc. Maintenance decision support system and method for vehicular and roadside applications
US7386377B2 (en) * 2005-04-07 2008-06-10 Sorensen David I Vehicle and equipment monitoring apparatus
WO2006122263A2 (en) * 2005-05-11 2006-11-16 Pinpoint Tracking Solutions, Llc Method and apparatus for secure storage and remote monitoring vehicle odometer
US7729824B2 (en) * 2005-07-29 2010-06-01 Gm Global Technology Operations, Inc. Remote diagnostic system for detecting tampering of vehicle calibrations
US20070050095A1 (en) * 2005-09-01 2007-03-01 Polaris Industries Inc. Controller area network based self-configuring vehicle management system and method
US20070109096A1 (en) * 2005-09-08 2007-05-17 Jeremy Breedlove Global tracking and communications device
US7920944B2 (en) * 2005-10-21 2011-04-05 General Motors Llc Vehicle diagnostic test and reporting method
US8255112B2 (en) * 2005-10-28 2012-08-28 The Boeing Company Remote aircraft maintenance in a networked environment
WO2008051236A2 (en) * 2005-11-09 2008-05-02 Sapias, Inc. Geospatially aware vehicle security
US8423430B2 (en) * 2005-11-16 2013-04-16 The Boeing Company Integrated materials management for commercial aircraft fleets including access to real-time on-board systems information
KR20070108432A (en) * 2006-01-23 2007-11-12 엘지전자 주식회사 Method for scheduling device mangament
US20070173993A1 (en) * 2006-01-23 2007-07-26 Nielsen Benjamin J Method and system for monitoring fleet metrics
US10528705B2 (en) * 2006-05-09 2020-01-07 Apple Inc. Determining validity of subscription to use digital content
US8850083B2 (en) * 2006-07-26 2014-09-30 Bosch Automotive Service Solutions, LLC Data management method and system
US7689594B2 (en) * 2006-09-22 2010-03-30 The Boeing Company Vehicle management and mission management computer architecture and packaging
DE102006044896B3 (en) * 2006-09-22 2008-04-10 GM Global Technology Operations, Inc., Detroit Remote manipulation diagnosis system for vehicle, has server assigned to distributed network information system and having access to service card index, where manipulation flag is maintained until access is made by server
US9747329B2 (en) 2006-10-05 2017-08-29 Trimble Inc. Limiting access to asset management information
US9747571B2 (en) 2006-10-05 2017-08-29 Trimble Inc. Integrated asset management
US9811949B2 (en) 2006-10-05 2017-11-07 Trimble Inc. Method for providing status information pertaining to an asset
US9519876B2 (en) 2006-10-05 2016-12-13 Trimble Navigation Limited Method for providing maintenance to an asset
US9984341B2 (en) * 2006-12-13 2018-05-29 Crown Equipment Corporation Information system for industrial vehicles including cyclical recurring vehicle information message
US7869906B2 (en) * 2007-01-08 2011-01-11 Ford Global Technologies Wireless gateway apparatus and method of bridging data between vehicle based and external data networks
US9392346B2 (en) * 2007-02-14 2016-07-12 Leica Geosystems Ag System and method of remote diagnostics
US8050815B2 (en) * 2007-05-02 2011-11-01 General Motors Llc Method and system for selectively monitoring vehicle systems and for controlling vehicle system parameters
US20080281518A1 (en) * 2007-05-10 2008-11-13 Dozier Chad A Vehicular communication and information system and method of using the same
US9864957B2 (en) 2007-06-29 2018-01-09 Concaten, Inc. Information delivery and maintenance system for dynamically generated and updated data pertaining to road maintenance vehicles and other related information
US8275522B1 (en) 2007-06-29 2012-09-25 Concaten, Inc. Information delivery and maintenance system for dynamically generated and updated data pertaining to road maintenance vehicles and other related information
DE102007038190B4 (en) * 2007-08-13 2009-07-02 Siemens Ag Method for parameterizing a diagnostic device, corresponding computer program and computer program product, and diagnostic system
US8306560B2 (en) * 2007-09-28 2012-11-06 General Motors Llc Method and system for configuring a telematics device using two-way data messaging
DE102008025065A1 (en) * 2007-12-21 2009-07-02 Continental Automotive Gmbh Method and system for transmitting data
WO2009088946A1 (en) 2008-01-03 2009-07-16 Iwapi, Inc. Integrated rail efficiency and safety support system
US20090222338A1 (en) * 2008-03-03 2009-09-03 Hamilton Ii Rick A Monitoring and Rewards Methodologies for "Green" Use of Vehicles
JP5163248B2 (en) * 2008-04-10 2013-03-13 トヨタ自動車株式会社 Vehicle group running control system
CA2937962C (en) 2008-04-18 2019-05-07 The Raymond Corporation System for managing operation of industrial vehicles
US8301330B2 (en) * 2008-05-02 2012-10-30 General Electric Company Method and system for providing supplemental services to telematics systems
US20090274263A1 (en) * 2008-05-05 2009-11-05 Collins Michael P Run-Time Meter With Blind Interface
US20100042287A1 (en) * 2008-08-12 2010-02-18 Gm Global Technology Operations, Inc. Proactive vehicle system management and maintenance by using diagnostic and prognostic information
US8095261B2 (en) * 2009-03-05 2012-01-10 GM Global Technology Operations LLC Aggregated information fusion for enhanced diagnostics, prognostics and maintenance practices of vehicles
GB2482265B (en) * 2009-05-11 2016-01-06 Mahindra Reva Electric Vehicles Pvt Ltd Estimating performance delivered by an energy storage system
US9916625B2 (en) 2012-02-02 2018-03-13 Progressive Casualty Insurance Company Mobile insurance platform system
DE102009038035A1 (en) * 2009-08-19 2011-02-24 Bayerische Motoren Werke Aktiengesellschaft Method for configuring infotainment applications in a motor vehicle
JP5208074B2 (en) * 2009-08-27 2013-06-12 日立建機株式会社 Remote management system for work machines
BR112012004602A2 (en) * 2009-09-01 2016-04-05 Crown Equip Corp methods for dynamically generating truck information and automatically monitoring truck information
GB201013131D0 (en) * 2009-09-24 2010-09-22 Barloworld Handling Ltd Positioning system
US20110083128A1 (en) * 2009-10-02 2011-04-07 International Truck Intellectual Property Company, Llc Method for selecting software and installing same via a telematic module in a motor vehicle
WO2011078748A1 (en) * 2009-12-22 2011-06-30 Volvo Lastvagnar Ab Driver notification system and method
US8902081B2 (en) 2010-06-02 2014-12-02 Concaten, Inc. Distributed maintenance decision and support system and method
EP2393049A1 (en) * 2010-06-04 2011-12-07 BAE Systems Bofors AB On-board service platform and services for fleet maintenance and management
EP2393050A1 (en) * 2010-06-04 2011-12-07 BAE Systems Bofors AB Central service platform and services for fleet maintenance and management
EP2393048A1 (en) * 2010-06-04 2011-12-07 BAE Systems Bofors AB Service platform system architecture for fleet maintenance and management
US9464905B2 (en) 2010-06-25 2016-10-11 Toyota Motor Engineering & Manufacturing North America, Inc. Over-the-air vehicle systems updating and associate security protocols
US8751100B2 (en) 2010-08-13 2014-06-10 Deere & Company Method for performing diagnostics or software maintenance for a vehicle
CN103080719B (en) * 2010-09-10 2016-04-06 迪尔公司 For the method and system of the diagnosis or software maintenance that perform vehicle
US11330644B2 (en) 2016-06-19 2022-05-10 Platform Science, Inc. Secure wireless networks for vehicle assigning authority
US10475258B1 (en) 2016-06-19 2019-11-12 Platform Science, Inc. Method and system for utilizing vehicle odometer values and dynamic compliance
US11197329B2 (en) 2016-06-19 2021-12-07 Platform Science, Inc. Method and system for generating fueling instructions for a vehicle
US9961710B2 (en) 2016-06-19 2018-05-01 Platform Science, Inc. Secure wireless networks for vehicles
US10652935B1 (en) 2016-06-19 2020-05-12 Platform Science, Inc. Secure wireless networks for vehicles
US11197330B2 (en) 2016-06-19 2021-12-07 Platform Science, Inc. Remote profile manage for a vehicle
US10321624B2 (en) 2011-03-11 2019-06-18 Intelligent Agriculture Solutions LLC Air seeder manifold system
US20160246296A1 (en) * 2011-03-11 2016-08-25 Intelligent Agricultural Solutions, Llc Gateway system and method
US10318138B2 (en) 2011-03-11 2019-06-11 Intelligent Agricultural Solutions Llc Harvesting machine capable of automatic adjustment
US8788139B2 (en) * 2011-03-21 2014-07-22 Webtech Wireless Inc. Multi-protocol vehicle diagnostic interface device and method
WO2012160667A1 (en) * 2011-05-25 2012-11-29 トヨタ自動車株式会社 Vehicle information acquiring apparatus, vehicle information supplying apparatus, and information communicating system of vehicle having vehicle information acquiring apparatus and vehicle information supplying apparatus
US8886390B2 (en) * 2011-09-22 2014-11-11 Aethon, Inc. Monitoring, diagnostic and tracking tool for autonomous mobile robots
US9183273B2 (en) 2011-09-23 2015-11-10 Omnitracs, Llc Systems and methods for processing location-and entity-based workflow data
KR101283051B1 (en) * 2011-11-25 2013-07-05 엘에스산전 주식회사 Method of managing program for electric vehicle
US20130170107A1 (en) * 2012-01-04 2013-07-04 Doug Dean Enclosure for Preventing Tampering of Mobile Communication Equipment in Transportation Industry
SE536394C2 (en) * 2012-01-13 2013-10-08 Scania Cv Ab System and method for providing diagnostic error information based on content from two databases
EP2696186B1 (en) * 2012-05-24 2019-03-27 Horiba, Ltd. Test system
DE102012010704A1 (en) 2012-05-30 2012-11-29 Daimler Ag Method for outputting information, particularly maintenance requests in vehicle, involves transmitting output processed information by employer to vehicle, where appropriate time for output of information is determined by scheduler
US9858809B2 (en) * 2012-11-08 2018-01-02 Qualcomm Incorporated Augmenting handset sensors with car sensors
US9087193B2 (en) * 2012-11-13 2015-07-21 Gogo Llc Communication system and method for nodes associated with a vehicle
WO2014088567A1 (en) 2012-12-05 2014-06-12 Bendix Commercial Vehicle Systems Llc Methods and apparatus for updating software components in coordination with operational modes of a motor vehicle
US8948996B2 (en) 2012-12-20 2015-02-03 Fleetmetrica Inc. Metrics-based transport vehicle fleet safety
GB2510384B (en) * 2013-02-01 2017-11-29 Jaguar Land Rover Ltd Vehicle diagnostics apparatus and method
US8799034B1 (en) 2013-03-08 2014-08-05 Allstate University Company Automated accident detection, fault attribution, and claims processing
US9019092B1 (en) 2013-03-08 2015-04-28 Allstate Insurance Company Determining whether a vehicle is parked for automated accident detection, fault attribution, and claims processing
US10963966B1 (en) 2013-09-27 2021-03-30 Allstate Insurance Company Electronic exchange of insurance information
US10032226B1 (en) 2013-03-08 2018-07-24 Allstate Insurance Company Automatic exchange of information in response to a collision event
FR3003382A1 (en) * 2013-03-12 2014-09-19 Mycar Innovations VEHICLE OPERATING DIAGNOSTIC SYSTEM
US11222485B2 (en) 2013-03-12 2022-01-11 Gogoro Inc. Apparatus, method and article for providing information regarding a vehicle via a mobile device
US11080734B2 (en) 2013-03-15 2021-08-03 Cdk Global, Llc Pricing system for identifying prices for vehicles offered by vehicle dealerships and other entities
US10445758B1 (en) 2013-03-15 2019-10-15 Allstate Insurance Company Providing rewards based on driving behaviors detected by a mobile computing device
EP2787205B1 (en) * 2013-04-03 2017-07-26 IVECO S.p.A. System for estimating a vehicle fuel consumption
GB2513395B (en) 2013-04-26 2017-01-04 Jaguar Land Rover Ltd Vehicle diagnostics apparatus, diagnostics unit and methods
US9165413B2 (en) * 2013-06-03 2015-10-20 Honda Motor Co., Ltd. Diagnostic assistance
US10572943B1 (en) 2013-09-10 2020-02-25 Allstate Insurance Company Maintaining current insurance information at a mobile device
US9443270B1 (en) 2013-09-17 2016-09-13 Allstate Insurance Company Obtaining insurance information in response to optical input
US20150094929A1 (en) * 2013-09-30 2015-04-02 Ford Global Technologies, Llc Vehicle diagnostic and prognostic systems and methods
US20150094903A1 (en) * 2013-09-30 2015-04-02 Ford Global Technologies, Llc Vehicle diagnostic and prognostic systems and methods
US9524156B2 (en) 2014-01-09 2016-12-20 Ford Global Technologies, Llc Flexible feature deployment strategy
US9766874B2 (en) 2014-01-09 2017-09-19 Ford Global Technologies, Llc Autonomous global software update
TWI589091B (en) * 2014-03-06 2017-06-21 睿能創意公司 Portable charging device and security system, security system method thereof
US9716762B2 (en) 2014-03-31 2017-07-25 Ford Global Technologies Llc Remote vehicle connection status
US9323546B2 (en) * 2014-03-31 2016-04-26 Ford Global Technologies, Llc Targeted vehicle remote feature updates
US10140110B2 (en) 2014-04-02 2018-11-27 Ford Global Technologies, Llc Multiple chunk software updates
US9325650B2 (en) 2014-04-02 2016-04-26 Ford Global Technologies, Llc Vehicle telematics data exchange
US9626811B2 (en) 2014-06-19 2017-04-18 Atieva, Inc. Vehicle fault early warning system
US9495814B2 (en) * 2014-06-19 2016-11-15 Atieva, Inc. Vehicle fault early warning system
US9299109B2 (en) * 2014-07-17 2016-03-29 Kenneth Carl Steffen Winiecki Motor vehicle monitoring method for determining driver negligence of an engine
US9460567B2 (en) * 2014-07-29 2016-10-04 GM Global Technology Operations LLC Establishing secure communication for vehicle diagnostic data
DE102014113371A1 (en) 2014-09-17 2016-03-17 Knorr-Bremse Systeme für Schienenfahrzeuge GmbH Method for monitoring and diagnosing components of a rail vehicle, with expandable evaluation software
JP6032265B2 (en) * 2014-12-10 2016-11-24 トヨタ自動車株式会社 Vehicle data collection system
US10713717B1 (en) 2015-01-22 2020-07-14 Allstate Insurance Company Total loss evaluation and handling system and method
TWI557007B (en) * 2015-04-10 2016-11-11 宏碁股份有限公司 Method and system for information transmission for a vehicle
US10083551B1 (en) 2015-04-13 2018-09-25 Allstate Insurance Company Automatic crash detection
US9767625B1 (en) 2015-04-13 2017-09-19 Allstate Insurance Company Automatic crash detection
ES2860577T3 (en) 2015-04-20 2021-10-05 Oshkosh Corp Response vehicle systems and procedures
US9916700B2 (en) * 2015-08-17 2018-03-13 Webtech Wireless Inc. Asset-agnostic framework with asset-specific module for alternate bus parameter calculation
US9870656B2 (en) * 2015-12-08 2018-01-16 Smartcar, Inc. System and method for processing vehicle requests
US10853769B2 (en) * 2016-04-21 2020-12-01 Cdk Global Llc Scheduling an automobile service appointment in a dealer service bay based on diagnostic trouble codes and service bay attributes
US10867285B2 (en) 2016-04-21 2020-12-15 Cdk Global, Llc Automatic automobile repair service scheduling based on diagnostic trouble codes and service center attributes
US10010021B2 (en) * 2016-05-03 2018-07-03 Cnh Industrial America Llc Equipment library for command and control software
US11400997B2 (en) 2016-05-23 2022-08-02 Indian Motorcycle International, LLC Display systems and methods for a recreational vehicle
US10917921B2 (en) 2016-06-19 2021-02-09 Platform Science, Inc. Secure wireless networks for vehicles
US11438938B1 (en) 2016-06-19 2022-09-06 Platform Science, Inc. System and method to generate position and state-based electronic signaling from a vehicle
US11503655B2 (en) 2016-06-19 2022-11-15 Platform Science, Inc. Micro-navigation for a vehicle
US11528759B1 (en) 2016-06-19 2022-12-13 Platform Science, Inc. Method and system for vehicle inspection
US10163278B2 (en) 2016-09-07 2018-12-25 Ford Global Technologies, Llc Method for sharing and receiving vehicle fuel quality alerts
US11361380B2 (en) 2016-09-21 2022-06-14 Allstate Insurance Company Enhanced image capture and analysis of damaged tangible objects
US10902525B2 (en) 2016-09-21 2021-01-26 Allstate Insurance Company Enhanced image capture and analysis of damaged tangible objects
JP6468277B2 (en) * 2016-12-26 2019-02-13 トヨタ自動車株式会社 Vehicle communication system
DE102017107202A1 (en) * 2017-04-04 2018-10-04 Avl Software And Functions Gmbh Method and device for protecting control units against harmful software
US10269192B2 (en) * 2017-04-07 2019-04-23 Airbiquity Inc. Technologies for verifying control system operation
US10445953B1 (en) 2017-04-12 2019-10-15 Drew Technologies, Inc. Vehicle programming and diagnostic device with integrated battery charger
US10937103B1 (en) 2017-04-21 2021-03-02 Allstate Insurance Company Machine learning based accident assessment
US10748356B1 (en) 2017-07-17 2020-08-18 Drew Technologies, Inc. Vehicle diagnostic and programming device and method
US10261777B2 (en) * 2017-07-25 2019-04-16 Aurora Labs Ltd. Detecting anomalies online using histograms of ECU processing activity
WO2019027061A1 (en) * 2017-07-31 2019-02-07 (주)디지파츠 Connected gateway server system for real-time vehicle control service
US11189163B2 (en) * 2017-10-11 2021-11-30 Toyota Motor Engineering & Manufacturing North America, Inc. Systems and methods for infrastructure improvements
DE102017221926A1 (en) * 2017-12-05 2019-06-06 Bayerische Motoren Werke Aktiengesellschaft Processing unit for a vehicle, a mobile device and a system
US11125493B2 (en) 2018-03-07 2021-09-21 Carrier Corporation Method and system for controlling use of a portable cooling container
JP7201329B2 (en) * 2018-03-12 2023-01-10 トヨタ自動車株式会社 vehicle controller
DK3539843T3 (en) * 2018-03-12 2021-08-09 Railnova Sa DEVICE FOR PROCESSING DATA FROM ROLLING STOCK
US11190608B2 (en) 2018-03-21 2021-11-30 Cdk Global Llc Systems and methods for an automotive commerce exchange
US11501351B2 (en) 2018-03-21 2022-11-15 Cdk Global, Llc Servers, systems, and methods for single sign-on of an automotive commerce exchange
DE102018003281B4 (en) * 2018-04-23 2019-12-05 Daimler Ag Vehicle operating system
US10755494B2 (en) 2018-08-03 2020-08-25 Ford Global Technologies, Llc Vehicle component diagnostic
US11449327B2 (en) 2018-11-30 2022-09-20 Paccar Inc Error-resilient over-the-air software updates for vehicles
US11356425B2 (en) 2018-11-30 2022-06-07 Paccar Inc Techniques for improving security of encrypted vehicle software updates
US11230197B2 (en) * 2019-08-07 2022-01-25 Toyota Motor Engineering & Manufacturing North America, Inc. Methods and systems for integrating a hub motor with a vehicle
US10973908B1 (en) 2020-05-14 2021-04-13 David Gordon Bermudes Expression of SARS-CoV-2 spike protein receptor binding domain in attenuated salmonella as a vaccine
US11080105B1 (en) 2020-11-18 2021-08-03 Cdk Global, Llc Systems, methods, and apparatuses for routing API calls
US11514021B2 (en) 2021-01-22 2022-11-29 Cdk Global, Llc Systems, methods, and apparatuses for scanning a legacy database
US11651632B2 (en) 2021-04-12 2023-05-16 Toyota Motor North America, Inc. Diagnosis of transport-related issues
US11887409B2 (en) * 2021-05-19 2024-01-30 Pony Al Inc. Device health code broadcasting on mixed vehicle communication networks
US20220371530A1 (en) * 2021-05-19 2022-11-24 Pony Ai Inc. Device-level fault detection
US11803535B2 (en) 2021-05-24 2023-10-31 Cdk Global, Llc Systems, methods, and apparatuses for simultaneously running parallel databases
WO2023102765A1 (en) * 2021-12-08 2023-06-15 陈献忠 Fault alarm system for intelligent electric locomotive
CN116414052A (en) * 2021-12-29 2023-07-11 康明斯有限公司 System and method for custom calibration updates

Citations (92)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4067061A (en) * 1975-03-18 1978-01-03 Rockwell International Corporation Monitoring and recording system for vehicles
US4258421A (en) * 1978-02-27 1981-03-24 Rockwell International Corporation Vehicle monitoring and recording system
US4630292A (en) * 1984-08-13 1986-12-16 Juricich Ronald A Fuel tax rebate recorder
US4677429A (en) * 1983-12-01 1987-06-30 Navistar International Transportation Corp. Vehicle information on-board processor
US4809177A (en) * 1987-08-14 1989-02-28 Navistar International Transportation Corp. Multiplexed electrical wiring system for a truck including driver interface and power switching
US4926331A (en) * 1986-02-25 1990-05-15 Navistar International Transportation Corp. Truck operation monitoring system
US4939652A (en) * 1988-03-14 1990-07-03 Centrodyne Inc. Trip recorder
US4979170A (en) * 1988-01-19 1990-12-18 Qualcomm, Inc. Alternating sequential half duplex communication system
US5157610A (en) * 1989-02-15 1992-10-20 Hitachi, Ltd. System and method of load sharing control for automobile
US5337236A (en) * 1990-05-21 1994-08-09 Taurean Electronics, Inc. System for categorizing and recording vehicle trip distance
US5359528A (en) * 1993-02-19 1994-10-25 Rockwell International Corp. System for accurately determining the mileage traveled by a vehicle within a state without human intervention
US5426585A (en) * 1991-03-29 1995-06-20 Cummins Electronics Company, Inc. Method and apparatus for generating calibration information for an electronic engine control module
US5442553A (en) * 1992-11-16 1995-08-15 Motorola Wireless motor vehicle diagnostic and software upgrade system
US5579233A (en) * 1995-01-09 1996-11-26 Burns; Robert R. Method of on-site refueling using electronic identification tags, reading probe, and a truck on-board computer
US5581464A (en) * 1992-08-14 1996-12-03 Vorad Safety Systems, Inc. Recording of operational events in an automotive vehicle
US5619412A (en) * 1994-10-19 1997-04-08 Cummins Engine Company, Inc. Remote control of engine idling time
US5648768A (en) * 1994-12-30 1997-07-15 Mapsys, Inc. System and method for identifying, tabulating and presenting information of interest along a travel route
US5680328A (en) * 1995-05-22 1997-10-21 Eaton Corporation Computer assisted driver vehicle inspection reporting system
US5682317A (en) * 1993-08-05 1997-10-28 Pavilion Technologies, Inc. Virtual emissions monitor for automobile and associated control system
US5694322A (en) * 1995-05-09 1997-12-02 Highwaymaster Communications, Inc. Method and apparatus for determining tax of a vehicle
US5708308A (en) * 1995-06-05 1998-01-13 Mitsubishi Denki Kabushiki Kaisha Apparatus for protecting automobile against unauthorized operation
US5721678A (en) * 1993-03-23 1998-02-24 Mannesmann Aktiengesellschaft Arrangement for a use billing system
US5729458A (en) * 1995-12-29 1998-03-17 Etak, Inc. Cost zones
US5732074A (en) * 1996-01-16 1998-03-24 Cellport Labs, Inc. Mobile portable wireless communication system
US5742915A (en) * 1995-12-13 1998-04-21 Caterpillar Inc. Position referenced data for monitoring and controlling
US5787373A (en) * 1990-08-22 1998-07-28 Datatrac International, Inc. Travel expense tracking system
US5803043A (en) * 1996-05-29 1998-09-08 Bayron; Harry Data input interface for power and speed controller
US5815822A (en) * 1995-03-13 1998-09-29 Iu; Howard Apparatus for remotely controlling a vehicle in motion
US5815071A (en) * 1995-03-03 1998-09-29 Qualcomm Incorporated Method and apparatus for monitoring parameters of vehicle electronic control units
US5831519A (en) * 1994-11-22 1998-11-03 Pedersen; Heine Ewi Traffic supervision system for vehicles
US5835868A (en) * 1996-08-30 1998-11-10 Mcelroy; Alejandro S. Automated system for immobilizing a vehicle and method
US5835376A (en) * 1995-10-27 1998-11-10 Total Technology, Inc. Fully automated vehicle dispatching, monitoring and billing
US5864831A (en) * 1993-02-17 1999-01-26 Daimler Benz Ag Device for determining road tolls
US5917434A (en) * 1995-06-15 1999-06-29 Trimble Navigation Limited Integrated taximeter/GPS position tracking system
US5919239A (en) * 1996-06-28 1999-07-06 Fraker; William F. Position and time-at-position logging system
US5928291A (en) * 1997-03-27 1999-07-27 Rockwell International Corporation Mileage and fuel consumption determination for geo-cell based vehicle information management
US5931877A (en) * 1996-05-30 1999-08-03 Raytheon Company Advanced maintenance system for aircraft and military weapons
US5937421A (en) * 1996-08-19 1999-08-10 International Business Machines Corporation Methods, systems and computer program products for performing interactive applications in a client-server based dialog system
US5938716A (en) * 1997-09-08 1999-08-17 Cummins Engine Company, Inc. System for customizing vehicle engine control computer operation
US5953706A (en) * 1996-10-21 1999-09-14 Orissa, Inc. Transportation network system
US5954773A (en) * 1996-12-13 1999-09-21 Eaton Corporation Vehicle state mileage determination system
US5974396A (en) * 1993-02-23 1999-10-26 Moore Business Forms, Inc. Method and system for gathering and analyzing consumer purchasing information based on product and consumer clustering relationships
US5974356A (en) * 1997-03-14 1999-10-26 Qualcomm Incorporated System and method for determining vehicle travel routes and mileage
US6060981A (en) * 1999-04-23 2000-05-09 Caterpillar Inc. Vehicle security system for unattended idle operations
US6078873A (en) * 1997-10-02 2000-06-20 Cummins Engine Company, Inc. Method and apparatus for real-time data stamping via datalink and volatile ECM timer/clock
US6085725A (en) * 1998-03-02 2000-07-11 Cummins Engine Co., Inc. Throttle control response selection system
US6088650A (en) * 1996-10-24 2000-07-11 Trimble Navigation, Ltd. Vehicle tracker, mileage-time monitor and calibrator
US6091340A (en) * 1997-11-25 2000-07-18 Lee; Brian Remote on/off disable parts and system
US6108591A (en) * 1998-01-22 2000-08-22 Qualcomm Incorporated Method and apparatus for validating vehicle operators
US6111539A (en) * 1994-09-01 2000-08-29 British Telecommunications Public Limited Company Navigation information system
US6185501B1 (en) * 1993-05-25 2001-02-06 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
US6195023B1 (en) * 1997-02-03 2001-02-27 Daimlerchrysler Ag Communication based vehicle positioning reference system
US6204772B1 (en) * 1999-12-16 2001-03-20 Caterpillar Inc. Method and apparatus for monitoring the position of a machine
US6226577B1 (en) * 1999-07-08 2001-05-01 Hyundai Motor Company Method for searching trip log of vehicle
US6232874B1 (en) * 1998-03-20 2001-05-15 Trimble Navigation Limited Vehicle use control
US6253129B1 (en) * 1997-03-27 2001-06-26 Tripmaster Corporation System for monitoring vehicle efficiency and vehicle and driver performance
US6259988B1 (en) * 1998-07-20 2001-07-10 Lockheed Martin Corporation Real-time mission adaptable route planner
US6263268B1 (en) * 1997-08-26 2001-07-17 Transcontech Corporation System and method for providing mobile automotive telemetry
US6275585B1 (en) * 1998-04-28 2001-08-14 Motorola, Inc. Method for reprogramming a vehicle system or a user system in a vehicle
US6278935B1 (en) * 1999-07-23 2001-08-21 Navigation Technologies Corp. Method and system for providing instructions about tollways with a navigation system
US20010018628A1 (en) * 1997-03-27 2001-08-30 Mentor Heavy Vehicle Systems, Lcc System for monitoring vehicle efficiency and vehicle and driver perfomance
US20010020204A1 (en) * 2000-03-06 2001-09-06 David Runyon System for tracking vehicle and driver location and mileage and generating reports therefrom
US6292724B1 (en) * 1999-10-12 2001-09-18 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
US6295492B1 (en) * 1999-01-27 2001-09-25 Infomove.Com, Inc. System for transmitting and displaying multiple, motor vehicle information
US6317668B1 (en) * 1999-06-10 2001-11-13 Qualcomm Incorporated Paperless log system and method
US20020007237A1 (en) * 2000-06-14 2002-01-17 Phung Tam A. Method and system for the diagnosis of vehicles
US20020016655A1 (en) * 2000-08-01 2002-02-07 Joao Raymond Anthony Apparatus and method for processing and/or for providing vehicle information and/or vehicle maintenance information
US6370449B1 (en) * 1999-06-14 2002-04-09 Sun Microsystems, Inc. Upgradable vehicle component architecture
US20020049523A1 (en) * 1998-11-05 2002-04-25 Diaz R. Gary Land vehicle communications system and process for providing information and coordinating vehicle activities
US6389337B1 (en) * 2000-04-24 2002-05-14 H. Brock Kolls Transacting e-commerce and conducting e-business related to identifying and procuring automotive service and vehicle replacement parts
US6430164B1 (en) * 1999-06-17 2002-08-06 Cellport Systems, Inc. Communications involving disparate protocol network/bus and device subsystems
US20020133273A1 (en) * 2001-03-14 2002-09-19 Lowrey Larkin Hill Internet-based vehicle-diagnostic system
US20020156588A1 (en) * 2001-03-05 2002-10-24 Arndt G. Dickey Sensor and method for detecting a superstrate
US20020173885A1 (en) * 2001-03-13 2002-11-21 Lowrey Larkin Hill Internet-based system for monitoring vehicles
US20020177926A1 (en) * 2000-10-06 2002-11-28 Lockwood Robert Farrell Customer service automation systems and methods
US20030004624A1 (en) * 2001-06-29 2003-01-02 Wilson Bary W. Diagnostics/prognostics using wireless links
US6516192B1 (en) * 1997-01-03 2003-02-04 Cellport Systems, Inc. Communications channel selection
US20030055912A1 (en) * 1998-08-17 2003-03-20 Bruce K. Martin Method and apparatus for controlling network connections based on destination locations
US20030093199A1 (en) * 2001-11-15 2003-05-15 Michael Mavreas Remote monitoring and control of a motorized vehicle
US20030105565A1 (en) * 2001-12-03 2003-06-05 Loda David C. Integrated internet portal and deployed product microserver management system
US20030105825A1 (en) * 2001-05-01 2003-06-05 Profluent, Inc. Method and system for policy based management of messages for mobile data networks
US20030158656A1 (en) * 2000-04-03 2003-08-21 Zvi David Locating and controlling a remote device through a satellite location system
US20030162523A1 (en) * 2002-02-27 2003-08-28 Michael Kapolka Vehicle telemetry system and method
US6636790B1 (en) * 2000-07-25 2003-10-21 Reynolds And Reynolds Holdings, Inc. Wireless diagnostic system and method for monitoring vehicles
US20040039504A1 (en) * 1999-12-19 2004-02-26 Fleet Management Services, Inc. Vehicle tracking, communication and fleet management system
US6714857B2 (en) * 2002-02-26 2004-03-30 Nnt, Inc. System for remote monitoring of a vehicle and method of determining vehicle mileage, jurisdiction crossing and fuel consumption
US20040138790A1 (en) * 2000-08-18 2004-07-15 Michael Kapolka Remote monitoring, configuring, programming and diagnostic system and method for vehicles and vehicle components
US6775267B1 (en) * 1999-12-30 2004-08-10 At&T Corp Method for billing IP broadband subscribers
US20050060070A1 (en) * 2000-08-18 2005-03-17 Nnt, Inc. Wireless communication framework
US20050085963A1 (en) * 2000-08-18 2005-04-21 Nnt, Inc. Vehicle-interactive system
US20050203673A1 (en) * 2000-08-18 2005-09-15 Hassanayn Machlab El-Hajj Wireless communication framework
US7084735B2 (en) * 2002-08-28 2006-08-01 Idsc Holdings, Llc. Remote vehicle security system

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
BE792277A (en) 1971-12-06 1973-03-30 Tull Aviation Corp REMOTE ACQUISITION SYSTEM OF OPERATING CONDITIONS DATA
US5343780A (en) 1992-07-27 1994-09-06 Cummins Engine Company, Inc. Variable power drivetrain engine control system
GB2288892A (en) 1994-04-29 1995-11-01 Oakrange Engineering Ltd Vehicle fleet monitoring apparatus
GB9409671D0 (en) 1994-05-14 1994-07-06 Eaton Corp Security device
DE4423328A1 (en) 1994-06-22 1996-01-04 Schmidt Karsten Lorry, car and mobile fleet tracking and display system
KR0153605B1 (en) 1995-10-13 1998-11-16 김광호 Remote management system
US6157317A (en) * 1996-12-02 2000-12-05 Kline And Walker Llc Secure communication and control system for monitoring, recording, reporting and/or restricting unauthorized use of vehicle.
US5844987A (en) * 1997-01-03 1998-12-01 Ericsson Inc. Communications system and method using vehicle identifications
US6008740A (en) * 1997-12-17 1999-12-28 Stmicroelectronics, Inc. Electronic speed limit notification system
US5999876A (en) * 1998-04-01 1999-12-07 Cummins Engine Company, Inc. Method and system for communication with an engine control module in sleep mode
GB2340974B (en) 1998-08-21 2000-08-23 Stuart Johnson The remote immobilisation of moving powered vehicles
US6487717B1 (en) 1999-01-15 2002-11-26 Cummins, Inc. System and method for transmission of application software to an embedded vehicle computer
US6323874B1 (en) * 1999-02-08 2001-11-27 Silicon Graphics, Inc. System and method for rendering an image
US6167333A (en) * 1999-08-19 2000-12-26 Lucent Technologies Inc. Highway information system
JP2001076012A (en) 1999-08-31 2001-03-23 Hitachi Ltd Method and device for gathering vehicle information
BR9905575C1 (en) 1999-11-24 2001-10-09 Carlos Eduardo Wendler Anti-theft controller and speed limiter for motor vehicles
EP1128333A3 (en) 2000-02-24 2004-07-07 Vodafone Holding GmbH Method and apparatus for generation of electronic evidence of the travels of a vehicle
AU8314001A (en) 2000-08-18 2002-03-04 Nexiq Technologies Inc System, method and computer program product for remote vehicle diagnostics, monitoring, configuring and reprogramming
JP2002228552A (en) * 2001-01-31 2002-08-14 Mazda Motor Corp Remote failure diagnostic server of vehicle, remote failure diagnostic method of vehicle, remote failure diagnostic program, on-vehicle remote failure diagnostic system and remote failure diagnostic system of vehicle
US6954689B2 (en) * 2001-03-16 2005-10-11 Cnh America Llc Method and apparatus for monitoring work vehicles

Patent Citations (101)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4067061A (en) * 1975-03-18 1978-01-03 Rockwell International Corporation Monitoring and recording system for vehicles
US4258421A (en) * 1978-02-27 1981-03-24 Rockwell International Corporation Vehicle monitoring and recording system
US4677429A (en) * 1983-12-01 1987-06-30 Navistar International Transportation Corp. Vehicle information on-board processor
US4630292A (en) * 1984-08-13 1986-12-16 Juricich Ronald A Fuel tax rebate recorder
US4926331A (en) * 1986-02-25 1990-05-15 Navistar International Transportation Corp. Truck operation monitoring system
US4809177A (en) * 1987-08-14 1989-02-28 Navistar International Transportation Corp. Multiplexed electrical wiring system for a truck including driver interface and power switching
US4979170A (en) * 1988-01-19 1990-12-18 Qualcomm, Inc. Alternating sequential half duplex communication system
US4939652A (en) * 1988-03-14 1990-07-03 Centrodyne Inc. Trip recorder
US5157610A (en) * 1989-02-15 1992-10-20 Hitachi, Ltd. System and method of load sharing control for automobile
US5337236A (en) * 1990-05-21 1994-08-09 Taurean Electronics, Inc. System for categorizing and recording vehicle trip distance
US5787373A (en) * 1990-08-22 1998-07-28 Datatrac International, Inc. Travel expense tracking system
US6064929A (en) * 1990-08-22 2000-05-16 Datatrac International, Inc. Travel expense tracking system
US5426585A (en) * 1991-03-29 1995-06-20 Cummins Electronics Company, Inc. Method and apparatus for generating calibration information for an electronic engine control module
US5426585B1 (en) * 1991-03-29 2000-10-10 Cummins Engine Co Inc Method and apparatus for generating calibration information for an electronic engine control module
US5581464A (en) * 1992-08-14 1996-12-03 Vorad Safety Systems, Inc. Recording of operational events in an automotive vehicle
US5581464B1 (en) * 1992-08-14 1999-02-09 Vorad Safety Systems Inc Recording of operational events in an automotive vehicle
US5442553A (en) * 1992-11-16 1995-08-15 Motorola Wireless motor vehicle diagnostic and software upgrade system
US5864831A (en) * 1993-02-17 1999-01-26 Daimler Benz Ag Device for determining road tolls
US5612875A (en) * 1993-02-19 1997-03-18 Rockwell Science Center Inc. System for accurately determining the mileage traveled by a vehicle within a state without human intervention
US5359528A (en) * 1993-02-19 1994-10-25 Rockwell International Corp. System for accurately determining the mileage traveled by a vehicle within a state without human intervention
US5974396A (en) * 1993-02-23 1999-10-26 Moore Business Forms, Inc. Method and system for gathering and analyzing consumer purchasing information based on product and consumer clustering relationships
US5721678A (en) * 1993-03-23 1998-02-24 Mannesmann Aktiengesellschaft Arrangement for a use billing system
US6185501B1 (en) * 1993-05-25 2001-02-06 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
US5682317A (en) * 1993-08-05 1997-10-28 Pavilion Technologies, Inc. Virtual emissions monitor for automobile and associated control system
US6111539A (en) * 1994-09-01 2000-08-29 British Telecommunications Public Limited Company Navigation information system
US6169515B1 (en) * 1994-09-01 2001-01-02 British Telecommunications Public Limited Company Navigation information system
US5619412A (en) * 1994-10-19 1997-04-08 Cummins Engine Company, Inc. Remote control of engine idling time
US5831519A (en) * 1994-11-22 1998-11-03 Pedersen; Heine Ewi Traffic supervision system for vehicles
US5648768A (en) * 1994-12-30 1997-07-15 Mapsys, Inc. System and method for identifying, tabulating and presenting information of interest along a travel route
US5579233A (en) * 1995-01-09 1996-11-26 Burns; Robert R. Method of on-site refueling using electronic identification tags, reading probe, and a truck on-board computer
US5815071A (en) * 1995-03-03 1998-09-29 Qualcomm Incorporated Method and apparatus for monitoring parameters of vehicle electronic control units
US5815822A (en) * 1995-03-13 1998-09-29 Iu; Howard Apparatus for remotely controlling a vehicle in motion
US5694322A (en) * 1995-05-09 1997-12-02 Highwaymaster Communications, Inc. Method and apparatus for determining tax of a vehicle
US5680328A (en) * 1995-05-22 1997-10-21 Eaton Corporation Computer assisted driver vehicle inspection reporting system
US5708308A (en) * 1995-06-05 1998-01-13 Mitsubishi Denki Kabushiki Kaisha Apparatus for protecting automobile against unauthorized operation
US5917434A (en) * 1995-06-15 1999-06-29 Trimble Navigation Limited Integrated taximeter/GPS position tracking system
US6087965A (en) * 1995-06-15 2000-07-11 Trimble Navigation Limited Vehicle mileage meter and a GPS position tracking system
US5835376A (en) * 1995-10-27 1998-11-10 Total Technology, Inc. Fully automated vehicle dispatching, monitoring and billing
US5742915A (en) * 1995-12-13 1998-04-21 Caterpillar Inc. Position referenced data for monitoring and controlling
US6026384A (en) * 1995-12-29 2000-02-15 Etak, Inc. Cost zones
US5729458A (en) * 1995-12-29 1998-03-17 Etak, Inc. Cost zones
US5732074A (en) * 1996-01-16 1998-03-24 Cellport Labs, Inc. Mobile portable wireless communication system
US5803043A (en) * 1996-05-29 1998-09-08 Bayron; Harry Data input interface for power and speed controller
US5931877A (en) * 1996-05-30 1999-08-03 Raytheon Company Advanced maintenance system for aircraft and military weapons
US5919239A (en) * 1996-06-28 1999-07-06 Fraker; William F. Position and time-at-position logging system
US5937421A (en) * 1996-08-19 1999-08-10 International Business Machines Corporation Methods, systems and computer program products for performing interactive applications in a client-server based dialog system
US5835868A (en) * 1996-08-30 1998-11-10 Mcelroy; Alejandro S. Automated system for immobilizing a vehicle and method
US5953706A (en) * 1996-10-21 1999-09-14 Orissa, Inc. Transportation network system
US6088650A (en) * 1996-10-24 2000-07-11 Trimble Navigation, Ltd. Vehicle tracker, mileage-time monitor and calibrator
US6181995B1 (en) * 1996-12-13 2001-01-30 Eaton Corporation Vehicle state mileage determination system
US5954773A (en) * 1996-12-13 1999-09-21 Eaton Corporation Vehicle state mileage determination system
US6516192B1 (en) * 1997-01-03 2003-02-04 Cellport Systems, Inc. Communications channel selection
US6195023B1 (en) * 1997-02-03 2001-02-27 Daimlerchrysler Ag Communication based vehicle positioning reference system
US5974356A (en) * 1997-03-14 1999-10-26 Qualcomm Incorporated System and method for determining vehicle travel routes and mileage
US6253129B1 (en) * 1997-03-27 2001-06-26 Tripmaster Corporation System for monitoring vehicle efficiency and vehicle and driver performance
US20010018628A1 (en) * 1997-03-27 2001-08-30 Mentor Heavy Vehicle Systems, Lcc System for monitoring vehicle efficiency and vehicle and driver perfomance
US5928291A (en) * 1997-03-27 1999-07-27 Rockwell International Corporation Mileage and fuel consumption determination for geo-cell based vehicle information management
US6263268B1 (en) * 1997-08-26 2001-07-17 Transcontech Corporation System and method for providing mobile automotive telemetry
US5938716A (en) * 1997-09-08 1999-08-17 Cummins Engine Company, Inc. System for customizing vehicle engine control computer operation
US6078873A (en) * 1997-10-02 2000-06-20 Cummins Engine Company, Inc. Method and apparatus for real-time data stamping via datalink and volatile ECM timer/clock
US6091340A (en) * 1997-11-25 2000-07-18 Lee; Brian Remote on/off disable parts and system
US6108591A (en) * 1998-01-22 2000-08-22 Qualcomm Incorporated Method and apparatus for validating vehicle operators
US6089207A (en) * 1998-03-02 2000-07-18 Cummins Engine Company, Inc. Throttle control response selection system
US6085725A (en) * 1998-03-02 2000-07-11 Cummins Engine Co., Inc. Throttle control response selection system
US6232874B1 (en) * 1998-03-20 2001-05-15 Trimble Navigation Limited Vehicle use control
US6275585B1 (en) * 1998-04-28 2001-08-14 Motorola, Inc. Method for reprogramming a vehicle system or a user system in a vehicle
US6259988B1 (en) * 1998-07-20 2001-07-10 Lockheed Martin Corporation Real-time mission adaptable route planner
US20030055912A1 (en) * 1998-08-17 2003-03-20 Bruce K. Martin Method and apparatus for controlling network connections based on destination locations
US20020049523A1 (en) * 1998-11-05 2002-04-25 Diaz R. Gary Land vehicle communications system and process for providing information and coordinating vehicle activities
US6295492B1 (en) * 1999-01-27 2001-09-25 Infomove.Com, Inc. System for transmitting and displaying multiple, motor vehicle information
US6060981A (en) * 1999-04-23 2000-05-09 Caterpillar Inc. Vehicle security system for unattended idle operations
US6317668B1 (en) * 1999-06-10 2001-11-13 Qualcomm Incorporated Paperless log system and method
US6370449B1 (en) * 1999-06-14 2002-04-09 Sun Microsystems, Inc. Upgradable vehicle component architecture
US6430164B1 (en) * 1999-06-17 2002-08-06 Cellport Systems, Inc. Communications involving disparate protocol network/bus and device subsystems
US6226577B1 (en) * 1999-07-08 2001-05-01 Hyundai Motor Company Method for searching trip log of vehicle
US6278935B1 (en) * 1999-07-23 2001-08-21 Navigation Technologies Corp. Method and system for providing instructions about tollways with a navigation system
US6292724B1 (en) * 1999-10-12 2001-09-18 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
US6204772B1 (en) * 1999-12-16 2001-03-20 Caterpillar Inc. Method and apparatus for monitoring the position of a machine
US20040039504A1 (en) * 1999-12-19 2004-02-26 Fleet Management Services, Inc. Vehicle tracking, communication and fleet management system
US6775267B1 (en) * 1999-12-30 2004-08-10 At&T Corp Method for billing IP broadband subscribers
US20010020204A1 (en) * 2000-03-06 2001-09-06 David Runyon System for tracking vehicle and driver location and mileage and generating reports therefrom
US20030158656A1 (en) * 2000-04-03 2003-08-21 Zvi David Locating and controlling a remote device through a satellite location system
US6389337B1 (en) * 2000-04-24 2002-05-14 H. Brock Kolls Transacting e-commerce and conducting e-business related to identifying and procuring automotive service and vehicle replacement parts
US20020007237A1 (en) * 2000-06-14 2002-01-17 Phung Tam A. Method and system for the diagnosis of vehicles
US6636790B1 (en) * 2000-07-25 2003-10-21 Reynolds And Reynolds Holdings, Inc. Wireless diagnostic system and method for monitoring vehicles
US20020016655A1 (en) * 2000-08-01 2002-02-07 Joao Raymond Anthony Apparatus and method for processing and/or for providing vehicle information and/or vehicle maintenance information
US20040138790A1 (en) * 2000-08-18 2004-07-15 Michael Kapolka Remote monitoring, configuring, programming and diagnostic system and method for vehicles and vehicle components
US20050203673A1 (en) * 2000-08-18 2005-09-15 Hassanayn Machlab El-Hajj Wireless communication framework
US20050085963A1 (en) * 2000-08-18 2005-04-21 Nnt, Inc. Vehicle-interactive system
US20050060070A1 (en) * 2000-08-18 2005-03-17 Nnt, Inc. Wireless communication framework
US20020177926A1 (en) * 2000-10-06 2002-11-28 Lockwood Robert Farrell Customer service automation systems and methods
US20020156588A1 (en) * 2001-03-05 2002-10-24 Arndt G. Dickey Sensor and method for detecting a superstrate
US20020173885A1 (en) * 2001-03-13 2002-11-21 Lowrey Larkin Hill Internet-based system for monitoring vehicles
US20020133273A1 (en) * 2001-03-14 2002-09-19 Lowrey Larkin Hill Internet-based vehicle-diagnostic system
US20030105825A1 (en) * 2001-05-01 2003-06-05 Profluent, Inc. Method and system for policy based management of messages for mobile data networks
US20030004624A1 (en) * 2001-06-29 2003-01-02 Wilson Bary W. Diagnostics/prognostics using wireless links
US20030093199A1 (en) * 2001-11-15 2003-05-15 Michael Mavreas Remote monitoring and control of a motorized vehicle
US20030105565A1 (en) * 2001-12-03 2003-06-05 Loda David C. Integrated internet portal and deployed product microserver management system
US6714857B2 (en) * 2002-02-26 2004-03-30 Nnt, Inc. System for remote monitoring of a vehicle and method of determining vehicle mileage, jurisdiction crossing and fuel consumption
US20030162523A1 (en) * 2002-02-27 2003-08-28 Michael Kapolka Vehicle telemetry system and method
US7084735B2 (en) * 2002-08-28 2006-08-01 Idsc Holdings, Llc. Remote vehicle security system

Cited By (211)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030162523A1 (en) * 2002-02-27 2003-08-28 Michael Kapolka Vehicle telemetry system and method
US7885599B2 (en) 2003-03-27 2011-02-08 Honda Motor Co., Ltd. System, method and computer program product for receiving data from a satellite radio network
US11355031B2 (en) * 2003-07-07 2022-06-07 Insurance Services Office, Inc. Traffic information system
US7818380B2 (en) 2003-12-15 2010-10-19 Honda Motor Co., Ltd. Method and system for broadcasting safety messages to a vehicle
US20050132024A1 (en) * 2003-12-15 2005-06-16 Masayuki Habaguchi Method and system for facilitating the exchange of information between a vehicle and a remote location
US20070022173A1 (en) * 2003-12-15 2007-01-25 Honda Motor Co., Ltd. Method and system for broadcasting safety messages to a vehicle
US8495179B2 (en) 2003-12-15 2013-07-23 Honda Motor Co., Ltd. Method and system for facilitating the exchange of information between a vehicle and a remote location
US8041779B2 (en) 2003-12-15 2011-10-18 Honda Motor Co., Ltd. Method and system for facilitating the exchange of information between a vehicle and a remote location
US7849149B2 (en) 2004-04-06 2010-12-07 Honda Motor Co., Ltd. Method and system for controlling the exchange of vehicle related messages
US20060028323A1 (en) * 2004-07-19 2006-02-09 Honda Motor Co., Ltd. Method and system for broadcasting audio and visual display messages to a vehicle
US20060068700A1 (en) * 2004-09-22 2006-03-30 Honda Motor Co., Ltd. Method and system for broadcasting data messages to a vehicle
US20100060481A1 (en) * 2004-09-22 2010-03-11 Honda Motor Co., Ltd. Method and System for Broadcasting Data Messages to a Vehicle
US7965992B2 (en) 2004-09-22 2011-06-21 Honda Motor Co., Ltd. Method and system for broadcasting data messages to a vehicle
US20080262848A1 (en) * 2005-01-06 2008-10-23 Eric Shienbrood Applications Server and Method
US7634259B2 (en) * 2005-03-18 2009-12-15 Orange Sa Applications server and method
US20060212515A1 (en) * 2005-03-18 2006-09-21 Shienbrood Eric R Applications server and method
US7165015B2 (en) * 2005-03-29 2007-01-16 Cryovac, Inc. Handheld device for retrieving and analyzing data from an electronic monitoring device
US20060229850A1 (en) * 2005-03-29 2006-10-12 Cryovac, Inc. Handheld device for retrieving and analyzing data from an electronic monitoring device
US10878646B2 (en) 2005-12-08 2020-12-29 Smartdrive Systems, Inc. Vehicle event recorder systems
US10706648B2 (en) * 2005-12-08 2020-07-07 Smartdrive Systems, Inc. System and method to detect execution of driving maneuvers
US20170200333A1 (en) * 2005-12-08 2017-07-13 Smartdrive Systems, Inc. System and method to detect execution of driving maneuvers
US20070142940A1 (en) * 2005-12-21 2007-06-21 Ferguson Alan L Processes for monitoring user-selected parameters
US20070185646A1 (en) * 2006-02-09 2007-08-09 Mario Neugebauer Transmission of sensor data based on geographical navigation data
US8594933B2 (en) * 2006-02-09 2013-11-26 Sap Ag Transmission of sensor data based on geographical navigation data
US20070192012A1 (en) * 2006-02-14 2007-08-16 Detroit Diesel Corporation Method and system of enhanced vehicle road speed limiting
US10404951B2 (en) 2006-03-16 2019-09-03 Smartdrive Systems, Inc. Vehicle event recorders with integrated web server
US20070250228A1 (en) * 2006-04-19 2007-10-25 Snap-On Incorporated Configurable method and system for vehicle fault alert
US20080005281A1 (en) * 2006-06-29 2008-01-03 Microsoft Corporation Error capture and reporting in a distributed computing environment
US20080016207A1 (en) * 2006-07-14 2008-01-17 Wesley Homer Cheng Electronic driver log application with bi-directional messaging to multiple backend systems
US20080082221A1 (en) * 2006-07-14 2008-04-03 David Nagy System for monitoring, controlling, and reporting vehicle operation through onboard diagnostic port
US20080015748A1 (en) * 2006-07-14 2008-01-17 David Nagy System for monitoring, controlling, and reporting vehicle operation through onboard diagnostic port
US20080016504A1 (en) * 2006-07-14 2008-01-17 Wesley Homer Cheng Dynamically programmable electronic data collection system combining declarative programming and native coding
US20080034379A1 (en) * 2006-08-04 2008-02-07 Lectronix, Inc. Method and System for Integrating and Controlling Components and Subsystems
US7681201B2 (en) * 2006-08-04 2010-03-16 Lectronix Method and system for integrating and controlling components and subsystems
WO2008019333A3 (en) * 2006-08-04 2009-05-22 Lectronix Inc Method and system for integrating and controlling components and subsystems
US20080059080A1 (en) * 2006-08-31 2008-03-06 Caterpillar Inc. Method and system for selective, event-based communications
US20080059005A1 (en) * 2006-08-31 2008-03-06 Jonny Ray Greiner System and method for selective on-board processing of machine data
US20080059411A1 (en) * 2006-08-31 2008-03-06 Caterpillar Inc. Performance-based job site management system
US20080059081A1 (en) * 2006-08-31 2008-03-06 Gualandri J Joseph Systems and methods for monitoring a machine
US20080059339A1 (en) * 2006-08-31 2008-03-06 Gualandri J Joseph Systems and methods for identifying attachments
US7711522B2 (en) 2006-08-31 2010-05-04 Caterpillar Inc. Systems and methods for monitoring a machine
US20080082345A1 (en) * 2006-09-29 2008-04-03 Caterpillar Inc. System and method for evaluating risks associated with delaying machine maintenance
US20080147571A1 (en) * 2006-09-29 2008-06-19 Caterpillar Inc. System and method for analyzing machine customization costs
US10339732B2 (en) 2006-11-07 2019-07-02 Smartdrive Systems, Inc. Vehicle operator performance history recording, scoring and reporting systems
US10682969B2 (en) 2006-11-07 2020-06-16 Smartdrive Systems, Inc. Power management systems for automotive video event recorders
US11623517B2 (en) 2006-11-09 2023-04-11 SmartDriven Systems, Inc. Vehicle exception event management systems
US10471828B2 (en) 2006-11-09 2019-11-12 Smartdrive Systems, Inc. Vehicle exception event management systems
EP3723053A1 (en) * 2006-12-13 2020-10-14 Crown Equipment Corporation Fleet management system
US9202186B2 (en) 2006-12-13 2015-12-01 Crown Equipment Corporation Fleet management system
US9632506B2 (en) 2006-12-13 2017-04-25 Crown Equipment Corporation Fleet management system
US20080154691A1 (en) * 2006-12-13 2008-06-26 Wellman Timothy A Fleet management system
US8239251B2 (en) 2006-12-13 2012-08-07 Crown Equipment Corporation Fleet management system
US8239252B2 (en) 2006-12-13 2012-08-07 Crown Equipment Corporation Fleet management system
US10599160B2 (en) 2006-12-13 2020-03-24 Crown Equipment Corporation Fleet management system
US8249910B2 (en) * 2006-12-13 2012-08-21 Crown Equipment Corporation Fleet management system
EP2115692A2 (en) * 2006-12-13 2009-11-11 Crown Equipment Corporation Fleet management system
US11225404B2 (en) 2006-12-13 2022-01-18 Crown Equipment Corporation Information system for industrial vehicles
US9152933B2 (en) 2006-12-13 2015-10-06 Crown Equipment Corporation Fleet management system
EP3699012A1 (en) * 2006-12-13 2020-08-26 Crown Equipment Corporation Fleet management system
EP2115692A4 (en) * 2006-12-13 2011-11-16 Crown Equip Corp Fleet management system
US11823502B2 (en) 2006-12-13 2023-11-21 Crown Equipment Corporation Impact sensing usable with fleet management system
EP2963596A1 (en) * 2006-12-13 2016-01-06 Crown Equipment Corporation Fleet management system
EP2963613A1 (en) * 2006-12-13 2016-01-06 Crown Equipment Corporation Fleet management system
US8161454B2 (en) * 2007-01-22 2012-04-17 Ford Motor Company Software architecture for developing in-vehicle software applications
US9081648B2 (en) 2007-01-22 2015-07-14 Ford Motor Company Software architecture for developing in-vehicle software applications
US20080177554A1 (en) * 2007-01-22 2008-07-24 Ford Motor Company Software architecture for developing in-vehicle software applications
US20080270074A1 (en) * 2007-04-30 2008-10-30 Caterpillar Inc. User customized machine data acquisition system
US10476933B1 (en) 2007-05-08 2019-11-12 Smartdrive Systems, Inc. Distributed vehicle event recorder systems having a portable memory data transfer system
US20080291918A1 (en) * 2007-05-25 2008-11-27 Caterpillar Inc. System for strategic management and communication of data in machine environments
US8462793B2 (en) * 2007-05-25 2013-06-11 Caterpillar Inc. System for strategic management and communication of data in machine environments
US7668653B2 (en) 2007-05-31 2010-02-23 Honda Motor Co., Ltd. System and method for selectively filtering and providing event program information
US20090055685A1 (en) * 2007-08-22 2009-02-26 Denso Corporation Electronic apparatus in which functioning of of a microcomputer is monitored by another microcomputer to detect abnormal operation
US8091014B2 (en) 2007-08-22 2012-01-03 Denso Corporation Electronic apparatus in which functioning of a microcomputer is monitored by another microcomputer to detect abnormal operation
US20090089134A1 (en) * 2007-10-02 2009-04-02 Robert Uyeki Method and system for vehicle service appointments based on diagnostic trouble codes
US8099308B2 (en) 2007-10-02 2012-01-17 Honda Motor Co., Ltd. Method and system for vehicle service appointments based on diagnostic trouble codes
US20090106036A1 (en) * 2007-10-22 2009-04-23 Kazuya Tamura Method and system for making automated appointments
US8041476B2 (en) * 2007-10-31 2011-10-18 Spx Corporation Error message details for debug available to end user
US20110160953A1 (en) * 2007-10-31 2011-06-30 Spx Corporation Error message details for debug available to end user
US8397228B2 (en) * 2007-11-14 2013-03-12 Continental Automotive Systems, Inc. Systems and methods for updating device software
US20090125900A1 (en) * 2007-11-14 2009-05-14 Continental Teves, Inc. Systems and Methods for Updating Device Software
US20090249040A1 (en) * 2008-03-31 2009-10-01 Hitachi, Ltd. Embedded Control System
US8484266B2 (en) * 2008-03-31 2013-07-09 Hitachi, Ltd. Embedded control system with floating-point conversion
US20090254240A1 (en) * 2008-04-07 2009-10-08 United Parcel Service Of America, Inc. Vehicle maintenance systems and methods
US9026304B2 (en) * 2008-04-07 2015-05-05 United Parcel Service Of America, Inc. Vehicle maintenance systems and methods
US9342933B2 (en) 2008-04-07 2016-05-17 United Parcel Service Of America, Inc. Vehicle maintenance systems and methods
US20100030466A1 (en) * 2008-08-01 2010-02-04 Environmental Systems Research Institute, Inc. System and Method for Hybrid Off-Board Navigation
US9310212B2 (en) * 2008-08-01 2016-04-12 Environmental Systems Research Institute, Inc. System and method for hybrid off-board navigation
US20150112584A1 (en) * 2008-08-01 2015-04-23 Environmental Systems Research Institute, Inc. System and method for hybrid off-board navigation
US8909466B2 (en) * 2008-08-01 2014-12-09 Environmental Systems Research Institute, Inc. System and method for hybrid off-board navigation
US20120179331A1 (en) * 2008-10-30 2012-07-12 International Business Machines Corporation Mechanic certification tracking validation
US20100169432A1 (en) * 2008-12-30 2010-07-01 Ford Global Technologies, Llc System and method for provisioning electronic mail in a vehicle
US9305288B2 (en) 2008-12-30 2016-04-05 Ford Global Technologies, Llc System and method for provisioning electronic mail in a vehicle
US20100190439A1 (en) * 2009-01-29 2010-07-29 Ford Global Technologies, Llc Message transmission protocol for service delivery network
US20100250881A1 (en) * 2009-03-31 2010-09-30 Joseph Bernard Steffler Systems and method for data recovery
RU2623676C2 (en) * 2009-04-03 2017-06-28 Краун Эквайпмент Корпорейшн Information system for vehicles of industrial purpose
US8564253B2 (en) * 2009-04-24 2013-10-22 Sinautec Automobile Technologies, Llc City electric bus powered by ultracapacitors
US20100270983A1 (en) * 2009-04-24 2010-10-28 Zhengda Gong City Electric Bus Powered by Ultracapacitors
US20110010432A1 (en) * 2009-07-07 2011-01-13 Robert Uyeki Method For Scheduling And Rescheduling Vehicle Service Appointments
US8135804B2 (en) 2009-07-07 2012-03-13 Honda Motor Co., Ltd. Method for scheduling and rescheduling vehicle service appointments
US20110161138A1 (en) * 2009-12-31 2011-06-30 Trapeze Software Inc. System and Method for Analyzing Performance Data in a Transit Organization
US20110225228A1 (en) * 2010-03-11 2011-09-15 Ford Global Technologies, Llc Method and systems for queuing messages for vehicle-related services
US8718632B2 (en) 2010-08-26 2014-05-06 Ford Global Technologies, Llc Service delivery network
US11763269B1 (en) 2010-09-29 2023-09-19 Opus Ivs, Inc. Remote diagnostic system for vehicles
US10719813B1 (en) 2010-09-29 2020-07-21 Bluelink Diagnostic Solutions, Inc. Remote diagnostic system for vehicles
US11295277B1 (en) 2010-09-29 2022-04-05 Opus Ivs, Inc. Remote diagnostic system for vehicles
US8726188B2 (en) 2010-10-29 2014-05-13 Nissan North America, Inc. Method for presenting information to a host vehicle having a user interface
US20120110466A1 (en) * 2010-10-29 2012-05-03 Nissan North America, Inc. Method for presenting information to a host vehicle having a user interface
US10528334B2 (en) 2010-12-23 2020-01-07 Repairify, Inc. Remote vehicle programming system and method
US8688313B2 (en) 2010-12-23 2014-04-01 Aes Technologies, Llc. Remote vehicle programming system and method
US20110106374A1 (en) * 2010-12-23 2011-05-05 Margol Lonnie E Remote vehicle programming system and method
US9684500B2 (en) 2010-12-23 2017-06-20 Repairify, Inc. Remote vehicle programming system and method
US20140380442A1 (en) * 2011-01-14 2014-12-25 Cisco Technology, Inc. System and method for enabling secure transactions using flexible identity management in a vehicular environment
US8751777B2 (en) 2011-01-28 2014-06-10 Honeywell International Inc. Methods and reconfigurable systems to optimize the performance of a condition based health maintenance system
US8615773B2 (en) 2011-03-31 2013-12-24 Honeywell International Inc. Systems and methods for coordinating computing functions to accomplish a task using a configuration file and standardized executable application modules
US8990770B2 (en) 2011-05-25 2015-03-24 Honeywell International Inc. Systems and methods to configure condition based health maintenance systems
US9538374B2 (en) * 2011-05-27 2017-01-03 Flycar Innovations 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
US20140200760A1 (en) * 2011-05-27 2014-07-17 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
US9292979B2 (en) 2011-07-26 2016-03-22 United Parcel Service Of America, Inc. Systems and methods for managing fault codes
US8897953B2 (en) 2011-07-26 2014-11-25 United Parcel Service Of America, Inc. Systems and methods for managing fault codes
US9811951B2 (en) 2011-07-26 2017-11-07 United Parcel Service Of America, Inc. Systems and methods for managing fault codes
US20130097459A1 (en) * 2011-10-14 2013-04-18 Honeywell International Inc. Methods and systems for distributed diagnostic reasoning
US8726084B2 (en) * 2011-10-14 2014-05-13 Honeywell International Inc. Methods and systems for distributed diagnostic reasoning
US8744668B2 (en) * 2012-05-09 2014-06-03 Bosch Automotive Service Solutions Llc Automotive diagnostic server
CN103425578A (en) * 2012-05-18 2013-12-04 日立汽车系统株式会社 Test support system, test support method, method and program for testing support
US8832649B2 (en) 2012-05-22 2014-09-09 Honeywell International Inc. Systems and methods for augmenting the functionality of a monitoring node without recompiling
CN103424263A (en) * 2012-05-23 2013-12-04 株式会社堀场制作所 Test system
US20130325248A1 (en) * 2012-05-23 2013-12-05 Horiba, Ltd. Test system
US9322743B2 (en) * 2012-05-23 2016-04-26 Horiba, Ltd. Test system
US8832716B2 (en) 2012-08-10 2014-09-09 Honeywell International Inc. Systems and methods for limiting user customization of task workflow in a condition based health maintenance system
US11030560B1 (en) 2012-10-31 2021-06-08 Brandt Vx Llc Dispatch system
US20140324275A1 (en) * 2013-04-26 2014-10-30 Ford Global Technologies, Llc Online vehicle maintenance
US8924071B2 (en) * 2013-04-26 2014-12-30 Ford Global Technologies, Llc Online vehicle maintenance
US11164116B2 (en) 2013-09-23 2021-11-02 Farmobile, Llc Farming data collection and exchange system
US11361261B2 (en) 2013-09-23 2022-06-14 Farmobile, Llc Farming data collection and exchange system
US10963825B2 (en) 2013-09-23 2021-03-30 Farmobile, Llc Farming data collection and exchange system
US11107017B2 (en) 2013-09-23 2021-08-31 Farmobile, Llc Farming data collection and exchange system
US11507899B2 (en) 2013-09-23 2022-11-22 Farmobile, Llc Farming data collection and exchange system
US11126937B2 (en) 2013-09-23 2021-09-21 Farmobile, Llc Farming data collection and exchange system
US11410094B2 (en) 2013-09-23 2022-08-09 Farmobile, Llc Farming data collection and exchange system
US11361260B2 (en) 2013-09-23 2022-06-14 Farmobile, Llc Farming data collection and exchange system
US11151485B2 (en) 2013-09-23 2021-10-19 Farmobile, Llc Farming data collection and exchange system
US10818112B2 (en) 2013-10-16 2020-10-27 Smartdrive Systems, Inc. Vehicle event playback apparatus and methods
US11884255B2 (en) 2013-11-11 2024-01-30 Smartdrive Systems, Inc. Vehicle fuel consumption monitor and feedback systems
US11260878B2 (en) 2013-11-11 2022-03-01 Smartdrive Systems, Inc. Vehicle fuel consumption monitor and feedback systems
US10246104B1 (en) 2013-11-11 2019-04-02 Smartdrive Systems, Inc. Vehicle fuel consumption monitor and feedback systems
US20150193326A1 (en) * 2014-01-06 2015-07-09 Ford Global Technologies, Llc Method and apparatus for error identification and data collection
US11734964B2 (en) 2014-02-21 2023-08-22 Smartdrive Systems, Inc. System and method to detect execution of driving maneuvers
US11250649B2 (en) 2014-02-21 2022-02-15 Smartdrive Systems, Inc. System and method to detect execution of driving maneuvers
US10497187B2 (en) 2014-02-21 2019-12-03 Smartdrive Systems, Inc. System and method to detect execution of driving maneuvers
US10249105B2 (en) 2014-02-21 2019-04-02 Smartdrive Systems, Inc. System and method to detect execution of driving maneuvers
US9715767B2 (en) * 2014-08-07 2017-07-25 Launch Tech Co., Ltd. Method and apparatus for processing realtime vehicle operating data
US20160203653A1 (en) * 2014-08-07 2016-07-14 Launch Tech Co., Ltd. Method and apparatus for processing realtime vehicle operating data
EP3179320A4 (en) * 2014-08-07 2018-04-04 Launch Tech Company Limited Method and device for processing real-time vehicle traveling data
KR20170013277A (en) * 2014-08-07 2017-02-06 런치 테크 컴퍼니 리미티드 Method and device for processing real-time vehicle traveling data
KR101934348B1 (en) * 2014-08-07 2019-03-25 런치 테크 컴퍼니 리미티드 Method and device for processing real-time vehicle traveling data
US10146521B2 (en) 2014-09-09 2018-12-04 Airpro Diagnostics, Llc Device, system and method for updating the software modules of a vehicle
US9847043B1 (en) 2014-09-23 2017-12-19 State Farm Mutual Automobile Insurance Company Student driver feedback system allowing entry of tagged events by instructors during driving tests
US9751535B1 (en) 2014-09-23 2017-09-05 State Farm Mutual Automobile Insurance Company Real-time driver monitoring and feedback reporting system
US10414408B1 (en) 2014-09-23 2019-09-17 State Farm Mutual Automobile Insurance Company Real-time driver monitoring and feedback reporting system
US10083626B1 (en) 2014-09-23 2018-09-25 State Farm Mutual Automobile Insurance Company Student driver feedback system allowing entry of tagged events by instructors during driving tests
US9279697B1 (en) * 2014-09-23 2016-03-08 State Farm Mutual Automobile Insurance Company Student driver feedback system allowing entry of tagged events by instructors during driving tests
US11069257B2 (en) 2014-11-13 2021-07-20 Smartdrive Systems, Inc. System and method for detecting a vehicle event and generating review criteria
US10360739B2 (en) 2015-04-01 2019-07-23 Smartdrive Systems, Inc. Vehicle event recording system and method
US10930093B2 (en) 2015-04-01 2021-02-23 Smartdrive Systems, Inc. Vehicle event recording system and method
US10373523B1 (en) 2015-04-29 2019-08-06 State Farm Mutual Automobile Insurance Company Driver organization and management for driver's education
US9586591B1 (en) 2015-05-04 2017-03-07 State Farm Mutual Automobile Insurance Company Real-time driver observation and progress monitoring
US10748446B1 (en) 2015-05-04 2020-08-18 State Farm Mutual Automobile Insurance Company Real-time driver observation and progress monitoring
US9959780B2 (en) 2015-05-04 2018-05-01 State Farm Mutual Automobile Insurance Company Real-time driver observation and progress monitoring
US10621797B2 (en) 2015-05-19 2020-04-14 Hex Microsystems (Pty) Ltd System and method for transferring diagnostic commands to a vehicle
CN107848522A (en) * 2015-05-19 2018-03-27 海克斯微系统(私人)有限公司 For diagnostic command to be transmitted to the system and method for the vehicles
WO2016185360A1 (en) 2015-05-19 2016-11-24 Hex Microsystems (Pty) Ltd System and method for transferring diagnostic commands to a vehicle
EP3297880A4 (en) * 2015-05-19 2018-06-20 HEX Microsystems (Pty) Ltd System and method for transferring diagnostic commands to a vehicle
US20160364310A1 (en) * 2015-06-15 2016-12-15 International Business Machines Corporation Managing a set of tests based on other test failures
US10452508B2 (en) * 2015-06-15 2019-10-22 International Business Machines Corporation Managing a set of tests based on other test failures
CN105657037A (en) * 2016-02-04 2016-06-08 金龙联合汽车工业(苏州)有限公司 New energy vehicle and charging facility data acquisition method
US10706645B1 (en) * 2016-03-09 2020-07-07 Drew Technologies, Inc. Remote diagnostic system and method
US10730626B2 (en) 2016-04-29 2020-08-04 United Parcel Service Of America, Inc. Methods of photo matching and photo confirmation for parcel pickup and delivery
US10726381B2 (en) 2016-04-29 2020-07-28 United Parcel Service Of America, Inc. Methods for dispatching unmanned aerial delivery vehicles
US9928749B2 (en) 2016-04-29 2018-03-27 United Parcel Service Of America, Inc. Methods for delivering a parcel to a restricted access area
US10860971B2 (en) 2016-04-29 2020-12-08 United Parcel Service Of America, Inc. Methods for parcel delivery and pickup via an unmanned aerial vehicle
US10796269B2 (en) 2016-04-29 2020-10-06 United Parcel Service Of America, Inc. Methods for sending and receiving notifications in an unmanned aerial vehicle delivery system
US10460281B2 (en) 2016-04-29 2019-10-29 United Parcel Service Of America, Inc. Delivery vehicle including an unmanned aerial vehicle support mechanism
US10453022B2 (en) 2016-04-29 2019-10-22 United Parcel Service Of America, Inc. Unmanned aerial vehicle and landing system
US9981745B2 (en) 2016-04-29 2018-05-29 United Parcel Service Of America, Inc. Unmanned aerial vehicle including a removable parcel carrier
US11472552B2 (en) 2016-04-29 2022-10-18 United Parcel Service Of America, Inc. Methods of photo matching and photo confirmation for parcel pickup and delivery
US9957048B2 (en) 2016-04-29 2018-05-01 United Parcel Service Of America, Inc. Unmanned aerial vehicle including a removable power source
US9969495B2 (en) 2016-04-29 2018-05-15 United Parcel Service Of America, Inc. Unmanned aerial vehicle pick-up and delivery systems
US10706382B2 (en) 2016-04-29 2020-07-07 United Parcel Service Of America, Inc. Delivery vehicle including an unmanned aerial vehicle loading robot
US10202192B2 (en) 2016-04-29 2019-02-12 United Parcel Service Of America, Inc. Methods for picking up a parcel via an unmanned aerial vehicle
US10482414B2 (en) 2016-04-29 2019-11-19 United Parcel Service Of America, Inc. Unmanned aerial vehicle chassis
US10586201B2 (en) 2016-04-29 2020-03-10 United Parcel Service Of America, Inc. Methods for landing an unmanned aerial vehicle
US20170322791A1 (en) * 2016-05-04 2017-11-09 General Motors Llc Providing vehicle system module updates
US10318269B2 (en) * 2016-05-04 2019-06-11 General Motors Llc Providing vehicle system module updates
CN107346254A (en) * 2016-05-04 2017-11-14 通用汽车有限责任公司 Vehicle system module renewal is provided
US20190232959A1 (en) * 2016-06-20 2019-08-01 Jaguar Land Rover Limited Activity monitor
US11040715B2 (en) * 2016-06-20 2021-06-22 Jaguar Land Rover Limited Activity monitor
US10353691B2 (en) 2016-09-30 2019-07-16 Cummins Inc. Updating electronic controller through telematics
DE102016224193A1 (en) * 2016-12-06 2018-06-07 Robert Bosch Gmbh Method for monitoring a control device for a vehicle
US11435744B2 (en) 2017-06-13 2022-09-06 United Parcel Service Of America, Inc. Autonomously delivering items to corresponding delivery locations proximate a delivery route
US10775792B2 (en) 2017-06-13 2020-09-15 United Parcel Service Of America, Inc. Autonomously delivering items to corresponding delivery locations proximate a delivery route
US11501634B2 (en) 2018-08-03 2022-11-15 Honda Motor Co., Ltd. Information management apparatus, vehicle, and method
US20220240064A1 (en) * 2019-06-19 2022-07-28 Sigfox Vehicle-sharing system and method for accessing a vehicle from such a system
US11257307B1 (en) 2019-06-24 2022-02-22 Opus Ivs, Inc. Adaptive vehicle diagnostic system and method
WO2021001776A1 (en) * 2019-07-03 2021-01-07 Telepass S.P.A. System comprising an on-board unit for telematic traffic services
DE102019211155A1 (en) * 2019-07-26 2021-01-28 Volkswagen Aktiengesellschaft Method of a vehicle and a network server for servicing vehicle components
DE102019211154A1 (en) * 2019-07-26 2021-01-28 Volkswagen Aktiengesellschaft Method of a network server for servicing vehicle components
US11861954B2 (en) 2019-08-27 2024-01-02 Opus Ivs, Inc. Vehicle diagnostic system and method
US11348382B1 (en) 2019-10-30 2022-05-31 Opus Ivs, Inc. System and method for detecting remote vehicle diagnosis
US11508191B1 (en) 2019-12-03 2022-11-22 Opus Ivs, Inc. Vehicle diagnostic interface device
US11423715B1 (en) 2019-12-03 2022-08-23 Opus Ivs, Inc. Vehicle diagnostic device
US11538290B1 (en) 2020-01-31 2022-12-27 Opus Ivs, Inc. Automated vehicle diagnostic navigation system and method

Also Published As

Publication number Publication date
TW200404201A (en) 2004-03-16
CA2478176A1 (en) 2003-09-18
US20040138790A1 (en) 2004-07-15
JP2005520725A (en) 2005-07-14
EP1485878A2 (en) 2004-12-15
WO2003077205A2 (en) 2003-09-18
AU2003224647A1 (en) 2003-09-22
US7092803B2 (en) 2006-08-15
TWI237758B (en) 2005-08-11
WO2003077205A3 (en) 2004-01-29

Similar Documents

Publication Publication Date Title
US20050038581A1 (en) Remote Monitoring, Configuring, Programming and Diagnostic System and Method for Vehicles and Vehicle Components
US20050065678A1 (en) Enterprise resource planning system with integrated vehicle diagnostic and information system
US7676804B2 (en) Systems and method for remotely modifying software on a work machine
US20050060070A1 (en) Wireless communication framework
US6643571B2 (en) System and method for communication between vehicles and a supervisor station
US6775238B1 (en) Image forming device management system and method
US7397392B2 (en) Method for remote monitoring equipment for an agricultural machine
AU2002301638B2 (en) Integrated internet portal and deployed product microserver management system
US8244779B2 (en) Method and system for monitoring a mobile equipment fleet
US7516193B2 (en) Method and system for diagnosing, collecting information and servicing a remote system
US8050811B2 (en) Method for controlling the distribution of vehicle-related data
US20040220778A1 (en) Remote maintenance system and stock management system
US20090111520A1 (en) System for collection and distribution of machine data via a cellular device
US7545262B2 (en) Method and system for automated recall notification
JP2004530174A (en) System, method, and computer program product for remotely diagnosing, monitoring, configuring, and reprogramming vehicles
WO2007008279A1 (en) Vehicle diagnostics
US20070088473A1 (en) Method of communications between telematics terminal and electronic control unit and vehicle sensor information management method and apparatus using the same
WO2004092857A2 (en) System, method and computer program product for remote vehicle diagnostics, telematics, monitoring, configuring, and reprogramming
US20200058173A1 (en) System and method for remote diagnostics and monitoring of heavy equipment
WO2014091361A1 (en) Vehicle evaluation and lead generation

Legal Events

Date Code Title Description
AS Assignment

Owner name: IDSC HOLDINGS LLC, WISCONSIN

Free format text: MERGER;ASSIGNOR:NNT, INC.;REEL/FRAME:019554/0870

Effective date: 20051222

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION