US20130317732A1

Movatterモバイル変換

Info

Publication number: US20130317732A1
Application number: US13/954,560
Authority: US
Inventors: Christophe S. Borg; Christopher K. Copeland
Original assignee: BorgSolutions Inc
Current assignee: BorgSolutions Inc
Priority date: 2008-02-22
Filing date: 2013-07-30
Publication date: 2013-11-28
Also published as: US20130040636A1; US8244779B2; US8065342B1; US20120028635A1

Abstract

A method is disclosed. The method includes receiving a message from a remote device. The message includes data. The method further includes analyzing the data using a set of rules. The analyzing includes performing a maintenance analysis by analyzing the data using a set of asset maintenance rules and a set of asset usage rules. Responsive to the analyzing the data using the set of rules, an alert is sent.

Description

CROSS-REFERENCES TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No. 13/572,887, filed Aug. 13, 2012, which is a continuation of U.S. application Ser. No. 13/253,599, filed Oct. 5, 2011, which is a continuation of U.S. application Ser. No. 12/390,960, filed Feb. 23, 2009, which claims the benefit, under 35 U.S.C. §119(e), of U.S. Provisional Patent Application No. 61/030,636, entitled “METHOD AND SYSTEM FOR MONITORING A MOBILE EQUIPMENT FLEET,” filed Feb. 22, 2008, and naming Christophe S. Borg and Christopher K. Copeland as inventors. The above-referenced applications are hereby incorporated by reference herein in their entirety.

BACKGROUND OF THE INVENTION

In the construction industry, among many other industries, enterprises maintain large fleets of mobile equipment, which they deploy, employ, and redeploy throughout a series of geographically distributed worksites. The nature of a large fleet of mobile equipment creates a long series of problems, both obvious and subtle, that create adverse impact on the profitability of the fleet-owning enterprise.

From the perspective of maintaining a distributed fleet, obvious difficulties exist in terms of maintenance. The geographic distribution of equipment adds difficulty to a central motor pool's tracking of the simplest tasks, such as when an oil change is needed or when spark plugs need to be replaced. The prior art offers no good solution to these problems, other than sending a human being to collect and analyze data at great cost in terms of labor.

Additionally, the prior art offers no real way for a central office to determine the utilization of a distributed fleet. Owners of construction equipment that is distributed over a geographic area may know that three job sites need backhoes to complete excavations, but they have no sense of the number of hours per working day that an individual backhoe is utilized. Stated simply, when equipment is idle and the central routing facility does not know that the equipment is idle, capacity is wasted and potential profit is lost.

Further, various forms of theft are made easier by distributed fleets, and the prior art makes no allowance for preventing these thefts. The most obvious thefts, such as loading a backhoe onto a trailer and stealing the backhoe during the night, are difficult to catch without a distributed security force monitoring assets. A distributed security force represents, of course, a tremendously costly investment of labor. Smaller forms of theft, such as the same backhoe being “borrowed” by an employee to dig out a swimming pool on the weekend, cost the owner of the equipment a tremendous amount of money and are nearly impossible to effectively police with prior art methods.

Under the prior art, there is simply no cost-effective way to monitor, without tremendous investment of labor, the deployment and disposition of distributed equipment fleets.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention may be better understood in its numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings.

FIG. 1 illustrates an exemplary system for performing monitoring and management of a mobile equipment fleet, in accordance with one embodiment of the present invention;

FIG. 2 depicts an exemplary database server for performing monitoring and management of a mobile equipment fleet, in accordance with one embodiment of the present invention;

FIG. 3 illustrates an exemplary remote unit for performing monitoring and management of a mobile equipment fleet, in accordance with one embodiment of the present invention;

FIG. 4 depicts a flowchart of a process for performing monitoring and management of a mobile equipment fleet, in accordance with one embodiment of the present invention;

FIG. 5 illustrates a flowchart of a process for a remote unit transmitting data for monitoring and management of a mobile equipment fleet, in accordance with one embodiment of the present invention;

FIG. 6 depicts a flowchart of a process for a system of one or more servers receiving data for monitoring and management of a mobile equipment fleet, in accordance with one embodiment of the present invention;

FIG. 7 illustrates a flowchart of a process for receiving and delivering to a database a message received from a remote device in accordance with one embodiment of the present invention;

FIG. 8 depicts a flowchart of a process for device-specific database processing in accordance with one embodiment of the present invention;

FIG. 9 illustrates a flowchart of a process for a priority push in accordance with one embodiment of the present invention;

FIG. 10 depicts a flowchart of a process for push of processed events in accordance with one embodiment of the present invention;

FIG. 11 illustrates a lifecycle diagram for an event in accordance with one embodiment of the present invention;

FIG. 12 depicts a component diagram for a process for information backflow in accordance with one embodiment of the present invention;

FIG. 13 illustrates a flowchart of a process for information configuration push during instruction backflow in accordance with one embodiment of the present invention;

FIG. 14 depicts a flowchart of a process for instruction backflow in accordance with one embodiment of the present invention;

FIG. 15 illustrates a flowchart of an alerts engine in accordance with one embodiment of the present invention;

FIG. 16 depicts a flowchart of a process for generating a geofence report in accordance with one embodiment of the present invention;

FIG. 17 illustrates a component diagram for providing maintenance alerts in accordance with one embodiment of the present invention;

FIG. 18 depicts a flowchart of a process for providing maintenance alerts in accordance with one embodiment of the present invention;

FIG. 19 illustrates a flowchart of a process for use of maintenance alerts in accordance with one embodiment of the present invention;

FIG. 20 depicts a component diagram for providing maintenance alerts in accordance with one embodiment of the present invention;

FIG. 21 illustrates a flowchart of a process for providing maintenance alerts in accordance with one embodiment of the present invention;

FIG. 22 depicts a component diagram for the calculation of multi-factor compounded maintenance schedules in accordance with one embodiment of the present invention;

FIG. 23 illustrates an information flow diagram for performing monitoring and management of a mobile equipment fleet, in accordance with one embodiment of the present invention;

FIG. 24 depicts logical components of a system for acquisition of data to be used in conjunction with monitoring and management of a mobile equipment fleet, in accordance with one embodiment of the present invention;

FIG. 25 illustrates a flow of telematic data processing for monitoring and management of a mobile equipment fleet, in accordance with one embodiment of the present invention;

FIG. 26 depicts a flowchart of a process for maintenance data processing for monitoring and management of a mobile equipment fleet, in accordance with one embodiment of the present invention;

FIG. 27 illustrates a flowchart of a process for device trouble code processing for monitoring and management of a mobile equipment fleet, in accordance with one embodiment of the present invention;

FIG. 28 depicts a flowchart of a process for telemetry processing for monitoring and management of a mobile equipment fleet, in accordance with one embodiment of the present invention;

FIG. 29 illustrates a flowchart of maintenance alert notification processing for monitoring and management of a mobile equipment fleet, in accordance with one embodiment of the present invention;

FIG. 30 depicts physical components of a system for acquisition of data to be used in conjunction with monitoring and management of a mobile equipment fleet, in accordance with one embodiment of the present invention;

FIG. 31A-C illustrate an entity relationship diagram for an alerts and notifications portion of a database in accordance with one embodiment of the present invention;

FIG. 32A-D depict an entity relationship diagram for a maintenance portion of a database in accordance with one embodiment of the present invention;

FIG. 33A-B illustrate an entity relationship diagram for a device management and interaction portion of a database in accordance with one embodiment of the present invention;

FIG. 34A-C depict an entity relationship diagram for an assets portion of a database in accordance with one embodiment of the present invention;

FIG. 35 illustrates an entity relationship diagram for a communications portion of a database in accordance with one embodiment of the present invention is illustrated; and

FIG. 36A-C depict an entity relationship diagram for a device management and interaction portion of a database in accordance with one embodiment of the present invention.

DETAILED DESCRIPTION

Embodiments of the present invention provide a solution to the many problems associated with a geographically distributed fleet of mobile equipment or equipment capable of being moved or relocated. Location-aware and sensor-enabled remote devices (or user entry, when such remote devices are not available) enable a data processing system to track the location, condition, and employment of assets in a geographically distributed fleet of mobile equipment. Using an array of communication interfaces, embodiments of the present invention enable a remote device to report its location and accumulated sensor data to a system of databases and servers. One embodiment of the present invention then enables those servers and databases to provide users with information that enables the users to efficiently deploy, maintain and protect assets in a geographically distributed fleet of mobile equipment.

Example applications of embodiments of the present invention include the determination of asset location, whether the asset is being used at a specific moment or during a given portion of the day of the day, and whether the asset requires scheduled maintenance or is experiencing a malfunction (typically reflected in a diagnostic trouble code (DTC)). One embodiment of the present invention further offers integrated parts ordering and labor scheduling for the maintenance of assets in a geographically distributed fleet of mobile equipment. Further, one embodiment of the present invention enables users of assets in a geographically distributed fleet of mobile equipment to deter theft by alerting those users to unauthorized movement of assets in a geographically distributed fleet of mobile equipment.

With reference now to the figures, and in particular with reference toFIG. 1, an exemplary system for performing monitoring and management of a mobile equipment fleet, in accordance with one embodiment of the present invention, is illustrated.Remote devices100a-100n, which can be mounted to and acquire data from a broad range of vehicles and equipment (called assets), receive location signals102a-102nfrom a global positioning system (GPS)satellite104.

As used with respect to an embodiment of the present invention, thenotation100a-100nindicates a flexibly variable quantity of devices, and the presence of differently numbered devices bearing the same reference letter (e.g.,102aand100a), does not necessarily indicate a correspondence or interaction between differently numbered devices bearing the same reference letter. Further, the recurrence of ‘n’ as an alphabetical designator does not indicate that multiple flexibly variable quantities of devices are equal. Nor does the designation of a single member of such a plurality as ‘n’ indicate that it necessarily corresponds to an ‘nth’ member of a different plurality, though they may correspond.

While oneGPS satellite104 is illustrated for the purpose of simplicity inFIG. 1, one skilled in the art will, in light of the present disclosure, realize that conventional location techniques employ a plurality of signals transmitted from a constellation of satellites similar toGPS satellite104. While embodiments of the present invention are illustrated with respect to location signals102a-102nfrom asatellite104 of the global positioning system, one skilled in the art will, in light of the present disclosure, realize that embodiments of the present invention can be practiced with a broad range of location-determination systems, including, for example, both radio-frequency and gyroscopic systems.

In one embodiment,remote devices100a-100nare capable of transmitting and receiving data and messages in several ways.Remote device100atransmits and receives data and messages over asatellite uplink106 to acommunications relay satellite108, which then delivers downlink signals122 to asatellite signal receiver124.Remote device100btransmits and receives data and messages over a medium-range wireless signal114, such as the global system for mobile communications (GSM) network, to abase station116.Remote device100ntransmits and receives data and messages over a short-range radio connection110, such as a connection complying with one or more of the Institute for Electrical and Electronics Engineers (IEEE) 802.11a/b/g standards (“Wi-Fi”), to adata aggregation server112, which can integrally contain or be connected to a radio-frequency transceiver (not shown) for handling short-range radio connection110.

While, for the sake of simplicity in illustration, an embodiment of the present invention is illustrated inFIG. 1 with respect to each ofremote devices100a-100ncommunicating over only a single mode of communication, one skilled in the art will, in light of the present disclosure, realize that each ofremote devices100a-100ncan be capable, in varying embodiments of the present invention, of communicating using several modes of communication without departing from embodiments of the present invention. Further, one skilled in the art will, in light of the present disclosure, realize that each ofremote devices100a-100ncan be capable, in varying embodiments of the present invention, of communicating using modes of communication not illustrated inFIG. 1, without departing from embodiments of the present invention.

Public network links118a-118e, which are part of apublic network120 mediated by apublic switch132, connectbase station116 andsatellite signal receiver124, as well as a device-specific server126band a terminal128, to adata conversion server130. In one embodiment,data conversion server130, device specific-servers126a-126n, and data aggregation server are composed of instructions stored on a computer-readable medium and executed by a processor.

Terminal

128 also connects through a private network link134atodata conversion server130. Similarprivate network links134b-134dconnectdata aggregation server112 to device-specific server126a, connect device-specific server126atodata conversion server130 and connect device-specific server126ntodata conversion server130.Data conversion server130 executes several programs, including aweb server132 in a hypertext transmission protocol (HTTP) or secure hypertext transmission protocol (HTTPS) layer, anapplication server136 in an application layer and adatabase server138 in a database layer.

The example embodiment shown inFIG. 1 illustrates specific uses of finite quantities ofprivate network links134b-134dand public network links118a-118d. One skilled in the art will quickly realize, in light of the present disclosure, that alternative embodiments and implementations of the present invention will utilize different configurations and quantities ofprivate network links134b-134dand public network links118a-118das well as varying virtual private network connections to connect various elements used in implementing embodiments of the present invention. In one embodiment, data for use byapplication server136 can be acquired through user input atterminal128, data feed fromdatabase server138, or through a third party, which can provide complete databases, such as a database of weather and geography and effects on usage and wear of equipment, or can provide a discrete data service such as data aggregation through adata aggregation server112.

