DEVELOPING AND USING A VEHICLE DIAGNOSTIC DISTRIBUTED DATABASE

Abstract

Described herein is a system and method of use for a vehicle diagnostic distributed database. One or more central servers are configured with a database containing diagnostic information pertaining to vehicles and relative to input received by the central server/s from client devices. The central server is configured to upload and download information with in-vehicle and external to vehicle diagnostic systems. These tasks are performed by first having the central server/s broadcast a message over open airways (for example, FM sidebands) to all potential client devices of interest. The message contains information identifying specific characteristics of client devices that should respond and further information about the information that is desired to be uploaded to the central server/s or for downloaded to the clients of interest. If clients meet the broadcast criteria, they then establish two-way communication with the central server/s and fulfill the request.

Claims

1. A system to create, manage and utilize a vehicle diagnostic distributed database comprising: a) at least one central server operable on one or more computers configured with at least: i) a radio transmitter configured to broadcast a query; ii) a first radio transceiver configured to perform two-way communications with the one or more client devices; and iii) a query engine configured to generate a query containing: (1) a selection criteria for client devices of interest; and (2) a request to at least one of upload information to the central server and download information from the at least one central server; and b) the one or more client device configured with at least: i) a broadcast radio receiver configured to receive broadcasts from the at least one central server station; ii) a second radio transceiver configured to perform two-way communications with the first radio transceiver in the at least one central server; and iii) a computer processor configured to receive a query from the broadcast radio transmitter and evaluate if the client device meets the selection criteria and if so, establish two-way communication, using the second radio transceiver, with the at least one central server, and perform the request.

2. The system of claim 1 wherein the query is a request to upload information that is specific for a particular vehicle type or component and related to known vehicle events or situations and comprises one or more of: a) vehicle component replacement and maintenance records; b) vehicle sensor data referenced in space and time; and c) environmental data referenced in space and time.

3. The system of claim 1 wherein the at least one central server is further configured to develop at least one of patterns and indices to predict vehicle events and identify situations based on information, from the one or more client devices, that was previously uploaded to the at least one central server.

4. The system of claim 3 wherein the query engine generates a bulletin apprising clients of interest on the availability for download of, one or more of patterns and indices and instructions for the usage of the one or more patterns and indices and the radio transmitter broadcasts the query.

5. The system of claim 4 wherein the clients of interest establish communication with the at least one central servers using the second radio transceiver and download the patterns and indices to predict events and identify situations.

6. The system of claim 1 wherein the selection criteria comprises at least one of make, model, year of manufacturer and optional equipment of a vehicle.

7. The system of claim 1 wherein the selection criteria comprises at least one of a geographic region, a climate zone, and within a political boundary.

8. The system of claim 1 wherein the request is for GPS traces along roads a client vehicle has traversed.

9. The system of claim 8 wherein the at least one server receives the requested GPS traces and is configured to update road geometry based on the GPS traces.

10. The system of claim 3 wherein the identified events and situations are one or more of: a) a vehicle accident occurring or having occurred. b) hazardous driving conditions; c) hazardous or illegal driving by a current driver of a vehicle; and d) required vehicle maintenance.

11. The system of claim 1 wherein the at least one client device is one or more of a: a) vehicle; b) satellite server or service; and c) mobile device.

12. The system of claim 10 wherein an assessment for damage or repair costs is made for the identified event or situation.

13. The system of claim 1 wherein the database comprises at least one: a) vehicle driving situations; b) vehicle driving patterns and indicators; c) vehicle components and maintenance records; d) sensor data referenced in space and time; and e) remote environmental data referenced in space and time.

14. A communication system used to operate a distributed vehicle diagnostic database comprising: a) one or more computer based servers configured with at least: i) a broadcast radio transmitter; ii) a first radio transceiver; and b) one or more client devices configured with at least: i) a broadcast radio receiver; ii) a second radio transceiver; wherein the one or more computer based servers transmits, using the broadcast radio transmitter, a request to one or more of upload and download information and further containing selection criteria, and the one or more client devices: a) listen for and receive the transmission, utilizing the broadcast radio receiver; b) determines whether the selection criteria are met; and c) if the selection criteria are met, establish communication between the first and second radio transceivers and perform the request.

