Systems and methods for accident reconstruction

According to various embodiments, systems and methods are provided for capturing vehicle activity data and filtering such data to reconstruct accident conditions according to a predetermined level of accuracy.

FIELD OF THE INVENTION

The present invention relates to systems and methods for evaluating driver safety and accident conditions by recording, filtering, and/or processing data relating to vehicle operations and driver behaviors.

BACKGROUND OF THE INVENTION

Delivery services and other transportation-related businesses utilize large numbers of drivers and must therefore implement certain measures to minimize the risk of accidents. Not only are accidents costly in terms of damage to company property, damage to other property, and injuries to the involved parties, but for businesses where transportation is an integral component, such as delivery services, an accident disrupts delivery schedules and, therefore, the entire flow of the business's operations.

Since drivers with unsafe habits increase the risks and liabilities of the business, delivery businesses, or other businesses with a component involving vehicular operations, generally have a significant incentive to promote driver safety. Driver safety can be assessed by monitoring day-to-day operational behaviors and also by evaluating accidents when they occur. If a business is able to determine that a driver's unsafe behavior is the cause of an accident, this information is valuable in managing future risks and liabilities. For instance, the driver could then be reprimanded or closely monitored, in order reduce the likelihood of a future occurrence.

On the other hand, if other factors caused the accident, the business may be able to relieve itself of liability upon a showing of evidence that the driver was not at fault. Therefore, there is a need for systems and methods for collecting accident data for use in assessing potential causes of the accident.

BRIEF SUMMARY OF THE INVENTION

Various embodiments of the present invention provide systems and methods for evaluating driver safety and accident conditions by recording, filtering, and/or processing data relating to vehicle operations and driver behaviors. For instance, in one aspect of the invention, a method for evaluating data relating to a vehicular accident is provided. The method includes the steps of: capturing a first set of data according to a first recording criteria wherein the first data set comprises operational data for a vehicle including telematics data indicative of vehicle dynamics and contextual data indicative of location and time data; storing said first set of data in a telematics device; transmitting said first set of data to a central server; capturing a second set of data according to a second recording criteria, wherein the second set of data comprises operational data for the vehicle including telematics data indicative of vehicle dynamics and contextual data indicative of location and time data, wherein the second set of data is captured at a higher frequency than the first set of data; storing said second set of data in the telematics device, wherein the stored set of data is periodically overwritten; selectively retrieving the second set of data using an accident key in the event of an accident and transferring to the central server; determining a time of the accident by the central server based at least in part on the second set of data; and combining at least portions of the first set of data and the second set of data to evaluate conditions relating to the vehicular accident.

In another aspect of the invention, a system for retrieving and storing data relating to a vehicle accident is provided. This system includes: a plurality of sensors configured to collect operational data including telematics data indicative of vehicle dynamics and contextual data indicative of location and time; a telematics device having a first memory and a second memory wherein the first memory is configured to store a first set of data collected from the plurality of sensors according to a first criteria and the second memory is configured store to a second set of data collected from the plurality of sensors according to a second criteria, wherein further, the telematics device is configured to transfer the first set of data to a central server; an accident key configured to communicate with the telematics device and extract the second set of data following a vehicle accident and further configured to communicate the second set of data to a central server; and the central server. The central server is configured to: determine a time of the accident based at least in part on the second set of data; and combine at least portions of the first set of data and the second set of data to evaluate conditions relating to the vehicle accident.

In a further aspect of the invention, a method for evaluating a vehicle accident is provided. The method includes the steps of: receiving data relating to the operation of a vehicle involved in an accident from a telematics device including location data, operational data, and associated time data for a predetermined time period; determining an accuracy of the received data and filtering data not satisfying an accuracy threshold; and determining the time of the accident based at least in part on the received data.

DETAILED DESCRIPTION OF THE INVENTION

Overview

According to various embodiments of the present invention, systems and methods are provided for capturing vehicle activity data, and in some embodiments filtering such data, to reconstruct accident conditions according to a predetermined level of accuracy.

FIG. 1illustrates the system architecture of an accident evaluation system1according to various embodiments. As shown, the accident evaluation system1includes one or more data sources2and a central server3. The data sources2may be, for example, devices configured for capturing and communicating operational data indicative of one or more operational characteristics (e.g., a telematics device capturing telematics data from a vehicle, a portable memory capturing a subset of telematics data from the telematics device, a computer tracking the activity of one or more users). The data sources2are configured to communicate with the central server3by sending and receiving operational data over a network4(e.g., the Internet, an Intranet, or other suitable networks). The central server3is configured to process and evaluate operational data received from the data sources2in accordance with user input received via a user interface (e.g., a graphical user interface provided on a local or remote computer). For example, the central server3may be configured for generating a graphical presentation of vehicular movement for a certain time period beginning before the time of an accident, or certain distance immediately preceding the location of an accident, in the context of other safety-indicative data.

As discussed in U.S. patent application Ser. No. 12/556,140, filed Sep. 9, 2009, which is incorporated herein by reference in its entirety, certain entities operate fleets of vehicles and may have data sources comprised of telematics devices positioned on various vehicles in the fleet. For example, a shipping entity may operate and manage a fleet of delivery vehicles, each being associated with a telematics device. The central server may be configured for processing telematics data received from any of the telematics devices in order to assess driver behaviors and also to evaluate the accuracy of such data.