One skilled in the art will also realize that whiledata aggregation server112,data conversion server130, and device-specific servers126a-126nare illustrated inFIG. 1 as free-standing systems running on independent hardware, alternative embodiments and implementations of the present invention can combinedata aggregation server112,data conversion server130, and device-specific servers126a-126nor various elements of the functions and processes that they embody, into integrated systems.

In one embodiment,remote devices100a-100nreceive location signals102a-102nfrom a global positioning system (GPS)satellite104, anddata conversion server130 provides several location-aware functions, as will be described below. Trip processing bydata conversion server130 includes location-enabled monitoring of key events, such as ignition on, trip start, trip idle, trip stop, and ignition off.Data conversion server130 calculates incremental hours of use computed from ignition on to ignition off, as well as idle time and active time computed from events.Data conversion server130 also provides user-configurable support for other events thatdata conversion server130 receives during ignition “on” and “off” periods, which are grouped into a “trip” for reporting and display toterminal128.

Data conversion server

130 provides several location-aware functions based on the concept of ageofence144a(orgeofence144n).Geofence144ais a group of coordinates140a-140ndefining a region, though a geofence need not be defined in terms of a closed figure, but can be defined relative to asingle line146 without departing from embodiments of the present invention. Alternatively,geofence144nrepresents a spherical volume defined by a distance frompoint140z, for applications, for example, involving air-mobile or crane-supported equipment.Application server130 provides geofence-based job billing. In geofence-based job billing, a user ofterminal128 creates ageofence144nto encompass or otherwise demarcate a job site.Data conversion server130 records when an asset equipped with aremote device100nenters and exits the job site to determine the total time the asset was assigned to the job site.Data conversion server130 records the number of engine hours and distance traveled within thegeofence144nto determine asset utilization within the job site.

Data conversion server

130 further provides server-basedgeofence144nreporting that supports legacy systems for geographic reporting. Forgeofence144ncoordinate sets that are numerous or complex, processing can be done ondata conversion server130 using a geographic information system (GIS)-enabled database system.Data conversion server130 supports reporting toterminal128 by political and governmental regions and can display hours of use, distance traveled, and time present within a region calculated for governmental regions such as counties, parishes, boroughs, states, and countries.Data conversion server130 supports uploading throughterminal128 of regions in the form of shapefiles available from government survey authorities or other sources. Additionally,data conversion server130 supports user entry of anygeofence144nthat has value to the user. As an example, in one embodiment of the present invention, a user can define ageofence144nor set thereof by uploading through terminal128 a database of location points and then establishing circular regions of a given diameter, e.g., 100 meters, centered on the points, which, in one embodiment, represent oil wells serviced by an oilfield services company. In another embodiment, such points can indicate a route along which cable is to be buried or a road on which an item of equipment is to be transported. As illustrated inFIG. 1, coordinates140a-140ndefine an enclosed region, which could represent a construction site, for example.

Data conversion server

130 processes GPS events to determine which region(s)remote devices100a-100nare contained in and if a region boundary has been crossed since a last report. In one embodiment, if a boundary has been crossed, usage data can be prorated bydata conversion server130, based on actual time spent within the boundaries of a selected region.

Data conversion server

130 includes geofence-based reporting including utilization metrics that incorporate data gathered usinggeofence144n, as well as information such as hours-of-use data and distance-traveled data.Data conversion server130 allows a user to, on the basis ofgeofence144n, monitor and analyze any data received byremote device100n. For example, in one embodiment of the present invention,remote device100nis equipped with pump sensors and mounted to a water tank truck and a user ofdata conversion server130 can request reporting of the number of gallons of water pumped in each ofseveral geofences144n.

Data conversion server

130 can define ageofence144nas, for example, either multiple adjacent geofences, each defining a segment of the job site, that together encompass the entire job site, or one geofence that encompasses the entire job site and one or more smaller geofences, each of which is wholly within the job site geofence, that define segments of the job site. Further, equipment can be shared across (and billed out separately to each of) multiple job sites by defining separate geofences and recording time spent within the region defined by each geofence.Data conversion server130 includes an option to allow that ageofence144nor portions can be implemented onremote device100nif the regions of interest are known at the time the asset is in use. Thegeofence144nor portions can also be implemented retrospectively ondata conversion server130 to examine regions of interest after the period of equipment utilization.

Application server

136 generates reports that show for each asset, for example, calendar time on the job site in total and per job site segment, daily hours of use or distance traveled per job site segment, and daily utilization percentage per job site segment based on standard working hours defined for the job site.

Application server

136 further provides reporting and management of maintenance tasks. A maintenance task encapsulates a specific service to be performed on an asset. Examples include: engine oil and filter change, brake system inspection, tire rotation, and the like. Maintenance tasks can also be created for administrative actions such as Department of Transportation (DOT) registration, safety inspection, insurance renewal, and the like. Standard tasks from manufacturers are available based on equipment model, and are supported bydata conversion server130.Application server136 allows a user to accept the manufacturer's recommended rules or customize them throughterminal128. Reporting for maintenance tasks includes a model-specific list of parts required to perform the task, a list of labor resources and hours normally required to perform the task. For example, a task could require 2 hours Master Mechanic, 1 hour Hydraulic Specialist, and 1 hour Mechanic's Assistant.

Database server

138 maintains a master library of parts. In one embodiment, a part has the following properties: manufacturer; part identifiers (e.g., part number, stock keeping unit (SKU), uniform product code (UPC)); description; manufacturer's suggested retail price (MSRP); restocking level (i.e., a minimum number to keep in stock); and warranty terms. Each part record contains a compatibility matrix that represents the assets on which the part is used. Compatibility may, for instance, be defined by the manufacturer and model, manufacturer, model, and year of manufacture, or other criteria.Database server138 tracks the inventory of parts throughout their lifecycle. Operations affecting inventory include, among others, receiving parts, using a part for a work order, selling a part and adjusting part stock level (e.g., due to loss or theft).

Database server

138 generates a report of parts needed based on parts with an inventory level less than their restocking level, parts that are needed for current work orders, and parts that are anticipated for upcoming work orders.Database server138 can, from the list of parts needed, generate quote requests to be sent to part suppliers for quotation. From a quote request (or from scratch),database server138 generates purchase orders for the parts that are needed. When parts are received for a purchase order, their arrival is entered throughterminal128, and they are reconciled against the purchase order. In one embodiment of the present invention,data conversion server130 stores and monitors maintenance rules, which define the schedule on which maintenance tasks should be performed. A task defines a unit of work to be performed on an asset. In one embodiment each task has a task code (i.e., identifier) and a task type (e.g., preventative maintenance, predictive maintenance, repair, inspection, or administration). When a task is associated with a model, the following additional attributes can be made to apply to the “task+model” combination: a list of parts needed to perform the task (with quantities) and a list of labor resources needed to perform the task (with quantities). For example, a combination could require 2 hours of labor from a master mechanic and 1 hour of labor from a hydraulic specialist. This allows the parts and personnel needed for a given task to be “reserved” (though still in stock or otherwise available), allowing a more accurate view of the parts actually available and actual stock levels of a given part, for example.

Data conversion server

130 operates on schedules based on one or more of distance traveled, engine usage hours, and calendar time. As will be described below, past usage data is analyzed by components ofdata conversion server130 to predict the next time a maintenance task will be due. In one embodiment of the present invention, a maintenance alert can also be generated in response toremote device100nreceiving a DTC, or a monitored sensor onremote device100nreporting an out of normal range value. As used herein, an alert includes any notification between system components or to a user. An example of alerts according to one embodiment of the present invention is an alert passed between system components, such as the reporting of a DTC fromremote device100nto a device-specific server126n. Another such example is an alert passed from a system component to a user, such as a maintenance alert delivered in an email or a report delivered byapplication server136 using a web application. Yet another example is an alert passed from a system component to a third party system, such as a service request transmitted fromapplication server136 to a third-party service vendor. Other examples of alerts will vary between embodiments of the present invention without departing from the scope and intent of the present disclosure.

