The present disclosure relates to the field of vehicle diagnosis, particularly to the field of remote vehicle diagnosis.
Today's vehicles are equipped with many different types of data collection and processing components. Much of the data collected by the data collection components is used to control the operation of the vehicle. For example, data collected by oxygen sensors is used to control the amount of fuel introduced into the engine, to avoid providing an overly rich fuel mixture that would result in decreased fuel efficiency and increased emissions.
Two broad classes of data include operational data and fault code data. As used herein and the claims that follow, the term operational data encompasses data that is used to control the operation of the vehicle, such as the data from oxygen sensors as noted above (data which is used by one or more vehicle controllers as feedback for controlling some aspect of the vehicles operation), or data that is simply generated during the operation of the vehicle (some vehicles generate operational data that is not used by any vehicle component during routine vehicle operation, but is rather used by diagnostic or service equipment during vehicle servicing or maintenance). In general, operational data is not stored, but rather is generated, contemporaneously used (either to control various vehicular systems or to provide data to diagnostic or service equipment during vehicle servicing), and then discarded. Exemplary operational data include, but is not limited to, engine coolant temperature, engine speed, oxygen levels, throttle position, brake temperature, vehicle speed, brake position, and gearbox parameters. Much of this data is collected very frequently, some types of operational data being collected multiple times per second. The sheer quantity of operational data being generated by the various vehicle components and subsystems makes storing or archiving all of such operational data problematical. Some vendors do provide data logging systems for temporary use in vehicles, where all the operational data generated by the vehicle is stored for later analysis, but such data logging systems are not designed for long term use.
Fault code data somewhat addresses the problem of storing the enormous quantity of operational data generated by vehicles. Fault codes corresponding to specific undesirable operating parameters are predefined. A processor in the vehicle monitors the operational data as it is generated, and whenever an operating parameter corresponding to a specific predefined fault code is detected, the fault code is stored in a memory in the vehicle. The fault code is generally a numeric or alphanumeric value that can be stored using very little memory resources. For example, the number 11 can be defined as a fault code for the following condition: battery sensing voltage drops below 4 or between 7 and 8 volts for more than 20 seconds. Fault codes can be retrieved and used to diagnose vehicle problems. Even with the data provided by fault codes, accurate diagnosis of complex or unusual vehicular system failures can be problematical.
It would be desirable to provide a vehicular diagnostic method and apparatus that provided more contextual data than available based on fault codes alone, which do not rely on storing all of the operational data produced by a vehicle.
This application specifically incorporates by reference the disclosures and drawings of each patent application identified above as a related application.
The concepts disclosed herein encompass temporarily storing operational data in a buffer in the vehicle, rather than simply discarding the operational data, and then archiving such buffered operational data whenever a fault code is generated. Such archived operational data combined with the fault code will provide a contextually rich data set that will greatly facilitate diagnosis of vehicle problems. The term combining does not require the archived or saved operational data and the fault code data to be stored in the same file location or data packet, rather, the term combining is used to indicate that a contextual link between the archived operational data and the fault code is generated, so that even if the archived operational data and the fault code are not stored together in a single file or data packet, the archived operational data corresponding to a particular fault code can be differentiated from archived operational data corresponding to a different fault code. Time indexing can be used to correlate specific archived operational data to specific fault codes, if the different types of data are to be stored separately.
In at least one exemplary embodiment, the archived operational data corresponding to a particular fault code is ring buffered operational data, which includes operational data collected both before and after the fault code is detected. The amount of operational data before and after the fault code can be defined as desired, and need not be identical (that is, some users may prefer relatively more operational data after a fault code is detected, and relatively less operational data before a fault code is detected, or vice versa). In at least one exemplary embodiment, systems implementing the concepts disclosed herein are configured to enable the temporal extent of such a ring buffer to be a user adjustable parameter.
In at least one exemplary embodiment, the contextually (and temporally) linked buffered operational data and fault code data are conveyed in real-time to a remote computing device, so that a diagnosis of a vehicle problem causing the generation of the fault code can occur while the vehicle is operational. Rapid diagnosis of problems can lead to the prevention of damage to the vehicle caused by continuing to operate the vehicle after a malfunction is detected, where the diagnosis indicates that continued operation of the vehicle would result in such damage. In such circumstances, the driver of the vehicle can be contacted to ensure that continued operation of the vehicle does not occur. If the diagnosed problem is relatively minor, the operator of the vehicle can be contacted with less urgency to arrange for a repair. In an exemplary, but not limiting embodiment, where continued operation of the vehicle is not likely to result in damage, the results of the vehicle diagnosis are forwarded to the vehicle operator, service for the vehicle is scheduled, and parts required for the service are ordered, all while the vehicle continues to operate.
A system for diagnosing vehicle faults may be summarized as including: a data buffer in which the operational data generated from a plurality of components during operation of the vehicle is temporarily stored; a data link for wirelessly conveying data from the vehicle during operation of the vehicle; and at least one vehicle processor configured to detect an anomalous condition and respond to detection of the anomalous condition, by conveying data defining the detected anomalous condition and buffered operational data generated at a time proximate to the detection of the anomalous condition; and a first remote server at a first remote location; and a second remote server at a second remote location, the first remote server being configured to forward the data defining the detected anomalous condition and buffered operational data to the second remote server at the second remote location without analyzing the data, the second remote server at the second remote location analyzing the detected anomalous condition and buffered operational data to determine if the detected anomalous condition and buffered operational data indicates a particular fault code data.
The at least one vehicle processor may be configured to identify an anomalous condition corresponding to a fault code defined by the vehicle's manufacturer. The at least one vehicle processor may be configured to identify a user defined anomalous condition, the user including at least one of an operator of the vehicle and an operator of a remote computing device. The at least one vehicle processor may be configured to receive instructions from the remote location defining the anomalous condition. The at least one vehicle processor may be configured to receive instructions from the remote location defining a quantity or type of buffered operational data to be conveyed to the remote location when the anomalous condition is detected. A processor in the second remote server may request additional one or more specific types of data from the vehicle processor, if the additional one or more specific types of data are needed by the second remote server to facilitate or confirm a diagnostic analysis performed by the second remote server to enable the processor to identify a cause of the anomalous condition. The at least one vehicle processor may be configured to detect the anomalous condition by analyzing the operational data as it is generated. The data buffer, the data link, and the vehicle processor may be combined into a diagnostic device that is attached to the vehicle.
The computing device may be further configured to detect instances in which a cause of the anomalous condition is likely to cause damage to the vehicle or an unsafe condition for the vehicle, and upon such detection, issue instructions to a vehicle operator to cease vehicle operations as soon as possible.
A method for diagnosing an anomalous vehicle condition, in a system including a vehicle having a plurality of components that generate operational data during operation of the vehicle over a road, a data buffer in which the operational data is temporarily stored, a data link for wirelessly conveying data from the vehicle during operation of the vehicle, and at least one vehicle processor, may be summarized as including detecting an anomalous condition during operation of the vehicle; responding to the detection of the anomalous condition, by conveying data defining the detected anomalous condition and buffered operational data generated at a time proximate to the detection of the anomalous condition; receiving, at a first remote server, the data defining the detected anomalous condition and buffered operational data; forwarding, from the first remote server, the data defining the detected anomalous condition and buffered operational data to a second remote server at a remote location without analyzing the data; and analyzing, at the second remote server, the detected anomalous condition and buffered operational data to determine if the detected anomalous condition and buffered operational data indicate a particular fault code data.
A system for diagnosing a vehicle fault may be summarized as including a vehicle data buffer in which operational data generated by operation of a vehicle is temporarily stored; a data link that wirelessly conveys data from the vehicle during operation of the vehicle; at least one vehicle processor configured to detect an anomalous condition and respond to detection of the anomalous condition, by conveying fault related data including one or more of detected fault codes, collected data about the vehicle fault, location of the vehicle at a fault time, and operational data before and after the vehicle fault; and a remote server at a remote location that analyzes the fault related data and the operational data to determine if the detected anomalous condition predicts a specific failure, wherein the remote server requests additional information from the vehicle, and wherein the remote server contacts an operator of the vehicle to advise the operator of the predicted specific failure determined by the analysis on the remote server. The request of additional information from the vehicle by the remote server may include instructing the vehicle operator to acquire electronic vehicle performance data. The at least one vehicle processor may be configured to identify an anomalous condition corresponding to a fault code defined by the vehicle's manufacturer.
The at least one vehicle processor may be configured to identify a user defined anomalous condition, the user including at least one of an operator of the vehicle and an operator of a remote computing device. The at least one vehicle processor may be configured to receive instructions from the remote location defining the anomalous condition. The at least one vehicle processor may be configured to receive instructions from the remote location defining a quantity or type of buffered operational data to be conveyed to the remote location when the anomalous condition is detected. A processor in the second remote server may request additional one or more specific types of data from the vehicle processor, if the additional one or more specific types of data are needed by a second remote server to facilitate or confirm a diagnostic analysis performed by the second remote server to enable the processor to identify a cause of the anomalous condition. The at least one vehicle processor may be configured to detect the anomalous condition by analyzing the operational data as it is generated. The data buffer, the data link, and the vehicle processor may be combined into a diagnostic device that is attached to the vehicle.
The computing device may be further configured to detect instances in which a cause of the anomalous condition is likely to cause damage to the vehicle or an unsafe condition for the vehicle, and upon such detection, issue instructions to a vehicle operator to cease vehicle operations as soon as possible.
A method for diagnosing a vehicle fault, in a system including a vehicle data buffer in which operational data generated by operation of a vehicle is temporarily stored, a data link that wirelessly conveys data from the vehicle during operation of the vehicle, and at least one vehicle processor, may be summarized as including detecting an anomalous condition during operation of the vehicle; in response to the detection of the anomalous condition, conveying fault related data including one or more of detected fault codes, collected data about the vehicle fault, location of the vehicle at a fault time, and operational data before and after the vehicle fault; receiving, at a remote server, the conveyed fault related data including one or more of detected fault codes, collected data about the vehicle fault, location of the vehicle at a fault time, and operational data before and after the vehicle fault; analyzing, at the remote server, the fault related data and buffered operational data to determine if the detected anomalous condition predicts a specific failure; requesting, via the remote server, additional information from the vehicle; and contacting, via the remote server, an operator of the vehicle to advise the operator of the predicted specific failure determined by the analysis on the remote server.
Requesting, via the remote server, additional information from the vehicle may include instructing the vehicle operator to acquire electronic vehicle performance data.
Various aspects and attendant advantages of one or more exemplary embodiments and modifications thereto will become more readily appreciated as the same becomes better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings, wherein:
Exemplary embodiments are illustrated in referenced Figures of the drawings. It is intended that the embodiments and Figures disclosed herein are to be considered illustrative rather than restrictive. No limitation on the scope of the technology and of the claims that follow is to be imputed to the examples shown in the drawings and discussed herein. Further, it should be understood that any feature of one embodiment disclosed herein can be combined with one or more features of any other embodiment that is disclosed, unless otherwise indicated.
As used herein and in the claims that follow, a reference to an activity that occurs in real-time is intended to refer not only to an activity that occurs with no delay, but also to an activity that occurs with a relatively short delay (i.e., a delay or lag period of seconds or minutes, but with less than an hour of lag time).
Referring to
In a block 12, the data link is used to convey the anomaly (i.e., vehicle data that is identified as non-standard, or anomalous, which in an exemplary, but not limiting embodiment, is represented by a fault code, which is a numeric or alphanumeric value corresponding to a predefined fault condition) and the contents of the data buffer (in some embodiments the entire contents of the data buffer is sent, whereas in other embodiments less than the entire contents of the data buffer is sent along with the anomaly) to a remote computing device for analysis. It should be understood that the fault code and contents of the data buffer (in which operational data are stored) may be sent to more than one remote computing device before analysis of the data is implemented. For example, in an exemplary but not limiting embodiment, the fault code and contents of the data buffer are wirelessly conveyed from the vehicle (in real-time) to a computing device (which may be a network of linked devices as opposed to a single computing device) operated by the vehicle owner or a vendor providing a service to the vehicle owner. The data is stored therein, and then conveyed to a different remote computing device (which itself maybe a network of linked devices as opposed to a single computing device) operated by a vendor providing diagnostic services to the vehicle owner.
In a block 14, a processor at a remote location is used to analyze the fault code (or other data defining the detected anomalous or non-standard data) and the contents of the data buffer conveyed from the vehicle to identify a cause of the anomaly. In an optional block 16, the processor at the remote location may request additional data from the vehicle to facilitate the analysis or to confirm a diagnosis. In some embodiments, the additional data is the contents of the data buffer at a subsequent time interval, while in other embodiments the additional data is specifically defined data that the vehicle collects and conveys.
In general, the analysis of the fault code/anomaly and the contents of the data buffer will be carried out by a remote computing device. The remote computing device in at least one embodiment comprises a computing system controlled by the operator of the vehicle, while in other exemplary embodiments the computing system is controlled by a third party or vendor who manages the diagnostic service for the operators of the enrolled vehicles (in some embodiments, the third party bills the vehicle operators a subscription fee). The remote computing device can be operating in a networked environment.
Also included in processing unit 254 are a random access memory (RAM) 256 and non-volatile memory 260, which can include read only memory (ROM) and may include some form of memory storage, such as a hard drive, optical disk (and drive), etc. These memory devices are bi-directionally coupled to CPU 258. Such storage devices are well known in the art. Machine instructions and data are temporarily loaded into RAM 256 from non-volatile memory 260. Also stored in the non-volatile memory are an operating system software and ancillary software. While not separately shown, it will be understood that a generally conventional power supply will be included to provide electrical power at voltage and current levels appropriate to energize computing system 250.
Input device 252 can be any device or mechanism that facilitates user input into the operating environment, including, but not limited to, one or more of a mouse or other pointing device, a keyboard, a microphone, a modem, or other input device. In general, the input device will be used to initially configure computing system 250, to achieve the desired processing (i.e., to analyze performance data from a vehicle to detect a mechanical or other fault). Configuration of computing system 250 to achieve the desired processing includes the steps of loading appropriate processing software into non-volatile memory 260, and launching the processing application (e.g., loading the processing software into RAM 256 for execution by the CPU) so that the processing application is ready for use. Output device 262 generally includes any device that produces output information, but will most typically comprise a monitor or computer display designed for human visual perception of output. Use of a conventional computer keyboard for input device 252 and a computer display for output device 262 should be considered as exemplary, rather than as limiting on the scope of this system. Data link 264 is configured to enable vehicle anomaly data and buffered operational data collected in connection with operation of enrolled vehicles to be input into computing system 250 for analysis to determine a cause of the anomalous data. Those of ordinary skill in the art will readily recognize that many types of data links can be implemented, including, but not limited to, universal serial bus (USB) ports, parallel ports, serial ports, inputs configured to couple with portable memory storage devices, FireWire ports, infrared data ports, wireless data communication such as Wi-Fi and Bluetooth™, network connections via Ethernet ports, and other connections that employ the Internet. Note that vehicle data from the enrolled vehicles will be communicated wirelessly, either directly to the remote computing system that analyzes the data to diagnose the anomaly, or to some storage location or other computing system that is linked to computing system 250. In at least one embodiment, the vehicle anomaly data and buffered operational data collected in connection with operation of enrolled vehicles is wirelessly transmitted in a compact binary format to a first server, where the data is converted to a different format for transmission to a second server over a computer network, such as the Internet. In at least one embodiment, the second format is XML.
It should be understood that the term remote computer and the term remote computing device are intended to encompass networked computers, including servers and clients, in private networks or as part of the Internet. The buffered operational data and anomaly defining data can be stored by one element in such a network, retrieved for review by another element in the network, and analyzed by yet another element in the network. In at least one embodiment, a vendor is responsible for diagnosing the operational data and anomaly defining data, and clients of the vendor are able to access and review such data, as well as any resulting diagnoses. While implementation of the method noted above has been discussed in terms of execution of machine instructions by a processor (i.e., the computing device implementing machine instructions to implement the specific functions noted above), the method could also be implemented using a custom circuit (such as an application specific integrated circuit).
In some embodiments, an output 45 is also included, to provide diagnostic related information to the driver in a form that can be easily understood by the driver. Output 45 can be implemented using one or more lights (for example, a red light can be used to indicate that a problem has been detected which requires the operator to stop the vehicle, or to modify vehicle operations (for example, to slow down or otherwise reduce a load being placed on the vehicle until a repair can be made), using a speaker providing an audible output, and using a display providing a visual output. Note that output 45 can be combined into a single component with the data buffer and the data link, so only a single additional component is added to the vehicle (recognizing that most vehicles already include the additional required components, such as the operational data collecting components and the processor, although in at least some embodiments an additional processor is added to the vehicle to control the triggering of the transmission of buffered operational data to the remote computing device).
The concepts disclosed herein are in at least some embodiments intended to be used by fleet owners operating multiple vehicles, and the anomaly defining data and buffered operational data conveyed to the remote location for diagnosis will include an ID component that enables each enrolled vehicle to be uniquely identified.
In the diagnostic system embodiment of
Diagnostic unit 68 conveys diagnostic logs 76 from vehicle 64 to remote computer 72 via wireless network 70, generally as discussed above. Diagnostic logs 76 include an identified anomaly (such as a fault code) and data stored in the data buffer portion of diagnostic unit 68. Remote computer 72 analyzes the diagnostic logs to determine a cause of the anomaly. Remote computer 72 conveys data 74 (which includes one or more of configuration data and diagnostic data) to diagnostic device 68 via the wireless network. The configuration data is used to modify the functions implemented by the processor in diagnostic unit 68. Modifications includes, but are not limited to, changing the amount of operational data to be stored in the data buffer, changing an amount of operational data collected before an anomaly that is conveyed to the remote computing device, changing an amount of operational data collected after an anomaly that is conveyed to the remote computing device, changing a type of operational data that is conveyed to the remote computing device (this enables the remote computing device to request specific types of operational data after a diagnostic log has been received, to facilitate diagnosing the anomaly), and changing a definition of what constitutes an anomaly. The diagnostic data includes data conveyed to the operator of the vehicle, informing the operator of what actions the operator needs to take in response to the diagnosis. Such diagnostic data can include instructions to cease vehicle operations as soon as possible to avoid unsafe or damaging conditions, instructions to proceed to a designated repair facility, and/or instructions to proceed with a scheduled route, and to wait to repair the vehicle when the route is complete.
In an exemplary embodiment, diagnostic device 68 is implemented by using a hardware device installed onboard medium and heavy duty (Class 5-8) vehicles that is permanently or temporarily installed, powered from onboard vehicle power systems, connected to the in-vehicle diagnostic data communications network, capable of collecting diagnostic data from the vehicle data communications network and sending it to an off board server. The specific information to be acquired from the vehicle communications data link is remotely configurable. The specific data messages that trigger a data collection event are also remotely configurable. Data transmission from the vehicle includes a wireless interface between the vehicle and the off board server, such as a cellular modem or other similar wireless data transmission method. Data received at the off board server may then be forwarded to any defined set of consumers for the diagnostic information to be remotely analyzed and acted upon.
The components of system 62 include the hardware device used to implement diagnostic device 68, hardware programming (firmware), the wireless network, and the remote computing device (such as a computer server/data center). System 62 operates by using the remote computing device to transmit programming/configuration data to the in-vehicle device (i.e., diagnostic device 68) via the wireless network. During vehicle operation, the diagnostic data device stores operational data to include with all diagnostic log events (i.e., with each fault code or detected anomaly). In an exemplary but not limiting embodiment, the diagnostic log conveyed to the remote computing device from the vehicle includes data such as a diagnostic log file revision, a diagnostic log file type, a device ID, a configured time interval defining the extent of buffered operational data, and the number of parameters to be stored in the diagnostic log files. The diagnostic data device in the vehicle performs the functions of: storing a list of diagnostic parameters to be monitored and recorded from the vehicle data link at regular periodic intervals; storing a list of event parameters to trigger diagnostic data capture; and storing a time interval for diagnostic parameter recording. In an exemplary but not limiting embodiment, the diagnostic data device is connected to an in-vehicle data link (e.g., a J1939 bus) and vehicle power connections.
During vehicle operation, while the vehicle data link communication is active, the diagnostic data device is continuously monitoring for specific data messages configured to trigger the collection of diagnostic log files. Once diagnostic log files are recorded, they are transmitted via the wireless network to the remote computing device. Diagnostic log files are moved from the data center server within minutes to a destination server where the data may be analyzed and/or distributed for further action.
In an exemplary, but not limiting embodiment, the diagnostic log sent to the remote computing device includes one minute worth of operational data collected both before and after the anomalous event.
In an exemplary, but not limiting embodiment, the diagnostic log sent to the remote computing device includes the following types of operational data: any user defined fault code that has been detected, any vehicle manufacturer defined fault code that has been detected, a position of the vehicle at the time the fault code is detected (if the vehicle includes a position sensor), trip start and end times, odometer value and source address, engine hours and source address, power take off (PTO) hours and source address, total fuel and source address, idle fuel and source address, PTO Fuel and source address, VIN and source address, and trip fuel economy calculated from odometer and total fuel values listed above. It should be understood the processor in the vehicle configured to assemble the vehicle data (including buffered operational data and data defining the anomaly that was detected) to be uploaded to the remote computing can be configured to always send the same types of data to the remote computing device for each anomaly detected, or the processor can be configured to send specific types of data to the remote computing device based on the anomaly detected. For example, assume that the following types of data are available (either in the buffered operational data, or accessible to the processor): brake temperature data, oil temperature data, fuel level data, engine hour data, coolant temperature data, and tire pressure data (such types of data being exemplary, and not limiting). In some embodiments, regardless of the type of anomaly detected, all available data types are sent to the remote computing device. In other embodiments, only a subset of the most likely relevant data is sent to the remote computing device (for example, if the anomaly deals with brakes, then brake temperature data and tire pressure data is sent, but other types of data having less to do with the vehicle braking system are not sent to the remote computing device).
In an exemplary, but not limiting embodiment, the diagnostic device in the vehicle can be remotely configured to redefine the parameters used to generate a diagnostic log. The diagnostic log generated by the diagnostic device includes two primary components; at least some of the operational data temporarily stored in the data buffer, and data defining the anomaly (in some embodiments, fault codes are used to define the anomaly). The diagnostic device can be remotely reconfigured to change an amount of buffered operational data acquired before the anomaly that is included in the diagnostic log. The diagnostic device can be remotely reconfigured to change an amount of buffered operational data acquired after the anomaly that is included in the diagnostic log. The diagnostic device can be remotely reconfigured to change the type of operational data that is included in the diagnostic log (in the terms of
The concepts disclosed herein also encompass embodiments in which a the data buffer, the data link to the remote computing device, and the processor for detecting the anomalous condition are incorporated into a diagnostic or telematics device also including a position tracking component (such as a GPS component, recognizing that other position sensing technologies can be similarly employed).
Buffer 108 can be implemented as a first in, first out buffer that temporarily stores the operational data generated by the vehicle in normal operation, which conventionally is generated and discarded rather than being saved. Buffer 108 is intended to be relatively small, and not intended to attempt to archive all of the operational data generated by the vehicle for an extended period of operation. Rather, buffer 108 is intended to store relatively small, but still useful amounts of operational data. In an exemplary, but not limiting embodiment, the amount of operational data stored in buffer 108 represents seconds or minutes of data, rather than hours or days of data. In an exemplary, but not limiting embodiment, buffer 108 is implemented using flash memory, of less than a gigabyte. With memory prices dropping regularly, more operational data could be stored. However, wireless transmission of data represents a cost, and in at least one embodiment a balance between the amount of data collected (more data leading to better diagnoses) and the amount of data wirelessly transmitted (less data being transmitted meaning less cost) is sought. Empirical studies have indicated that useful amounts of data can be obtained using a buffer of 256 MB or less and data transmissions of less than about 30 kilobytes per anomaly.
Processor 106 implements at least the function of using the data link to send the contents of the buffer (or at least a portion of the contents) to the remote computing device when an anomalous event occurs. In some embodiments, processor 106 implements additional functions. In at least one embodiment, processor 106 analyzes the operational data to detect specific conditions that have been predetermined to represent an anomaly that should trigger the transmission of the buffer to the remote computing device. In at least some embodiments, the data link can be used to enable changes to be made to the logic used by the processor to determine what represents an anomaly.
In some embodiments, a different processor (i.e., not processor 106) in the vehicle is determining when an anomalous condition occurs. For example, any processor in a vehicle that generates a fault code based on specific operational data can be configured to send that fault code to processor 106, so that processor 106 responds by using the data link to send the fault code and the contents of the data buffer to the remote computing device.
As noted above, block 114 refers to the function of applying specific logic (i.e., one or more filters) to reduce an amount of data that might otherwise be sent to the remote computing device. In some embodiments, such logic is implemented to reduce an amount of buffered operational data conveyed to a remote computing device for analysis, as a cost control function. The concepts disclosed herein encompass a variety of filtering techniques that can be used to determine if a particular condition exists, such that when such a predefined condition exists, the buffered operational data will not be sent to the remote computing device, even if an anomalous condition is detected. One such filtering technique is based on detecting (using GPS component 110) a location of the vehicle at startup. If that location corresponds to a repair facility or service center, then the automated buffered operational data transmission functionality can be turned off (as the vehicle will likely be coupled to a diagnostic device at the service center, such that the remote diagnostic function is not needed). Such locations can be stored in a memory at the vehicle, or more preferably, the vehicle can communicate its location at start up to the remote computing device, which has access to the locations of such service centers. The remote computing device then determines if processor 106 should be instructed (via data link 104) not to transmit the buffered operational data to the remote computing device even if an anomaly is detected. Another such filter technique is based on analyzing whether the same anomalous conditions are being detected in about the same geographic position and/or within a predefined time period (which can indicate that the vehicle is being driven around a service facility trying to replicate an intermittent fault). In one embodiment, controller 106 is configured to not to transmit the buffered operational data to the remote computing device even if an anomaly is detected, if the vehicle remains within a relatively small geographical area (i.e., within five miles or so, such an area being exemplary and not limiting) in a predefined period of time (such as 24 hours, again recognizing that the specified interval is exemplary, and not limiting). Another technique that can be used to reduce the amount of buffered operational data that is wirelessly conveyed to a remote computing device is to ensure that duplicate information, related to the same anomalous condition, is not sent time and time again. In at least one embodiment, an occurrence counter in a diagnostic trouble code (DTC) generated in the vehicle is analyzed to determine if a particular fault code is a reoccurring event that can be ignored to minimize an amount of data that is transmitted wirelessly to the remote computing device for analysis. Processor 106 can be configured to send repeating fault codes/anomalies, when the reoccurring anomaly is accompanied by a new anomaly.
The concepts disclosed herein also encompass embodiments in which processor 106 is configured to either ignore operational data generated during an initial startup of the vehicle (referred to as settling time). During initial vehicle startup, as various components in the vehicle initialize, what otherwise might appear to be anomalous operating conditions may briefly exist. In general, such conditions rapidly disappear as vehicle components operate for more than several seconds. In an exemplary, but not limiting embodiment, controller 106 is configured to ignore, or not to store, about the first ten seconds of operational data that is generated upon vehicle startup. Vehicle startup can also present the unusual condition where the data buffer may not have filled to capacity. Assume the data buffer is configured to store 90 seconds of operational data, and an anomalous condition is detected 45 seconds after operational data began to fill up the buffer. Controller 106 can be configured to send only the 45 seconds present in the buffer, or can be configured to not transmit any portion of the buffer, if the buffer is not full, depending on the logic one wishes to employ. Partial data is likely to be more useful than no data, so the former technique is more likely to be implemented.
As noted above, block 118 refers to the function of using the data link to send lamp escalation data to the remote computing device after buffered operational data corresponding to a previously detected anomalous condition has been sent, in the event that an indicator lamp has changed status since the anomalous event. In at least one embodiment, processor 106 is configured to monitor dashboard lamps, to determine if any warning indicator lamps on the vehicle dashboard change in response to the recently detected anomalous condition. When such a lamp status change (i.e., from off to on, or from amber/yellow to red, indicating an escalation) is detected, processor 106 is configured to use data link 104 to send information defining the change in the lamp status to the remote computing device. Depending on the vehicle, the fault code data may include lamp status, but that information is not necessarily accurate, and even when accurate the buffered operational data may not capture a change in lamp status that occurs at a time point after the anomaly has occurred. In general, this lamp escalation logic pertains only to the same fault or anomaly. If there were a fault code such as (SrcAddr=3, SPN=111, FMI=1 and lamp state=all off) followed by the same SrcAddr, SPN, FMI and a different lamp state, then the lamp escalation logic component in processor 106 would send the new lamp state to the remote server/computing device via the data link. If the SrcAddr, SPN, FMI are different, then a new fault entry is created and buffered operational data pertaining to the new fault/anomaly and data defining the new anomaly are sent to the remote computing device.
It should be recognized that processor 106 can be implemented via hardware (such as an application specific integrated circuit implementing fixed logical steps), or a controller implementing software (i.e., a series of logical steps). Processor 106 can be a single component, or different functions described above that are implemented by processor 106 can be distributed across multiple processors.
In at least one embodiment, processor 106 is configured to include data from GPS component 110 with the buffered operational data, when such data is conveyed to the remote computing device via data link 104.
Thus, the concepts disclosed herein encompass at least one embodiment implemented as a system in which diagnostic units such as those shown in
The concepts disclosed herein further specifically encompass the following.
A first telematics unit for use in a vehicle, the telematics unit comprising: (a) a first data port for receiving operational data from the vehicle during operation of the vehicle; (b) a first in, first out buffer in which operational data is temporarily stored during operation of the vehicle; (c) a data link for wirelessly conveying data from the vehicle to a remote computing device; and (d) a processor configured to use the data link to send operational data from the buffer to the remote computing device when an anomalous condition is detected at the vehicle.
The first telematics unit described above, where the processor is configured to include data defining the anomalous condition with the buffered operational data that is sent to the remote computing device.
The first telematics unit described above, where the processor is configured to send a predefined additional quantity of operational data collected after the anomaly is detected to the remote computing device, along with buffered operational data collected before the anomaly is detected.
The first telematics unit described above, where the processor is configured to analyze the operational data entering the buffer to detect the anomalous condition.
The first telematics unit described above, where the processor is configured to receive a notification from a different vehicle processor that is configured to detect the anomalous condition.
The first telematics unit described above, where the processor is configured to ignore anomalous conditions occurring during a predefined settling period after vehicle startup.
The first telematics unit described above, where the processor is configured to ignore anomalous conditions that have already been reported to the remote computing device.
The first telematics unit described above, where the processor is configured to send buffered operational data to the remote computing device based on a trigger signal received from a vehicle operator, even if an anomalous condition has not been detected.
The first telematics unit described above, where after buffered operational data has been sent to the remote computing device in response to the detection of an anomalous condition, the processor is configured to monitor a warning lamp status associated with the anomaly, and to use the data link to send lamp escalation data to the remote computing device when that warning lamp changes condition.
A second telematics unit for use in a vehicle, the telematics unit comprising: (a) a positioning sensing component for collecting geographical position data from the vehicle during vehicle operation, the geographical position data being time indexed; (b) a data port for receiving operational data from the vehicle during operation of the vehicle; (c) a first in, first out buffer in which operational data is temporarily stored during operation of the vehicle; (d) a data link for wirelessly conveying data from the vehicle to a remote computing device; and (e) a processor configured to use the data link to send operational data from the buffer to the remote computing device when an anomalous condition is detected at the vehicle.
The second telematics unit described above, where the processor is configured to include data defining the anomalous condition with the buffered operational data that is sent to the remote computing device.
The second telematics unit described above, where the processor is configured to send a predefined additional quantity of operational data collected after the anomaly is detected to the remote computing device, along with buffered operational data collected before the anomaly is detected.
The second telematics unit described above, where the processor is configured to include geographical position data defining a location of the vehicle when the anomalous condition is detected with the buffered operational data that is sent to the remote computing device.
The second telematics unit described above, where the processor is configured to analyze the operational data entering the buffer to detect the anomalous condition.
The second telematics unit described above, where the processor is configured to receive a notification from a different vehicle processor configured to detect the anomalous condition.
The second telematics unit described above, where the processor is configured to ignore anomalous conditions occurring during a predefined settling period after vehicle startup.
The second telematics unit described above, where the processor is configured to determine a position of the vehicle at startup, and ignore anomalous conditions occurring while the vehicle's position is proximate to a known location where anomalous conditions should be ignored.
The second telematics unit described above, where the processor is configured to determine a position of the vehicle at startup, then send a request to the remote computing device to determine if the position of the vehicle is proximate to a known location where anomalous conditions should be ignored, and if so, the processor is configured to ignore anomalous conditions occurring proximate that location.
The second telematics unit described above, where the processor is configured to ignore anomalous conditions that have already been reported to the remote computing device.
The second telematics unit described above, where the processor is configured to send buffered operational data to the remote computing device based on a trigger signal received from a vehicle operator, even if an anomalous condition has not been detected.
The second telematics unit described above, where after buffered operational data has been sent to the remote computing device in response to the detection of an anomalous condition, the processor is configured to monitor a warning lamp status associated with the anomaly, and to use the data link to send lamp escalation data to the remote computing device when that warning lamp changes condition.
A system for detecting an anomalous condition with a vehicle and diagnosing that anomalous condition: (a) a vehicle comprising: (i) at least one sensor for generating vehicle operational data; (ii) a first in, first out buffer in which operational data is temporarily stored during operation of the vehicle; (iii) a data link for wirelessly conveying data from the vehicle to a remote location; and (iv) a processor configured to use the data link to send operational data from the buffer to the remote location when an anomalous condition is detected at the vehicle; and (b) a computing device at the remote location, the computing device being configured to implement the function of analyzing the buffered operational data received from the vehicle to diagnose the anomalous condition.
The system described above, where the computing device at the remote location is configured to automatically alert the operator of the vehicle about the diagnosis. Such an alert can be conveyed using at least one of a text message, an email message, and an automated telephone message.
The system described above, where the processor in the vehicle is configured to include position data defining a location of the vehicle when the anomaly is detected with the data being conveyed to the remote computing device.
The system described above, where the processor in the vehicle is configured to ignore anomalies, and thus not send data to the remote computing device, for a predetermined period of time following vehicle startup.
The system described above, where the processor in the vehicle is configured to ignore anomalies when a location of the vehicle at startup corresponds to a predefined location. In some embodiments, each such predefined location is stored in the vehicle, while in other embodiments, upon startup the processor communicates with the remote computing device to determine if the vehicle's present location indicates that anomalies should be ignored.
The system described above, where the processor in the vehicle is configured to ignore anomalies that are repetitive.
The system described above, where the processor in the vehicle is configured to monitor lamp status associated with a previously detected anomaly, and if the lamp status of a warning lamp associated with that anomaly changes, the processor is configured to convey lamp escalation data to the remote computing device.
The system described above, where the processor in the vehicle is configured to convey buffered operational data to the remote computing device based on an operator trigger, even if no anomaly has been detected.
The system described above, where the computing device at the remote location is configured to automatically schedule a repair of the vehicle.
The system described above, where the computing device at the remote location is configured to automatically schedule a repair of the vehicle based on a current location of the vehicle using location data received from the vehicle with the buffered operational data.
The system described above, where the computing device at the remote location is configured to automatically order parts required to repair the vehicle.
The system described above, where the computing device at the remote location is configured to receive and store position data from the vehicle during normal operation of the vehicle, and when buffered operational data is received from the vehicle, the computing device automatically forwards the buffered operational data to a computing device operated by a different entity, the different entity performing the diagnosis. In such a system, the buffered operational data received by the first entity may require reformatting to a different data format, such as XML, before sending the data to the second entity for analysis.
A method for detecting an anomalous condition with a vehicle and diagnosing that anomalous condition, including the steps of: (a) storing operational data generated while operating a vehicle in a first in, first out buffer during operation of the vehicle; (b) detecting an anomalous condition; (c) using a data link to wirelessly convey buffered operational data from the vehicle to a remote location; and (d) analyzing the buffered operational data at the remote location to diagnose the anomalous condition.
The method described above, where a computing device at the remote location is configured to automatically alert the operator of the vehicle about the diagnosis. Such an alert can be conveyed using at least one of a text message, an email message, and an automated telephone message.
The method described above, where a processor in the vehicle is configured to include position data defining a location of the vehicle when the anomaly is detected with the data being conveyed to the remote location.
The method described above, where a processor in the vehicle is configured to ignore anomalies, and thus not send data to the remote location, for a predetermined period of time following vehicle startup.
The method described above, where a processor in the vehicle is configured to ignore anomalies when a location of the vehicle at startup corresponds to a predefined location. In some embodiments, each such predefined location is stored in the vehicle, while in other embodiments, upon startup the processor communicates with a remote computing device to determine if the vehicle's present location indicates that anomalies should be ignored.
The method described above, where a processor in the vehicle is configured to ignore anomalies that are repetitive.
The method described above, where a processor in the vehicle is configured to monitor lamp status associated with a previously detected anomaly, and if the lamp status of a warning lamp associated with that anomaly changes, the processor is configured to convey lamp escalation data to the remote computing device.
The method described above, where a processor in the vehicle is configured to convey buffered operational data to the remote computing device based on an operator trigger, even if no anomaly has been detected.
The method described above, where a computing device at the remote location is configured to automatically schedule a repair of the vehicle.
The method described above, where a computing device at the remote location is configured to automatically schedule a repair of the vehicle based on a current location of the vehicle using location data received from the vehicle with the buffered operational data.
The method described above, where a computing device at the remote location is configured to automatically order parts required to repair the vehicle.
The method described above, where a computing device at the remote location is configured to receive and store position data from the vehicle during normal operation of the vehicle, and when buffered operational data is received from the vehicle, the computing device automatically forwards the buffered operational data to a computing device operated by a different entity, the different entity performing the diagnosis. In such a method, the buffered operational data received by the first entity may require reformatting to a different data format, such as XML, before sending the data to the second entity for analysis.
Although the concepts disclosed herein have been described in connection with the preferred form of practicing them and modifications thereto, those of ordinary skill in the art will understand that many other modifications can be made thereto within the scope of the claims that follow. Accordingly, it is not intended that the scope of these concepts in any way be limited by the above description, but instead be determined entirely by reference to the claims that follow.
This application is a continuation of U.S. application Ser. No. 13/219,467 filed on Aug. 26, 2011, which claims priority from U.S. Provisional Application Ser. No. 61/377,865, filed on Aug. 27, 2010, the benefit of the filing date of which is hereby claimed under 35 U.S.C. § 119(e). The Ser. No. 13/219,467 application is further a continuation-in-part of U.S. application Ser. No. 12/956,961, filed on Nov. 30, 2010, U.S. application Ser. No. 13/157,184, filed on Jun. 9, 2011, now U.S. Pat. No. 10,600,096, and U.S. application Ser. No. 13/157,203, also filed on Jun. 9, 2011, the benefits of the filing dates of which are hereby claimed under 35 U.S.C. § 120.
Number | Name | Date | Kind |
---|---|---|---|
3573620 | Ashley et al. | Apr 1971 | A |
3990067 | Va et al. | Nov 1976 | A |
4025791 | Lennington et al. | May 1977 | A |
4092718 | Wendt | May 1978 | A |
4258421 | Juhasz et al. | Mar 1981 | A |
4263945 | Va | Apr 1981 | A |
4325057 | Bishop | Apr 1982 | A |
4469149 | Walkey et al. | Sep 1984 | A |
4602127 | Neely et al. | Jul 1986 | A |
4658371 | Walsh et al. | Apr 1987 | A |
4763356 | Day et al. | Aug 1988 | A |
4799162 | Shinkawa et al. | Jan 1989 | A |
4804937 | Barbiaux et al. | Feb 1989 | A |
4846233 | Fockens | Jul 1989 | A |
4897792 | Hosoi | Jan 1990 | A |
4934419 | Lamont et al. | Jun 1990 | A |
4935195 | Palusamy et al. | Jun 1990 | A |
5058044 | Stewart et al. | Oct 1991 | A |
5068656 | Sutherland | Nov 1991 | A |
5072380 | Randelman et al. | Dec 1991 | A |
5120942 | Holland et al. | Jun 1992 | A |
5128651 | Heckart | Jul 1992 | A |
5204819 | Ryan | Apr 1993 | A |
5206643 | Eckelt | Apr 1993 | A |
5243323 | Rogers | Sep 1993 | A |
5321629 | Shirata et al. | Jun 1994 | A |
5337003 | Carmichael et al. | Aug 1994 | A |
5359522 | Ryan | Oct 1994 | A |
5394136 | Lammers et al. | Feb 1995 | A |
5399844 | Holland | Mar 1995 | A |
5400018 | Scholl et al. | Mar 1995 | A |
5442553 | Parrillo | Aug 1995 | A |
5459304 | Eisenmann | Oct 1995 | A |
5459660 | Berra | Oct 1995 | A |
5479479 | Braitberg et al. | Dec 1995 | A |
5488352 | Jasper | Jan 1996 | A |
5499182 | Ousborne | Mar 1996 | A |
5541845 | Klein | Jul 1996 | A |
5546305 | Kondo | Aug 1996 | A |
5557254 | Johnson et al. | Sep 1996 | A |
5557268 | Hughes et al. | Sep 1996 | A |
5572192 | Berube | Nov 1996 | A |
5585552 | Heuston et al. | Dec 1996 | A |
5594650 | Shah et al. | Jan 1997 | A |
5596501 | Comer et al. | Jan 1997 | A |
5598534 | Haas | Jan 1997 | A |
5600323 | Boschini | Feb 1997 | A |
5610596 | Petitclerc | Mar 1997 | A |
5623258 | Dorfman | Apr 1997 | A |
5629678 | Gargano et al. | May 1997 | A |
5671141 | Smith | Sep 1997 | A |
5671158 | Fournier et al. | Sep 1997 | A |
5680328 | Skorupski et al. | Oct 1997 | A |
5719771 | Buck | Feb 1998 | A |
5731893 | Dominique | Mar 1998 | A |
5732074 | Spaur et al. | Mar 1998 | A |
5742915 | Stafford | Apr 1998 | A |
5745049 | Akiyama et al. | Apr 1998 | A |
5758299 | Sandborg et al. | May 1998 | A |
5758300 | Abe | May 1998 | A |
5781871 | Mezger et al. | Jul 1998 | A |
5794164 | Beckert et al. | Aug 1998 | A |
5808565 | Matta et al. | Sep 1998 | A |
5809437 | Breed | Sep 1998 | A |
5815071 | Doyle | Sep 1998 | A |
5835871 | Smith et al. | Nov 1998 | A |
5838251 | Brinkmeyer et al. | Nov 1998 | A |
5839112 | Schreitmueller et al. | Nov 1998 | A |
5862223 | Walker et al. | Jan 1999 | A |
5867404 | Bryan | Feb 1999 | A |
5874891 | Lowe | Feb 1999 | A |
5884202 | Arjomand | Mar 1999 | A |
5890061 | Timm et al. | Mar 1999 | A |
5890520 | Johnson | Apr 1999 | A |
5913180 | Ryan | Jun 1999 | A |
5920846 | Storch et al. | Jul 1999 | A |
5922037 | Potts | Jul 1999 | A |
5923572 | Pollock | Jul 1999 | A |
5942753 | Dell | Aug 1999 | A |
5956259 | Hartsell et al. | Sep 1999 | A |
5974483 | Ray et al. | Oct 1999 | A |
5995898 | Tuttle | Nov 1999 | A |
6009355 | Obradovich et al. | Dec 1999 | A |
6009363 | Beckert et al. | Dec 1999 | A |
5223844 | Mansel et al. | Jan 2000 | A |
6016795 | Ohki | Jan 2000 | A |
6024142 | Bates | Feb 2000 | A |
6025776 | Matsuura | Feb 2000 | A |
6043661 | Gutierrez | Mar 2000 | A |
6054950 | Fontana | Apr 2000 | A |
6061614 | Carrender et al. | May 2000 | A |
6064299 | Lesesky et al. | May 2000 | A |
6070156 | Hartsell | May 2000 | A |
6078255 | Dividock et al. | Jun 2000 | A |
6084870 | Wooten et al. | Jul 2000 | A |
6092021 | Ehlbeck et al. | Jul 2000 | A |
6107915 | Reavell et al. | Aug 2000 | A |
6107917 | Carrender et al. | Aug 2000 | A |
6112152 | Tuttle | Aug 2000 | A |
6127947 | Uchida et al. | Oct 2000 | A |
6128551 | Davis et al. | Oct 2000 | A |
6128959 | McGovern et al. | Oct 2000 | A |
6169938 | Hartsell | Jan 2001 | B1 |
6169943 | Simon et al. | Jan 2001 | B1 |
6181994 | Colson et al. | Jan 2001 | B1 |
6182275 | Beelitz et al. | Jan 2001 | B1 |
6199099 | Gershman et al. | Mar 2001 | B1 |
6202008 | Beckert et al. | Mar 2001 | B1 |
6208948 | Klingler et al. | Mar 2001 | B1 |
6236911 | Kruger | May 2001 | B1 |
6240365 | Bunn | May 2001 | B1 |
6246688 | Angwin et al. | Jun 2001 | B1 |
6253129 | Jenkins et al. | Jun 2001 | B1 |
6256579 | Tanimoto | Jul 2001 | B1 |
6259358 | Fjordbotten | Jul 2001 | B1 |
6263268 | Nathanson | Jul 2001 | B1 |
6263273 | Henneken et al. | Jul 2001 | B1 |
6263276 | Yokoyama et al. | Jul 2001 | B1 |
6278936 | Jones | Aug 2001 | B1 |
6285953 | Harrison et al. | Sep 2001 | B1 |
6295492 | Lang et al. | Sep 2001 | B1 |
6330499 | Chou et al. | Dec 2001 | B1 |
6338152 | Fera et al. | Jan 2002 | B1 |
6339745 | Novik | Jan 2002 | B1 |
6362730 | Razavi et al. | Mar 2002 | B2 |
6370454 | Moore | Apr 2002 | B1 |
6374176 | Schmier et al. | Apr 2002 | B1 |
6380951 | Petchenkine et al. | Apr 2002 | B1 |
6396413 | Hines et al. | May 2002 | B2 |
6408232 | Cannon et al. | Jun 2002 | B1 |
6411203 | Lesesky et al. | Jun 2002 | B1 |
6411891 | Jones | Jun 2002 | B1 |
6417760 | Mabuchi et al. | Jul 2002 | B1 |
6438472 | Tano et al. | Aug 2002 | B1 |
6450411 | Rash et al. | Sep 2002 | B1 |
6456039 | Lauper et al. | Sep 2002 | B1 |
6502030 | Hilleary | Dec 2002 | B2 |
6505106 | Lawrence et al. | Jan 2003 | B1 |
6507810 | Razavi et al. | Jan 2003 | B2 |
6526335 | Treyz et al. | Feb 2003 | B1 |
6529723 | Bentley | Mar 2003 | B1 |
6529808 | Diem | Mar 2003 | B1 |
6539296 | Diaz et al. | Mar 2003 | B2 |
6578005 | Lesaint et al. | Jun 2003 | B1 |
6587768 | Chene et al. | Jul 2003 | B2 |
6594579 | Lowrey et al. | Jul 2003 | B1 |
6594621 | Meeker | Jul 2003 | B1 |
6597973 | Barich et al. | Jul 2003 | B1 |
6604033 | Banet et al. | Aug 2003 | B1 |
6608554 | Lesesky et al. | Aug 2003 | B2 |
6609051 | Fiechter et al. | Aug 2003 | B2 |
6609082 | Wagner | Aug 2003 | B2 |
6611740 | Lowrey et al. | Aug 2003 | B2 |
6614392 | Howard | Sep 2003 | B2 |
6615184 | Hicks | Sep 2003 | B1 |
6616036 | Streicher et al. | Sep 2003 | B2 |
6621452 | Knockeart et al. | Sep 2003 | B2 |
6631322 | Arthur et al. | Oct 2003 | B1 |
6636790 | Lightner et al. | Oct 2003 | B1 |
6664897 | Pape et al. | Dec 2003 | B2 |
6671646 | Manegold et al. | Dec 2003 | B2 |
6679110 | Oka et al. | Jan 2004 | B2 |
6680694 | Knockeart et al. | Jan 2004 | B1 |
6708113 | Vo et al. | Mar 2004 | B1 |
6714859 | Jones | Mar 2004 | B2 |
6727818 | Wildman et al. | Apr 2004 | B1 |
6732031 | Lightner et al. | May 2004 | B1 |
6732032 | Banet et al. | May 2004 | B1 |
6744352 | Lesesky et al. | Jun 2004 | B2 |
6754183 | Razavi et al. | Jun 2004 | B1 |
6754570 | Iihoshi et al. | Jun 2004 | B2 |
6768994 | Howard et al. | Jul 2004 | B1 |
6801841 | Tabe | Oct 2004 | B2 |
6804606 | Jones | Oct 2004 | B2 |
6804626 | Manegold et al. | Oct 2004 | B2 |
6816762 | Hensey et al. | Nov 2004 | B2 |
6834259 | Markwitz et al. | Dec 2004 | B1 |
6856820 | Kolls | Feb 2005 | B1 |
6876642 | Adams et al. | Apr 2005 | B1 |
6879894 | Lightner et al. | Apr 2005 | B1 |
6880390 | Emord | Apr 2005 | B2 |
6894617 | Richman | May 2005 | B2 |
6899151 | Latka et al. | May 2005 | B1 |
6904359 | Jones | Jun 2005 | B2 |
6909947 | Douros et al. | Jun 2005 | B2 |
6924750 | Flick | Aug 2005 | B2 |
6928348 | Lightner et al. | Aug 2005 | B1 |
6946953 | Lesesky et al. | Sep 2005 | B2 |
6952645 | Jones | Oct 2005 | B1 |
6954689 | Hanson et al. | Oct 2005 | B2 |
6957133 | Hunt et al. | Oct 2005 | B1 |
6959327 | Vogl et al. | Oct 2005 | B1 |
6968259 | Simons et al. | Nov 2005 | B2 |
6972668 | Schauble | Dec 2005 | B2 |
6988033 | Lowrey et al. | Jan 2006 | B1 |
7022018 | Koga | Apr 2006 | B2 |
7027955 | Markwitz et al. | Apr 2006 | B2 |
7048185 | Hart | May 2006 | B2 |
7068301 | Thompson | Jun 2006 | B2 |
7096193 | Beaudoin et al. | Aug 2006 | B1 |
7103460 | Breed | Sep 2006 | B1 |
7113127 | Banet et al. | Sep 2006 | B1 |
7117121 | Brinton et al. | Oct 2006 | B2 |
7142099 | Ross et al. | Nov 2006 | B2 |
7155199 | Zalewski et al. | Dec 2006 | B2 |
7155322 | Nakahara et al. | Dec 2006 | B2 |
7171372 | Daniel et al. | Jan 2007 | B2 |
7174243 | Lightner et al. | Feb 2007 | B1 |
7174277 | Vock et al. | Feb 2007 | B2 |
7188073 | Tam et al. | Mar 2007 | B1 |
7219066 | Parks et al. | May 2007 | B2 |
7225065 | Hunt et al. | May 2007 | B1 |
7228211 | Lowrey et al. | Jun 2007 | B1 |
7254516 | Case et al. | Aug 2007 | B2 |
7343252 | Wiens | Mar 2008 | B2 |
7362229 | Brinton et al. | Apr 2008 | B2 |
7401025 | Lokitz | Jul 2008 | B1 |
7408480 | Woo et al. | Aug 2008 | B2 |
7421321 | Breed et al. | Sep 2008 | B2 |
7421334 | Dahlgren et al. | Sep 2008 | B2 |
7447574 | Washicko et al. | Nov 2008 | B1 |
7477968 | Lowrey et al. | Jan 2009 | B1 |
7480551 | Lowrey et al. | Jan 2009 | B1 |
7490086 | Joao | Feb 2009 | B2 |
7500151 | Englert et al. | Mar 2009 | B2 |
7523159 | Williams et al. | Apr 2009 | B1 |
7532962 | Lowrey et al. | May 2009 | B1 |
7532963 | Lowrey et al. | May 2009 | B1 |
7596437 | Hunt et al. | Sep 2009 | B1 |
7604169 | Demere | Oct 2009 | B2 |
7627546 | Moser et al. | Dec 2009 | B2 |
7640185 | Giordano et al. | Dec 2009 | B1 |
7650210 | Breed | Jan 2010 | B2 |
7672756 | Breed | Mar 2010 | B2 |
7672763 | Hunt et al. | Mar 2010 | B1 |
7680594 | Cabral et al. | Mar 2010 | B2 |
7729977 | Xiao et al. | Jun 2010 | B2 |
7778752 | Hunt et al. | Aug 2010 | B1 |
7783507 | Schick et al. | Aug 2010 | B2 |
7844500 | Ran | Nov 2010 | B2 |
7849149 | Habaguchi et al. | Dec 2010 | B2 |
7869906 | Louch et al. | Jan 2011 | B2 |
7933841 | Schmeyer et al. | Apr 2011 | B2 |
7953530 | Pederson et al. | May 2011 | B1 |
7983960 | Rigole | Jul 2011 | B2 |
8099308 | Uyeki | Jan 2012 | B2 |
8131417 | Picard | Mar 2012 | B2 |
8251702 | Marks | Aug 2012 | B2 |
8630765 | Chen | Jan 2014 | B2 |
8694328 | Gormley | Apr 2014 | B1 |
20010037281 | French et al. | Nov 2001 | A1 |
20010039508 | Nagler et al. | Nov 2001 | A1 |
20010047283 | Melick et al. | Nov 2001 | A1 |
20010048222 | Mitchell | Dec 2001 | A1 |
20010053983 | Reichwein et al. | Dec 2001 | A1 |
20020016655 | Joao | Feb 2002 | A1 |
20020022979 | Whipp et al. | Feb 2002 | A1 |
20020032597 | Chanos | Mar 2002 | A1 |
20020038233 | Shubov et al. | Mar 2002 | A1 |
20020059046 | Mifune et al. | May 2002 | A1 |
20020065698 | Schick et al. | May 2002 | A1 |
20020082912 | Batachia et al. | Jun 2002 | A1 |
20020087522 | MacGregor et al. | Jul 2002 | A1 |
20020107833 | Kerkinni | Aug 2002 | A1 |
20020107873 | Winkler et al. | Aug 2002 | A1 |
20020111725 | Burge | Aug 2002 | A1 |
20020111897 | Davis | Aug 2002 | A1 |
20020120696 | Mousseau et al. | Aug 2002 | A1 |
20020133273 | Lowrey | Sep 2002 | A1 |
20020133275 | Thibault | Sep 2002 | A1 |
20020133374 | Agoni et al. | Sep 2002 | A1 |
20020150050 | Nathanson | Oct 2002 | A1 |
20020160793 | Pradhan et al. | Oct 2002 | A1 |
20020177926 | Lockwood et al. | Nov 2002 | A1 |
20020178147 | Arroyo et al. | Nov 2002 | A1 |
20020183972 | Enck et al. | Dec 2002 | A1 |
20030028297 | Iihoshi et al. | Feb 2003 | A1 |
20030030550 | Talbot | Feb 2003 | A1 |
20030055666 | Roddy et al. | Mar 2003 | A1 |
20030097218 | Borugian | May 2003 | A1 |
20030120745 | Katagishi et al. | Jun 2003 | A1 |
20030233278 | Marshall | Dec 2003 | A1 |
20040049450 | Lussler | Mar 2004 | A1 |
20040139047 | Rechsteiner et al. | Jul 2004 | A1 |
20040153356 | Lockwood | Aug 2004 | A1 |
20040199412 | McCauley | Oct 2004 | A1 |
20040236596 | Chowdhary et al. | Nov 2004 | A1 |
20040243464 | Beck | Dec 2004 | A1 |
20050038688 | Collins et al. | Feb 2005 | A1 |
20050065853 | Ferreira | Mar 2005 | A1 |
20050103874 | Erdman, Jr. | May 2005 | A1 |
20050125117 | Breed | Jun 2005 | A1 |
20050149250 | Isaac | Jul 2005 | A1 |
20050222756 | Davis et al. | Oct 2005 | A1 |
20050228707 | Hendrickson | Oct 2005 | A1 |
20050240459 | Cox | Oct 2005 | A1 |
20050273250 | Hamilton et al. | Dec 2005 | A1 |
20050288830 | Reeser et al. | Dec 2005 | A1 |
20060015404 | Tran | Jan 2006 | A1 |
20060025966 | Kanamaru | Feb 2006 | A1 |
20060052921 | Bodin et al. | Mar 2006 | A1 |
20060089767 | Sowa | Apr 2006 | A1 |
20060100919 | Levine | May 2006 | A1 |
20060129309 | Alewine et al. | Jun 2006 | A1 |
20060184381 | Rice et al. | Aug 2006 | A1 |
20060195365 | Karabetsos | Aug 2006 | A1 |
20060232406 | Filibeck | Oct 2006 | A1 |
20060282364 | Berg | Dec 2006 | A1 |
20070050193 | Larson | Mar 2007 | A1 |
20070069947 | Banet et al. | Mar 2007 | A1 |
20070100519 | Engel | May 2007 | A1 |
20070124283 | Gotts et al. | May 2007 | A1 |
20070179709 | Doyle | Aug 2007 | A1 |
20070203769 | Thomas | Aug 2007 | A1 |
20070208630 | Chatter et al. | Sep 2007 | A1 |
20070241874 | Okpysh et al. | Oct 2007 | A1 |
20070244797 | Hinson et al. | Oct 2007 | A1 |
20070244800 | Lee et al. | Oct 2007 | A1 |
20070266180 | Mitchell et al. | Nov 2007 | A1 |
20080040129 | Cauwels et al. | Feb 2008 | A1 |
20080049123 | Gloudemans et al. | Feb 2008 | A1 |
20080119981 | Chen | May 2008 | A1 |
20080140571 | Inbarajan | Jun 2008 | A1 |
20080154489 | Kaneda et al. | Jun 2008 | A1 |
20080154712 | Wellman | Jun 2008 | A1 |
20080167758 | Louch | Jul 2008 | A1 |
20080177653 | Famolari et al. | Jul 2008 | A1 |
20080189199 | Sarid et al. | Aug 2008 | A1 |
20080228619 | Locker et al. | Sep 2008 | A1 |
20080249813 | Schmeyer | Oct 2008 | A1 |
20080263016 | Lokitz | Oct 2008 | A1 |
20080288830 | Marinucci | Nov 2008 | A1 |
20080294556 | Anderson | Nov 2008 | A1 |
20080306960 | Poechmueller et al. | Dec 2008 | A1 |
20080319665 | Berkobin et al. | Dec 2008 | A1 |
20090062978 | Picard | Mar 2009 | A1 |
20090069999 | Bos | Mar 2009 | A1 |
20090089149 | Lerner et al. | Apr 2009 | A1 |
20090150023 | Grau | Jun 2009 | A1 |
20090177350 | Williams et al. | Jul 2009 | A1 |
20090192854 | Pietrucha et al. | Jul 2009 | A1 |
20090222200 | Link et al. | Sep 2009 | A1 |
20090254240 | Olsen et al. | Oct 2009 | A1 |
20090276115 | Chen | Nov 2009 | A1 |
20100010705 | Duddle et al. | Jan 2010 | A1 |
20100036595 | Coy et al. | Feb 2010 | A1 |
20100088127 | Betancourt et al. | Apr 2010 | A1 |
20100106534 | Robinson et al. | Apr 2010 | A1 |
20100114423 | Boss et al. | May 2010 | A1 |
20100217680 | Fusz et al. | Aug 2010 | A1 |
20100257104 | Bundy | Oct 2010 | A1 |
20110012720 | Hirschfeld | Jan 2011 | A1 |
20110118934 | Lowrey et al. | May 2011 | A1 |
20110225096 | Cho et al. | Sep 2011 | A1 |
20110302046 | Arian | Dec 2011 | A1 |
20120028680 | Breed | Feb 2012 | A1 |
20120130844 | Picard | May 2012 | A1 |
20120136527 | McQuade et al. | May 2012 | A1 |
20120136743 | McQuade et al. | May 2012 | A1 |
20120136802 | McQuade et al. | May 2012 | A1 |
20160071338 | McQuade et al. | Mar 2016 | A1 |
20160342456 | McQuade et al. | Nov 2016 | A1 |
20160343177 | McQuade et al. | Nov 2016 | A1 |
20160350985 | McQuade et al. | Dec 2016 | A1 |
20170076344 | McQuade et al. | Mar 2017 | A1 |
20200043068 | McQuade et al. | Feb 2020 | A1 |
Number | Date | Country |
---|---|---|
2138378 | Nov 1994 | CA |
2 388 572 | May 2001 | CA |
2 326 892 | Jun 2005 | CA |
0 814 447 | Sep 2002 | EP |
0 926 020 | Sep 2002 | EP |
0 755 039 | Dec 2002 | EP |
1 005 627 | Oct 2003 | EP |
1 027 792 | Jan 2004 | EP |
1 067 498 | May 2004 | EP |
1 271 374 | May 2004 | EP |
2 116 968 | Nov 2009 | EP |
2007-102336 | Apr 2007 | JP |
2008-217341 | Sep 2008 | JP |
10-2007-0006134 | Jan 2007 | KR |
10-2009-0063024 | Jun 2009 | KR |
10-2010-0023434 | Mar 2010 | KR |
10-0987319 | Oct 2010 | KR |
9726750 | Jul 1997 | WO |
9803952 | Jan 1998 | WO |
9830920 | Jul 1998 | WO |
03023550 | Mar 2003 | WO |
2007033311 | Mar 2007 | WO |
2007027702 | Mar 2007 | WO |
2007092711 | Aug 2007 | WO |
Entry |
---|
H. Schweppe et al. “Flexible On-Board Stream Processing for Automotive Sensor Data”, IEEE Transactions on Industrial Informatics, vol. 6, No. 1, pp. 81-92, Feb. 2010. doi: 10.1109/TII.2009.2037145 (Year: 2010). |
“Tracking out of route: software helps fleets compare planned routes to actual miles. (Technology),” Commercial Carrier Journal 162(10):S46(2), 2005. (4 pages). |
Albright, “Indiana embarks on ambitious RFID roll out—Amusement ride inspection just the first of many applications,” Frontline Solutions, May 20, 2002, 2 pages. |
Anonymous, “Transit agency builds GIS to plan bus routes,” American City & County 118(4):14-16, 2003. |
Black, “OBD II Up Close,” Motor, pp. 28-34, Jul. 1998. |
Business Wire, “MIRAS GPS vehicle tracking using the Internet,” Nov. 22, 1996, 2 pages. |
Business Wire, “TrackingAdvisor with Qualcomm's FleetAdvisor System: Updated Version Offers Benefit of Visual Display of Vehicles and Routes to Improve Fleet Productivity,” Newswire, Oct. 27, 2003, 4 pages. |
Child Check-Mate Systems Inc., “What is the Child Check-Mate Safety System?,” retrieved from http://www.childcheckmate.com/what.html, retrieved on Apr. 7, 2004, 5 pages. |
Detex Corporation, “Detex Announces the Latest Innovation in Guard Tour Verification Technology,” Press Release, Jan. 1, 2003, 1 page. |
Dwyer et al., “Performance and Emissions of Different Bus Technologies on the city of San Francisco Routes,” Commercial Vehicle Engineering Congress and Exhibition, 2004, 2 pages. |
Extended European Search Report, dated May 9, 2014, for European Application No. 11845242.4-1955 / 2646969, 7 pages. |
FleetOwner, “Private fleets moving to wireless communications,” May 1, 1997, 4 pages. |
FleeTTrackkeR LLC, “ReporTTrakkeR,” 2002-2003, retrieved from http://www.fleettrakker.com/web/index.isp, retrieved on Mar. 12, 2004, 3 pages. |
Ford Motor Company, “2008 My OBD System Operation Summary for 6.4L Diesel Engine,” Apr. 28, 2008 Running Change (R42), 2008, 66 pages. |
Frost & Sullivan, “Remote Vehicle Diagnostics—The Quiet Revolution Signalling A New Era For Auto Makers,” Oct. 10, 2002, URL=http://www.frost.com/prod/servlet/press-release-print.pag?docid=KMEE-5ESE9W, download date Apr. 26, 2019, 2 pages. |
GCS (UK), “News,” 2000, retrieved from http://www.gcs.at/eng/news/allgemein.htm, retrieved on Apr. 21, 2005, 2 pages. |
GCS (UK), “The PenMaster,” retrieved from http:www.gcs.at/eng/produkte/hw/penmaster.htm, retrieved om Apr. 5, 2007, 3 pages. |
Guensler et al., “Development of a Comprehensive Vehicle Instrumentation Package for Monitoring Individual Tripmaking Behavior,” Technical Specifications and Analysis, GTI-R-99003, Feb. 1999, 31 pages. |
IBM Technology, “Terms B,” retrieved from http://www-01.ibm.com/software/globalization/terminology/b.html, retrieved on Dec. 11, 2014, 69 pages. |
IBM Technology, “Terms R,” retrieved from http://www-01.ibm.com/software/globalization/terminology/r.html, retrieved on Dec. 11, 2014, 137 pages. |
International Search Report, dated Feb. 9, 2012, for International Application No. PCT/US2011/049470, 7 pages. |
International Search Report, dated Jul. 30, 2012, for International Application No. PCT/US2011/062480, 9 pages. |
Jenkins et al., “Real-Time Vehicle Performance Monitoring Using Wireless Networking,” Proceedings of 3rd IASTED International Conference on Communications, Internet, and Information Technology, 2004, 7 pages. |
Kurtz, “Indiana's E-Government: A Story Behind Its Ranking,” INContext 4(1): Jan.-Feb. 2003, 5 pages. |
Kwon, “Networking Technologies of In-Vehicle,” Seoul National University, Mar. 8, 2000, 44 pages. |
Leavitt, “The Convergence Zone,” FleetOwner, Jun. 1, 1998, 4 pages. |
McQuade et al., “System and Method for Obtaining Competitive Pricing for Vehicle Services,” Office Action, dated Feb. 12, 2014, for U.S. Appl. No. 13/157,203, 31 pages. |
McQuade et al., “System and Method for Obtaining Competitive Pricing for Vehicle Services,” Office Action, dated Feb. 13, 2014, for U.S. Appl. No. 13/157,184, 53 pages. |
McQuade et al., “System and Method for Obtaining Competitive Pricing for Vehicle Services,” Office Action, dated Jan. 22, 2014, for U.S. Appl. No. 13/157,203, 29 pages. |
McQuade et al., “System and Method for Obtaining Competitive Pricing for Vehicle Services,” Office Action, dated Jul. 30, 2013, for U.S. Appl. No. 13/157,203, 30 pages. |
McQuade et al., “System and Method for Obtaining Competitive Pricing for Vehicle Services,” Office Action, dated Oct. 7, 2014, for U.S. Appl. No. 13/157,203, 59 pages. |
McQuade et al., “System and Method for Obtaining Competitive Pricing for Vehicle Services,” Office Action, dated Sep. 20, 2012, for U.S. Appl. No. 13/157,184, 32 pages. |
McQuade et al., “System and Method for Obtaining Competitive Pricing for Vehicle Services,” Office Action, dated Sep. 23, 2015, for U.S. Appl. No. 13/157,203, 34 pages. |
McQuade et al., “System and Method for Obtaining Competitive Pricing for Vehicle Services,” Office Action, dated Sep. 8, 2015, for U.S. Appl. No. 13/157,184, 69 pages. |
McQuade et al., “System and Method for Vehicle Maintenance Including Remote Diagnosis and Reverse Auction for Identified Repairs,” Office Action, dated Aug. 11, 2015, for U.S. Appl. No. 12/956,961, 28 pages. |
McQuade et al., “System and Method for Vehicle Maintenance Including Remote Diagnosis and Reverse Auction for Identified Repairs,” Office Action, dated Dec. 16, 2014, for U.S. Appl. No. 12/956,961, 118 pages. |
McQuade et al., “System and Method for Vehicle Maintenance Including Remote Diagnosis and Reverse Auction for Identified Repairs,” Office Action, dated Jun. 28, 2013, for U.S. Appl. No. 12/956,961, 75 pages. |
McQuade et al., “System and Method for Vehicle Maintenance Including Remote Diagnosis and Reverse Auction for Identified Repairs,” Office Action, dated Sep. 21, 2012, for U.S. Appl. No. 12/956,961, 45 pages. |
Miras, “About SPS Technologies,” May 7, 1999, retrieved from http://replay.waybackmachine.org/19990507195047/http://www.miras.com/html/about_sps_technologies . . . , retrieved on Sep. 29, 2010, 1 page. |
Miras, “How MIRAS Works,” Apr. 29, 1999, retrieved from http://replay.waybackmachine.org/19990429144910/http://miras.com/html/products.html, retrieved on Sep. 29, 2010, 1 page. |
Miras, “Miras 4.0 Screenshot,” May 7, 1999, retrieved from http://replay.waybackmachine.org/19990507205618/http://www.miras.com/html/largescreen.html, retrieved on Sep. 29, 2010, 1 page. |
Miras, “MIRAS Unit,” May 4, 1999, retrieved from http://replay.waybackmachine.org/19990504052250/http://www.miras.com/html/1000unit.html, retrieved on Sep. 29, 2010, 1 page. |
Miras, “Monitoring Vehicle Functions,” Apr. 27, 1999, retrieved from http://replay.waybackmachine.org/19990427152518/http://www.miras.com/html/monitoring.html, retrieved on Sep. 29, 2010, 1 page. |
Miras, “Remote Control,” Apr. 29, 1999, retrieved from http://replay.waybackmachine.org/19990429145717/http://miras.com/html/remote_control.html, retrieved on Sep. 29, 2010, 1 page. |
Miras, “Tracking & Monitoring Software,” Apr. 29, 1999, retrieved from http://replay.waybackmachine.org/19990429160322/http://miras.com/html/software.html, retrieved on Apr. 29, 2010, 1 page. |
Security Management Online—Bulletin Board, Member: Quaan, “Guard Tour Systems,” posted Sep. 16, 2003, 1 page. |
Senger, “Inside RF/ID: Carving a Niche Beyond Asset Tracking—Systems integrator SPEC designs innovative RF/ID solutions beyond asset tracking for food processing plant and heavy-equipment dealer,” Business Solutions, Feb. 1999, 5 pages. |
Sterzbach, “A Mobile Vehicle On-Board Computing And Communication System,” Comput. & Graphics 20(4):659-667, 1996. |
The Auto Channel, “Nextel, Motorola and Symbol Technologies Offer First Wireless Bar Code Scanner for Mobile Phones,” Jun. 11, 2003, 3 pages. |
The Proxi Escorte, “The Data Acquisition Unit Escorte,” retrieved from http://www.gcs.at/eng/produckte/hw/escorte.htm, retrieved on Apr. 21, 2005, 4 pages. |
Tiscor, “Inspection Manager 6.0, User Guide,” 2004, 73 pages. |
Tiscor, “Inspection Manager,” 2004, 19 pages. |
Tsakiri et al., Monitoring with GPS and GLONASS, Journal of Navigation 51(3):382-393, 1998. |
Tuttle, “Digital RF/ID Enhances GPS,” Proceedings of the Second Annual Wireless Symposium, pp. 406-411, 1994. (6 pages). |
U.S. Environmental Protection Agency, “On-Board Diagnostics (OBD)—Frequent Questions,” retrieved from http://web.archive.org/web/20050915205926/http://www.epa.gov/obd/questions.htm, retrieved on Dec. 9, 2014, 4 pages. |
Want, “RFID—A Key to Automating Everything,” Sci. American, pp. 58-65, 2004. (10 pages). |
Zujkowski, “Savi Technology, Inc.—Savy Security and Productivity Systems,” ATA Security Forum, Chicago, IL, May 15, 2002, 21 pages. |
Non-Final Office Action dated Sep. 15, 2022 from related U.S. Appl. No. 17/080,502. |
Number | Date | Country | |
---|---|---|---|
20200258323 A1 | Aug 2020 | US |
Number | Date | Country | |
---|---|---|---|
61377865 | Aug 2010 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 13219467 | Aug 2011 | US |
Child | 16863735 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 13157184 | Jun 2011 | US |
Child | 13219467 | US | |
Parent | 13157203 | Jun 2011 | US |
Child | 13157184 | US | |
Parent | 12956961 | Nov 2010 | US |
Child | 13157203 | US |