15. A communication method used to operate a distributed vehicle diagnostic database comprising: a) broadcasting a radio transmission, using a radio transmitter that is part of a central server wherein the broadcast contains a query or bulletin including a client selection criteria, b) listening for and receiving the broadcast, utilizing the broadcast radio receiver that is part of a client device and determining whether the client device meets the client selection criteria, and if the client device meets the client selection criteria, establish communication between a first radio transceiver that is part of the client device and second radio transceivers that is part of the one or more central servers, and moving information between the one or more computer servers and the client device that meets the client selection criteria.

16. Then communication method of claim 15 wherein the information to upload or download comprises one or more of: a) driving situations; b) driving patterns and indicators; c) vehicle components and maintenance records; d) sensor data referenced in space and time; and e) remote environmental data referenced in space and time.

17. The communication method of claim 15 wherein the client device is one of a: a) vehicle; b) satellite server or service; and c) mobile device.

18. The communication method of claim 15 wherein the client transceiver of the one or more client devices is configured to also act as a repeater transmitting information to another client device which in turn can repeat the information and further transmit to yet another client or one or more of the computer based servers.

Description

BRIEF DESCRIPTION OF THE FIGURES

[0049] FIG. 1 is a depiction of an embodiment of a system that houses a distributed vehicle diagnostic database.

[0050] FIG. 2 is a flow chart of an embodiment of a method of using a distributed vehicle diagnostic database.

[0051] FIG. 3 is a flow chart of an embodiment of a method for follow up instructions after an event has occurred and been reported.

[0052] FIG. 4 is a flow chart of an embodiment of how patterns and indicators are updated.

DETAILED DESCRIPTION

[0053] FIG. 1 is an example of a distributed vehicle database system. System hardware is distributed between one or more central servers 102 and client systems 106. The client systems can include, for example, passenger vehicles 108, trucks 120, satellite servers 112, external data feeds, such as weather 114 and traffic 118, on-board vehicle systems and portable devices 110.

[0054] Information is communicated in the form of a query or a notification from the one or more central servers 102 to clients 106 via a radio broadcast 104. All clients have a radio receiver that conforms to the radio frequency and standard of broadcast as the radio broadcast device connected to the central server/s. All of the clients 106 in range of the broadcast receive the broadcast and digest the query or bulletin. If the query or bulletin pertains to the particular client 106, each client 106 establishes two-way communication, for example, over a mobile network 124, with the central server/s 102and uploads to the central server/s 102 the requested information for a query or downloads the available information to the clients 106 for a bulletin.

[0055] As not all data are needed for every situation, the data are maintained in the device or system where it was generated and/or in a regional client of some kind. All data does not need to be uploaded to a central server for storage and subsequent analysis unless a central server asked for it.

[0056] Below are examples of data that could be stored: [0057] raw sensor data recorded as time histories

[0058] accelerometer readings over time [0059] all sensors that can be queried via a vehicle diagnostic port (onboard diagnostics OBD) including: mass flow, oxygen, seat belt, air bag, tire pressure, gps, accelerometers, gyroscope, and more. [0060] sensor data derived from mobile or 3rd party devices within the vehicleincluding accelerometers, gyroscope, air pressure, gps. [0061] VIN, and/or make model and model year, accessories such as larger than normal tires, engine type and size, etc. [0062] Wheel diameter [0063] Tire tread pattern/age of tires/inflation pressure

[0064] Characteristic about the load in the vehicle (could for example be provided by RFID tags on cargo or passengers) [0065] Number of passengers [0066] Gross and Net Vehicle Weight [0067] Load distribution [0068] Environmental sensors and feeds either from on-board vehicle sensors or sensors external to the vehicle

[0069] The driver may be identified either by manually input, or via automatic connection between the vehicle and a mobile device of the driver, or by visual or audible input query by controlling software within the car. These are just examples and any type of identification of the driver could be used. The driver could carry an RFID tag that identifies her, for example.

[0070] Information relayed from roadside sensors or sensors or devices that monitor road conditions or weather can be stored. These can come from Bluetooth connections, side bands on radio stations (for example traffic); internet feeds and peer-to-peer networks from other vehicles.

[0071] Other information may concern repair history of warn vehicle parts as related to all the above mentioned information. This information could be stored directly in a server at a repair shopfor example.