When an asset is added to the system, the user ofterminal128 can specify todata conversion server130 the next time a maintenance task should be performed so that assets can be added mid-maintenance cycle. Standard rules from manufacturers are available based on equipment model, and are supported bydata conversion server130.Application server136 allows a user to accept the manufacturer's recommended rules or customize them throughterminal128. In one embodiment, when an asset is sold from one entity, the asset's maintenance history can be transferred to the new owner (with the seller's permission).Data conversion server130 further supports part management, including attributes of a part such as manufacturer, stock keeping unit (SKU), type, supplier(s), restocking level, manufacturer's suggested retail price (MSRP), price, units, description, location date and method received, and cost.

Application server

136 implements a part acquisition process for identifying needed parts and acquiring them. A part need is identified bydata conversion server130, for example because a quantity in inventory is less than restocking level or because parts are requested for work orders and not available from inventory. Additionally,application server136 can calculate an anticipated part need by analyzing the upcoming maintenance tasks and the parts they require.

Application server

136 also provides a quote builder (not shown) that builds quotes. Parts are listed byapplication server136 in the quote builder as follows: one group of parts, each of which does not have an associated supplier and one group per supplier listing each part that is needed and is available from that supplier. A part can be listed byapplication server136 in the quote builder in more than one supplier group if it is available from more than one supplier. Suppliers can be added byapplication server136 in the quote builder to move parts from the “no suppliers” group and additional suppliers can be added to parts within a supplier group to quote them from n+1 suppliers. Suppliers can be removed byapplication server136 in the quote builder from a part to remove it from a quote request. The list of needed parts for a supplier is converted byapplication server136 in the quote builder into a quote request. The quote request consists of a list of each part needed and the quantity needed for work orders and inventory. The quantity can be adjusted manually throughterminal128 to request additional parts in excess of those required.

A part can be deleted from the quote request manually. Additional parts can be manually added throughterminal128 to the quote request.Application server136 provides delivery of the quote request to the supplier byapplication server136 emailing directly from the system, printing and faxing, printing and mailing, and electronic delivery through an integration with the supplier overnetwork120.

Application server

136 provides purchase order creation through several methods. In a first method, a user can create a purchase order fromscratch using terminal128 by selecting a supplier, selecting part(s) to purchase and quantity and price for each, and adding shipping and taxes. In a secondmethod application server136 creates a purchase order from a quote request.Application server136 creates a blank purchase order and then copies the parts list, quantity, and the like from the quote request. A user atterminal128 can adjust quantities, add parts or delete parts as desired. A user atterminal128 enters the price to pay for each part and adds shipping and taxes.Application server136 provides delivery of a purchase order to the supplier byapplication server136 emailing directly from the system, printing and faxing, printing and mailing, and electronic delivery through an integration with the supplier overnetwork120.

When parts are received,application server136 supports recordation of receipt of parts as delivery of a purchase order, in which a user atterminal128 enters the quantity of each part actually received (as the purchase order could arrive in multiple shipments).Application server136 pre-fills quantity blanks on display ofterminal128 with the number of parts remaining to be received for the purchase order. For each part,application server136 provides the following options for allocation: one item to stock and one item for every work order requesting the part. If there are enough parts received to satisfy all requesting work orders, thenapplication server136 allocates the parts to the work orders and the remaining, if any, are allocated to stock. If there are not enough parts to satisfy all requesting work orders, thenapplication server136 allocates parts to the oldest work orders first. The user atterminal128 can manually adjust the allocation of parts between work orders and stock.Application server136 associates a work order with an asset for performance of a maintenance task or a group of maintenance tasks. A Work Order consists of one or more tasks for performance on an asset using a list of parts (e.g. 4 quarts oil (part #ABC) and 1 ea. oil filter (part #XYZ)), using a list of labor (e.g. Employee A, 4 hours on Jul. 1, 2008 and Employee C 8 hours on Jul. 2, 2008) and using services of a third party (e.g. work performed at an external shop vs. in house). Parts needed for a work order may be configured by adding them individually, by selecting a set of parts that has been prescribed for performing the task by the task+model combination described above, or by selecting from a set of parts previously used for the same task on that asset or similar assets. If a part is assigned to a work order and there are not sufficient parts in stock to perform the work order, then a part request is created which feeds into the inventory “parts needed” calculation. When a work order is created, a notice is given if the asset is still under warranty. When parts are added to a work order, past work orders for the asset are checked to see if the same part has been used before and, if so, if it is still under warranty. If any parts are under warranty, a notice is given.

Application server

136 assigns to a work order a quantity of parts. If the parts are available in inventory, they are assigned to the work order byapplication server136. If the total quantity of parts is not available in inventory, thenapplication server136 assigns any that are available and the remainder are requested through a part acquisition process.Application server136 assigns to a work order hours from any number of employees, recording, for each employee, the date and number of hours. If employee hours across all work orders for that day are higher than a standard workday (e.g., eight hours),application server136 calculates labor cost at overtime rates, a calculation which can also be performed for weekends, holidays and the like, or other time periods during which modified billing rates are appropriate.

Application server

136 generates, for example the following metrics: total parts cost, total parts charge, total labor cost, total labor charge, total labor hours, total work order cost, and total work order charge (for invoicing and inclusion in a maintenance cost history, which is used by an asset replacement analysis engine, discussed and illustrated below). At the time of performing a work order, the asset's meter readings are recorded byremote device100nand associated with the work order bydatabase server138. In the case of an asset without aremote device100n, the meter readings are entered manually by a user atterminal128. In the case of an asset with aremote device100n, the most recent reading from the device is used and can be manually adjusted by the user atterminal128. The meter reading(s) now associated with the work order bydatabase server138 and the date the work order was performed are associated bydatabase server138 with the maintenance task to baseline the next time the maintenance task needs to be performed.

Application server

136 additionally facilitates employee management by storing indatabase server138 basic employee information and emergency contacts, providing evaluation of an employee based on, for example, ten criteria, and calculation of a rating and ranking of the employee on a configurable scale.Application server136 further provides attendance tracking with reason for absence and tardiness, which can be used for rating and ranking purposes. Work order efficiency is reported by comparing the actual labor hours used to complete a work order against the standards set for the task+model combination. Work order labor trends are reported by analyzing the actual labor hours spent for many instances of performing the same task.

Turning now toFIG. 2, an exemplary database server for performing monitoring and management of a mobile equipment fleet, in accordance with one embodiment of the present invention, is depicted.Database server138 contains device-specific databases200a-200n(which receive data) and amaster database202, which provide much of the processing that underlies the solutions provided by embodiments of the present invention. In one embodiment,master database202 contains data stored in a standardized format that represents events while accommodating a wide range of devices and implements procedures stored in Procedural Language/Postgre Structured Query Language (PL/pgSQL)™. (It will be noted that all trademarks used in the present specification are the property of their respective owners.) Use of trademarks or service marks in describing the present application is for example only and does not imply any affiliation between the inventor or assignee and the trademark or service mark owner.Master database202 supports manipulation of event data stored through event parameters such as, for example, start_trip and end_trip through the employment of a standard table structure schema.

In one embodiment,master database202 is accessed using a master database application program interface, which can be implemented as follows:


FUNCTION public.record_gps_event(

	_gps_device_id integer,
	_gps_trip_id integer,
	_event_timestamp timestamp with time zone,
	_gps_event_type_id integer,
	_gps_lock_type_id integer,
	_latitude numeric,
	_longitude numeric,
	_address character varying,
	_speed integer,
	_course integer,
	_total_trip_time integer,
	_accumulated_idle_time integer,
	_accumulated_travel_distance integer,
	_geofence_id integer,
	_input_number integer,
	_output_number integer,
	_sort_order integer,
	_inserted_by character varying)

RETURNS integer

/*

Record a gps_event in the master database.

The new event's gps_event_id is returned so that it can be referenced in

future.

*/

FUNCTION public.create_trip(

	_gps_device_id integer,
	_start_timestamp timestamp with time zone,
	_inserted_by character varying)

RETURNS integer

/*

Create a new trip in the master database.

The new trip's gps_trip_id is returned so that it can be referenced in the

future.

*/

FUNCTION public.add_event_to_trip(

	_gps_event_id integer,
	_gps_trip_id integer,
	_incremental_idle_minutes integer,
	_incremental_total_minutes integer,
	_incremental_meters integer)

RETURNS void

/*

Create an association between a gps_event and a gps_trip in the master

database.

Optionally, update the incremental idle minutes, total minutes, and meters

of the gps_event at the same time.

*/

FUNCTION public.update_meter(

	_gps_device_id integer,
	_asset_id integer,
	_meter_type_id integer,
	_meter_update_source_id integer,
	_amount numeric,
	_input_unit_of_measure_id integer,
	_display_unit_of_measure_id integer,
	_is_visible Boolean,
	_is_absolute Boolean,
	_last_updated_by character varying)

RETURNS void

/*

Update a meter by specifying a gps_device_id or asset_id and the

meter_type_id.

If the selected meter_type does not exist for the asset, it will be created.

*/

CREATE FUNCTION public.update_trip(

	_gps_trip_id integer,
	_end_timestamp timestamp with time zone,
	_meters integer,
	_idle_minutes integer,
	_total_minutes integer,
	_max_speed integer,
	_last_updated_by character varying)

RETURNS void

/*

Updates a gps_trip in the master database to set end_timestamp, total

meters, idle minutes, trip minutes, and maximum speed. The gps_trip

must be referenced by the gps_trip_id returned from create_trip.

*/

Each of device-specific databases200a-200nis specific to a particular type ofremote devices100a-100nand any similarremote devices100a-100ncommunicating through employment of a sufficiently similar protocol. In one embodiment, device-specific databases200a-200ncontain records204a-204n, the schema of each of device-specific databases200a-200nreflecting the structure of data associated with a particular type ofremote devices100a-100nand the assets to which they are deployed or with which they are associated. In one embodiment, fields of records204a-204ninclude data such as, for example, latitude, longitude, speed, heading and flags for information, including whether a record has been processed and pushed. While one embodiment of the present invention employs, PL/pgSQL™ and Java™, one skilled in the art will, in light of the present disclosure, realize that equivalent embodiments will employ other programming languages and architectures without departing from embodiments of the present invention.

Device-specific databases200a-200nreceive data from Java™ processes206a-206nrunning ondevice servers126a-126n. In one embodiment, Java™ processes206a-206nreceive messages fromremote devices100a-100n, which Java™ processes206a-206nthen package and deliver to device-specific databases200a-200n. When device-specific databases200a-200nreceive data from Java™ processes206a-206n, device-specific databases200a-200nsend acknowledgement to Java™ processes206a-206n. In one embodiment, device-specific databases200a-200nalso send downstream messages, including, for example, configuration information, to Java™ processes206a-206nfor delivery toremote devices100a-100n.

Device-specific databases200a-200nsend data to asynchronous device-specific pre-processing engines208a-208n, which identify devices needing processing and process new data to create new events, in a manner asynchronous to receipt, and return the data to device-specific databases200a-200nafter pre-processing. Device-specific databases200a-200nthen deliver the pre-processed events to one of a priority push engine210, which delivers the events tomaster database202 without processing, or a processed push engine212, which identifies events requiring processing and processes the events before delivering them tomaster database202.

One skilled in the art will, in light of the present disclosure, realize that while device-specific databases200a-200n, asynchronous device-specific pre-processing engines208a-208n, processed push engine212, priority push engine210 andmaster database202 are illustrated inFIG. 2 as independent modules, alternative embodiments and implementations of the present invention can combine device-specific databases200a-200n, asynchronous device-specific pre-processing engines208a-208n, processed push engine212, priority push engine210 andmaster database202 or various elements of the functions and processes that they embody, into integrated systems.

Asset management functions supported bymaster database202 include, among other functions, creating an asset record, associating an asset with aremote device100n, complete manual entry of data atterminal128, and receipt of data pre-filled from a vehicle information number or other such asset identifier, imported from upload of a data file or automatically created from a link to another system, such as a database owned by a customer.Master database202 supports usage measurement in terms of, among others, distance traveled, hours of engine use, or a combination of these. For equipment with multiple engines, hours of use are tracked per engine. Data can be uploaded tomaster database202, manually entered as incremental or absolute values or received fromremote devices100a-100n.

Referring now toFIG. 3, an exemplary remote device for performing monitoring and management of a mobile equipment fleet, in accordance with one embodiment of the present invention, is illustrated. As will be appreciated by one skilled in the art,FIG. 3 is a simplified schematic representation ofremote device100n, and one skilled in the art will, in light of the present disclosure, realize that it is possible to add, remove and substitute various components to fit the needs of various embodiments of the present invention.Remote device100nsupports many of the data gathering functions of embodiments of the present invention. In one embodiment,remote device100nis associated with an asset bydatabase server138 through a record inmaster database202.Remote device100ncontains aprocessor300, astorage unit302, aGPS antenna306, adata transceiver antenna308, asensor lead304, atactile input subsystem312 and adisplay unit314.Processor300,storage unit302,sensor lead304

GPS antenna

306,data transceiver antenna308,tactile input subsystem312 anddisplay unit314 are connected by abus310, which provides signal connectivity betweenprocessor300,storage unit302,sensor lead304,GPS antenna306,data transceiver antenna308,tactile input subsystem312 anddisplay unit314.

Processor

300 provides centralized control forremote device100n, executing instructions and processing data stored onstorage unit302, which one skilled in the art will, in light of the present disclosure, realize can be embodied by one of many forms of memory or disk storage, among other computer-readable storage media.GPS antenna306 receives GPS signals102a-102n, which enableprocessor300 to determine a location ofremote device100n.Remote device100nusesdata transceiver antenna308 for transmission of data and messages over, for example, short-range radio connection110, medium-range wireless signal114 orsatellite uplink106. Embodiments of the present invention support radio/modem, cellular-based, shortwave, Bluetooth, Wi-Fi, and like implementations.

Remote device

100ncommunicates with a user throughdisplay unit314, and a user communicates withremote device100nthroughtactile input subsystem312, such as a set of buttons and knobs or a keypad. Asensor lead304, or in some embodiments, multiple sensor leads, provide a data acquisition interface to enableremote device100nto receive signals from, and in some embodiments provide signals to, a vehicle or unit of equipment to whichremote device100nis attached. Signals readable byremote device100noversensor lead304 can include electrical impulses, such as data signals from an onboard computer in a vehicle or unit of equipment to whichremote device100nis attached.Sensor lead304 can attach to an interface (not shown) to a vehicle's onboard diagnostic system or from actual sensors indicative of asset conditions, such as whether an engine is started or stopped. In some embodiments,sensor lead304 can be equipped to detect external conditions such as temperature and humidity. In further embodiments,sensor lead304 can provide signals to a vehicle or unit of equipment, such as signals enablingremote device100nto start or stop an engine. One embodiment of the present invention supports telemetry data processing on the basis ofremote device100nbeing fitted to a mobile (or possibly fixed) asset such as a vehicle.

Remote device

100nusesdata transceiver antenna308 for transmission of data and messages, when, for example, an alert occurs due to, for example, the presence of a diagnostic trouble code (DTC), a malfunction indicator light (MIL) becoming illuminated, or a monitored parameter exceeding or falling below a threshold, which can also be triggered atdata conversion server130. Additionally,remote device100nusesdata transceiver antenna308 for transmission of data and messages, such as when, for example, telemetry is requested by one of device-specific servers126a-126n. When an alert message is received by one of device-specific servers126a-126n, it is converted into an actionable item in a standard format by one of device-specific servers126a-126nand passed todata conversion server130. For example, a DTC is looked up indata conversion server130 to determine the corrective action to be taken and a work order is created and transmitted toterminal128.

In one embodiment, device provisioning forremote device100n, including assignment of server address and network credentials for device-specific servers126a-126nis performed prior to customer deployment usingdata transceiver antenna308,tactile input subsystem312 anddisplay unit314. Likewise, device configuration can be determined manually usingtactile input subsystem312 anddisplay unit314 or by usingdata transceiver antenna308 to communicate standard configurations frommaster database202 based on an equipment type or usage profile.Remote device100nalso typically includes a serial port (not shown), and a user can connect toremote device100nthrough a serial connection and issue the provisioning commands, update firmware or perform other necessary functions.

Configuration scenarios supported byremote device100nprovide the ability for a user ofterminal128 to specify parameters to manufacturer's firmware, write rules for manufacturer's event engine or write custom firmware. Further,remote device100nsupports dynamic configuration, including reconfiguration on the asset based on rules related to, for example, sensitivity based on ignition, interval based on location relative to ageofence144n(inside/outside), an interval based on speed, an interval based on communication used during a time period, a set of geofences based on location, a set of geofences based on job assignment, or other factors that will vary from implementation to implementation.

Turning now toFIG. 4, a flowchart of a process for performing monitoring and management of a mobile equipment fleet, in accordance with one embodiment of the present invention, is depicted. The process depicted with respect toFIG. 4 provides one embodiment of several aspects of the overall interaction of various components of embodiments of the present invention, though one skilled in the art will quickly realize that steps may be added to, removed from, or substituted into the process described inFIG. 4. After starting, the process proceeds to step402, which illustratesremote device100ncollecting data, for example throughsensor lead304. The process next moves to step404. Step404 depictsremote device100ntransmitting data. Examples ofremote device100ntransmitting data include transmission of data and messages over, for example, short-range radio connection110, medium-range wireless signal114 orsatellite uplink106. The process then proceeds to step406, which illustrates one of device-specific servers126a-126n, for example, receiving data transmitted byremote devices100a-100n. The process next moves to step408. Step408 depicts one of device-specific servers126a-126n, for example, parsing an event from data transmitted byremote devices100a-100n. The process then proceeds to step410, which illustratesdata conversion server130 processing data. Such data processing can include exemplary processes discussed further with respect toFIG. 8 below, and includes database processing, such as event creation data format normalization. The process next moves to step412. Step412 depictsdata conversion server130 reporting an alert of the event toterminal128. The process then ends.

Referring now toFIG. 5, a flowchart of a process for a remote device transmitting data for monitoring and management of a mobile equipment fleet, in accordance with one embodiment of the present invention, is illustrated. The process depicted with respect toFIG. 5 provides one embodiment of several aspects of the transmission behavior ofremote devices100a-100ninstep404 above, though one skilled in the art will quickly realize that steps may be added to, removed from, or substituted into the process described inFIG. 5. After starting, the process proceeds to step502, which illustratesremote device100nchecking a transmit queue instorage302. The process next moves to step504. Step504 depictsremote device100ndetermining whether any untransmitted events are present in the transmit queue ofstorage302. If no untransmitted events are present in the transmit queue ofstorage302, then the process next moves to step508.

Step508 depictsremote device100ndetermining whetherremote device100nhas experienced a timeout on acknowledgement of any previously transmitted data. Ifremote device100ndetermines thatremote device100nhas not experienced a timeout on acknowledgement of a previously transmitted event, the process then returns to step502, which is described above. Ifremote device100ndetermines thatremote device100nhas experienced a timeout on acknowledgement of a previously transmitted event, the process proceeds to step510, which illustratesremote device100nreturning to transmit queue ofstorage302 an event for which a timeout on acknowledgement has occurred. The process then returns to step502, which is described above.

Returning to step504, if any untransmitted events remain in the transmit queue, then the process next moves to step512, which illustratesremote device100ndetermining whether, for example, short-range radio connection110, medium-range wireless signal114 orsatellite uplink106 are available todata transceiver antenna308 for transmission of data and messages. In some embodiments of the present invention,remote device100nwill have the ability to attempt communication over multiple links to (in parallel or in series) to determine whether, for example, short-range radio connection110, medium-range wireless signal114 orsatellite uplink106 are available todata transceiver antenna308 for transmission of data and messages. Ifremote device100ndetermines that short-range radio connection110, medium-range wireless signal114 orsatellite uplink106 are not available todata transceiver antenna308 for transmission of data and messages, then the process returns to step508, which is described above. Ifremote device100ndetermines that short-range radio connection110, medium-range wireless signal114 orsatellite uplink106 are available todata transceiver antenna308 for transmission of data and messages, then the process proceeds to step514. Step514 depictsremote device100ntransmitting data and messages over short-range radio connection110, medium-range wireless signal114 orsatellite uplink106. The process then returns to step504, which is described above.

Turning now toFIG. 6, a flowchart of a process for a system of one or more servers receiving data for monitoring and management of a mobile equipment fleet, in accordance with one embodiment of the present invention, is depicted. The process depicted with respect toFIG. 6 provides one embodiment of several aspects of the communication behavior of device-specific servers126a-126n, though one skilled in the art will quickly realize that steps may be added to, removed from, or substituted into the process described inFIG. 6. After starting, the process proceeds to step602, which illustrates one of device-specific servers126a-126nreceiving an event. The process next moves to step604. Step604 depicts one of device-specific servers126a-126nparsing the event received in step602. The process then proceeds to step606, which illustrates one of device-specific servers126a-126ncalling a database stored procedure on one of device-specific databases200a-200nand updating a timestamp for last communication withremote device100n. The process next moves to step608. Step608 depicts one of device-specific databases200a-200nstoring the event received in step602. The process then ends.

Referring now toFIG. 7, a flowchart of a process for receiving and delivering to a database a message received from a remote device in accordance with one embodiment of the present invention, is illustrated. The process depicted with respect toFIG. 7 provides one embodiment of several aspects of the message-handling behavior of device-specific servers126a-126n, though one skilled in the art will quickly realize that steps may be added to, removed from, or substituted into the process described inFIG. 7. After starting, the process then moves to step702, which illustrates one of device-specific servers126a-126nchecking a receive buffer. The process then proceeds to step704. Step704 depicts device-specific server126ndetermining whether there is a network (e.g., TCP or UDP) message in a receive buffer. If device-specific server126ndetermines that there is no message in a receive buffer, then the process returns to step702, which is described above.

Returning to step704, if device-specific server126ndetermines that there is a message in a receive buffer, then the process proceeds to step708. Step708 depicts device-specific server126nparsing a message in a receive buffer. The process next moves to step710, which illustrates device-specific server126ncalling a database routine on one of device-specific databases200a-200n. The process then proceeds to step712. Step712 depicts device-specific server126ndetermining whether the database call to device-specific database200nwas successful. If device-specific server126ndetermines that the database call to device-specific database200nwas successful, then the process next moves to step714, which illustrates device-specific server126nsending an acknowledgement to one ofremote devices100a-100n. The process then returns to step702, which is described above.

Returning to step712, if device-specific server126ndetermines that the database call to device-specific database200nwas not successful, then the process proceeds to step716. Step716 depicts device-specific server126nlogging an error. No acknowledgement is sent toremote device100n, with the effect thatremote device100nwill attempt to resend the message. The process then returns to step702, which is described above.

Turning now toFIG. 8, a flowchart of a process for device-specific database processing in accordance with one embodiment of the present invention is depicted. The process depicted with respect toFIG. 8 provides one embodiment of several aspects of the data processing behavior of device-specific databases200a-200n, broadly labeled as step410 above, though one skilled in the art will quickly realize that steps may be added to, removed from, or substituted into the process described inFIG. 8. One skilled in the art will recognize that device-specific databases200a-200ncontain data forremote devices100a-100nthat device-specific databases200a-200nserve.

After starting, the process moves to step802, which illustratesdatabase server138 measuring the amount of stored data awaiting processing and pushing. The process then proceeds to step804, which illustratesdatabase server138 determining whether sufficient pushed and unprocessed data exists. Ifdatabase server138 determines that insufficient pushed and unprocessed data exists, then the process next returns to step802, which is described above.

Returning to step804, ifdatabase server138 determines, in reference, for instance, to a user-configurable standard, that sufficient pushed and unprocessed data exists, then the process next moves to step808, which illustratesdatabase server138 generating a list ofremote devices100a-100nwith unprocessed data. The process then proceeds to step810. Step810 depictsdatabase server138 determining whether the list ofremote devices100a-100nwith unprocessed data is exhausted. Ifdatabase server138 determines that the list ofremote devices100a-100nwith unprocessed data is exhausted, then the process proceeds to step812, which illustratesdatabase server138 calling data push process212. The process then ends at step814.

Returning to step810, ifdatabase server138 determines that the list ofremote devices100a-100nwith unprocessed data is not exhausted, then the process next moves to step816. Step816 depictsdatabase server138 generating a list of unprocessed events (ordered by time stamp, for example) for aremote device100n. The process then proceeds to step818, which illustratesdatabase server138 determining whether the list of unprocessed events forremote device100nis exhausted. Ifdatabase server138 determines that the list of unprocessed events, ordered by time stamp, forremote device100nis exhausted, then the process next moves to step820. Step820 depictsdatabase server138 markingremote device100nas processed. The process then returns to step810, which is described above.

Returning to step818, ifdatabase server138 determines that the list of unprocessed events, ordered by time stamp, forremote device100nis not exhausted, then the process proceeds to step822, which illustratesdatabase server138 processing a next queued event from the list of unprocessed events, ordered by time stamp, for aremote device100n. The process then moves to step824. Step824 depictsdatabase server138 determining whether a synthetic event, which is created bydatabase server138, is needed in response to the processing of the event instep822. Ifdatabase server138 determines that no synthetic event is needed in response to the processing of the event instep822, then the process proceeds to step826, which illustratesdatabase server138 marking the event processed instep822 as processed. The process then returns to step818, which is described above.

Returning to step824, ifdatabase server138 determines that a synthetic event is needed in response to the processing of the event instep822, then the process next moves to step828. Step828 depictsdatabase server138 generating a synthetic event. The process then returns to step826, which is described above.

Referring now toFIG. 9, a flowchart of a process for a priority push in accordance with one embodiment of the present invention is illustrated. A priority push exists when an event is pushed ahead of processing. After starting, the process proceeds to step902, which illustratesdatabase server138 measuring unprocessed unpushed events. The process next moves to step904. Step904 depictsdatabase server138 determining whether raw events exist. Ifdatabase server138 determines that no raw events, which are both unpushed and unprocessed, exist, then the process returns to step902, which is described above.

Returning to step904, ifdatabase server138 determines that raw events exist, then the process proceeds to step906. Step906 illustratesdatabase server138 pushing an event by calling the record_gps_event function described above with respect to the application interface ofmaster database202. In one embodiment, pushing an event includes normalizing the event data from a device-specific format to a standardized format compatible with the functions, such as record_gps_event, ofmaster database202. The function record_gps_event records a GPS event, such as the movement of an asset, inmaster database202. The new event's identifier (e.g., gps_event_id) is returned so that the event can be referenced in future. The process next moves to step908, which depictsdatabase server138 marking the event as pushed. The process then returns to step902, which is described above.

Turning now toFIG. 10, a flowchart of a process for push of processed events in accordance with one embodiment of the present invention, is depicted. After starting, the process proceeds to step1002, which illustratesdatabase server138 measuring processed unpushed events. The process next moves to step1004.Step1004 depictsdatabase server138 determining whether processed unpushed events exist. Ifdatabase server138 determines that no processed unpushed events exist, then the process returns to step1002, which is described above.

Returning to step1004, ifdatabase server138 determines that processed unpushed events exist, then the process proceeds to step1006.Step1006 illustratesdatabase server138 pushing a processed event by calling, responsive to the content of the event, one or more of the add_event_to_trip, update_trip, update_meter, and create_trip functions described above. In one embodiment, pushing an event includes normalizing the event data from a device-specific format to a standardized format compatible with the functions, such as add_event_to_trip, update_trip, update_meter, and create_trip, ofmaster database202. Function add_event_to_trip allows for creation of an association between a gps_event data structure (which records a location-linked event) and a gps_trip data structure (which records a group of gps_event variables) inmaster database202. Function update_trip updates a gps_trip data structure inmaster database202 to set an end timestamp, meter totals, and other parameters. Function update_meter updates a meter reading inmaster database202 by specifying meter, asset, and device types. Function create_trip creates a new trip data structure inmaster database202. The process next moves to step1008, which depictsdatabase server138 marking the event as pushed. The process then returns to step1002, which is described above.

Referring now toFIG. 11, a lifecycle diagram for an event in accordance with one embodiment of the present invention is illustrated. The process depicted inFIG. 11 illustrates the handling of a message consistent with steps406-410 above, as viewed from the perspective of the data being processed. In one embodiment, the lifecycle begins at step1100, when an event from one ofremote devices100a-100nis received in one of device-specific databases200a-200n. After the event is received and entered in one of device-specific databases200a-200nfrom one ofremote devices100a-100n, araw event1102 exists in device-specific database200n, having been received fromremote devices100a. The lifecycle then proceeds through step1104, which depicts a priority push operation with no processing on priority push engine210. After the use of priority push engine210, a pushed andunprocessed event1106 exists in device-specific database200n. The lifecycle next moves through step1108. Step1108 illustrates device-specific database200nperforming data processing. After data processing, a processedevent1110 exists in device-specific database200n. The lifecycle then proceeds through step1112, which depicts a processed push operation with no processing on processed push engine212. The event lifecycle then ends.

Turning now toFIG. 12, a component diagram for information backflow in accordance with one embodiment of the present invention is depicted. A customer application1200 or anadministrator console1202 running on, for example, terminal128 sends application-level instructions1214a-1214bto master database1204 ondatabase server138. Application-level instructions can, for example, configureremote devices100a-100n, or a specific one of them, to transmit an alert if the speed of a vehicle exceeds a fixed velocity for a fixed length of time. Master database1204 ondatabase server138 then processes application-level instructions1214a-1214bto generate database-level instructions1216, whichdatabase server138 sends to aconfiguration push process1206, which typically executes ondata conversion server130.Configuration push process1206 ondata conversion server130 then transmits device database instructions1218a-1218nto each of device-specific databases200a-200n. In one embodiment, device-specific databases200a-200nestablish polls1208a-1208nfor regular bi-directional communication with device-specific servers126a-126nand device server instructions, derived from device database instructions1218a-1218nare sent to device-specific servers126a-126nusing polls1208a-1208n. One skilled in the art will, in light of the present disclosure, realize that alternatives to polls, such as heartbeat messages, may also be used. Device-specific servers126a-126ntransmit remote device instructions1210a-1210ntoremote devices100a-100n, which receive the device instructions1210a-1210nand respond with acknowledgements1212a-1212n.

Embodiments of the present invention can additionally provide for a flow of instructions frommaster database202 toremote devices100a-100nthrough instruction backflow. Referring now toFIG. 13, a flowchart of a process for information configuration push during instruction backflow in accordance with one embodiment of the present invention is illustrated. After starting, the process proceeds to step1302, which depictsconfiguration push process1206 ondata conversion server130 determining whether pending configuration changes have been received in database-level instructions1216 frommaster database138. Ifconfiguration push process1206 ondata conversion server130 determines that no pending configuration changes have been received in database-level instructions1216 frommaster database138, then the process next returns to step1302, which is described above.

Returning to step1302,data conversion server130 determines that pending configuration changes have been received in database-level instructions1216 frommaster database138, then the process proceeds to step1306, which illustratesconfiguration push process1206 ondata conversion server130 determining which of device-specific databases200a-200nserves theremote device100nto which pending configuration changes in database-level instructions1216 apply. The process next moves to step1308. Step1308 depictsconfiguration push process1206 ondata conversion server130 calling a stored procedure on a device-specific database200nto set a configuration in accordance with pending configuration changes in database-level instructions1216. The process then returns to step1302, which is described above.

Turning now toFIG. 14, a process for instruction backflow is depicted. The process depicted with respect toFIG. 14 provides one embodiment of several aspects of the communication behavior of embodiments of the present invention in transmitting information toremote devices100a-100n, though one skilled in the art will quickly realize that steps may be added to, removed from, or substituted into the process described inFIG. 14. After starting, the process proceeds to step1402, which depicts device-specific server126ndetermining whether a configuration change exists for aremote device100nwith whichpolls1212nindicate that communication is available. If device-specific server126ndetermines that no configuration change exists for aremote device100nwith whichpolls1212nindicate that communication is available, then the process returns to step1404, which is described above. Returning to step1404, if device-specific server126ndetermines that a configuration change exists for aremote device100nwith whichpolls1212nindicate that communication is available, then the process proceeds to step1408, which depicts device-specific server126ntransmittingremote device instructions1210ntoremote device100n. The process next moves to step1408.

Step1408 illustrates device-specific server126nlistening for anacknowledgement1212nfromremote device100n. The process then proceeds to step1412, which depicts device-specific server126ndetermining whether anacknowledgment1212nfromremote device100nwas received. If device-specific server126ndetermines that noacknowledgment1212nfromremote device100nwas received, the process then returns to step1410, which is described above. Returning to step1412, if device-specific server126ndetermines that anacknowledgment1212nfromremote device100nwas received, then the process proceeds to step1416, which depicts device-specific server126nmarking the configuration change sent inremote device instructions1210nas acknowledged. The process next returns to step1404 which is described above.

Referring now toFIG. 15, a flowchart of an alerts engine in accordance with one embodiment of the present invention is illustrated. The process ofFIG. 15 illustrates an embodiment of the event reporting ofstep412 above. The alerts described with respect toFIG. 15 are exemplary in nature, and one skilled in the art will realize, in light of the present specification, that alternative alerts may be implemented using similar location-based rules. After starting, the process proceeds to step1502, which illustratesdatabase server138 containingmaster database202 determining whether an event, which is an item of data, was received from one ofremote devices100a-100n. Ifdatabase server138 determines that an event was received from one ofremote devices100a-100n, then the process proceeds to step1506, which depictsdatabase server138 retrieving an asset to which theremote device100nfrom which the event was received is assigned. The process next moves to step1508.Step1508 illustratesdatabase server138 retrieving a list of rules, which are location-based rules, for the asset to which theremote device100nfrom which the event was received is assigned.

The process then proceeds to step1510, which depictsdatabase server138 determining whether a geofence exit event has been received. A geofence exit event occurs when an item of data representing the location ofremote device100ntransitions outside of a list of location parameters set by a user. Ifdatabase server138 determines that a geofence exit event has been received, the process then next moves to step1512.Step1512 illustratesdatabase server138 determining whether a rule requires the sending of an alert for the exit event detected. Ifdatabase server138 determines that no rule requires the sending of an alert for the exit event detected, then the process returns to step1502, which is described above. If, however, instep1512,database server138 determines that a rule requires the sending of an alert for the exit event detected, then the process proceeds to step1514, which depictsdatabase server138 sending an exit alert to a user atterminal128 or directly todisplay unit314 onremote device100n. The process then returns to step1502, which is described above. In alternative embodiments, exit alerts can be sent via SMS, email, or phone calls, depending on the configuration ofdata conversion server130 deployed in the alternative embodiment. Returning to step1510, ifdatabase server138 determines that a geofence exit event has not been received, the process then next moves to step1516.

Step

1516 illustratesdatabase server138 making a determination as to whether a speed threshold has been exceeded. A speed threshold has been exceeded when data including the location ofremote device100nis determined by comparison to a rule to have changed during a fixed period by an amount exceeding parameters set by a user. Ifdatabase server138 determines that a speed threshold has been exceeded, the process then next moves to step1518. In alternative embodiments, alerts can also be generated from theremote device100non the basis of the programming ofremote device100n, anddatabase server138 can be programmed to immediately recognize an alert as a speed alert.Step1518 illustratesdatabase server138 determining whether a rule requires the sending of an alert for speed threshold that has been exceeded. Ifdatabase server138 determines that no rule requires the sending of an alert for the speed threshold that has been exceeded, then the process returns to step1502, which is described above. If, however, instep1518,database server138 determines that a rule requires the sending of an alert for the speed threshold that has been exceeded, then the process proceeds to step1520, which depictsdatabase server138 sending a speed alert to a user atterminal128 or directly todisplay unit314 onremote device100n. The process then returns to step1502, which is described above. In alternative embodiments, speed alerts can be sent via SMS, email, or phone calls, depending on the configuration ofdata conversion server130 deployed in the alternative embodiment. Returning to step1516, ifdatabase server138 determines that a speed threshold has not been exceeded, the process then next moves to step1522.

Step

1522 illustratesdatabase server138 determining whether aremote device100nis in motion without engine ignition. Ifdatabase server138 determines thatremote device100nis in motion without engine ignition, the process then next moves to step1524. In alternative embodiments, alerts can also be generated from theremote device100non the basis of the programming ofremote device100n, anddatabase server138 can be programmed to immediately recognize an alert as an ignition alert. Step1524 illustratesdatabase server138 determining whether a rule requires the sending of an alert forremote device100nin motion without engine ignition. Ifdatabase server138 determines that no rule requires the sending of an alert forremote device100nin motion without engine ignition, then the process returns to step1502, which is described above. If, however, in step1524,database server138 determines that a rule requires the sending of an alert forremote device100nin motion without engine ignition, then the process proceeds to step1526, which depictsdatabase server138 sending an alert to the effect thatremote device100nis in motion without engine ignition to a user atterminal128 or directly todisplay unit314 onremote device100n. The process then returns to step1502, which is described above. In alternative embodiments, motion without ignition alerts can be sent via SMS, email, or phone calls, depending on the configuration ofdata conversion server130 deployed in the alternative embodiment. Returning to step1522, ifdatabase server138 determines thatremote device100nis not in motion without engine ignition, the process then next moves to step1502, which is described above.

The present alerts engine is depicted inFIG. 15 with respect to a set of three exemplary rules for an exit event, a speed alert and a notification of motion without engine ignition. One skilled in the art will quickly realize, in light of the present disclosure, that a wide range of rules (e.g., ignition outside of allowed times, motion outside of allowed times, and the like) can be implemented as part of the alerts engine depicted inFIG. 15.

Turning now toFIG. 16, a flowchart of a process for generating a geofence report in accordance with one embodiment of the present invention is depicted. The process ofFIG. 16 illustrates an embodiment of the event reporting ofstep412 above. After starting, the process proceeds to step1602, which depictsdatabase server138 containingmaster database202 reading a set of parameters, e.g., a list of assets, a list of geofences, or a date range. The process next moves to step1604.Step1604 illustratesdatabase server138 generating a query, e.g., in SQL, to retrieve events frommaster database202, where events contain fields such as, e.g., asset_id, geofence_id, event_type (such as enter or exit) and timestamp. The process then proceeds to step1606, which illustratesdatabase server138 determining whether untreated events remain in the results of the query generated instep1604. Ifdatabase server138 determines that no untreated events remain in the results of the query generated instep1604, then the process next moves to step1608.Step1608 illustratesdatabase server138 determining whether reporting is required. Ifdatabase server138 determines that no reporting is required, then the process ends. Ifdatabase server138 determines that reporting is required, then the process proceeds to step1612, which illustratesdatabase server138 rendering a report. The process then ends.

Returning to step1606, ifdatabase server138 determines that untreated events remain in the results of the query generated instep1604, then the process next moves to step1614.Step1614 illustratesdatabase server138 queuing a next untreated event. The process then proceeds to step1616, which illustratesdatabase server138 determining whether the event queued instep1614 is an entrance to a geofence perimeter. Ifdatabase server138 determines that the event queued instep1614 is an entrance to a geofence perimeter, the process next moves to step1618.Step1618 depictsdatabase server138 creating a geofence cycle data structure containing fields such as, e.g., asset_id for recording an asset with which the geofence cycle data structure is associated, geofence_id for recording a geofence with which the geofence cycle data structure is associated, enter_time for recording the time that the asset recorded in the asset_id field entered the geofence recorded in the geofence_id field, and exit_time for recording the time that the asset recorded in the asset_id field exited the geofence recorded in the geofence_id field. The process then returns to step1606, which is described above.

Returning to step1616, ifdatabase server138 determines that the event queued instep1614 is not an entrance to a geofence perimeter, the process next moves to step1620. Step1620 illustratesdatabase server138 searching for an open geofence cycle matching the event queued instep1614. The process then proceeds to step1622, which illustratesdatabase server138 closing the geofence cycle represented by the event queued instep1614 by setting its end_time variable to the time associated with the event queued instep1614. The process next moves to step1624.Step1624 illustratesdatabase server138 determining whethermaster database202 contains an asset record for the geofence corresponding to the geofence cycle closed instep1622. Ifdatabase server138 determines thatmaster database202 contains an asset record for the geofence corresponding to the geofence cycle closed instep1622, then the process proceeds to step1626, which depictsdatabase server138 incrementing a time-within-geofence accumulator variable for the asset record for the geofence corresponding to the geofence cycle closed instep1622, for instance, incrementing the accumulator variable by the minutes between time exited and time entered. The process then returns to step1606, which is described above.

Returning to step1624,database server138 determines thatmaster database202 does not contain an asset record for the geofence corresponding to the geofence cycle closed instep1622, then the process proceeds to step1628.Step1628 illustratesdatabase server138 creating an asset record for the geofence corresponding to the geofence cycle closed instep1622 by creating an asset record containing an asset_id variable identifying the relevant asset, a geofence_id variable identifying the relevant geofence, and an accumulator variable set to the difference between the exit time and the entrance time for the geofence cycle closed instep1622. The process then returns to step1606, which is described above.

Referring now toFIG. 17, a component diagram for providing maintenance alerts in accordance with one embodiment of the present invention is illustrated. In one embodiment of the present invention,maintenance rules1700,asset usage rules1702 andasset maintenance history1704 are stored in device-specific databases200a-200normaster database202 and illustrate an embodiment of the means necessary for the reporting ofstep412 above. In one non-limiting example of an embodiment of the present invention,asset usage rules1702 include a derived set of rules modeling an asset's typical usage rates and patterns based on observed data and events. Amaintenance analysis engine1706, which, in one embodiment, is part ofmaster database202, performs a maintenance analysis by using each ofmaintenance rules1700,asset usage rules1702 and data inasset maintenance history1704 to generatemaintenance alerts1708, whichdatabase server138 sends to a user atterminal128 or directly todisplay unit314 onremote device100n. In alternative embodiments,asset maintenance alerts1708 can be sent via SMS, email, or phone calls, depending on the configuration deployed in the alternative embodiment.

Turning now toFIG. 18, a flowchart of a process for providing maintenance alerts in accordance with one embodiment of the present invention is depicted. The process ofFIG. 18 illustrates an embodiment of the event reporting ofstep412 above. After starting, the process proceeds to step1802, which depictsmaintenance analysis engine1706 retrieving a list of assets to process. The process next moves to step1804.Step1804 illustratesmaintenance analysis engine1706 determining whether unprocessed assets remain. Ifmaintenance analysis engine1706 determines that no unprocessed assets remain, then the process ends. If, howevermaintenance analysis engine1706 determines that unprocessed assets remain, then the process proceeds to step1808, which depictsmaintenance analysis engine1706 retrieving from device-specific databases200a-200nall maintenance rules that apply to a next unprocessed asset. The process next moves to step1810.Step1810 illustratesmaintenance analysis engine1706 determining whether unprocessed maintenance rules remain among the rules selected at step1808. Ifmaintenance analysis engine1706 determines that no unprocessed maintenance rules remain among the rules selected at step1808, then the process returns to step1804, which is described above.

If, however,maintenance analysis engine1706 determines that unprocessed maintenance rules remain among the rules selected at step1808, then the process proceeds to step to step1812, which illustratesmaintenance analysis engine1706 retrieving from master database202 a record reflecting a last occasion on which a maintenance task associated with a selected rule was performed on the asset for which rules were retrieved in step1808. The process next moves to step1814.Step1814 illustratesmaintenance analysis engine1706 calculating a date or meter readings associated with the occasion on which the task associated with the selected rule will next be due on the asset for which rules were retrieved in step1808. The process then proceeds to step1816, which depictsmaintenance analysis engine1706 determining, through a query ofmaster database202, whether current date or meter readings are greater than the due date calculated instep1814. Ifmaintenance analysis engine1706 determines that current date or meter readings are greater than the due date calculated instep1814, then the process next moves to step1818.

Step

1818 illustratesmaintenance analysis engine1706 determining whether a maintenance alert exists for the rule for which retrieval was performed in step1812. Ifmaintenance analysis engine1706 determines that a maintenance alert exists for the rule for which retrieval was performed in step1812, then the process proceeds to step1820, which depictsmaintenance analysis engine1706 updating to today the due date for the maintenance alert associated with the maintenance rule described instep1810.

Returning to step1818, ifmaintenance analysis engine1706 determines that a maintenance alert does not exist for the rule for which retrieval was performed in step1812, then the process proceeds to step1822.Step1822 illustratesmaintenance analysis engine1706 creating a maintenance alert with the current date as its due date for the rule for which retrieval was performed in step1812. The process then returns to step1810, which is described above.

Returning to step1816, ifmaintenance analysis engine1706 determines that the current date or meter readings are not greater than the due date calculated or meter readings instep1814, then the process proceeds to step1826, which depictsmaintenance analysis engine1706 determining a date on which meter readings are predicted to exceed due values. The process next moves to step1828.Step1828 illustratesmaintenance analysis engine1706 determining whether the due date calculated instep1814 is within 30 days of the current date. Ifmaintenance analysis engine1706 determines that the due date calculated instep1814 is within 30 days of the current date, then the process proceeds to step1830, which depictsmaintenance analysis engine1706 determining whether the date on which meter readings are predicted to exceed due values calculated instep1826 is less than 30 days away. One skilled in the art will recognize that, while in the preferred embodiment discussed above, references are made to 30 day periods, one embodiment will be configurable to allow for periods of different lengths. Ifmaintenance analysis engine1706 determines that the date on which meter readings are predicted to exceed due values calculated instep1826 is less than 30 days away, the process next moves to step1832.Step1832 illustratesmaintenance analysis engine1706 creating a maintenance alert with a due date on the sooner of the due date used instep1828 or the date on which meter readings are expected to exceed due values as calculated instep1826. The process then returns to step1810, which is described above.

Returning to step1830, ifmaintenance analysis engine1706 determines that the date on which meter readings are predicted to exceed due values calculated instep1826 is not less than 30 days away, the process next moves to step1834, which depictsmaintenance analysis engine1706 creating a maintenance alert with a due date on the due date used instep1828. The process then returns to step1810, which is described above.

Returning to step1828, ifmaintenance analysis engine1706 determines that the due date calculated instep1814 is not within 30 days of the current date, then the process next moves to step1838.Step1838 depictsmaintenance analysis engine1706 determining whether the date on which meter readings are predicted to exceed due values calculated instep1826 is less than 30 days away. Ifmaintenance analysis engine1706 determines that the date on which meter readings are predicted to exceed due values calculated instep1826 is not less than 30 days away, then the process returns to step1810, which is described above. Ifmaintenance analysis engine1706 determines that the date on which meter readings are predicted to exceed due values calculated instep1826 is less than 30 days away, then the process proceeds to step1836, which illustratesmaintenance analysis engine1706 creating a maintenance alert with a due date on the due date used instep1826. The process then returns to step1810, which is described above.

Referring now toFIG. 19, a flowchart of a process for use of maintenance alerts in accordance with one embodiment of the present invention is illustrated. After starting, the process proceeds to step1902, which depicts a user accessing a maintenance-alerts-enabled application onterminal128. The process next moves to step1904. Step1904 illustrates a user of a maintenance-alerts enabled application onterminal128 viewing a list of maintenance alerts provided bymaintenance analysis engine1706. The process then proceeds to step1906, which depicts a user of a maintenance-alerts enabled application onterminal128 scheduling work orders for tasks on the basis of one or more maintenance alerts provided bymaintenance analysis engine1706. The process then ends.

Turning now toFIG. 20, a component diagram for providing maintenance alerts in accordance with one embodiment of the present invention is depicted. In one embodiment of the present invention,original asset costs2000, currentasset market values2002, costs ofequivalent replacement assets2004,maintenance cost history2008 andasset maintenance history2010 are stored in device-specific databases200a-200normaster database202 and illustrate an embodiment of the means associated with the reporting ofstep412 above. An assetreplacement analysis engine2006, which, in one embodiment, is part of master database202 (though, in an alternative embodiment, assetreplacement analysis engine2006 can be incorporated into another module) uses eachoriginal asset costs2000, currentasset market values2002, costs ofequivalent replacement assets2004,maintenance cost history2008 andasset maintenance history2010 to generateasset replacement alerts2012, whichdatabase server138 sends to a user atterminal128 or directly todisplay unit314 onremote device100n. In alternative embodiments,asset replacement alerts2012 can be sent via SMS, email, or phone calls, depending on the configuration deployed in the alternative embodiment.

Referring now toFIG. 21, a flowchart of a process for providing maintenance alerts in accordance with one embodiment of the present invention is illustrated. After starting, the process proceeds to step2102, which depicts assetreplacement analysis engine2006 retrieving a list of assets to process. The process next moves to step2104.Step2104 illustrates assetreplacement analysis engine2006 determining whether unprocessed assets remain. If assetreplacement analysis engine2006 determines that no unprocessed assets remain, then the process ends. If, however assetreplacement analysis engine2006 determines that unprocessed assets remain, then the process proceeds to step2108, which depicts assetreplacement analysis engine2006 retrieving from master database202 a history of actual maintenance for a selected asset, which, in one embodiment, is included inmaintenance cost history2008. The process then moves to step2110.Step2110 illustrates assetreplacement analysis engine2006 retrieving frommaster database202 an industry average maintenance model for a selected asset, which, in one embodiment, is included in predicted maintenance costs2010.

The process next proceeds to step2112, which depicts assetreplacement analysis engine2006 calculating predicted maintenance costs for the upcoming year, which, in one embodiment, is calculated based onmaintenance cost history2008 and predicted maintenance costs2010. While the implementation depicted calculates costs for the upcoming year, one skilled in the art will quickly realize, in light of the present disclosure, that the calculation can be made over any length of time desired. The process next moves to step2114.Step2114 illustrates assetreplacement analysis engine2006 retrieving from master database202 a current market value for the selected asset, which, in one embodiment, is included in currentasset market values2002. The process then proceeds to step2116, which depicts assetreplacement analysis engine2006 retrieving from master database202 a market price of a same or comparable replacement asset, which, in one embodiment, is included in cost ofequivalent replacement assets2004. The process next moves to step2118.Step2118 illustrates assetreplacement analysis engine2006 calculating predicted maintenance costs for the replacement asset for which acquisition cost was retrieved instep2116. The process then proceeds to step2120, which depicts assetreplacement analysis engine2006 calculating a predicted savings to result from asset replacement.

The process then moves to step2122.Step2122 illustrates assetreplacement analysis engine2006 determining whether the savings calculated instep2120 exceeds a user-configurable threshold. If assetreplacement analysis engine2006 determines that the savings calculated instep2120 does not exceed a user-configurable threshold, then the process returns to step2104, which is described above. If assetreplacement analysis engine2006 determines that the savings calculated instep2120 exceeds a user-configurable threshold, then the process proceeds to step2124, which depicts assetreplacement analysis engine2006 generating an asset replacement alert. The process then returns to step2104, which is described above.

Turning now toFIG. 22, a component diagram for the calculation of multi-factor compounded maintenance schedules in accordance with one embodiment of the present invention is depicted. In order to further refine accuracy of the results deliverable by assetreplacement analysis engine2006 andmaintenance analysis engine1706,database server138 calculates multi-factor compounded maintenance schedules, which illustrate an embodiment of the means associated with the reporting ofstep412 above.Database server138 uses an asset usage history including geographic coordinates2200 from device-specific databases200a-200n, a database of geological characteristics bylocation2202 withinmaster database202 and a database of equipment wear factor by material operated in/on2204 withinmaster database202 to compute a correlation between time worked in a given type of material andadditional wear2206. Correlation of time worked in type of material toadditional wear2206 allows for prediction of any accelerated maintenance needed by the equipment.Database server138 also uses asset usage history including geographic coordinates2200 from device-specific databases200a-200nwith a database of historical weather conditions bylocation2210 withinmaster database202 and a database of equipment wear factor by weather operated in2212 withinmaster database202 to calculate a correlation between the time worked in a given type of weather andadditional wear2214. Correlation of time worked in type of weather toadditional wear2214 allows for prediction of any accelerated maintenance needed by the equipment.

Database server

138 also uses asset usage history including geographic coordinates2200 from device-specific databases200a-200nwith an extensible database ofother factors2216 withinmaster database202 and a database of equipment wear factor by other factors2218 withinmaster database202 to calculate a correlation of time worked in type of other factors toadditional wear2220, where the “other factors” referred to herein are configurable by customer over time and can include, by way of non-limiting example, construction materials and level of demolition required or depth of surface abrasion expected. Other factors considered can vary from those described herein.

Referring now toFIG. 23, an information flow diagram for performing monitoring and management of a mobile equipment fleet, in accordance with one embodiment of the present invention is illustrated. In one embodiment of the present invention,asset listing2300, which is a data structure for listing assets, is provided to adata acquisition process2302.Asset listing2300 can be generated from a database. Referring now toFIG. 2, in one embodiment of the present invention,asset listing2300 is generated frommaster database202 or from a survey of device-specific databases200a-200n. For instance, referring briefly toFIG. 34A-C,asset listing2300 can be generated from database entities and functions3400, which is an assets portion of a database, non-limiting examples of which are illustrated below in the entity relationship diagrams ofFIG. 34A-C.

In one embodiment of the present invention,data acquisition process2302 includes, referring now toFIG. 4, steps402-406 ofFIG. 4.Data acquisition process2302 can be performed by, in the example of an embodiment depicted inFIG. 1,device servers126a-126nacting in concert withremote devices100a-100nthrough a wide range of communication channels. Communication channels can include, for example,satellite uplink106 tocommunications relay satellite108 anddownlink signals122 tosatellite signal receiver124; medium-range wireless signal114, such as a Global System for Mobile communications (GSM) network, tobase station116; or short-range radio connection110, such as a connection complying with one or more of the Institute for Electrical and Electronics Engineers (IEEE) 802.11a/b/g standards, to adata aggregation server112. Through the wide range of available communication channels described above,data acquisition process2302 can be executed by a platform-independent manner and receive data from equipment created by a broad range of vendors. Further, a user can provide information directly todata acquisition process2302 through entry at a terminal128. Finally, a third-party source, such as a fuel provider, can transmit data todata acquisition process2302.

Data acquisition process

2302 generates raw telematic data2304, the format and nature of which is as varied as the range of assets and data inputs described above and includes location and condition information from a variety of sources. Examples of raw telematic data include sensor results and location information fromremote device100nor human-entered data received throughterminal128. Raw telematic data2304 is then provided to a process oftelematic data processing2306, which normalizes raw telematic data2304 from its first (native) format to a second (standardized) format to create standardizedtelematic data2308. Examples oftelematic data processing2306 include, for example, step410 ofFIG. 4, step812 ofFIG. 8, or step1008 ofFIG. 10.

Standardizedtelematic data2308 is then provided to a maintenancedata processing process2312, such asmaintenance analysis engine1706 ofFIG. 17, that compares standardizedtelematic data2308 to a set ofmaster data2310, such asmaintenance rules1700 ofFIG. 17, containing rules or other relevant data structures and instructions. While maintenancedata processing process2312 is illustrated inFIG. 23, one skilled in the art will quickly realize, in light of the present disclosure, that embodiments of the present invention can be as easily practiced with regard to rules and data automating many aspects of a business, such as employee management, inventory accounting, asset location management, and cost accounting. Examples of alternative embodiments of the present invention include geographical information and geographical rules, such as are, for example, depicted with respect toFIG. 15.Maintenance data processing2312 compares received data, such as standardizedtelematic data2308 to a set of rules, such asmaintenance rules1700 to generatemaintenance data2314, including alerts, which are sent by adata presentation process2316, such as the process of maintenance alert use portrayed with respect toFIG. 19.Data presentation process2316 results in delivered data2318, such as alerts communicated via email or display onterminal128.

Turning now toFIG. 24, logical components of a system for acquisition of data to be used in conjunction with monitoring and management of a mobile equipment fleet, in accordance with one embodiment of the present invention are depicted. Note thatFIG. 30, described below, provides an embodiment of physical components that can perform the functions of the logical components illustrated inFIG. 24. In one embodiment of the present invention, the logical components displayed inFIG. 24 perform components ofdata acquisition process2302 ofFIG. 23.Direct user input2400 can be supplied through aweb application server2402, such asdata conversion server130 ofFIG. 1, and transmitted to a system providingtelematic data processing2404. Examples oftelematic data processing2404 include, for example, step410 ofFIG. 4, step812 ofFIG. 8, or step1008 ofFIG. 10.Telematic data processing2404, which is labeled above with respect toFIG. 23 astelematic data processing2306, normalizes raw telematic data2304 received form a variety of sources from its first (native) format to a second (standardized) format to create standardizedtelematic data2308.

Atelematic device2406, such asremote unit100nofFIG. 1, can send data in a highly customized manner. In one embodiment,remote unit100ncan communicate over short-range radio connection110, such as a connection complying with one or more of the IEEE 802.11a/b/g standards, to a proprietary device server (such as device-specific server126nor data aggregation server112) using a proprietary protocol, referred to as a Device Direct Proprietary Protocol (DDPP). Examples DDPPs include protocols used by devices used for remotely monitoring the position of an asset, which are also known as Automatic Vehicle Location (AVL) devices. In such an embodiment,telematic device2406 sends data to aproprietary device server2408, which may be implemented asdevice server126nofFIG. 1, for communication to adevice database2410, which may be implemented as device-specific database200bofFIG. 2, and eventual delivery totelematic data processing2404.

Embodiments of the present invention allow for interoperability with a broad range ofexternal data systems2452 including processes, applications and devices communicating over standardized interfaces and protocols, which can include proprietary components, third-party components, and/or other components. For example,direct user input2412, such as input into a business application or a web reporting service can be communicated to a queryable interfacecompliant application2416, such as a web service. Similarly,automated input2414, such as pump data received from a gasoline or water pump at a service station, can be communicated to a queryable interfacecompliant application2416. Queryable interfacecompliant application2416 can then provide data through aqueryable integration interface2418 to adata pulling agent2422 for presentation to anintegration database2424, which, in one embodiment, can reside ondata conversion server130 ofFIG. 1. Examples of data acquisition using aggregator pull solutions include business applications that store asset-related data such as fuel usage, mileage, or maintenance costs. Similarly, queryable interfacecompliant application2416 can deliver data to aweb services endpoint2442 using adata pushing agent2420. Examples of aggregator push systems include vehicle location service providers.

In one embodiment of an aggregator push solution in accordance with the present invention, atelematic device2436 can communicate with a push-compliant third-party application2438, such as a navigation and dispatching support system, which interacts directly with adata pushing agent2440 to deliver data toweb service endpoint2442 for presentation to anintegration database2444 and communication totelematic data processing2404.

Further, atelematic device2426 may communicate directly with a queryable interfacecompliant application2428, such as a driver performance monitoring system, which provides data to adevice database2434 through adata pulling agent2432 that interrogates aqueryable integration interface2430, thereby allowingdevice database2434 to receive data from a telematic device for which it has no direct protocol access. In one embodimentdata pulling agent2432 initiates calls toqueryable integration interface2430 on a regular schedule, e.g., every 5 minutes. In one implementation, the act of queryingqueryable integration interface2430 consists ofdata pulling agent2432 building a Standard Object Access Protocol (SOAP) request and transmitting it to thequeryable integration interface2430 over a TCP/IP socket. The SOAP request contains parameters necessary to retrieve the data of interest such as dates, customer identifiers, and/or asset or device identifiers. In response to the SOAP request sent bydata pulling agent2432 toqueryable integration interface2430, a response encoded in XML is returned todata pulling agent2432 which is stored indevice database2434.

Atelematic device2446, such asremote unit100nofFIG. 1, can send data in a standardized manner to astandard device server2448, which then delivers the data to adevice database2450 for presentation totelematic data processing2404, by providing standardized interfaces allowing any device or system implementing the interfaces to send data into device-specific databases200a-200nusing, for example, a Device Direct Standard Protocol (DDSP).

Referring now toFIG. 25, a flow of telematic data processing for monitoring and management of a mobile equipment fleet, in accordance with one embodiment of the present invention, is illustrated. Rawtelematic data2500 is normalized, using a set ofconversion processes2550 from its first (native) format, in which it is received, to a second (standardized and/or device-neutral) format to create standardized telematic data2502 through a series of steps illustrated inFIG. 26, which are an embodiment oftelematic data processing2306 and will vary according to the type of rawtelematic data2500.Telematic data processing2306 allows the standardized telematic data2502 to be utilized generically within a system without applying special logic based on the source of the data. While some data sources are capable of producing standards-compliant native-format data, generally speaking, the format of rawtelematic data2500 and the format of standardized telematic data2502 are different formats.

Rawtelematic data2500 may take the form of a diagnostic trouble code (DTC)2504. To convert aDTC2504 to astandardized DTC2510,telematic data processing2306 includes conversion of encodeddata2506 and mapping of parameters tocommon names2508. Examples A-C, below, depict different examples of raw formats that are converted to a standardized format for use asstandardized DTC2510.

Example (A) ofDTC2504 depicts a raw SAE J1939 DM1 message fragment, in which the received data is:
0x970314 (hexadecimal)
0000 0000 1001 0111 0000 0011 0001 0100 (binary)
Example (B) ofDTC2504 depicts a partially decoded, attribute value pair notation, in which the received data is:

SPN=1208; FMI=3; OC=10

Example (C) of DTC2504: depicts a proprietary XML-encoded fragment, in which the received data is:


	<DTC>

	<PARAMETER>4584</PARAMETER>
	<CHANNEL>2</CHANNEL>
	<DETAIL MODE=“3” />
	<COUNT>10</COUNT>

	</DTC>

For each of examples A-C,telematic data processing2306 uses conversion of encodeddata2506 and mapping of parameters tocommon names2508 to generate astandardized DTC2510 indicating that the monitored parameter “Engine Pre-filter Oil Pressure” has entered the failure mode indicating “Voltage Above Normal, Or Shorted To High Source” and the failure mode has occurred 10 times. In one embodiment, the resultingstandardized DTC2510 may use content identical to Example C as a standardized data storage format forstandardized DTC2510.

Additionally, rawtelematic data2500 may include bus-deriveddata2512. Examples of bus-derived data include data compliant with the Controller Area Network Bus (CANbus) standards published by the Society of Automotive Engineers (SAE), including, for example, the SAE J1939 and SAE J1708 standards. Examples of the data provided include an “on”, “working”, “idle” or “off” state of an engine (based on revolution per minute (RPM) rates and rules for decoding them), fuel consumption data, speed data, or mileage data.

To convert bus-deriveddata2512 tometer updates2518,telematic data processing2306 includes conversion processes2502 for conversion of encodeddata2514 and mapping tometer type2516. In one embodiment of mapping tometer type2516, “Engine Total Hours of Operation” is mapped to the meter type “Hour Meter.” In order to generatemeter updates2518, mapping tometer type2516 determines the type of update, (e.g., absolute). A call to the meter_update( ) stored procedure ondatabase server138 is executed, passing the unique device identifier, update type, timestamp, and “Engine Total Hours of Operation” as parameters. The meter_update( ) stored procedure records the meter update inmaster database202 by performing SQL insert and updated operations.

Receipt of bus-deriveddata2512 is available from a telematic device, such asremote unit100n, which is capable of communicating on a vehicle bus utilizing the SAE J1939 protocol.Remote device100nreads and delivers as bus-deriveddata2512 the SPN 247 “Engine Total Hours of Operation” signal, which includes binary encoded data of size 4 bytes, indicating 0.05 hr/bit, with 0 offset.Remote device100ntransmits:

1. Unique Device Identifier

2. Date and time the data was read

3. Raw 4 bytes

Conversion of encodeddata2514 takes the raw four bytes and converts the raw four bytes to an unsigned integer. The resulting value is multiplied by 0.05 to yield the decoded “Engine Total Hours of Operation.”

Alternatively, if standards-compliant raw meter updates2520 are received as raw data, they are used as standardized data2502. Examples of meter updates2520 can include odometer updates, engine hour meter updates, separator hours updates for a combine, pump hours updates for a concrete truck, or any other running tally of the use of equipment associated with an asset. Meter updates2520 can also include absolute data (such as engine hours=12,345 total) or incremental data (such as engine use=+13.5 hours for a particular session).

Rawtelematic data2500 may also take the form of GPS-derived odometer updates2522. GPS-derivedodometer updates2522 involve the conversion of GPS-coordinates to estimate a linear distance traveled, and can be used, as a proxy for an odometer reading, to estimate asset usage when an odometer reading is not available. To convert GPS-derived odometer update2522 (also called a virtual odometer reading) tometer update2518,telematic data processing2306 includes conversion processes2502 for conversion of encodeddata2524 and mapping tometer type2526.

Example (A)

In one embodiment, an absolute virtual odometer reading from a telematic device consists of the following data:

- 1. Unique Device Identifier
- 2. Date and time the reading was recorded
- 3. Number of miles (or kilometers or some distance measure) traveled since last reset of virtual odometer

Example (B)

In one embodiment, an incremental virtual odometer reading from a telematic device consists of the following data:

- 1. Unique Device Identifier
- 2. Date and time the reading was recorded
- 3. Number of miles (or kilometers or some distance measure) traveled since the last incremental virtual odometer reading was transmitted
  In one embodiment, conversion of encodeddata2524 includes both conversion of each parameter of the message from its native format (binary, character, XML, or other encoding) into primitive values of integers and timestamps and conversion of the distance traveled into meters, which is used as the standard unit of measure in the system for distance. In one embodiment, mapping tometer type2526 includes determination of the type of meter being updated, (e.g., virtual odometer updates map to an odometer meter type). In one embodiment, mapping tometer type2526 completes the conversion of GPS-derivedodometer update2522 by executing the following steps:
- 1. Determine the type of update, either absolute (Ex. A) or incremental (Ex. B).
- 2. Execute a call to the meter_update( ) stored procedure on the master database server passing the unique device identifier, update type, timestamp, and distance traveled as parameters.
- 3. The meter_update( ) stored procedure records the meter update in the master database by performing SQL insert and updated operations.

Rawtelematic data2500 may further take the form ofbus data2528. Examples of bus data can include odometer and hour meter readings, sensor readings (such as engine coolant temperature), and certain device trouble codes. To convertbus data2528 tostandardized telemetry2534,telematic data processing2306 includes conversion processes2502 for conversion of encodeddata2530 and mapping of parameters tocommon names2532.

Rawtelematic data2500 may additionally take the form ofmovement events2536, which may be received directly astrips2538 orstandardized events2542, which can then be converted to asset state updates2544. Examples of an asset state include “the cargo door is open,” which would inform the system that the state of the cargo door of the asset is “open” until a “cargo door is closed” state update is received. Work/idle state updates2540 may also be received directly asstandardized events2542, which can then be converted to asset state updates2544. Similarly,sensor data2546 may be aggregated intoinput cycles2548 for use as meter updates2518.Sensor data2546 can include any data received by amobile unit100nover asensor lead304 or a serial port, for example. Typical examples of sensor data include detection of whether an engine has turned on or off, detection of whether a cargo door has opened or closed, detection of a temperature in a refrigerated compartment, detection of whether a dump truck gate has opened or closed, and detection of whether a power take-off (PTO) is engaged. Other examples of sensor data will vary from embodiment to embodiment.

Turning now toFIG. 26, a flowchart of a process for maintenance data processing for monitoring and management of a mobile equipment fleet, in accordance with one embodiment of the present invention, is depicted. In one embodiment, preventive maintenance alerts are created from usage information accumulated for an asset, which is compared to maintenance schedules that can be applied to a single asset or a group of assets. In one embodiment, usage information for an asset is a part of standardizedtelematic data2308, and is more specifically contained in meter updates2518. The process of creating maintenance alerts is2312 shown in more detail inFIG. 18, above. Referring briefly toFIG. 18, in one embodiment, step1808 includes retrieval of all maintenance rules that apply to an asset. Maintenance rules which apply include those that are directly assigned to the asset and those that are assigned to a group of assets where the asset is a member of the group. Groups of assets can be flexibly defined on the basis of a broad range of factors, which include the manufacturer of an asset, the model or year of an asset, or the equipment type of an asset (e.g., an excavator, loader, or passenger vehicle). Examples of groups provided by the system include groups based on asset type (e.g., all excavators belonging to an enterprise or all passenger vehicles leased by an enterprise regardless of manufacturer, year of manufacture), groups based on model (e.g., all Ford F-150 pickup trucks), and groups based on location (e.g., all assets domiciled at the northwest regional yard). The system also supports user-defined groups which allow the user to define a group for any purpose. Example usage of a user-defined group includes all assets expected to be used in the next month, all assets planned for sale or disposal, and all assets requiring a trailer for transport between locations.

Further, maintenance can be scheduled for attachments to assets, which can be attached and recorded as being attached in a fixed or interchangeable manner. After starting, the process moves to step2602, which depictsmaintenance analysis engine1706 determining that new standardized telematic data2502 is available for processing. The process then proceeds to step2604. Step2604 illustrates processing of preventative maintenance alerts, which can be, in one embodiment, performed bymaintenance analysis engine1706. An example of a process of processing preventative maintenance alerts is provided inFIG. 18, which is described above. The process then moves to step2606, which depicts processing of device trouble codes. An example of a process for processing device trouble codes is described below with respect toFIG. 27. The process next moves to step2608, which depicts processing telemetry data. An example of a process for processing telemetry data is described below with respect toFIG. 28. The process then ends.

Referring now toFIG. 27, a flowchart of a process for device trouble code processing for monitoring and management of a mobile equipment fleet, in accordance with one embodiment of the present invention, is illustrated.FIG. 27 displays the steps taken when a new DTC is available for processing. In one embodiment, the steps ofFIG. 27 are performed bymaintenance analysis engine1706. Additionally, the process illustrated inFIG. 27 reflects one embodiment ofmaintenance data processing2312. Many assets, such as automobiles, constantly report a DTC while the DTC remains active. If a DTC is determined to be new, a tracking record is created for the DTC. Rules for creating maintenance alerts based on the DTC and the asset with which it is associated are then retrieved. In one embodiment, the task for which the maintenance alert is created is selected by a prioritized search for the most specific rule that applies to the asset. In one embodiment, such a search is conducted in the following order:

A rule that matches the manufacturer, model, and year of manufacture;

A rule that matches the manufacturer and model;

A rule that matches the manufacturer;

If the DTC is related to the engine;

- A rule that matches the engine manufacturer and engine model, and
- A rule that matches the engine manufacturer;

A rule that matches the asset type; and

A rule that matches the DTC.

For example, a DTC for “Engine coolant temperature exceeds normal range” triggers a maintenance alert for the “Cooling System Inspection” task. These rules may be defined with a variable number of parameters such that they apply only when the DTC occurs on assets of a particular make, model, year of manufacture, or type of asset. Notifications are then processed for any maintenance alerts that are created.

The process ofFIG. 27 provides for tracking of DTCs that are currently active and identifying, by creating a tracking record, new DTCs that are detected. After starting, the process moves to step2702, which depicts receiving a new DTC. The process then proceeds to step2704. Step2704 illustrates determining whether a DTC tracking record exists for the asset associated with the DTC received instep2702. If it is determined that a tracking record exists for the asset associated with the DTC received instep2702, then the process next moves to step2706, which depicts performing an update of a “last seen” time stamp on the DTC tracking record referenced in step2704. The process then ends.

Returning to step2704, if it is determined bydatabase server138 through a query ofmaster database202 that a tracking record does not exist for the asset associated with the DTC received instep2702, then the process next moves to step2708.Step2708 illustratesdatabase server138 creating a new DTC tracking record inmaster database202 for the asset associated with the DTC received instep2702. The process then proceeds to step2710, which depicts retrieval bydatabase server138 through a query ofmaster database202 of maintenance alert rules for the DTC received instep2702. The process next moves to step2712.Step2712 illustrates determining whether maintenance alert rules were found for the DTC received instep2702. If it is determined that no maintenance alert rules were found for the DTC received instep2702, the process then ends at step2718. If, however, it is determined that maintenance alert rules were found for the DTC received instep2702, then the process proceeds to step2714, which depicts creation of a maintenance alert.

The process next moves to step2716.Step2716 illustrates processing of notification rules. The process then ends. An example of a process for processing maintenance rules is discussed below with respect toFIG. 29.

Turning now toFIG. 28, a flowchart of a process for telemetry processing for monitoring and management of a mobile equipment fleet, in accordance with one embodiment of the present invention, is depicted. When data is received, data is processed against a multivariate rule set based on the reported values and known asset information such as make, model, type, and usage profile. Turning briefly toFIG. 2, reported values include any information received atdatabase server138. Turning briefly toFIG. 15, one example of a multivariate rule set is the set of geofence rules retrieved instep1508, where the multiple variables include speed, ignition condition, and position. Turning briefly toFIG. 17, another example of a multivariate rule set is the set ofmaintenance rules1700 and asset usage rules1702. One skilled in the art will readily conclude, based on the content of the present disclosure, that the current invention includes the use of multivariate rule sets including automating many aspects of a business, such as employee management, inventory accounting, asset location management, and cost accounting. Turning briefly toFIG. 2, known asset information includes the entire content ofmaster database202. If the data reported violates the rule, then a maintenance alert is created. For example, a rule could dictate that engine oil pressure on 2000-2005 Ford F-150 trucks should be within a specified range, measured in psi. If the received data, which is compared to the limits of a range, is not within the specified range, a maintenance alert is created. An alternative method of processing telematic data compares actual values to establish a “known good” baseline. Baseline readings are obtained at a time when the asset is known to be operating properly. Data subsequently received is then compared against the baseline for substantial fluctuation (measured as a percentage deviation from the baseline or, alternatively, a percentile deviation from the baseline when a large sample of historical values is available), which will cause a maintenance alert to be created. Both such a baseline embodiment and a rules embodiment can be integrated into a single process, as is illustrated by the process depicted inFIG. 28, which is, in one embodiment, performed bymaintenance analysis engine1706.

After starting, the process proceeds to step2802, which depicts receiving new telemetry. The process then moves to step2804, which illustrates retrieving telemetry rules. The process then proceeds to step2806, which depicts determining whether telemetry rules were found for the telemetry received instep2802. If it is determined that telemetry rules were not found for the telemetry received instep2802, the process next moves to step2812, which is described below. If, however, it is determined that telemetry rules were found for the telemetry received instep2802, the process proceeds to step2808.Step2808 illustrates processing rules against the telemetry received instep2802. The process next moves to step2810, which depicts determining whether any of the telemetry rules against which the telemetry received instep2802 was processed instep2808 are violated. If it is determined that telemetry rules against which the telemetry received instep2802 was processed instep2808 are violated, the process proceeds to step2824, which is described below. If, however, it is determined that telemetry rules against which the telemetry received instep2802 was processed instep2808 are not violated, the process next moves to step2812.

Step

2812 illustrates retrieving a telemetry baseline. In one embodiment, a telemetry baseline is an expected numerical value or set of values stored inmaster database202 that is used for a rule-based comparison to telemetry data received instep2802. The process then proceeds to step2814, which depicts determining whether a telemetry baseline was found instep2812. If it is determined atstep2814 that no telemetry baseline was found instep2812, then the process ends. If, however, a telemetry baseline was found instep2812, then the process next moves to step2816, which depicts retrieving baseline rules. Baseline rules are rules for comparing the values received instep2812 to the value received instep2802 and acting on the results of the comparison. The process then proceeds to step2818, which depicts determining whether telemetry rules were found for the baseline retrieved instep2812. If it is determined that telemetry rules were not found for the baseline retrieved instep2812, then the process ends. If, however, it is determined that telemetry rules were found for the baseline retrieved instep2812, the process proceeds to step2820.Step2820 illustrates processing rules against the telemetry received instep2802 and the baseline retrieved instep2812.

The process next moves to step2822, which depicts determining whether any of the telemetry rules against which the telemetry received instep2802 was processed instep2820 are violated. If it is determined that the telemetry data received instep2802 does not violate the telemetry rules, the process ends. If, however, it is determined that the telemetry data received instep2802 does violate the telemetry rules, the process next moves to step2824.Step2824 depicts creation of a maintenance alert. The process next moves to step2826, which represents processing of notification rules. An example of an embodiment of a process for processing notification rules is discussed below with respect toFIG. 29. The process then ends.

Referring now toFIG. 29, a flowchart of maintenance alert notification processing for monitoring and management of a mobile equipment fleet, in accordance with one embodiment of the present invention, is illustrated.FIG. 29 depicts a process, which can be performed ondata conversion server130 for sending notifications in response to creation of a maintenance alert. Examples of methods for sending a notification include email, short message service (SMS), interactive voice response (IVR) phone call, message displayed on a website, or any other applicable method of communication. Two methods of defining rules are shown (per asset and per task) but many more options are available in a variety of implementations. Similarly, some embodiments of the present invention include analysis of the history of telemetry data received to find readings that are statistically abnormal and create maintenance alerts base on those abnormal readings.

After starting, the process proceeds to step2902, which depicts creation of a new maintenance alert. An example of a process for creation of a new maintenance is portrayed inFIG. 26, which is described above. The process next moves to step2904.Step2904 illustrates retrieval of notification rules for an asset. The process then proceeds to step2906, which depicts determining whether asset-based notification rules have been found for the maintenance alert created atstep2902. An asset-based notification rule defines conditions for sending alerts to a particular recipient by a particular mode and is referenced all alerts that occur for a particular asset. For example, an asset-based notification rule could require notifying a department supervisor about alerts on vehicles assigned to employees reporting to the supervisor. If it is determined that no asset-based notification rules have not been found for the maintenance alert created atstep2902, then the process proceeds to step2910, which is described below. If, however, it is determined that asset-based notification rules have been found for the maintenance alert created atstep2902, then the process next moves to step2908.Step2908 depicts sending asset-based notifications.

The process then proceeds to step2910, which depicts retrieval of notification rules for a task. The process then proceeds to step2912, which depicts determining whether task-based notification rules have been found for the maintenance alert created atstep2902. A task-based notification rule defines conditions for sending an alert to a particular recipient by a particular mode. For example, an asset-based notification rule could require notifying a hydraulic specialist about DTCs raised for hydraulic systems. If it is determined that task-based notification rules have not been found for the maintenance alert created atstep2902, then the process ends. If, however, it is determined that task-based notification rules have been found for the maintenance alert created atstep2902, then the process next moves to step2914.Step2914 depicts sending task-based notifications. The process then ends.

Turning now toFIG. 30, physical components of a system for acquisition of data to be used in conjunction with monitoring and management of a mobile equipment fleet, in accordance with one embodiment of the present invention, are depicted. In one embodiment of the present invention, the physical components displayed inFIG. 30 perform components ofdata acquisition process2302 ofFIG. 23. Direct user input can be supplied through auser terminal3000 to aweb application server3002 and transmitted to a system providing telematic data processing, such asmaster database server3004. Examples of telematic data processing performed bymaster database server3004 include, for example, step410 ofFIG. 4, step812 ofFIG. 8, or step1008 ofFIG. 10.Master database server3004 normalizes the raw telematic data2304 received form a variety of sources from its first (native) format to a second (standardized) format to create standardizedtelematic data2308.

Atelematic device3006, such asremote unit100nofFIG. 1, can send data in a customized manner. Examples of customization include the use of a proprietary communication protocol. Customization can also be provided for by allowing for configurably variable conditions motivating when data is transmitted and what data is transmitted. In one embodiment,remote unit100ncan communicate to aproprietary device server3008 using a proprietary protocol, referred to as a Device Direct Proprietary Protocol. In such an embodiment,telematic device3006 sends data to aproprietary device server3008 for communication to a proprietarydevice database server3010 and eventual delivery tomaster database3004.

Some embodiments of the present invention allow for interoperability with a broad range ofexternal data systems3052 including processes, applications and devices communicating over standardized interfaces and protocols. For example,direct user input3012, such as input into a business application or a web reporting service can be communicated to a queryable interfacecompliant application3016, such as a web service. Similarly,automated input3014, such as pump data received from a gasoline or water pump at a service station, can be communicated to a queryable interfacecompliant application3016. Queryable interfacecompliant application3016 can then provide data through aqueryable integration interface3018 to adata pulling server3022 for presentation to anintegration database server3044. Data acquisition using aggregator pull solutions includes business applications that store asset-related data such as fuel usage, mileage, or maintenance costs. Similarly, queryable interfacecompliant application3016 can deliver data to aweb services server3042 using adata pushing agent3020. Examples of aggregator push systems include vehicle location service providers.

In one embodiment of an aggregator push solution in accordance with the present invention, atelematic device3036 can communicate with a push-compliant third-party application3038, such as a navigation and dispatching support system, which interacts directly with adata pushing agent3040 to deliver data toweb service server3042 for presentation to anintegration database3044 and communication tomaster database server3004.

Further, atelematic device3026 may communicate directly with a queryable interfacecompliant application3028, which provides data to a proprietarydevice database server3034 through adata pulling server3032 that interrogates a queryable integration interface, thereby allowingdevice database3034 to receive data from a telematic device for which it has no direct protocol access.

A telematic device3046, such asremote unit100nofFIG. 1, can send data in a highly standardized manner to astandard device server3048, which then delivers the data to a standarddevice database server3050 for presentation tomaster database server3004, by providing standardized interfaces allowing any device or system implementing the interfaces to send data intomaster database server3004 using a Device Direct Standard Protocol (DDSP).

Referring now toFIG. 31A-C, an entity relationship diagram for an alerts and notifications portion of a database in accordance with one embodiment of the present invention is illustrated. In one embodiment of the present invention database entities andfunctions3100 exist withinmaster database202 and support implementation of the functions described above.

Turning now toFIG. 32A-D, an entity relationship diagram for maintenance portion of a database in accordance with one embodiment of the present invention is depicted. In one embodiment of the present invention database entities andfunctions3200 exist withinmaster database202 and support implementation of the functions described above.

Referring now toFIG. 33A-B, an entity relationship diagram for the device management and interaction portion of a database in accordance with one embodiment of the present invention is illustrated. In one embodiment of the present invention database entities andfunctions3300 exist within device-specific database200aand support implementation of the functions described above.

Turning now toFIG. 34A-C, an entity relationship diagram for an assets portion of a database in accordance with one embodiment of the present invention is depicted. In one embodiment of the present invention database entities andfunctions3400 exist withinmaster database202 and support implementation of the functions described above.

Referring now toFIG. 35, an entity relationship diagram for a communications portion of a database in accordance with one embodiment of the present invention is illustrated. In one embodiment of the present invention database entities andfunctions3500 exist withinmaster database202 and support implementation of the functions described above.

Turning now toFIG. 36A-C, an entity relationship diagram for the device management and interaction portion of a database in accordance with one embodiment of the present invention is depicted. In one embodiment of the present invention database entities andfunctions3600 exist within device-specific database200band support implementation of the functions described above. With respect to each ofFIG. 31A-36C, although depicted separately, the entities shown are, in one embodiment, part of an interrelated database system, Additionally, while one embodiment of the present invention is displayed with respect to each ofFIG. 31A-36C, one skilled in the art will quickly realize that substantially different database relationship implementations can embody the present invention without departing from the scope of the present invention.

Although the present invention has been described in connection with several embodiments, the invention is not intended to be limited to the specific forms set forth herein. On the contrary, it is intended to cover such alternatives, modifications, and equivalents as can be reasonably included within the scope of the invention as defined by the appended claims.