In various embodiments, the accident evaluation system is also configured for evaluating operational behaviors of drivers based at least in part on data indicative of driver location and operational activity in relation to time. In such embodiments, the data sources may comprise telematics devices (i.e., GPS or RFID-based location-indicating devices embedded in the driver's vehicle) and driver input devices. The central server may be configured for evaluating data received from the location-indicating devices in order to determine whether a driver is operating a driver input device while the vehicle is in motion by associating device operation times with times reflecting change vehicle location. For example, if at a given time, the driver input device displays activity and the vehicle changes location, the central server could highlight this as an occurrence of “recording in transit”, which could constitute unsafe driving behavior.

The following description provides a detailed explanation of certain embodiments of the accident evaluation system in the context of a package delivery enterprise. As will be appreciated from the detailed description herein, the various components and features of these systems may be modified and adapted to reconstruct conditions surrounding accidents and to assess driver safety-related behaviors in a variety of operational contexts.

Accident Evaluation System

According to various embodiments, accident evaluation systems are provided for capturing operational data for a fleet of vehicles, storing accident-related operational data, and evaluating the accuracy of the stored operational data. In various other embodiments, an accident evaluation system is provided for capturing operational data for a fleet of vehicles, evaluating the accuracy of the captured operational data, and storing the operational data falling within a given quality range. The accident evaluation system may further be configured to provide a graphical representation of certain operational data for a certain vehicle in relation to an accident in a way that allows system users to understand the context in which the accident occurred. As described in greater detail below, by identifying relevant, high-quality data, the system permits the long-term storage of useful data for large fleets of vehicles without overloading system storage.

System Architecture

A data retrieval system5according to various embodiments is shown inFIG. 2. In the illustrated embodiment, the data retrieval system5comprises a vehicle telematics device102positioned on a delivery vehicle100, a portable data acquisition device110, an accident key115, and a central server120. The telematics device102, portable data acquisition device110, and central server120are configured to communicate with each other via a communications network130(e.g., the Internet, an Intranet, a cellular network, or other suitable network). The accident key115is configured for retrieving and storing data from the telematics device102. In addition, the telematics device102, portable data acquisition device110, accident key115, and central server120are configured for storing data to an accessible central server database (not shown) located on, or remotely from, the central server120.

According to various embodiments, the data retrieval system5may be implemented to retrieve and store select accident-related data from a large fleet of delivery vehicles. While the detailed description of the fleet management system's components is provided below with reference to individual components or devices, it will be understood from the description herein that various embodiments of the data retrieval system5may include a plurality of the components each configured as described below. For example, large-scale embodiments of the data retrieval system may include thousands of telematics devices102and portable data acquisition devices110, each capturing data from a unique delivery vehicle100or driver and transmitting the captured data to multiple servers120.

In the illustrated embodiment ofFIG. 2, the delivery vehicle100includes a plurality of vehicle sensors configured for generating telematics data indicative of various vehicle dynamics, such as engine ignition, engine speed, vehicle speed, steering angle, use of turn signals, and the status of various vehicle components, such as the brakes and lights. The vehicle sensors are controlled by the telematics device102, which may be positioned on or within the vehicle100. In various embodiments, the telematics device102is able to able to capture and store telematics data from the various vehicle sensors according to a programmed logic and associate the captured telematics data with contextual data (e.g., date, time, location). The captured telematics data and contextual data may then be transmitted by the telematics device102directly to the central server120via the network130, or to the portable data acquisition device110(which may later transmit the data to the central server120).

The portable data acquisition device110may be a handheld electronic device—such as a pocket PC, delivery information acquisition device (“DIAD”), laptop, or smartphone—that may be operated by a driver of the delivery vehicle100. The portable data acquisition device110is generally configured for receiving and displaying service data such as delivery information received from the central server120(e.g., delivery instructions pertaining to the delivery of freight or packages), as well as for receiving and storing telematics data received from the telematics device102. In addition, the portable data acquisition device110is configured for receiving and storing delivery data generated by user input (e.g., delivery data input by a driver via a user interface indicating the status of a particular delivery or driver activity, time and date of data entry, etc.). Furthermore, the portable data acquisition device110is configured for transmitting received data to the central server120and/or telematics device102over the network130.

The accident key115is a portable storage device—such as a USB flash drive—that may be operated by the driver of the delivery vehicle100or by another party. The accident key115is generally configured for extracting and storing accident-related data received from the telematics device102via a USB connection. The accident key115is further configured for transmitting the stored accident-related data to the central server120via, for example, a USB connection with a computer on the network130.

According to various embodiments, the central server120is generally configured for receiving and storing data from the telematics device102, the portable data acquisition device110, and the accident key115. As shown inFIG. 2, the central server120is particularly configured for receiving and storing accident-related data from the accident key115. Based on such accident-related data from the accident key115, the central server is then able to amass operational data to reconstruct the accident.

In addition, the central server120is further configured for receiving and storing telematics data from the telematics device102and delivery data from the portable data acquisition device110over the network130. By collecting such operational data over a period of time from various telematics devices102and portable data acquisition devices110—which may be associated with a fleet of vehicles100and their respective drivers—the central server120is able to amass operational data reflecting the overall operations of the fleet. As will be described in greater detail below, the central server120is configured for evaluating telematics data and delivery data together, presenting the data to a user in the context of one another, and evaluating the data in a variety of ways in order to assess safety-related driver behaviors. Various components of the accident evaluation system1are now described in detail below according to various embodiments.

Network

According to various embodiments of the present invention, the communications network130may be capable of supporting communication in accordance with any one or more of a number of second-generation (2G), 2.5G and/or third-generation (3G) mobile communication protocols or the like. More particularly, the network130may be capable of supporting communication in accordance with 2G wireless communication protocols IS-136 (TDMA), GSM, and IS-95 (CDMA). Also, for example, the network130may be capable of supporting communication in accordance with 2.5G wireless communication protocols GPRS, Enhanced Data GSM Environment (EDGE), or the like. In addition, for example, the network130can be capable of supporting communication in accordance with 3G wireless communication protocols such as Universal Mobile Telephone System (UMTS) network employing Wideband Code Division Multiple Access (WCDMA) radio access technology. Some narrow-band AMPS (NAMPS), as well as TACS, network(s) may also benefit from embodiments of the present invention, as should dual or higher mode mobile stations (e.g., digital/analog or TDMA/CDMA/analog phones). As yet another example, the network130may support communication between the accident evaluation system1components (e.g., the telematics device102, portable data acquisition device110, and accident key115) in accordance with techniques such as, for example, radio frequency (RF), Bluetooth™, infrared (IrDA), or any of a number of different wireless networking techniques, including Wireless LAN (WLAN) techniques.

Although the telematics device102, portable data acquisition device110, and central server120are illustrated inFIG. 2as communicating with one another over the same network130, these devices may likewise communicate over separate networks. For example, while the telematics device102may communicate with the portable data acquisition device110over a wireless personal area network (WPAN) (e.g., using Bluetooth™ techniques), the telematics device102and/or portable data acquisition device110may communicate with the central server120over a wireless wide area network (WWAN) (e.g., in accordance with EDGE, or some other 2.5G, 3G, or 4G wireless communication protocol).

Vehicle Sensors

As noted above, in various embodiments the delivery vehicle100is equipped with a variety of vehicle sensors capable of generating vehicle telematics data. For example, in one embodiment, the vehicle100includes sensors configured to make measurements and capture data pertaining to the following vehicle dynamics: engine ignition (e.g., on or off), engine speed (e.g., RPM and idle time events), vehicle speed (e.g., miles per hour), seat belt status (e.g., engaged or disengaged), vehicle heading (e.g., degrees from center), vehicle backing (e.g., moving in reverse or not moving in reverse), vehicle door status (e.g., open or closed), vehicle handle status (e.g., grasped or not grasped by a driver), vehicle location (e.g., latitude and longitude), distance traveled (e.g., miles between two points), throttle position, brake pedal position, parking break position, distance or time since last maintenance, and various engine measurements (e.g., engine oil pressure, engine temperature, and engine faults). In various other embodiments, the delivery vehicle100may include any combination of the above-referenced sensors (and additional sensors known in the art) depending on the operational data desired by a fleet management system5user.

According to various embodiments, the vehicles sensors disposed within the delivery vehicle100comprise on/off sensors, which register a voltage amount that corresponds with an on/off condition. For example, in one embodiment, a seat belt sensor may register 0V when the seat belt is disengaged and 12V when the seat belt is engaged. Such on/off sensors are sufficient for measuring vehicle dynamics in which operational data is needed to indicate two conditions, such as a seat belt, which is either engaged or disengaged at all times. As another example, one or more door position sensors may be connected, for example, to the driver side, passenger side, and bulkhead doors, and may register 0V when the door with which the sensor is associated is in an open position, and 12V when the door is closed. As another example, an ignition sensor may register 0V when the vehicle100is turned off and 12V when the vehicle100is turned on. As yet another example, a backing light sensor may register 0V when the vehicles' backing lights are off and 12V when the vehicle's backing lights are on. As yet another example, the engine idle sensor may be configured to generate 0V when the engine speed is above idle and 12V when the engine is idling.

In addition, according to various embodiments, the vehicle sensors disposed within the delivery vehicles100also comprise variable voltage sensors, which may be used to register variations in voltage reflecting a certain vehicle dynamic. For example, the engine speed sensor may detect the speed of the engine in revolutions per minute (RPM) by registering a particular voltage that corresponds to a particular RPM reading. The voltage of the sensor may increase or decrease proportionately with increases or decreases in the engine RPM. As another example, oil pressure sensors may detect the vehicle's oil pressure by registering a particular voltage that corresponds to a particular oil pressure. Other examples of variable voltage sensors may include temperature sensors, vehicle speed sensors, vehicle heading sensors, and vehicle location sensors.

The exemplary vehicle sensors described above may be configured, for example, to operate in any fashion suitable to generate computer-readable data that may be captured, stored, and transmitted by the telematics device102. In addition, while certain sensors are preferably disposed at particular locations on or within the vehicles100(e.g., handle sensors at the vehicle handles), other sensors may be disposed anywhere within the vehicle, such as within the telematics device102itself (e.g., a location sensor).

Telematics Device

As noted above, according to various embodiments, the telematics device102is configured to control various vehicle sensors positioned on an associated delivery vehicle100, capture vehicle telematics data generated by those sensors, and/or transmit the captured telematics data to the portable data acquisition device110and/or central server120via one of several communication methods. According to various embodiments, the various functions of the telematics device102described herein may be generally understood as being performed by one or more of the telematics device102components described below.

FIG. 3illustrates a detailed schematic block diagram of an exemplary telematics device102according to one embodiment. In the illustrated embodiment, the telematics device102includes the following components: a processor201, a location-determining device or sensor202(e.g., GPS sensor), a real-time clock203, J-Bus protocol architecture204, an electronic control module (ECM)205, a port206for receiving data from vehicle sensors410located in one of the delivery vehicles100(shown inFIG. 2), a communication port207for receiving instruction data, a radio frequency identification (RFID) tag212, a power source208, a data radio209for communication with a general memory module210, and a short-term memory module211. In an alternative embodiment, the RFID tag212and the location sensor202, may be located in the delivery vehicle100, external from the telematics device102. In other embodiments, the processes described herein as being carried out by a single processor201may be accomplished by multiple processors. In various embodiments, the telematics device102may not include certain of the components described above, and may include any other suitable components in addition to, or in place of, those described above. For example, the telematics device102may include various types of communications components other than those described above (e.g., to support new or improved communications techniques).

In one embodiment, the location sensor202may be one of several components available in the telematics device102. The location sensor202may be, for example, a GPS-based sensor compatible with a low Earth orbit (LEO) satellite system, medium Earth orbit satellite system, or a Department of Defense (DOD) satellite system. Alternatively, triangulation may be used in connection with various cellular towers positioned at various locations throughout a geographic area in order to determine the location of the delivery vehicle100and/or its driver. The location sensor202may be used to receive position, time, and speed data. In addition, the location sensor202may be configured to detect when its delivery vehicle100has entered or exited a GPS-defined geographic area (e.g., a geo-fenced area). As will be appreciated from the description herein, more than one location sensor202may be utilized, and other similar techniques may likewise be used to collect geo-location information associated with the delivery vehicle100and/or its driver.

In one embodiment, the ECM205with J-Bus protocol204may be one of several components available in the telematics device102. The ECM205, which may be a scalable and subservient device to the telematics device102, may have data processor capability to decode and store analog and digital inputs and ECM data streams from vehicle systems and sensors410,420. The ECM205may further have data processing capability to collect and present vehicle data to the J-Bus204(which may allow transmittal to the telematics device102), and output standard vehicle diagnostic codes when received from a vehicle's J-Bus-compatible on-board controllers420or vehicle sensors410.

In one embodiment, the instruction data receiving port207may be one of several components available in the telematics device102. Embodiments of the instruction data receiving port207may include an Infrared Data Association (IrDA) communication port, a data radio, and/or a serial port. The instruction receiving data port207may receive instructions for the telematics device102. These instructions may be specific to the vehicle100in which the telematics device102is installed, specific to the geographical area in which the vehicle100will be traveling, or specific to the function the vehicle100serves within the fleet.

In one embodiment, a radio frequency identification (RFID) tag212may be one of several components available for use with the telematics device102. One embodiment of the RFID tag212may include an active RFID tag, which comprises at least one of the following: (1) an internal clock; (2) a memory; (3) a microprocessor; and (4) at least one input interface for connecting with sensors located in the vehicle100or the telematics device102. Another embodiment of the RFID tag212may be a passive RFID tag. One or more RFID tags212may be internal to the telematics device102, wired to the telematics device102, and/or proximate to the telematics device102. Each RFID tag212may communicate wirelessly with RFID interrogators within a certain geographical range of each other. RFID interrogators may be located external to the vehicle100and/or within the portable data acquisition device110that can be carried in and out of the vehicle100by the vehicle operator.

In one embodiment, the data radio209may be one of several components available in the telematics device102. The data radio209may be configured to communicate with a WWAN, WLAN, or WPAN, or any combination thereof. In one embodiment, a WPAN data radio provides connectivity between the telematics device102and peripheral devices used in close proximity to the vehicle100, such as the portable data acquisition device110, a local computer, and/or a cellular telephone. As mentioned above, in one embodiment of the invention, a WPAN, such as, for example, a Bluetooth™ network (IEEE 802.15.1 standard compatible) may be used to transfer information between the telematics device102and the portable data acquisition device110. In other embodiments, WPANs compatible with the IEEE 802 family of standards may be used. In one embodiment, the data radio209may be a Bluetooth™ serial port adapter that communicates wirelessly via WPAN to a Bluetooth™ chipset located in the portable data acquisition device110, or other peripheral device. In addition, a Media Access Control (MAC) address, which is a code unique to each Bluetooth™-enabled device that identifies the device, similar to an Internet protocol address identifying a computer in communication with the Internet, can be communicated to other devices in communication with the WPAN, which may assist in identifying and allowing communication among vehicles, cargo, and portable data acquisition devices equipped with Bluetooth™ devices. As discussed above with regard toFIG. 2, and as one of ordinary skill in the art will readily recognize, other wireless protocols exist (e.g., cellular technology) and can likewise be used in association with embodiments of the present invention.

As described in greater detail below, in various embodiments, the telematics device102is configured to capture and store telematics data from the vehicle sensors410at predefined time intervals and in response to detecting the occurrence of one or more of a plurality of predefined vehicle events. Generally, a vehicle event may be defined as a condition relating to any parameter or combination of parameters measurable by the one or more vehicle sensors410(e.g., the engine idling, vehicle speed exceeding a certain threshold, etc.). As such, the telematics device102is configured to continuously monitor the various vehicle sensors410and detect when the data being generated by one or more the vehicle sensors410indicates one or more of the plurality of predefined vehicle events. In response to detecting a vehicle event, the telematics device102captures data from all of the vehicle sensors410or a particular subset of the vehicle sensors410associated with the detected vehicle event.

As an example, the telematics device102may be configured to recognize the occurrence of a first vehicle event (e.g., the vehicle's100engine being turned on or off), a second vehicle event (e.g., the vehicle's100speed exceeding a certain threshold), and a third vehicle event (e.g., a seat belt in the vehicle100being engaged or disengaged). In one embodiment, the telematics device102is configured to capture and store telematics data from all of the vehicle sensors410in response to detecting any of the first vehicle event, the second vehicle event, and the third vehicle event. In another embodiment, the telematics device102is further configured such that the first vehicle event is associated with a first subset of vehicle sensors (e.g., the seat belt sensor and location sensor), the second vehicle event is associated with a second subset of vehicle sensors (e.g., a vehicle speed sensor and location sensor), and the third vehicle event is associated with a third subset of vehicle sensors (e.g., a seat belt sensor, engine speed sensor, and vehicle speed sensor). Accordingly, in this embodiment, the telematics device102will capture and store telematics data from the first set of vehicle sensors upon detecting the first vehicle event, the second set of vehicle sensors upon detecting the second vehicle event, and the third set of vehicle sensors upon detecting the third vehicle event.

The vehicle events programmed for recognition by the telematics device102can be defined in a variety of ways. As will be appreciated from the description herein, the telematics device102may be configured to capture telematics data in response to vehicle events defined by any combination of conditions sensed by the vehicle sensors410. These predefined vehicle events may be stored, for example, on the telematics device's general memory module210, or on another data storage medium accessible by the telematics device's processor201.

For example, in various embodiments, the telematics device102is configured to recognize vehicle events characterized by data generated by on/off vehicle sensors. These vehicle events include: (a) a vehicle's engine being turned on, (b) a vehicle's engine being turned off, (b) a vehicle door opening, (c) a vehicle door closing, (d) a vehicle door being locked, (e) a vehicle door being unlocked, (f) a vehicle's reverse gear being selected, (g) a vehicle's one or more forward drive gears being selected, (h) a vehicle's neutral or park gear being selected, (i) a vehicle's parking break being engaged, (j) a vehicle's seat belt being engaged, (k) a vehicle's seat belt being disengaged, and any other event definable by a parameter measured by an on/off sensor.

In addition, various embodiments of the telematics device102are also configured to recognize vehicle events characterized by data generated by variable voltage vehicles sensors or other types of dynamic vehicle sensors. These vehicle events include (a) a vehicle's speed increasing from standstill to a non-zero value, (b) a vehicle's speed decreasing from a non-zero value to standstill, (c) a vehicle's engine speed exceeding a certain threshold, (d) a vehicle's engine speed dropping below a certain threshold, (e) a vehicle beginning to move in a reverse direction, (f) a vehicle ceasing to move in a reverse direction, (g) a vehicle's heading reaching a threshold away from center, (h) a vehicle's engine temperature exceeding a certain threshold, (i) a vehicle's gas level falling below a certain level, (j) a vehicle's speed exceeding a certain threshold, and any other event definable by a parameter measured by a variable voltage or other dynamic sensor.

According to various embodiments, the telematics device102may be also configured to recognize multiple unique vehicle events based on a single varying parameter measured by one of the vehicle sensors410. As one example, the telematics device102may be configured such that a first vehicle event is detected anytime the vehicle's speed begins to exceed 50 miles-per-hour, while a second vehicle event is detected anytime the vehicle's speed begins to exceed 70 miles-per-hour. As such, the telematics device102may capture telematics data from vehicle sensors410in response to the vehicle100accelerating past 50 miles-per-hour, and again as the vehicle100accelerates past 70 miles-per-hour. In addition, as noted earlier, the telematics device102may capture telematics data from unique subsets of vehicle sensors based on the varying measurements of vehicle speed (e.g., a first subset of vehicles sensors associated with the 50-mph vehicle event and a second subset of vehicle sensors associated with the 70-mph vehicle event). This concept may also be applied to other variable parameters sensed by vehicle sensors, such as vehicle heading (e.g., various threshold degrees from center), engine speed (e.g., various threshold RPM measurements), and vehicle distance from a predefined path (e.g., threshold value for feet from a known road, vehicle route, or other GPS-based geographic location).

In addition, vehicle events may be defined by a combination of conditions indicated by various vehicle sensors410. For example, in certain embodiments, the telematics device102is configured to detect (a) where a vehicle seat belt is engaged or disengaged while the vehicle is idling, (b) where a vehicle exceeds a certain speed while located within a certain geographic area associated with the certain speed, and (c) a vehicle door opening or closing while the engine is on.

In addition to capturing telematics data in response to detected vehicle events, the telematics device102may be further configured to automatically capture telematics data from the vehicle sensors410at predefined time intervals. For example, in one embodiment, the telematics device102is programmed with a maximum data capture time (e.g., 10 seconds, one minute) and is configured to automatically capture telematics data from the vehicle sensors410where no vehicle events are detected for a period exceeding the defined time. This configuration ensures that the maximum data capture time is the longest possible duration between telematics data being collected and ensures that the vehicle100is continuously monitored even through periods where none of the predefined vehicle events are detected. As will be appreciated from the description herein, the maximum data capture time may be defined as any period of time according to the preference of a fleet management system5user.

As noted above, in response to a triggering event—such as defined vehicle event or elapsed maximum data capture time—the telematics device102captures telematics data from the vehicle sensors410. In one embodiment, the telematics device102is configured to store the captured telematics data in fields of one or more data records, each field representing a unique measurement or other data from a unique vehicle sensor. As the telematics device102continues to capture telematics data in response to triggering events, multiple records of data comprising multiples sets of concurrently captured telematics data are amassed.

The telematics data captured according to combinations of the parameters described above (i.e., in response to certain of the stated vehicle events and also according to the maximum data capture time) is stored collectively in the telematics device's general memory module210. In various other embodiments, this collective data can be stored on another data storage medium accessible by the telematics device's processor201.FIG. 4depicts a sample set of the telematics data45stored in the telematics device's general memory module210.

Furthermore, the telematics device102also maintains a continuously overwritten set of high-resolution telematics data55that can be downloaded via the accident key115in the event of an accident. This high-resolution telematics data55is stored in the telematics device's short-term memory module211, or another data storage medium accessible by the telematics device's processor201. The short-term memory module stores data only temporarily. For example, in various embodiments of the present invention, the short-term memory module211is configured to store an hour's worth of one-second interval recordings of data. After one hour's worth of one-second data is recorded, the next data record will overwrite the oldest data in the set, so that the record will always reflect the last hour of data.

In various embodiments, upon capturing data from any of the vehicle sensors410, the telematics device102is further configured to concurrently capture and store contextual data. The contextual data may include, for example, the date (e.g., 12/30/10) and time (e.g., 13:24) the data was captured, the vehicle from which the data was captured (e.g., a vehicle identification number such as 16234), the driver of the vehicle from which the data was captured at the time it was captured (e.g., John Q. Doe), a logged reason for the data capture (e.g., a code indicating a detected vehicle event or indicating that the predefined time interval had elapsed), and/or quality-related indicators. The contextual data may be captured, for example, from various telematics device components (e.g., an internal clock) and from data stored on the telematics device102(e.g., current driver name, current vehicle id, or various vehicle event codes). Further, the telematics device102is configured to associate the captured telematics data with the captured contextual data in order to ensure concurrently captured telematics data and contextual data are linked. For example, in one embodiment, the telematics device102stores concurrently captured telematics data and contextual data in the same data record or records.

As noted above, the telematics device102is also configured to transmit captured telematics data and contextual data to the portable data acquisition device110and/or the central server120.

Accident Key

As noted above, the accident key115may be a portable storage device—such as a USB flash drive—that may be operated by the driver of the delivery vehicle100or by another party. For example, a company responsible for a large fleet of vehicles may have supervisors or accident response members assigned to monitor each region or group of vehicles. The supervisor or accident response member assigned to a particular vehicle would then be called, following an accident, to retrieve the accident data from the vehicle following an accident.

In various embodiments, the accident key115is comprised of a connective portion (e.g., a USB connection) and a memory portion. The accident key115is programmed so that, upon insertion of the connective portion of the accident key115into a corresponding port in the delivery vehicle100or telematics device, the high-resolution vehicle data55is extracted from the telematics device's the short-term memory module211and downloaded to the memory portion of the accident key115. In various embodiments, the accident key115is programmed to associate this set of high-resolution data55with a marker that signifies it as accident-related data. The accident key115is further configured for transmitting the stored accident-related data to the central server120via, for example, a USB connection with a computer on the network130. In various embodiments, each data record in the set of high-resolution vehicle data55contains or is associated with a vehicle identifier and a date/time stamp. In this way, the high-resolution vehicle data55can later be integrated with other data specific to the vehicle.

Central Server

As noted above, various embodiments of the central server120are generally configured for receiving and evaluating telematics data received from the telematics device102, delivery data received from the portable data acquisition device110, and accident-related data received from the accident key115for a vehicle in order to reconstruct conditions of an accident and assess driver safety. According to various embodiments, the central server120includes various means for performing one or more functions in accordance with embodiments of the present invention, including those more particularly shown and described herein. As will be appreciated from the description herein, however, the central server120may include alternative devices for performing one or more like functions without departing from the spirit and scope of the present invention.

FIG. 6illustrates a schematic diagram of the central server120according to various embodiments. The central server120includes a processor60that communicates with other elements within the central server120via a system interface or bus61. In the illustrated embodiment, the central server120includes a display device/input device64for receiving and displaying data. This display device/input device64may be, for example, a keyboard or pointing device that is used in combination with a monitor. In certain embodiments, the central server120may not include a display device/input device and may be alternatively accessed by a separate computing device (e.g., a networked workstation) having a display device and input device. The central server120further includes memory66, which preferably includes both read only memory (ROM)65and random access memory (RAM)67. The server's ROM65is used to store a basic input/output system26(BIOS), containing the basic routines that help to transfer information between elements within the central server120.

In addition, the central server120includes at least one storage device63—such as a hard disk drive, a floppy disk drive, a CD Rom drive, or optical disk drive—for storing information on various computer-readable media, such as a hard disk, a removable magnetic disk, or a CD-ROM disk. As will be appreciated by one of ordinary skill in the art, each of these storage devices63is connected to the system bus61by an appropriate interface. The storage devices63and their associated computer-readable media provide nonvolatile storage for a personal computer. It is important to note that the computer-readable media described above could be replaced by any other type of computer-readable media known in the art. Such media include, for example, magnetic cassettes, flash memory cards, digital video disks, and Bernoulli cartridges.

A number of program modules may be stored by the various storage devices and within RAM65. Such program modules may include a data filtration module, an accident reconstruction module, and a driver safety module. According to various embodiments, the modules control certain aspects of the operation of the central server120with the assistance of the processor60and an operating system80. Embodiments of these modules are described in more detail below.

In a particular embodiment, these program modules are executed by the central server120and are configured to generate graphical user interfaces accessible to users of the system. In one embodiment, the user interfaces may be accessible via the Internet or other communications network. In other embodiments, one or more of the modules may be stored locally on one or more computers and executed by one or more processors of the computers.

According to various embodiments, the central server120is configured to send data to, receive data from, and utilize data contained in a central server database, which may be comprised of one or more separate, linked databases. For example, in executing the various modules, the central server120may retrieve data necessary for performing various analyses from the central server database, and may store data resulting from various analyses in the central server database. According to various embodiments, the central server database may be a component of the central server120, or a separate component located remotely from the central server120. In addition, the central server database may be configured for storing data in various data sets. In various embodiments, each data set may comprise a plurality of stored data records, each record (or set of associated records) comprising one or more data fields of unique data entries. For example, telematics data and contextual data concurrently captured by the telematics device102may be stored in a data record, where each data field in the data record represents a unique data entry (e.g., a measurement of vehicle speed, GPS coordinates, the time and date the data was captured, and an ID number of the vehicle from which the data was captured).

Also located within the central server120is a network interface74, for interfacing and communicating with other elements of a computer network. It will be appreciated by one of ordinary skill in the art that one or more of the central server120components may be located geographically remotely from other central server120components. Furthermore, one or more of the components may be combined, and additional components performing functions described herein may be included in the central server120.

While the foregoing describes a single processor60, as one of ordinary skill in the art will recognize, the central server120may comprise multiple processors operating in conjunction with one another to perform the functionality described herein. In addition to the memory66, the processor60can also be connected to at least one interface or other means for displaying, transmitting and/or receiving data, content or the like. In this regard, the interface(s) can include at least one communication interface or other means for transmitting and/or receiving data, content or the like, as well as at least one user interface that can include a display and/or a user input interface. The user input interface, in turn, can comprise any of a number of devices allowing the entity to receive data from a user, such as a keypad, a touch display, a joystick or other input device.

While reference is made to a central “server”120, as one of ordinary skill in the art will recognize, embodiments of the present invention are not limited to a client-server architecture. The system of embodiments of the present invention is further not limited to a single server, or similar network entity or mainframe computer system. Other similar architectures including one or more network entities operating in conjunction with one another to provide the functionality described herein may likewise be used without departing from the spirit and scope of embodiments of the present invention. For example, a mesh network of two or more personal computers (PCs), or similar electronic devices, collaborating with one another to provide the functionality described herein in association with the central server120may likewise be used without departing from the spirit and scope of embodiments of the present invention.

Central Server User Interface

As described above, the central server120is configured for evaluating operational data (e.g., telematics, portable device operation, and accident data) for a fleet of vehicles in order to assess driver behaviors in the context of operational safety. According to various embodiments, the central server's120evaluation of operational data is conducted in accordance with user instructions received via the central server's user interface. In various embodiments, the user interface is a graphical user interface accessible from a remote workstation (e.g., in communication with the central server120via the network130), or by using the central server's display device/input device64.

For example, in various embodiments, a user may log in to the accident evaluation system1from a remote workstation (e.g., by opening a log-in page and entering a user id and password using a workstation display and keyboard). The central server120is configured to recognize any such log-in request, verify that user has permission to access the system (e.g., by confirming the user id and password are valid), and present the user with a graphical user interface (e.g., displayed on the workstation's monitor). From the graphical user interface, the user can access and run any of the modules described below.

GPS Records

As noted above, the telematics data received from the telematics device102, the delivery data received from the portable data acquisition device110, and the accident-related data received from the accident key115may each include GPS records. Each GPS record contains a time component, a location component, and a set of data quality indicators. The data quality indicators in various embodiments of the present invention may include: signal-to-noise ratio (SNR), number of satellites, signal strength, horizontal dilution of precision (HDOP), and vertical dilution of precision (VDOP).FIG. 12demonstrates, based on a sample set of GPS records, that the number of satellites used to calculate a particular GPS reading is positively correlated with the associated HDOP value. As can be seen, as the number of satellites increases, the HDOP values decrease indicating a greater level of precision.

Data Filtration Module

According to various embodiments, the data filtration module is generally configured for filtering out GPS records based on a predetermined threshold of precision. In various embodiments, the data filtration module accesses one or more data quality indicators associated with a GPS record to determine the level of precision of the GPS record. The level of precision required may vary depending on the particular function of the data. Therefore, in various embodiments, the data filtration module may be configured to prompt a user to enter or select a value or range of values representative of a degree of precision. Alternatively, the data filtration module may be configured to automatically select a value or range of values in response to a user selection of a particular data function (e.g., safety monitoring, accident reconstruction, etc.).

In various embodiments of the present invention, data is filtered based on HDOP values alone. It is generally understood that HDOP values closest to 1.0 are ideal, and values between 1.0 and 2.0 are accurate for use in most applications. For example, the data filtration module may be configured to filter out any GPS-related data records where the HDOP value is greater than 5.0 when a user is accessing data for the purposes of evaluating a driver's safety. A higher threshold of precision is required for data used to reconstruct an accident sequence versus for data used to generally evaluate driver safety, in light of the fact that the data in the context of an accident is evaluated in terms of relation to other vehicles and/or objects, and data in the context of safety can typically be evaluated on a more general level. Therefore, in various embodiments of the present invention, when a user is accessing data for the purposes of reconstructing an accident sequence, the data filtration module may filter out any GPS-related data records where the HDOP value is, for example, greater than 3.0. Furthermore, when the data records are being used for an evidentiary purpose, such as, for example, in apportioning liability regarding an accident, an even higher degree of precision may be desired or even required by the decision-making authority. Therefore, the data filtration module in various embodiments may be configured to filter out GPS records associated with an HDOP value greater than 2.0, for example, when the data is being accessed for an accident-related evidentiary purpose.

Accident Reconstruction Module

According to various embodiments, the accident reconstruction module is generally configured for providing information pertaining to the details of a vehicle's travel path in the moments preceding an accident. In particular, referring briefly toFIG. 8, the accident reconstruction module generates the vehicle travel path on a user interface's map display810and view information derived from operational data captured as the vehicle traveled along a portion of the travel sequence leading to the accident.

FIG. 7illustrates the steps executed by the accident reconstruction module according to one embodiment. Beginning at step702, the accident reconstruction module detects accident data, for instance, when data from an accident key is uploaded to the central server. As noted above, data extracted from the telematics device in a vehicle and downloaded to an accident key can be flagged as being accident-related. Next, at step704, the accident reconstruction module identifies the driver ID and vehicle ID associated with the accident data.

Then, in various embodiments, in step706, the accident reconstruction module determines the time of the accident. In various embodiments of the present invention, the time of the accident may be determined by manual entry (e.g., if the driver noted the time of impact) or by the presence of certain data “flags” in the accident data (e.g., records associated with harsh braking or sudden vehicle movement signifying impact, etc.).

Next, in step708, the accident reconstruction module creates a geographical representation of the vehicle's movement in the accident sequence. In particular, the accident reconstruction module plots GPS points falling within a predetermined period of time leading up to the time of the accident. The GPS points are obtained from a combination of telematics data stored on the central server and accident data from the accident key. For example, as shown inFIG. 5, by using the time stamp as a reference point, accident data can be used to supplement telematics data to create the most comprehensive set of GPS data available.

In addition, as shown inFIG. 8, the accident reconstruction module may associate additional data with the GPS points that could be relevant for accident reconstruction (e.g., change in heading, speed, and reverse, brake, bulkhead, and seatbelt statuses).

In various embodiments, the data points for the travel sequence may have already been subjected to filtration for quality control, as described above with respect to the data filtration module. Therefore, a user assessing an accident sequence can be confident that the depicted sequence and corresponding data meets a certain degree of precision. In step710, the accident reconstruction module is configured to identify accident-prone conditions based on the GPS points and related data. For instance, in various embodiments, the accident reconstruction module may be configured to flag instances where the vehicle is traveling at a certain level over the speed limit or any predetermined speed deemed to be “safe” in the conditions. In other embodiments, step710can be carried out manually.

Conclusion

As should be appreciated, the embodiments may be implemented in various ways, including as methods, apparatus, systems, or computer program products. Accordingly, the embodiments may take the form of an entirely hardware embodiment or an embodiment in which a processor is programmed to perform certain steps. Furthermore, the various implementations may take the form of a computer program product on a computer-readable storage medium having computer-readable program instructions embodied in the storage medium. Any suitable computer-readable storage medium may be utilized including hard disks, CD-ROMs, optical storage devices, or magnetic storage devices.

The embodiments are described below with reference to block diagrams and flowchart illustrations of methods, apparatus, systems, and computer program products. It should be understood that each block of the block diagrams and flowchart illustrations, respectively, may be implemented in part by computer program instructions, e.g., as logical steps or operations executing on a processor in a computing system. These computer program instructions may be loaded onto a computer, such as a special purpose computer or other programmable data processing apparatus to produce a specifically-configured machine, such that the instructions which execute on the computer or other programmable data processing apparatus implement the functions specified in the flowchart block or blocks.

Accordingly, blocks of the block diagrams and flowchart illustrations support various combinations for performing the specified functions, combinations of operations for performing the specified functions and program instructions for performing the specified functions. It should also be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, can be implemented by special purpose hardware-based computer systems that perform the specified functions or operations, or combinations of special purpose hardware and computer instructions.