Method of Use

[0072] All information stored in the distributed database is optionally spatially and/or temporally referenced. In addition, the information can be referenced based on the type of vehicle and/or how the vehicle is equipped and/or by the driver of the vehicle. Patterns that relate changes in one or more sensor and environmental data overtime to events are also stored in the database, both in vehicles were the patterns are pertinent and in a central database located on a central server or in satellite databases.

[0073] Patterns are created by analyzing many datasets with known events happening and developing a predictive model of the event based on the available data. Patterns are updated by a central server in communication with client systems through the process of querying the client system (such as a vehicle fleet) and having clients (vehicles) that match the requirements for the pattern, respond with relaying data for the event in question.

[0074] FIG. 2 explains how an embodiment of the system is used. The system consists of one or more central servers 202 equipped with one or more processors and one or more client devices 204 (see client devices as depicted in FIG. 1). The central server/s is configured with software to predict events and to make assessments. The central server/s is further equipped with a list of events of interest.

[0075] To predict an event, the central server/s 202 needs to correlate potential contributing factors to particular events or types of events 206. In some embodiments, the prediction or assessment is of regional or local in interest only and this will effect what sources of information are used 210. The central server/s 202 broadcasts, using a radio broadcast transmitter, a request to all potential clients 204 including identifying parameters of type of information and also what type of vehicle or other source for the information that is needed 212. This request is generated by instructions loaded in one or more processors and referred to as a query engine. Clients 204 are typically listening for broadcasts, using a radio broadcast receiver, from the central server/s 202. Once a broadcast is detected by a client, each client 204 parses the query or bulletin that was broadcast and determines whether it is able to comply with all of the requirements 216. If the client 204 can comply and the request (or query) is for information, the client will 1) relay the requested information to the central server/s 202, using a two way radio transceiver, and/or 2) start collecting the requested information from sensors or other devices. Once a packet of information is acquired, the client 204 establishes a two-way radio communication link using the transceiver and uploads the information 218 to the central server 202 which receives the information on a radio transceiver that is part of the central server/s.

[0076] The central server/s 202 then uses a form of statistical analysis to establish a relationship between the uploaded information from numerous clients 204 and creates predictive models 220 in the form of patterns and indicators. A broadcast, using the transmitter, is made to the clients 204 to let them know the derived patterns, and indicators are available for usage 222. Clients 204 that have need of the patterns and indicators 224,then download the information 226, then monitor sensors and other incoming information to determine if patterns or indicators occur that are indicate an event has happened 228.

[0077] FIG. 3 depicts how certain events trigger other events. A follow-on analysis may be necessary after certain types of events are detected to form a proper assessment of needs to be performed. An example of an assessment would be to indicate how much damage occurs when a vehicle is in an accident. Sensor output could be used to determine the type and severity of impact, and averages of repair bills for similar accidents in the vicinity of the current accident could be used to estimate the cost of repair.

[0078] In FIG. 3, a client 302 continuously monitors sensors and external feeds 304 and compares to patterns and indicators to detect an event. If an event is detected 306, pre-programmed activities are initiated that are associated with the event 308. One of these activities may be to inform the central server/s of the event and to upload information pertaining to the event. The client 302 establishes two way communications with the central server/s and then uploads the information and data associated with the event. The central server/s 310 in turn receives the information 312 and determines the type of follow-up information that is needed 314. An example would be, an accident is detected; it is reported to the central server along with particulars about speed, location, severity of impact. The central server may be programmed to determine if the accident caused a traffic slow down; therefore, it would broadcast a bulletin that it is interested in knowing the speed of vehicles that are in the vicinity of the accident so it can determine what, if any, roads were affected by the accident 318. In response other clients 320 that meet the selection criteria would communicate with the central server and upload their speed 322.

[0079] In the same scenario above, the central server could also send out a request for available tow trucks that could be dispatched immediately to the scene. Yet another request would be to the insurance company of the vehicle involved in the accident; to emergency responders; and the like to send out a representative to the scene. Another example would be notifying local auto body shops of a potential client.

[0080] FIG. 4 describes periodic update of the patterns and indicators stored in the system. Patterns and indicators need to be updated by central server/s. This happens by determining when certain patterns are either too old or new information is available that needs to be incorporated. For example, a new sensor reading may have been determined to be useful in prediction of certain types of events and has previously not been included in the patterns for that event. The central server/s 402 would send out a query for additional information to be used for this update including the type of sensor reading that are needed and other pertinent information 406. Potential clients of interest receive the query and determines if they are a client 404 of interest (have pertinent information) 414. Clients 404 of interest establish a link 416 with the server/s 402 and then upload pertinent information 418. The server/s 402 receives the information 408, and retires older information 410 and re-compute updated patterns and indicators 412.

Normal Mode of Operation

[0081] Numerous databases exist that have valuable information for vehicle diagnostics and analysis and for warning vehicles of impending events about to happen. One problem is that all of these databases may have different means of access (different query language, different security, and different accessibility on a network). For a distributed database to work, then all the databases that are a part of the whole, must either be structured in a similar fashion (have the same schema and identifying elements with the same nomenclature) and have a common query language or there must be an intermediate step to translate one schema and one query language to another.

[0082] For example, in a vehicle collision database, identification of where damage was sustained on the vehicle and the severity of the damage must be codified so that a central server understands the information provided by a client.

[0083] In Table 1,below, is an example of information that might be conveyed in a bulletin using the distributed vehicle database system - regarding a terrorist alert status. The scenario would be as follows: One or more of the central servers received a statement from the department of Homeland Security (a potential client) indicating that there will be an amber alert for a specific geographic area for a specified period.

[0084] The information in the alert could be represented with fields defined in table 1and with their XML (extensible markup language) counterpart below that.

Alert Parameters

[0085] alert [0086] A single active alert. Contains the following attributes
start [0087] The effective start date/time of the alert, in the form YYYY/MM/DD HH:MM, expressed in GMT
end [0088] The effective end date/time of the alert, in the form YYYY/MM/DD HH:MM, expressed in GMT
type [0089] The type of the alert. Possible choices are [0090] Imminent Threat [0091] Elevated Threat
link [0092] a URL to a PDF document which provides further details about the alert
summary [0093] A short plain text summary of the alert.
details [0094] A longer explanation of the alert. May contain HTML
sectors [0095] A possibly empty list of sectors which are impacted by this alert
sector [0096] An individual sector impacted by an alert. Represented as plain text
locations [0097] A possibly empty list of locations which are impacted by this alert
location [0098] An individual location impacted by an alert. Represented as plain text
duration [0099] A plain text description of the expected duration of this alert May be blank
detail.sub.sections [0100] A list of information specific to the threat detailed by the alert
detail.sub.section [0101] An individual detail section containing a specific piece of information for the alert.
detail.sub.title [0102] An individual detail section title. May contain HTML
detail [0103] An individual piece of detail related to the threat. May contain HTML

Alert in XML Format

[0104]

TABLE-US-00001 TABLE 1 <?xml version=1.0 encoding=UTF-8?> <alert start=2011/04/14 14:39 end=2012/04/14 14:38 type=Elevated Threat link=http://www.dhs.gov/xlibrary/assets/ntas/ntas-sample-alert.pdf> <summary><![CDATA[This is a summary of the alert]]></summary> <details><![CDATA[<p>This is a more detailed description of the alert</p>]]></details> <locations> <location><![CDATA[A location or region]]></location> <location><![CDATA[Another location or region]]></location> </locations> <sectors> <sector><![CDATA[An impacted sector]]></sector> <sector><![CDATA[Another impacted sector]]></sector> </sectors> <duration><![CDATA[Freeform text description of the duration of the alert]]></duration> <detail_sections> <detail_section> <detail_title><![CDATA[Freeform detail title]]></detail_title> <detail><![CDATA[<p>Freeform text description of threat details</p>]]></detail> </detail_section> <detail_section> <detail_title><![CDATA[Freeform detail title]]></detail_title> <detail><![CDATA[<p>Freeform text description of threat details</p>]]></detail> </detail_section> <detail_section> <detail_title><![CDATA[Freeform detail title]]></detail_title> <detail><![CDATA[<p>Freeform text description of threat details</p>]]></detail> </detail_section> <detail_section> <detail_title><![CDATA[Freeform detail title]]></detail_title> <detail><![CDATA[<p>Freeform text description of threat details</p>]]></detail> </detail_section> </detail_sections> </alert>

[0105] The central server may be programmed to receive the xml above and parse it. Based on the location fields, the type of alert field and the duration, the server may be further programmed to divert members of a fleet of vehicle away from the alert area if they are scheduled to be in the alert area at the specified time. This would happen by broadcasting a request that all members of the fleet of interest to establish a link with the central server and receive further information about the threat level. This would save having to relay the entire message to all vehicles. In addition, the central server would know have a good indication of how many vehicles in its fleet would be impacted by the alert. Of course other scenarios could be treated in the same manner.

[0106] In an embodiment of the system and method, the prediction of required maintenance and the estimated cost of maintenance is transmitted to the vehicle when service or maintenance is needed. The transmission can occur to either the in-vehicle system or to a mobile device carried by a driver or passenger or directly to a service technician.

[0107] If the analysis is transmitted to the car, results can be displayed either graphically and/or in text on a screen in the vehiclefor example, an infotainment system screen.

Communication Protocols

[0108] For radio broadcast from the central server to client devices communications could for example be using FM side-bands much like Traffic Messaging channels operate. Communication could also be peer-to-peer and/or repeated. For example, the central server/s could broadcast a query or bulletin which is received by a vehicle. The vehicle could then rebroadcast it over a different frequency or using a different protocolfor example Bluetooth.

[0109] Communications between various sensors and a processor in a client can happen via the system bus in the client or via short range wireless or via fiber optics or wired connections. If the client device is an add-on product or consists of software running on a mobile device within a vehicle, then communication with the integral vehicle sensor may be by using an interface that can read on-board diagnostic (OBD II) codes by interfacing with a vehicle portal designed for external communications. Another type of code that is somewhat standardized for vehicle diagnostics is the diagnostic trouble codes (DTC).

[0110] Many vehicles have Bluetooth or similar short range wireless protocol communication modules and can transmit information such as DTC codes to nearby devices. Longer range telematics devices that use, for example, mobile phone communication methods, also exist that can transmit DTC codes or similar code to a central location

[0111] If the vehicle data collection module has software running on a general purpose computing device such as a mobile phone, the phone or other device could be plugged into the vehicle using a wired means such as a Universal Serial Bus (USB) or short range wireless such as Bluetooth.

[0112] Sensor that are part of the mobile device can also be considered in-vehicle sensors provided the device is in or attached to the vehicle. These types of sensors can include gyroscopes, accelerometers, altimeters and GPS, for example. Communication with these sensors would be over the data bus of the portable device.

[0113] For client device that are in a stationary location, for example, road side sensor suites, an autobody repair facility, communication to a certain server or other nodes could happen over the internet and/or other form of wired and/or satellite communication.

[0114] In addition, a client device may communicate with a central server and/or a client device using a per-to-per network where a message is transmitted to one or more other client devices and then the message is repeated for other client that are in communication with the transmitting client device.

Database Design and Input Normalization

[0115] In embodiments of this invention, vehicle maintenance and service requirements are predicted by comparing the observed conditions that occur during vehicle operation over time with similar observed conditions for similarly classed vehicle used in similar conditions stored in a historical vehicle maintenance database. Algorithms are developed to classify each maintenance or service event as succinctly as possible, given the available data, such that when the conditions requiring maintenance or service for a vehicle in use match a classification, this can be used with a degree of certainty, to predict resulting maintenance required and the parts and services necessary to effect the maintenance.

[0116] In an embodiment, the observed conditions of interest during vehicle operation include:

Specific Type of Vehicle, Including Make, Year, Model, Weight and Options

[0117] Condition of the vehicle (prior damage, corrosion, state of repair) [0118] Maintenance and Repair History [0119] Accident History [0120] Locale of vehicle operation (for determination of regional variable costs) [0121] Environmental factors (weather, road conditions) during operation

[0122] Raw data that may be used to predict maintenance and service needed can come from a plurality of sources. Sources include: [0123] In-vehicle Sensors [0124] Accelerometer to measure starting and stopping, rapid turning [0125] ABS sensors to detect when slippery conditions occur [0126] Gyroscope to erratic driving patterns [0127] GPS for speed and direction of travel [0128] Seatbelt sensors [0129] Engine sensors such as oxygen, rpm, pollution control, temperature, etc [0130] External Sensors [0131] Weather from web services [0132] Traffic information from web services or FM sideband (Traffic Messaging Channel) [0133] Road Condition Information from web-sources such as highway departments [0134] Other means of collecting information [0135] Fleet Maintenance Reports (subsequently manually entered into the system database by manual entry using a computer interface application [0136] Repair Shop Invoices [0137] GIS information (speed limits where traveled and roads traveled) [0138] A listing of parts replaced [0139] Price of labor (preferably broken out by part installed or service performed) [0140] Price of parts [0141] Time between suggested maintenance and it actually occurring [0142] Amount of lost time failures when maintenance suggestions are followed vs when maintenance lags

[0143] The database initially will have a mix of more qualitative data, for example from manually entered fleet maintenance records and repair shop invoices and quantitative data, for example, from in-vehicle sensors. As such there is a subjective element in the reporting and the likelihood of human error will reduce the quality of the manually entered data and therefore if the manually entered data makes up the bulk of the available information, the error in prediction of maintenance will be greater.

[0144] In addition, since much of qualitative information would have initially have been manually entered on a piece of paper, there will also be transcription errors regardless of whether the information is manually input into the database by a human or if the information is machine input using optical character recognition and algorithmic processing of the text.

[0145] Available information to input into the database will change with time. As more information of a quantitative nature or more precise, accurate and with less bias information becomes available, older more qualitative data will be replaced and the resulting predictive model or associated statistics will be updated to reflect the new data.

[0146] For information from disparate sources to be compared, the information must be normalized, i.e. converted to the same units of measure and be relative to the same reference frame. In addition, the quality and precision of the data must also be evaluated and represented within the database in a normalized fashion. In other words, if for example, one speed is known to be accurate within +/ 10 mph, then all speeds in the database should have an error of estimate in mph (as opposed to kph for example).

Components of the System

[0147] The following components are parts of embodiments of the system described in this application: [0148] One or more central servers that contain: [0149] Computer memory loaded with: [0150] a comprehensive database and patterns and indicators that correlate to events and situations [0151] One or more processors containing: [0152] Instructions for when and how to transmit requests for information and/or bulletins [0153] Instructions for receiving and analyzing information from remote devices [0154] Communications Devices [0155] One-way transmitter of binary digital data containing: [0156] Coded requests for information including: [0157] Identification of the information requested [0158] Optional: Identification of the type of vehicle and/or components required by for a respondent [0159] Optional: Geographic Area of Interest [0160] Optional: Time period of Interest [0161] Radio Transceiver used to upload and download information to one or more specific client systems after two-way communication has been established by the client [0162] Vehicle Systems and / or Portable Devices [0163] Radio Receiver for information from central servers via the one-way transmitter and/or other vehicles or systems including: [0164] Query for information [0165] Updates of patterns and indicators [0166] Updates on codes that are used to identify fields in a query [0167] Updates on sensor information and/or external feeds that are available on the network [0168] Updates on parts inventory that are part of each car [0169] Radio Transceiver configured to establish two-way communications with one or more central servers and further used to upload and download information [0170] Sensors (in-vehicle and external to vehicles) [0171] See listing of sensors elsewhere in this document

Examples of Use

[0172] An example of how to use the above information is that the central server can query the satellite servers for regional information, when, for example, an insurance carrier wants to adjust rates base on region or a fleet management company wants to perform preventative maintenance on their fleet which is region dependent.

[0173] An operator of the system may desire to update the geography of a specific road segment. To do this a query may be sent to all vehicle, requesting a download of gps traces for vehicles that have traversed the segment within a specified time period. Vehicles that meet this requirement and that received the query then respond by sending the appropriate information. Once the information is received, then the GPS traces can be processed to revise the geometry or the road segment in the central database. Transportation network information comprises the physical location of roads, the road condition, traffic density throughout the day or week and typical weather conditions for a given time and relative to a road position and more.

[0174] Another example of how the distributed database could be used would be, for example, in the current Volkswagen scandal. Suppose it is desired to measure fuel emissions from diesel engines while on the road, yet it is very difficult and expensive to do this directly. By using the relationship between the observed emissions values and the vehicle weight, slope angle the vehicle is driving on, country of origin of the vehicle (depending on country regulations, the vehicle is equipped with different engine features for example), octane level of the fuel, engine rpms, and tire type and inflation a pattern can be determined so that emissions can be measured indirectly. Then it can be determined how often vehicles on the road have emission values that exceed the emissions for the similarly equipped vehicle when run on a dynamometer.

[0175] The central processor/s could send out a query request to all vehicles in the network and request that all vehicles with a specific model and model year and that have the specific engine type of interest, record the above parameters over a period of time and transmit that information back to the central server. Alternatively, the vehicles in question will already be recording and storing this information, and can relay this information to the central server for a former time period once it is requested by the central server. Yet another possibility is for the central server to send the stored relationship (pattern or indicators) with the query, so that the individual vehicle systems can determine emission values based on the stored pattern and/or indicators and send only the computed emission values back to the central server.

[0176] Another example usage is in comparing vehicle wear as a function of region. Similarly, equipped vehicles will wear out faster or sustain differing levels of damage when involved in an accident depending on where the vehicle is driven. This type of information could be important for determining insurance rates. Corrosion due to salt being used as a de-icer for roads, corrodes vehicle parts significantly faster than when the salt is not applied. Likewise, in an area where there is significant rain, corrosion will be higher than in an arid region.

Other Use Scenarios

[0177] Determining if a detour and/or road construction is still in effect for a particular street segment. [0178] Request issued from Central Server/s: Rate of speed for vehicles traveling a specific road segment within the last day. [0179] Analysis: If no replies: road most likely closed: [0180] If replies from client devices indicate vehicles are moving slow over the whole day, construction most likely active

[0181] Determining why a particular vehicle part broke or wore out. [0182] Request for a response from any repair facility: record of repairs or replacement of the part of interest that has worn out; supply all vehicle information, such as mileage on the part, location, vehicle type, vehicle model, subcomponents related to the part of interest. [0183] Analysis: Cross correlate subcomponents and mileage and vehicle type with the failure. Determine how to avoid the failure and/or determine what set of variable most likely predict the failure. [0184] Broadcast a repair bulletin for the identified vehicle characteristics of interest for when to perform scheduled maintenance based on when the part is anticipated to fail. Send a request to update the database in in-vehicle systems for this particular anticipated failure.

[0185] Update the geometry of a road [0186] Broadcast a request for GPS traces of a road from all vehicles driving the road. [0187] Analysis: Merge the traces from the responding vehicles into an average and compare with the existing segment in a navigation database. If the new segment is substantially different, replace the old one, or merge the new one with the old one. [0188] Broadcast that a new update in road geometry is available for download

[0189] Update traffic light timing [0190] Request: For all vehicles that are traveling within a defined geographic area, upload the gps trace and traveltime while in the defined area. [0191] Analysis: Determine how long each vehicle had to wait for a traffic signal (i.e. more than once) in all four directions of travel at times throughout the day. Compare with other traffic lights that are in the area. Using traffic modeling determine if changing the timing of the traffic lights would minimize congestion and improve transit speed. [0192] Broadcast to the traffic lights in question that a new timing scenario is available for download.

Implementations

[0193] The present invention may be conveniently implemented using one or more conventional general purpose or specialized digital computers or microprocessors programmed according to the teachings of the present disclosure, or a portable device (e.g., a smartphone, tablet computer, computer or other device), equipped with including one or more sensors (e.g., accelerometers, GPS) or where the portable device are connected to the data collection devices that are remote to the portable device, or that are connected via wired or wireless means. Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art.

[0194] In some embodiments, the present invention includes a computer program product which is a non-transitory storage medium (media) having instructions stored thereon/in which can be used to program a computer to perform any of the processes of the present invention. The storage medium can include, but is not limited to, any type of disk including floppy disks, optical discs, DVD, CD-ROMs, micro drive, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data.

Remarks

[0195] The foregoing description of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the invention for various embodiments and with various modifications that are suited to the particular use contemplated. For example, although the illustrations provided herein primarily describe embodiments using vehicles, it will be evident that the techniques described herein can be similarly used with, e.g., trains, ships, airplanes, containers, or other moving equipment, and with other types of data collection devices. It is intended that the scope of the invention be defined by the following claims and their equivalence.