Patent Description:
Most vehicles, such as an automobile or a heavy-duty truck, typically exhibit some type of malfunction during the life of the vehicle. In some cases, a vehicle malfunction is easily diagnosable and repairable. In other cases, a vehicle malfunction is not easily diagnosable and repairable. In any of these cases, but especially the latter cases, the vehicle owner may experience the vehicle malfunctioning while she drives the vehicle, but a technician that subsequently tries to diagnose and repair the malfunction may be unable to experience the vehicle malfunction while driving the vehicle.

Moreover, when the vehicle owner takes her vehicle to the technician for diagnosis and repair, the vehicle owner may be unable to recall some or all of the circumstances that occurred while the vehicle was malfunctioning. Both the relative difficulty in diagnosing and repairing the vehicle and the diagnosis and repair time may increase if the technician is unaware of those circumstances. It may be beneficial to provide the technician with a test drive script to guide the technician to drive the vehicle such that the vehicle is driven on roads where the owner's vehicle malfunctioned or a similar vehicle malfunctioned in a manner similar to the owner's vehicle so that the technician can experience the vehicle malfunction and confirm that a repair performed by the technician successfully fixed the vehicle.

In <CIT>, a scan tool with an integrated global positioning system (GPS) is disclosed, so that a vehicle can be serviced for optimal operations at a certain temperature. <CIT> discloses a method for conducting a vehicle-related survey to gather information about a specific area of interest. <CIT> relates to an on-vehicle breakdown-warning report system, which can instruct a driver to take certain actions in order to obtain additional information if this is required for a diagnosis process. From <CIT>, it is known to take geographic information into account when selecting a subset of potentially relevant repair information.

Example embodiments pertaining to generating and using a test drive script (TDS) are described herein. In one respect, an example embodiment can take the form of a method according to any of claims <NUM>-<NUM>.

In another respect, an example embodiment can take the form of a system according to any of claims <NUM>-<NUM>.

In yet another respect, an example embodiment can take the form of a computer-readable medium according to claim <NUM>.

These as well as other aspects and advantages will become apparent to those of ordinary skill in the art by reading the following detailed description, with reference where appropriate to the accompanying drawings. Further, it should be understood that the embodiments described in this overview and elsewhere are intended to be examples only and do not necessarily limit the scope of the invention.

Example embodiments are described herein with reference to the drawings.

This description describes several example embodiments including, but not limited to, example embodiments pertaining to generating, storing, and outputting a test drive script. A TDS, such as a baseline TDS, can include instructions for following a baseline path upon which a vehicle traveled while generating VDV upon which the TDS is based. A TDS, such as an alternative TDS, can include instructions for following an alternative path that is different than the baseline path but has a number of path characteristics that match or substantially match path characteristics of a baseline path. An alternative TDS can include at least one of the vehicle data values, load instructions, control instructions, and time intervals for controlling operation of a vehicle in a manner similar to a manner in which a vehicle was driven when the VDV were captured by a data collector.

A TDS presentation device can output a TDS to guide a technician while performing a test drive of a vehicle (e.g., driving the vehicle in an attempt to recreate a service condition or vehicle malfunction or to confirm a repair to the vehicle successfully fixed the service condition or vehicle malfunction). A TDS presentation device can output a TDS to a vehicle for controlling operation of the vehicle or for outputting the TDS by an ECU or an output device within the vehicle. A TDS presentation device can output a TDS to a path or load simulator, such as a dynamometer, to provide a vehicle with operating conditions such that the vehicle produces VDV similar to the VDV in the TDS. Outputting a TDS can include outputting an entire TDS or a portion thereof.

Configuring a system with the ability to generate, store, or output a TDS, such as a baseline TDS or an alternative TDS overcomes an inability of current systems to generate, store, or output a TDS. Moreover, an alternative TDS can be output to guide a technician to drive a first vehicle in a first location (e.g., Columbus, Ohio) even though the baseline TDS is based on VDV or DCP pertaining to a second vehicle previously driven in a second location (e.g., San Jose, California).

In this description, the articles "a", "an", or "the" are used to introduce elements of the example embodiments. The intent of using those articles is that there is one or more of the elements. The intent of using the conjunction "or" within a described list of at least two terms is to indicate any of the listed terms or any combination of the listed terms. The use of ordinal numbers such as "first," "second," "third" and so on is to distinguish respective elements rather than to denote a particular order of those elements.

The block diagrams, flow charts, and other data shown in the figures are provided merely as examples and are not intended to be limiting. Many of the elements illustrated in the figures or described herein are functional elements that can be implemented as discrete or distributed components or in conjunction with other components, and in any suitable combination and location. Those skilled in the art will appreciate that other arrangements and elements (e.g., machines, interfaces, functions, orders, or groupings of functions) can be used instead. Furthermore, various functions described as being performed by one or more elements can be carried out by a processor executing computer-readable program instructions (CRPI) or by any combination of hardware, firmware, or software.

The description includes examples of data values within various messages or data storage devices. The example data values can include hexadecimal data values. The data values in this description contained within square brackets (i.e., [ ]) represent hexadecimal data values. The example data values can also include decimal data values. Any described data value not identified as a hexadecimal data value can be considered to be a decimal data value. The example embodiments are not limited to using decimal and hexadecimal data values.

Each element shown in <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, and <FIG>, can be or include a separate article of manufacture or can be or include one or more articles of manufacture.

<FIG> is a block diagram of a system <NUM> in accordance with the example embodiments. The system <NUM> includes a vehicle <NUM>, a vehicle <NUM>, a data collector <NUM>, DCP providers <NUM>, <NUM>, <NUM>, and <NUM>, a TDS computing device <NUM>, a TDS presentation device <NUM>, a network <NUM>, a database <NUM>, local communication links <NUM>, <NUM>, and <NUM>, network communication links <NUM>, vehicle interface links <NUM> and <NUM>, and a dynamometer <NUM>.

The local communication links <NUM>, <NUM>, and <NUM>, the network communication links <NUM>, and the vehicle interface links <NUM> and <NUM> can include a wired communication link, a wireless communication link, or a combination of a wired link and a wireless communication link, but are not so limited. Furthermore, the various links <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> can communicatively couple two or more elements together so as to allow at least one of the communicatively coupled elements to communicate with at least one of the other communicatively coupled elements using a circuit-switched technique, a packet-switched technique, or some other technique. The circuit-switched technique can include establishing a point-to-point connection between the two or more elements. The packet-switched technique can include transmitting blocks of data (e.g., packets), based on a destination address within the blocks of data, to at least one of the other communicatively coupled elements.

A vehicle, such as the vehicle <NUM> or <NUM>, can include an automobile, a motorcycle, a light-duty truck, a medium-duty truck, a heavy-duty truck, a semi-tractor, a farm machine, or some other type of vehicle that can be driven or otherwise guided along a path (e.g., a paved road). A vehicle can include or use any appropriate voltage or current source, such as a battery, an alternator, a fuel cell, and the like, providing any appropriate current or voltage, such as about <NUM> volts, about <NUM> volts, and the like. A vehicle can include or use any desired system or engine. Those systems or engines can include items that use fossil fuels, such as gasoline, natural gas, propane, and the like, electricity, such as that generated by a battery, magneto, fuel cell, solar cell and the like, wind and hybrids or combinations thereof.

The vehicle <NUM> can include one or more electronic control units (ECU) <NUM> to control aspects of operating the vehicle. For example, the vehicle <NUM> can include a powertrain system ECU, an engine system ECU, a supplemental inflatable restraint system (i.e., an airbag system) ECU, an entertainment system ECU, or some other ECU. One or more of the ECU can receive inputs (e.g., a sensor input), control output devices (e.g., a solenoid), generate VDV (such as a VDV based on a received input or a controlled output), and generate a diagnostic trouble code (DTC). As another example, the vehicle <NUM> can include one or more ECU of an infotainment system, such as, but not limited to, a vehicle navigation ECU or a radio sound system (e.g., an AM/FM/XM® band sound system) ECU. As yet another example, the vehicle <NUM> can include one or more ECU of an autonomous driving system for operating the vehicle <NUM> as a driverless vehicle. The vehicle <NUM> can include one or more ECU <NUM> to control aspects of operating the vehicle <NUM> in a manner similar to or different than an ECU <NUM> of the vehicle <NUM>.

One or more ECU within a vehicle can connect to a vehicle communication link <NUM>. Vehicle communication link <NUM> can include a data link connector (DLC) <NUM>, such as a Society of Automotive Engineers (SAE) J1962 connector or some other connector, for connection to the data collector <NUM> by a vehicle interface link <NUM>. The vehicle communication links <NUM> and vehicle interface links <NUM> and <NUM> can include one or more distinct vehicle communication links that carry communications according to a common or different vehicle communication protocol. The vehicle interface link <NUM> can include the DLC <NUM>.

The data collector <NUM> can include a device or system that receives (e.g., collects) VDV from a vehicle, such as the vehicle <NUM>, stores the VDV in a computer-readable medium, and provides the VDV to the TDS computing device <NUM> or some other element within the system <NUM>. The data collector <NUM> can communicatively couple to the vehicle <NUM> by the vehicle interface link <NUM>. The data collector <NUM> can communicatively couple to the vehicle <NUM> by the vehicle interface link <NUM> or to other vehicles (not shown). The data collector <NUM> can be configured to communicatively couple with one vehicle at a time or more than one vehicle at a time.

The DCP provider <NUM> is configured as a local DCP provider with respect to the data collector <NUM> because the DCP provider <NUM> is communicatively coupled directly to the data collector <NUM> by the local communication link <NUM>. In a first respect, the local communication link <NUM> can include a wired communication link that communicatively couples the data collector <NUM> and the DCP provider <NUM>. In a second respect, the local communication link <NUM> can operate using a short-range wireless communication protocol such as, but not limited to, an Institute of Electrical and Electronics Engineers (IEEE) <NUM>. <NUM> standard for wireless personal area networks (PANs), a Bluetooth version <NUM> standard developed by the Bluetooth Special Interest Group (SIG) of Kirkland, Washington, or an IEEE <NUM> standard for wireless LANs, which is sometimes referred to as a Wi-Fi standard. The DCP provider <NUM> can be configured like or include aspects of the DCP provider <NUM> shown in <FIG>.

THE DCP providers <NUM>, <NUM>, and <NUM> are configured as remote DCP providers to the data collector <NUM> as the remote DCP providers are communicatively coupled to the data collector <NUM> by the network <NUM> and the network communication links <NUM>. As shown in <FIG>, the data collector <NUM> and the DCP provider <NUM> are connected to the network <NUM> by the network communication links <NUM> such that the DCP provider <NUM> could, but is not required to, function as a remote DCP provider to the data collector <NUM> or to a different data collector (not shown). Two or more of the DCP providers described herein, such as the DCP providers <NUM> and <NUM>, can be arranged as a single DCP provider. The DCP providers <NUM>, <NUM>, or <NUM> can be configured like or include aspects of the DCP provider <NUM>.

The DCP provider <NUM> can provide DCP including meteorological parameters (i.e., data) to devices within the system <NUM>. The meteorological data can include, but is not limited to, temperature data (e.g., one or more temperature values), barometric data (e.g., one or more barometric values), humidity data (e.g., one or more humidity values), and rainfall data (e.g., one or more rainfall per time values). The meteorological data can include corresponding time data so that the meteorological data can be associated with (i.e., correspond to) VDV and other DCP that correspond to (i.e., are associated with) similar time data. Some or all of the meteorological data provided by the DCP provider <NUM> can be provided by or based on data provided by the National Oceanic and Atmospheric Administration of the United States Department of Commerce or by some other source of meteorological data.

The DCP provider <NUM> can provide DCP including traffic data to devices within the system <NUM>. The traffic data can include, but is not limited to, velocity data (e.g., a velocity or speed value corresponding to a particular path and time). The traffic data can include corresponding time data so that the traffic data can be associated with VDV and other DCP that correspond to similar time data. Some or all of the traffic data provided by the DCP provider <NUM> can be provided by or based on data provided by a state highway traffic authority, such as the Illinois State Toll Highway Authority or by some other source of traffic data.

The DCP provider <NUM> can provide DCP including path data to devices within the system <NUM>. The path data can include, but is not limited to, elevation data (e.g., elevations values corresponding to particular portions of a path), path name data (e.g., data indicating names of particular paths), speed limit data (e.g., speed limits corresponding to particular portions of a path), direction data (e.g., data identifying traffic directions for paths configured for reversible traffic flow), path inclination data (e.g., data that indicates a grade or slope of the path), path curvature data that indicates a degree in which the path curves, and path pavement data (e.g., data that indicates the type of pavement (e.g., bricks, cement, or asphalt) if the path is paved. The path data can include corresponding time data so that the path data can be associated with VDV and other DCP that correspond to similar time data. Some or all of the path data provided by the DCP provider <NUM> can be provided by NAVTEQ NAVSTREETS™ or by some other source of path data.

The TDS computing device <NUM> can include one or more elements that work separately or in combination to carry out functions pertaining to a TDS. Details regarding at least some of those elements are shown in <FIG>. The functions pertaining to a TDS can include, but are not limited to, requesting, receiving, or storing data for generating a TDS, generating a TDS, storing a TDS in the database <NUM>, searching for a TDS stored in the database <NUM>, and outputting a TDS by the user interface <NUM> or the network interface <NUM>. The TDS computing device <NUM> can communicatively couple to the network <NUM>, the database <NUM>, or one or more devices within the network <NUM>. The TDS computing device <NUM> can communicatively couple to the database <NUM> directly by the local communication link <NUM>.

The TDS presentation device <NUM> includes a device for generating and transmitting a TDS request, receiving a TDS in response to the TDS request, and presenting a TDS. The TDS presentation device <NUM> can communicatively couple to the network <NUM> or one or more devices within the network <NUM>. Additional details regarding the TDS presentation device <NUM> are shown in <FIG>. The TDS presentation device <NUM> can communicatively couple to the dynamometer <NUM> by the local communication link <NUM>. The TDS presentation device <NUM> can operate as a data collector and can include the components of the data collector <NUM> or perform any of the functions described herein as being performed by the data collector <NUM>.

The database <NUM> includes a computer-readable medium for storing a variety of computer-readable data. That computer-readable data can include, but is not limited to, VDV, DCP, and TDS. The database <NUM> can receive the variety of data from the data collector <NUM>, the TDS computing device <NUM>, a DCP provider, or some other element of the system <NUM>.

The database <NUM> can store data for generating a TDS. As an example, the database <NUM> can include VDV and TDS instructions associated with a vehicle identifier, such as a year, make, and model of a vehicle. Table <NUM> shows vehicle identifiers for two different vehicles (i.e., Y/M/M-<NUM> (e.g., a <NUM> Chevrolet Corvette) and Y/M/M-<NUM> (e.g., a <NUM> Ford Escape)) and a complaint, cause, and correction (C/C/C) associated with VDV captured in an instance of the identified vehicle experiencing the C/C/C. The VDV in Table <NUM> include VDV that indicate an engine RPM value and an intake MAP value captured for an instance of the vehicle identified by the vehicle identifier. The database <NUM> can include load instruction data (e.g., a throttle position sensor value), and a control instruction (e.g., an air conditioning system state or a transmission gear position (e.g., drive or neutral)) for including in a TDS for another instance of the identified vehicle. Other examples of the vehicle identifiers, C/C/C, VDV, load instruction data, and the control instructions are also possible. A time or location identifier may be associated with each instance of data shown in Table <NUM>.

The network <NUM> (i.e., one or more networks) can include any of a variety of communication networks. Each communication network of the network <NUM> can include, but is not limited to, a wired communication network, a wireless communication network, or a combination of a wired and a wireless communication network. The network <NUM> can include the communication links <NUM> and <NUM>, various switches (not shown), various gateways (not shown) and other network components. The network <NUM> can include the elements communicatively coupled to the communication links <NUM>. A portion of the network <NUM> can include a local area network (LAN) such as a LAN within a repair shop. A portion of the network <NUM> can include the Internet. A portion of the network <NUM> can include a cellular telephone network.

Two or more of the elements shown in <FIG>, as well as other elements described herein, can communicatively couple to each other. Two or more elements communicatively coupled to each other can transmit communications to each other and can receive communications transmitted by the other elements. A communicative coupling between two or more elements can occur by any of the communication links described herein, but is not so limited.

An example use of the components of the system <NUM> include a vehicle owner driving the vehicle <NUM> with the data collector <NUM> communicatively coupled to the vehicle <NUM>, and the data collector <NUM> capturing VDV while the owner is driving the vehicle <NUM>. A location DCP provider <NUM> may be communicatively coupled to the data collector <NUM> or the vehicle <NUM> while the vehicle owner is driving the vehicle. The vehicle owner then takes the vehicle <NUM> and the data collector <NUM> to a technician at a vehicle repair shop. The technician can request a TDS using TDS presentation device <NUM>. The TDS computing device <NUM> can generate a TDS based on VDV captured by the data collector <NUM>, DCP provided by the DCP provider <NUM>, and requested from the DCP providers <NUM>, <NUM>, or <NUM> based on, at least in part, the VDV and DCP captured while the vehicle owner was driving the vehicle <NUM>. The TDS presentation device <NUM> can receive the TDS and present the TDS to guide the technician while driving the vehicle <NUM> in an attempt to recreate a vehicle symptom exhibited by the vehicle <NUM> while driven by the vehicle owner or to confirm a repair to the vehicle <NUM> was successful.

Another example use of the components of the system <NUM> include the TDS presentation device <NUM> receiving a TDS and providing control commands to the dynamometer <NUM> while the vehicle <NUM> is positioned on the dynamometer <NUM>. The control commands can be based on data values that the TDS presentation device <NUM> receives from the vehicle <NUM>. The dynamometer <NUM> can be controlled using the control commands so as to generate conditions that cause the vehicle <NUM> to exhibit load conditions indicated by the TDS. The load conditions indicated by the TDS can include conditions of a vehicle being driven in a single direction without any turns. This example use can benefit technicians that desire to simulate conditions on a road on which a vehicle was driven to generate the TDS without having to actually drive the vehicle on a road. For instance, the TDS can be based on a vehicle being driven on a road with steep inclines, but the technician and the vehicle <NUM> are located in an area that does not have roads with similar steep inclines.

Another example use of the components of the system <NUM> include the vehicle <NUM> transmitting VDV to the TDS computing device <NUM> over the network communication link <NUM>. The TDS computing device <NUM> can provide the VDV received from the vehicle <NUM> to the database <NUM>. The components used to perform these aspects of communicating the VDV can be referred to as the telematics components. The data collector <NUM> can request and receive the VDV that the vehicle <NUM> provides to the TDS computing device <NUM>. Other examples of using one or more of the components of the system <NUM> are also possible.

Next, <FIG> is a block diagram of the TDS computing device <NUM>. The TDS computing device <NUM> includes a processor <NUM>, a computer-readable medium <NUM>, a user interface <NUM>, and a network interface <NUM>, two or more of which can be communicatively coupled or linked together via a system bus, network, or other connection mechanism <NUM>. The TDS computing device <NUM> can include or be configured as a desktop or laptop computing device or a server workstation that includes the elements of the TDS computing device <NUM> shown in <FIG>. The computer-readable medium <NUM> can store CRPI <NUM>, TDS <NUM>, and other data, but is not so limited. The local communication link <NUM> can communicatively couple the network interface <NUM> and the database <NUM>.

A processor, such as the processor <NUM> or any other processor disclosed herein, can include one or more general purpose processors (e.g., INTEL® single core microprocessors or INTEL® multicore microprocessors) or one or more special purpose processors (e.g., digital signal processors). Additionally or alternatively, a processor can include an application specific integrated circuit (ASIC). The processor <NUM> can be configured to execute CRPI, such as the CRPI <NUM>.

A computer-readable medium, such as computer-readable medium <NUM> or any other computer-readable medium disclosed herein, can include a non-transitory computer-readable medium readable by a processor. A computer-readable medium can include volatile or nonvolatile storage components, such as optical, magnetic, organic or other memory or disc storage, which can be integrated in whole or in part with a processor, or which can be separate from a processor. A computer readable medium can include, but is not limited to, a random-access memory (RAM), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a compact disk read-only memory (CD-ROM), or any other device that is capable of providing data or executable instructions that may be accessed by a processor, such as the processor <NUM>. A computer-readable medium can be referred to by other terms such as, but not limited to, a "computer-readable storage medium," a "data storage device," a "memory device," or a "memory.

Additionally or alternatively, a computer-readable medium, such as the computer-readable medium <NUM> or any other computer-readable medium disclosed herein, can include a transitory computer-readable medium. The transitory computer-readable medium can include, but is not limited to, a communications medium such as a digital or analog communications medium (e.g., a fiber optic cable, a waveguide, a wired communication link, or a wireless communication link).

A user interface (UI), such as the user interface <NUM> or any other user interface disclosed herein, can include input UI elements and output UI elements. The input UI elements can include devices that allow a user to input data. As an example, the input UI elements can include, but are not limited to, a keyboard, a pointing device (e.g., a mouse), and a microphone and corresponding electronic circuitry. The output UI elements can include devices for presenting data to a user. As an example, the output UI elements can include, but are not limited to, a display unit (or more simply, a display) for presenting the data visually, and a loud speaker for presenting the data audibly. The display can include, but is not limited to, a liquid crystal display (LCD), a light emitting diode (LED) display, a plasma display, or a cathode ray tube (CRT) display. Some elements of a UI, such as a touch screen display can function as both an input UI element and an output UI element.

A network interface, such as the network interface <NUM> or any other network interface disclosed herein, can include an interface to the network <NUM> or to some other network or communication link. The interface to network <NUM> can include a transceiver having one or more transmitters configured for transmitting data over the network <NUM> to another device within the network <NUM> and one or more receivers configured to receive data transmitted over the network <NUM> from another device within the network <NUM>. Any of the network interfaces disclosed herein can include circuitry, for example electronic circuitry, for converting data received from the network <NUM> to data that can be provided to a processor for processing the received data. The circuitry of the network interfaces can include a modulator demodulator (modem). Any of the network interfaces disclosed herein can include circuitry, for example electronic circuitry, for converting data received from another device, such as a processor or a computer-readable medium, to data in a form that can be transmitted over the network <NUM>.

A network interface that provides for communicatively coupling to a wireless communication network can include one or more antennas for transmitting or receiving wireless communications. A network interface can include one or more communication ports configured to connect to a wired communication link of a network, such as a coaxial cable, an Ethernet cable, a fiber optic cable, a digital subscriber line (DSL), a telephone line of a public switched telephone network (PSTN) or some other wired connector. The transmitter or transceiver can provide data or information to a communication port for transmission as network communications over the connected network. The receiver or transceiver can receive data or information received at a communication port from the connected network.

In general, CRPI, such as the CRPI <NUM> or any other CRPI disclosed herein, can include data structures, objects, programs, routines, or other program modules that may be accessed by a processor, such as the processor <NUM> or any other processor disclosed herein. For brevity purposes, those aspects are referred to herein simply as "program instructions. " Execution of the CRPI can cause the processor or an element communicatively coupled to the processor to perform a particular function or set of functions.

In particular, the CRPI <NUM> can include program instructions to generate a TDS. Examples of generating a TDS are described with respect to <FIG> and <FIG>. The CRPI <NUM> can include CRPI to carry out one or more of the functions shown in <FIG> or <FIG>. The CRPI <NUM> can include program instruction to cause computer-readable medium to store a TDS within the TDS <NUM>. The CRPI <NUM> can include program instructions to receive a TDS request, search the TDS <NUM> or the database <NUM> for a TDS based on the TDS request, and cause the network interface <NUM> to transmit a TDS discovered or retrieved from the TDS <NUM> or the database <NUM> in response to the TDS request. The TDS <NUM> can include the database <NUM>, at least one TDS stored within the database <NUM>, or one or more TDS not stored within the database <NUM>.

Next, <FIG> is a block diagram of the data collector <NUM>. The data collector <NUM> includes a processor <NUM>, a computer-readable medium <NUM>, a user interface <NUM>, a motion detector <NUM>, a clock <NUM>, a location detector <NUM>, a vehicle interface <NUM>, a network interface <NUM>, and a camera <NUM>, two or more of which can be communicatively coupled or linked together via a system bus, network, or other connection mechanism <NUM>. The data collectors of the example embodiments can include one or more of the components of the data collector <NUM>. The computer-readable medium <NUM> can store CRPI <NUM>, VDV <NUM>, DCP <NUM>, and other data, but is not so limited. The processor <NUM> can execute the CRPI <NUM>. Any or all of the remarks above regarding, in general, a processor, a computer-readable medium, a user interface, and a network interface, are applicable to the processor <NUM>, the computer-readable medium <NUM>, the user interface <NUM>, and the network interface <NUM> respectively.

The motion detector <NUM> includes one or more devices for determining motion data (e.g., an acceleration value, a velocity value, a speed value, or a heading value). One or more of the motion values can include an angular motion value, such as an angular acceleration value or an angular velocity value. As an example, the one or more devices can include an accelerometer or a yaw rate sensor. The motion detector <NUM> can provide the motion data to any other component of the data collector <NUM> by the connection mechanism <NUM>. The motion data can be stored as DCP within the DCP <NUM>.

A clock, such as the clock <NUM> or any other clock disclosed herein, can include a clock configured to provide time data for associating with a parameter, such as a VDV or a DCP, or a request, such as a TDS request, a VDV request or a DCP request. A clock can be integrated within a processor. Additionally or alternatively, the time data that the data collector <NUM> associates with a parameter can be provided by another component of the data collector <NUM>, such as the location detector <NUM> or the network interface <NUM>.

The location detector <NUM> includes one or more devices configured to determine a location to associate with other data, such as a VDV or a DCP. The determined location can be represented by a location identifier. A location or location identifier associated with a VDV or a DCP can be referred to as a location or location identifier corresponding to (or associated with) the VDV or a DCP respectively. As an example, a location identifier can include a latitude value and a longitude value, but is not so limited. As another example, a location identifier can include a Universal Transverse Mercator (UTM) zone number and an easting and northing coordinate pair within that UTM zone or some other data representing a location. As another example, a location identifier can include a path name and path location (e.g., United States Highway <NUM>, mile marker <NUM>).

The location detector <NUM> can include a Global Position System (GPS) receiver configured to receive GPS messages broadcast by a GPS satellite. The location detector <NUM> can use GPS messages from four separate GPS satellites to determine an accurate location of the location detector <NUM>. The location detector <NUM> can determine a location from a message received by the network interface <NUM> from a device in the network <NUM> (e.g., a base station of a cellular telephone network) or from a message provided by a local DCP provider, such as the DCP provider <NUM>.

The vehicle interface <NUM> includes one or more devices for communicatively coupling the data collector <NUM> to a vehicle, such as the vehicle <NUM>. A device of a vehicle interface can include, but is not limited to, (i) a vehicle interface connector connectable to the DLC <NUM>, (ii) a vehicle data bus interface including a transceiver, (iii) a harness that connects the vehicle interface connector to the DLC <NUM>, or (iv) a wireless communication transceiver such as a Bluetooth® protocol transceiver. The transmitter of the transceiver can transmit VDV requests to the vehicle <NUM> and a receiver of the transmitter can receive the VDV from the vehicle <NUM>. A vehicle interface can be configured to communicate with the vehicle <NUM> using any of a variety of vehicle communication protocols such as, but not limited to, the SAE J1850 protocol, the SAE J1939 protocol, the controller area network (CAN) protocol, the media oriented systems transport (MOST) protocol, a Diagnostic over Internet Protocol (DoIP) that meets an International Organization for Standardization (ISO) <NUM> standard, or another vehicle communication protocol discussed herein.

The camera <NUM> can be configured to capture one or more images for storing within the computer-readable medium <NUM>. One or more of the captured images can be stored within the DCP <NUM>. Multiple captured images can be stored as a video within the DCP <NUM>. As an example, an image captured by the camera <NUM> can show an external environment to a vehicle being driven. The external environment can be a traffic pattern, a path the vehicle is being driven on, or some other aspect in an environment external to the vehicle. As another example, an image captured by the camera <NUM> can show a component of a vehicle being driven. For instance, the component in the captured image can include an instrument panel that is displaying a malfunction indicator lamp or a driver warning message. As yet another example, an image captured by the camera <NUM> can include a screen capture of an image displayed by the user interface <NUM>. For instance, the image displayed by the user interface can show a representation, numerical, graphical, or otherwise, of a VDV received from a vehicle. Other examples of captured images stored as part of the DCP <NUM> are also possible.

The CRPI <NUM> can include program instructions to generate or transmit a VDV request. Generating the VDV request can include the processor <NUM> determining which vehicle parameter identifier (PID) to include within the VDV request. In one respect, the processor <NUM> can determine which VDV to request based on, at least in part, a vehicle PID selected by the user interface <NUM>. In another respect, the processor <NUM>, while executing those program instructions, can refer to VDV request rules stored within the computer-readable medium <NUM> (as part of CRPI <NUM> or otherwise) to determine what VDV request should be sent to the vehicle <NUM>. The VDV request rules can be conditioned on, at least in part, the year, make, and model of a vehicle. The VDV request rules can be based on, at least in part, one of a complaint, cause, and correction listed on a repair order, such as the complaint: check engine light on, the cause: DTC P0115 set, or the correction: replaced engine coolant temperature sensor. Examples of a VDV request are shown within VDV requests <NUM> shown in <FIG>.

As another example, the VDV request can include multiple VDV requests to request vehicle data values that indicate engine revolutions per minute (RPM) and intake manifold absolute pressure (intake MAP) from the vehicle <NUM>. In accordance with the SAE J1979 standard, each VDV request for the engine RPM can include the data identifiers [<NUM>0C], where [<NUM>] represents an OBD II Mode [<NUM>] and [0C] represents a vehicle PID [0C] (e.g., engine RPM), and each VDV request for intake MAP can include the data identifiers [<NUM>0B], where [<NUM>] represents an OBD II Mode [<NUM>] and [0B] represents a vehicle PID [0B] (e.g., intake MAP). A TDS can include the responses to the multiple VDV requests.

Each response to the VDV request for engine RPM can include four data bytes, such as the data bytes [<NUM>0C 0B B8], where [<NUM>] indicates a response message (e.g., the OBD II Mode [<NUM>] plus [<NUM>]), [0C] indicates the vehicle PID [0C], and [0B B8] are vehicle data values representing an engine RPM data value (<NUM>/<NUM> RPM per bit). The engine RPM for that example VDV request response is as follows: [0B B8] = <NUM>,<NUM>, and the engine RPM equals <NUM>,<NUM> / <NUM> = <NUM> RPM.

Each response to the VDV request for intake MAP can include three data bytes, such as the data bytes [<NUM>0B <NUM>], where [<NUM>] indicates a response message (e.g., OBD II Mode [<NUM>] plus [<NUM>]), [0B] indicates the vehicle PID [0B], and [<NUM>] is a data value representing the intake MAP data value. The intake MAP for that example VDV response is as follows: [<NUM>] = <NUM> kPA.

The CRPI <NUM> can include program instruction to generate or transmit a DCP request. Generating the DCP request can include the processor <NUM> determining which DCP to include within the DCP request. In one respect, the processor <NUM> can determine which DCP to request based on, at least in part, a data collector configuration input (DCCI) entered or received by the user interface <NUM>. In another respect, the processor <NUM>, while executing those program instructions, can refer to DCP request rules stored within the computer-readable medium <NUM> (as part of the CRPI <NUM> or otherwise) to determine what DCP request should be sent to the vehicle <NUM>. The DCP request rules can be conditioned on, at least in part, the year, make, and model of a vehicle. The DCP request rules can be based on, at least in part, one of a C/C/C listed on a repair order, such as the complaint: check engine light on, the cause: DTC P0115 set, or the correction: replaced engine coolant temperature sensor. Examples of a DCP request are shown within DCP requests <NUM> shown in <FIG>.

In accordance with the example embodiments, the data collector <NUM> can include or be configured as a desktop or laptop computing device that includes one or more of the components of the data collector <NUM> shown in <FIG>. In accordance with the example embodiments, the data collector <NUM> can include or be configured as a diagnostic device or system, such as a MODIS™ ultra integrated diagnostic system provided by Snap-on Incorporated in Kenosha, Wisconsin or with components thereof. Moreover, the output UI elements of the user interface <NUM> can be configured like a ten inch high-resolution (e.g., <NUM> x <NUM> resolution) touch screen display that is part of the Versus® Pro Diagnostic Information System provided by Snap-on Incorporated, but are not so limited.

The data collector <NUM> can include or be configured as a smartphone (such as an IPHONE® smartphone from Apple Inc. of Cupertino, California, or a GALAXY S® smartphone from Samsung Electronics Co. Of Maetan-Dong, Yeongtong-Gu Suwon-Si, Gyeonggi-Do, Republic of Korea), or a tablet device (such as an IPAD® tablet device from Apple Inc. , or a SAMSUNG GALAXY TAB tablet device from Samsung Electronics Co. The CRPI <NUM> of a data collector including or configured as a smartphone or a tablet device can include an application downloaded to the data collector <NUM> from the APP STORE® online retail store or from the GOOGLE PLAY® online retail store.

Next, <FIG> is a block diagram of the TDS presentation device <NUM>. A data collector, such as the data collector <NUM> or another device operational as a data collector, can include the elements or perform the functions of the TDS presentation device <NUM>, as described herein.

The TDS presentation device <NUM> includes a processor <NUM>, a computer-readable medium <NUM>, a user interface <NUM>, a network interface <NUM>, and a vehicle interface <NUM>, two or more of which can be communicatively coupled or linked together via a system bus, network, or other connection mechanism <NUM>. The computer-readable medium <NUM> can store CRPI <NUM>, TDS <NUM>, and other data, but is not so limited. The processor <NUM> can execute the CRPI <NUM>. Any or all of the remarks above regarding, in general, a processor, a computer-readable medium, a user interface, a network interface, and a vehicle interface, are applicable to the processor <NUM>, the computer-readable medium <NUM>, the user interface <NUM>, the network interface <NUM>, and the vehicle interface <NUM>, respectively.

The CRPI <NUM> can include program instructions to generate a TDS request. Those program instructions can cause the output UI elements of the user interface <NUM> to display fields, pull-down menus, or the like, by which a user can enter data (such as vehicle identification information, location information, or vehicle symptom information) for including with the TDS request. The input UI elements of the user interface <NUM> can be used to enter the data. The vehicle identification information can include data that identifies at least a vehicle type (e.g., the year, make, and model of the vehicle <NUM>) or data (e.g., vehicle identification number) that identifies a particular instance of the vehicle type. The vehicle symptom information can include one or more of a C/C/C listed on a repair order regarding the vehicle <NUM> when the vehicle <NUM> is a vehicle-under-service. The CRPI <NUM> can cause the computer-readable medium <NUM> to store at least a portion of the vehicle symptom information.

The CRPI <NUM> can include program instructions to cause the network interface <NUM> to transmit the TDS request over the network <NUM> to the TDS computing device <NUM> or another device. The network interface <NUM> can transmit the TDS request and receive a TDS in response to the TDS request. The CRPI <NUM> can include program instructions to cause the network interface <NUM> to provide a received TDS to the processor <NUM>, the computer-readable medium <NUM>, the user interface <NUM>, or the connection mechanism <NUM>. Providing a TDS to the computer-readable medium <NUM> can include storing the TDS within TDS <NUM>.

CRPI <NUM> can include program instructions to cause the output UI elements of the user interface <NUM> to output a TDS stored within the computer-readable medium <NUM>. Outputting the TDS by the user interface <NUM> can include presenting at least a portion of the TDS, such as turn-by-turn navigation instructions, visually or audibly. The turn-by-turn instructions can include vehicle operation instructions such as accelerate quickly, accelerate slowly, brake quickly, or brake slowly, as well as instructions such as turn left, turn right, etc. Outputting a TDS can include displaying a map with highlighted paths to be followed. Outputting a TDS can include outputting any aspects of TDS <NUM> (shown in <FIG>). Outputting a TDS can include displaying an image or video captured by a camera, such as the camera <NUM>.

The CRPI <NUM> can include program instructions to cause the vehicle interface <NUM> to output a TDS stored within the TDS <NUM>. Outputting the TDS using the vehicle interface <NUM> can include the vehicle interface <NUM> transmitting the TDS over the vehicle interface link <NUM> to the DLC <NUM> of the vehicle <NUM>. The TDS can be carried to one or more ECU <NUM> within the vehicle <NUM> over the vehicle communication link <NUM>. As an example, an infotainment system ECU within the vehicle <NUM> can receive the TDS and output the TDS within the vehicle <NUM> (e.g., displaying TDS instructions, VDV or DCP on a visual display within the vehicle <NUM> or playing audible TDS instructions, VDV or DCP using one or more audio speakers within the vehicle <NUM>). As another example, an autonomous vehicle ECU within the vehicle <NUM> can receive the TDS and control aspects of driving the vehicle (e.g., following a particular path, operating an engine with a particular load, or placing vehicle accessories in defined states (e.g.. , on or off)) based on the TDS.

To avoid providing too much information of a TDS using an infotainment system, the CRPI <NUM> can include a program instructions to reduce the amount of TDS information to be presented by a vehicle display. Those program instructions can include or operate in a manner similar to the mySPIN application provided by Bosch SoftTec GmbH that reduces the information from a smartphone application to be presented by a display within a vehicle. Additionally or alternatively, those program instructions may be compatible with the In-Vehicle Infotainment (IVI) open-source development platform developed by GENIVI®.

The TDS presentation device <NUM> can include or be configured as a desktop or laptop computing device that includes one or more of the components of the TDS presentation device <NUM> shown in <FIG>. The TDS presentation device <NUM> can include or be configured as a diagnostic device or system, such as a MODIS™ ultra integrated diagnostic system or with components thereof. Moreover, the output UI elements of the user interface <NUM> can be configured like a ten inch high-resolution touch screen display that is part of the Versus® Pro Diagnostic Information System, but are not so limited. The TDS presentation device <NUM> can include or be configured as a smartphone or a tablet device. The CRPI <NUM> of the TDS presentation device <NUM> including or configured as a smartphone or a tablet device can include an application downloaded to the TDS presentation device from the APP STORE® online retail store or from the GOOGLE PLAY® online retail store.

Next, <FIG> is a block diagram of a DCP provider <NUM>. One or more of DCP providers <NUM>, <NUM>, <NUM>, and <NUM> can be configured like at least a portion of the DCP provider <NUM>. In that regard, one or more of the DCP providers <NUM>, <NUM>, <NUM>, and <NUM> may include all or only a portion of the components of the DCP provider <NUM>.

The DCP provider <NUM> includes a processor <NUM>, a computer-readable medium <NUM>, a user interface <NUM>, a network interface <NUM>, a clock <NUM>, a motion detector <NUM>, and a location detector <NUM>, two or more of which can be communicatively coupled or linked together via a system bus, network, or other connection mechanism <NUM>. The computer-readable medium <NUM> can store CRPI <NUM>, DCP <NUM>, and other data, but is not so limited. The processor <NUM> can execute the CRPI <NUM>. Any or all of the remarks above regarding, in general, a processor, a computer-readable medium, a user interface, a network interface, a clock, a motion detector, and a location detector, are applicable to the processor <NUM>, the computer-readable medium <NUM>, the user interface <NUM>, the network interface <NUM>, the clock <NUM>, the motion detector <NUM>, and the location detector <NUM> respectively.

The CRPI <NUM> can include program instructions to receive messages including DCP, extract the DCP from the received messages, correlate the extracted DCP with other data (e.g., time data provided by the clock <NUM>), or store the DCP within the DCP <NUM>. In addition to time data, the DCP stored within the DCP <NUM> can include data corresponding to location or motion data.

The CRPI <NUM> can include program instructions to determine DCP (i.e., DCP determination CRPI). For example, the DCP determination CRPI can determine the DCP based on data determined or provided by the motion detector <NUM> or the location detector <NUM>.

The network interface <NUM> can receive parameters storable as DCP within the DCP <NUM>. The network interface <NUM> can provide the received parameters (e.g., to the processor <NUM>, the computer-readable medium <NUM> or the connection mechanism <NUM>) for storage within the DCP <NUM>. The received parameters can include time data or the processor <NUM> can correlate time data with the received parameters for storage within the DCP <NUM>.

The network interface <NUM> can receive, over the network <NUM> from TDS computing device <NUM>, a DCP request. The DCP request can include, but is not limited to, a time identifier, a location identifier, a quantity identifier, and a time interval identifier. The time identifier can include a start time, an end time, or a time range including the start time and the end time, but is not so limited. The location identifier can include data to identify a given area, such as a zip code to identify an area associated with the zip code or a set of GPS locations to identify an area associated with a path traveled by a vehicle, but is not so limited. The quantity identifier can, for example, identify a minimum or maximum number of DCP to provide (e.g., <NUM> DCP). The time interval identifier can, for example, identify a time interval (e.g., <NUM> or <NUM> seconds) to identify a desired timing between two consecutive DCP.

The CRPI <NUM> can include program instructions that cause the network interface <NUM> to transmit DCP in response to a DCP request. The network interface <NUM> can transmit, over the network <NUM> to the TDS computing device <NUM> or another device that transmitted the DCP request, the requested DCP in response to the DCP request.

The user interface <NUM> can be used to enter DCP for storage with the DCP <NUM>. The user interface <NUM> can present data pertaining to creating, storing, and providing DCP.

The DCP provider <NUM> can include or be configured as a desktop or laptop computing device that includes one or more of the components of the DCP provider <NUM> shown in <FIG>. The DCP provider <NUM> can include or be configured as a diagnostic device or system, such as a MODIS™ ultra integrated diagnostic system or with components thereof. Moreover, the output UI elements of the user interface <NUM> can be configured like a ten inch high-resolution touch screen display that is part of the Versus® Pro Diagnostic Information System, but are not so limited. The DCP provider <NUM> can include or be configured as a smartphone or a tablet device. The CRPI <NUM> of the DCP provider <NUM> including or configured as a smartphone or a tablet device can include an application downloaded to the TDS presentation device from the APP STORE® online retail store or from the GOOGLE PLAY® online retail store.

The data collector <NUM> can be configured to request, receive, or store any of a variety of VDV that are available from a vehicle. The available VDV from a vehicle can be based on various vehicle characteristics such as, but not limited to, the year, make, and model of the vehicle, and the components (e.g., an engine with a particular displacement or a transmission type (e.g., manual or automatic)) within the vehicle. The values of the VDV provided by a vehicle can be based on various driving circumstances such as, but not limited to, how the vehicle is being driven, where the vehicle is being driven, and meteorological circumstances. A VDV can also be provided by a vehicle that is not being driven. For example, a VDV can be provided by a vehicle parked and idling in a parking lot or within a vehicle repair shop.

The data collector <NUM> can transmit VDV requests to the vehicle <NUM>. A VDV request can include an ECU identifier, a source identifier, or a vehicle PID, but is not so limited. An ECU identifier transmitted on the vehicle communication link <NUM> allows the ECU receiving the VDV request to determine whether the ECU is to respond to the VDV request. An ECU can use the source identifier in the VDV request as a destination of a VDV request response. An ECU can use the vehicle PID to determine which VDV to include in the VDV request response.

<FIG> shows an example set of VDV requests <NUM> including VDV requests <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>. Each of those VDV requests is destined for an engine ECU within the vehicle <NUM> and is sourced by the data collector <NUM>. Each of the VDV requests <NUM> to <NUM> include a Mode number (e.g., an OBD II Mode number). Mode [<NUM>] can represent a request for VDV. Mode [<NUM>] can represent a request for DTC. A VDV request can include other modes as well, or no modes at all. The destination of a VDV request can be for an ECU other than an engine ECU. Each of the VDV requests <NUM>, <NUM>, <NUM>, and <NUM> include a PID. PID [<NUM>] can identify a calculated engine load value as a percentage between <NUM> and <NUM> percent inclusive. PID [<NUM>] can identify an engine coolant temperature VDV in degrees centigrade. PID [0F] can identify an intake air temperature VDV in degrees centigrade. A VDV request can include a different PID than those shown in <FIG>. The VDV requests <NUM> and <NUM> are examples of VDV requests without a PID.

A device, such as the data collector <NUM> or the TDS computing device <NUM>, can be configured to determine, request, receive or store any of a variety of DCP that can be associated with a VDV, such as the VDV requested, received, or stored by the data collector <NUM>. In one respect, the data collector <NUM> can associate the VDV and DCP when the data collector <NUM> receives the VDV or when the data collector <NUM> stores the VDV as part of the VDV <NUM>. In another respect, the data collector <NUM> can associate the VDV and DCP after the data collector <NUM> receives and stores the VDV. In yet another respect, the TDS computing device <NUM> can request and receive the DCP and then associate the DCP with the VDV instead of or in addition to the data collector <NUM>.

The VDV request response provided by a vehicle can include a VDV identifier (e.g., a PID) and the VDV. The VDV request response provided by a vehicle can include a time stamp associated with the VDV (e.g., a time the VDV was captured or transmitted by the vehicle <NUM> to the data collector <NUM>). Additionally or alternatively, the data collector <NUM> can associate a time with the VDV such as a time when the data collector <NUM> receives or stores the VDV.

<FIG> shows an example set of VDV <NUM> including VDV <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>. For the VDV <NUM> and <NUM>, a VDV type (i.e., the type of VDV) is identified by the Mode (e.g., Mode [<NUM>]) and the VDV are within the Data-<NUM> and Data-<NUM> values. For the VDV <NUM>, <NUM>, <NUM>, and <NUM>, the VDV type is identified by the mode (i.e., Mode [<NUM>]) and the Data-<NUM> value (e.g., PID [<NUM>] or [0F]), and the VDV is shown by the Data-<NUM> value. The null values for Data-<NUM> and Data-<NUM> for VDV <NUM> can indicate that no DTC is set by the engine ECU.

<FIG> shows each of the VDV <NUM> to <NUM> including a response identifier (e.g., <NUM> to <NUM>) that corresponds to a request identifier (e.g., <NUM> to <NUM> in the VDV requests <NUM> to <NUM>). The VDV <NUM> to <NUM> also include a destination identifier for the data collector <NUM>, a source identifier for the engine ECU.

Next, <FIG> shows a set of DCP requests <NUM>, a set of DCP request responses <NUM>, and a set of DCP <NUM> in accordance with the example embodiments. The set of DCP <NUM> can include DCP determined locally to the data collector <NUM>, such as DCP determined by the data collector <NUM> or by DCP provider <NUM>. The set of DCP <NUM> includes DCP <NUM> associated with a first time (i.e., time <NUM>) and DCP <NUM> associated with a second time (i.e., time <NUM>). An associated time could include a date identifier (e.g., an identifier of January <NUM>, <NUM>) and a time identifier (e.g., <NUM>:<NUM> AM Pacific Standard Time). The DCP <NUM> and DCP <NUM> include DCP that indicate a location identifier, a heading identifier, a speed value, and an acceleration value. The heading identifier can include a direction (e.g., north, south or northwest) or other information to indicate a heading of the vehicle <NUM>.

The set of requests for DCP <NUM> includes DCP requests <NUM>, <NUM>, <NUM>, and <NUM>. A DCP request can include a source identifier, a destination identifier, a location, a heading, a time, a DCP identifier, and a request number, but is not so limited. The set of DCP request responses <NUM> includes DCP request responses <NUM>, <NUM>, <NUM>, and <NUM>. A DCP request response can include a source identifier, a destination identifier, a response identifier (e.g., <NUM> to <NUM> that corresponds to a request identifier <NUM> to <NUM> respectively of DCP requests <NUM> to <NUM>), and a DCP value, but is not so limited. The data collector <NUM> or another device can determine VDV and DCP associated with a common time and associate those VDV and DCP.

As an example, the DCP-<NUM> values and the DCP-<NUM> values of DCP request responses <NUM> and <NUM> are associated with time Time-<NUM> (based on requests <NUM> and <NUM>), the DCP values of DCP <NUM> are associated with time Time-<NUM>, and the VDVs of VDV request responses <NUM> is associated with time Time-<NUM>. All of those parameters or some portion thereof can be associated with each other.

The VDV of VDV request responses <NUM> and <NUM> are associated with times Time-<NUM> and Time-<NUM> respectively. The data collector <NUM> or TDS computing device <NUM> can determine that times Time-<NUM> and Time-<NUM> are within a threshold amount of time from time Time-<NUM> and responsively associate the VDV of VDV request responses <NUM> and <NUM> to the DCP and VDV associated with time Time-<NUM>. In that way, TDS computing device <NUM> can use that associated data to determine that the engine ECU did not have any DTC set when the vehicle was located at location LOC-<NUM> or a location approximate to LOC-<NUM>.

As another example, the DCP-<NUM> values and the DCP-<NUM> values of DCP request responses <NUM> and <NUM> are associated with time Time-<NUM> (based on requests <NUM> and <NUM>), the DCP values of DCP <NUM> are associated with time Time-<NUM>, and the VDVs of VDV request responses <NUM> is associated with time Time-<NUM>. All of those parameters or some portion thereof can be associated with each other.

The VDVs of VDV request responses <NUM> and <NUM> are associated with times Time-<NUM> and Time-<NUM> respectively. The data collector <NUM> or TDS computing device <NUM> can determine that times Time-<NUM> and Time-<NUM> are within a threshold amount of time from time Time-<NUM> and responsively associate the VDV of VDV request responses <NUM> and <NUM> to the DCP and VDV associated with time Time-<NUM>. In that way, TDS computing device <NUM> can use that associated data to determine that the engine ECU had set DTC P0115 and DTC P0116 when the vehicle was located at location LOC-<NUM> or a location approximate to LOC-<NUM>.

Next, <FIG> is a flowchart depicting a set of functions <NUM> (or more simply "the set <NUM>") that can be carried out in accordance with one or more example embodiments described herein. The set <NUM> includes the functions shown in blocks labeled with even numbers <NUM> through <NUM> inclusive. The following description of the set <NUM> includes references to elements shown in other figures in this application, but the functions of the set <NUM> are not limited to be carried out by the referenced elements. A variety of methods can be performed using one or more of the functions shown in the set <NUM> and one or more other functions described herein, such as, but not limited to, one or more of the functions shown in <FIG>, <FIG>, or <FIG>.

Block <NUM> includes receiving, by the data collector <NUM>, inputs for configuring the data collector <NUM> to collect VDV. These inputs can include a DCCI. The data collector <NUM> can receive DCCI that are entered by use of the user interface <NUM>. For example, the DCCI can include one or more PID, DTC, vehicle identifier, vehicle system identifier, or symptom data (e.g., C/C/C data) entered by use of the user interface <NUM>. Additionally or alternatively, the data collector <NUM> can receive DCCI from the network interface <NUM>. For example, the DCCI can include one or more PID, DTC, vehicle identifier, vehicle system identifier, or symptom data transmitted to the data collector <NUM> over the network <NUM> from another network device, such as a data collector used by a service advisor to input data regarding the vehicle <NUM>. The data collector <NUM> can also receive DCCI from the vehicle <NUM>. For example, the data collector <NUM> can request a VIN from the vehicle <NUM> and a VIN returned in response to that request can be used as DCCI to determine which protocols and messages are applicable to requesting VDV from the vehicle <NUM>.

Receiving the DCCI can also include receiving the DCCI from the computer-readable medium <NUM>. The processor <NUM> can execute the CRPI <NUM> to determine the DCCI within computer-readable medium based on, at least in part, other DCCI received by the data collector <NUM>. For example, the processor <NUM> can determine one or more VDV to request from the vehicle <NUM> based on the DCCI including vehicle identification data and symptom data regarding the vehicle <NUM>. For example, if the symptom data indicates a Check Engine Light is on within the vehicle <NUM> and the temperature gauge within the vehicle is malfunctioning, processor <NUM> can determine that OBD II Mode [<NUM>], PID [<NUM>], for engine coolant temperature, and OBD II Mode [<NUM>] for requesting DTC are applicable VDV to request for a vehicle identified by and exhibiting symptoms based on the DCCI including the vehicle identification data and symptom data regarding the vehicle <NUM>.

Next, block <NUM> includes establishing, by the data collector <NUM>, a communicative coupling to the vehicle <NUM> and a DCP provider. The established communicative coupling between the data collector <NUM> and the vehicle <NUM> can include a wired or wireless connection between the data collector <NUM> and the vehicle <NUM>. The wired connection can include a power connection that provides operational power for the data collector <NUM> from a battery in the vehicle <NUM> to the data collector <NUM>. Establishing the communicative coupling can include connecting vehicle interface link <NUM> to the vehicle <NUM> and the data collector <NUM>.

Similarly, the established communicative coupling between the data collector <NUM> and a DCP provider, such as DCP provider <NUM>, can include a wired or wireless connection between the data collector <NUM> and the DCP provider. The wired connection can include a power connection that provides operational power from one of the data collector <NUM> and the DCP provider to the other. Establishing the communicative coupling between the data collector <NUM> and the DCP provider can include connecting the local communication link <NUM> to the data collector <NUM> and the DCP provider <NUM>.

Next, block <NUM> includes requesting, by the data collector <NUM>, VDV from the vehicle <NUM>. Requesting the VDV can include the vehicle interface <NUM> transmitting one or more requests for VDV to the vehicle <NUM> over the vehicle interface link <NUM>. The requested VDV can be based on, at least in part, the DCCI received at block <NUM>. For VDV in accordance with OBD II diagnostics, a VDV request can include a Mode number or a PID, as shown in <FIG>. The VDV is not restricted to OBD II diagnostic parameters. For example, the VDV could include VDV from an entertainment system, a supplemental inflatable restraint system, or some other non-emission related ECU or system within the vehicle <NUM>.

Next, block <NUM> includes requesting, by the data collector <NUM>, DCP from a DCP provider. The DCP requested at block <NUM> can include, but are not limited to, traffic condition parameters pertaining to paths followed by the vehicle <NUM> when the DCP are captured, meteorological parameters pertaining to a location of the vehicle <NUM> when the DCP are captured, location parameters of the vehicle <NUM> when the DCP are captured, or motion parameters pertaining to the vehicle <NUM> when the DCP are captured.

Requesting the DCP can include the data collector <NUM> transmitting a DCP request to the DCP provider <NUM> over the local communication link <NUM> or to DCP provider <NUM>, <NUM>, or <NUM> over the network <NUM>. In one respect, a DCP request can include an identifier of the data collector <NUM> (e.g., the source data in DCP request <NUM>) such that the DCP provider knows where to transmit the DCP requested by the data collector <NUM>. In another respect, a DCP request can include a request for a subset of DCP that the DCP provider can provide to the data collector <NUM>. For instance, if DCP provider <NUM> can provide the meteorological DCP values described above, the DCP request may include a request for just the temperature and barometric values from the DCP provider <NUM>. In yet another respect, a DCP request can include a location identifier, such as a location identifier that indicates a location of the vehicle <NUM>. As the location of the vehicle <NUM> changes, the data collector <NUM> can send another DCP request based on the new location.

Referring to the DCP requests <NUM> to <NUM>, each request can identify a source of the request (e.g., the data collector <NUM>) and destination of the request (e.g., DCP provider <NUM> or <NUM>). When a DCP provider is communicatively coupled locally to the data collector <NUM>, such as the DCP provider <NUM>, a source and destination may be implied by a DCP request. As shown in <FIG>, a DCP request can indicate which DCP are to be provided (e.g., temperature and barometric values for DCP requests <NUM> and <NUM>, and a traffic speed (e.g., an average traffic speed) for DCP requests <NUM> and <NUM>).

Next, block <NUM> includes receiving, by the data collector <NUM>, the VDV from the vehicle <NUM>. Receiving the VDV can include vehicle interface <NUM> receiving VDV that the vehicle <NUM> transmits over vehicle communication link <NUM>.

Next, block <NUM> includes receiving, by the data collector <NUM>, the DCP from the DCP provider. Receiving the VDV can include the network interface <NUM> receiving VDV that the DCP provider <NUM> transmits over the local communication link <NUM> or that any of the DCP providers <NUM>, <NUM>, or <NUM> transmit over the network <NUM> to the data collector <NUM>.

Block <NUM> includes storing, by a computer-readable medium, a plurality of VDV pertaining to a first vehicle, such as the vehicle <NUM>. Storing the VDV can include the computer-readable medium <NUM> storing the VDV that the data collector <NUM> receives from the vehicle <NUM>, as described in block <NUM>. Additionally or alternatively, storing the VDV can include the computer-readable medium <NUM> storing the VDV that the TDS computing device <NUM> receives from the data collector <NUM> (e.g., some or all of the VDV stored in VDV <NUM>). The VDV stored at block <NUM> can include VDV obtained from the vehicle <NUM>, such as, but not limited to, DTC, PID, and PID values. Additionally or alternatively, the VDV stored at block <NUM> can include electrical measurements of a component installed within a vehicle.

Storing the plurality of VDV can include storing data associated with the plurality of VDV. In general, the data associated with the VDV can include data that a device, such as the data collector <NUM> or TDS computing device <NUM>, can use to determine DCP that correspond to the VDV. As an example, the data associated with the VDV can include a time value, such as a time value indicating when the VDV was generated or received, or a location value, such as a location of the vehicle <NUM> when the VDV was generated or a location of the data collector <NUM> when the VDV was received by the data collector <NUM>. The data associated with the VDV can include a vehicle identifier (e.g., a VIN) of the vehicle <NUM>.

Next, block <NUM> includes storing, by the computer readable medium, a plurality of DCP corresponding to the VDV. Storing the DCP can include the computer-readable medium <NUM> storing the DCP determined by the data collector <NUM>, storing DCP determined by a local DCP provider <NUM>, or storing DCP determined by a remote DCP provider <NUM>, <NUM>, or <NUM>. Additionally or alternatively, storing the DCP can include the computer-readable medium <NUM> storing the DCP that the TDS computing device <NUM> receives from the data collector <NUM> (e.g., some or all of the DCP stored in DCP <NUM>). The DCP stored at block <NUM> can include, but are not limited to, traffic condition parameters, meteorological parameters, location parameters, and motion parameters.

Storing the DCP can include storing data associated with the DCP. In general, the data associated with the DCP can include data a device, such as the data collector <NUM> or the TDS computing device <NUM>, can use to determine VDV that correspond to the DCP. Some or all of the types of data that can be associated with the VDV, as described above, can be associated with the DCP.

Next, block <NUM> includes generating, by the processor <NUM>, a TDS based on a selection of at least one of the VDV and a least a portion of the DCP that correspond to the at least one of the VDV. The processor <NUM> can select the at least one VDV based on data within a TDS request. The data within the TDS request can include at least a portion of the C/C/C from a repair order pertaining to servicing the vehicle <NUM>. As an example, the data within the TDS request can include a DTC identifier (e.g., P0115 or P0116) or a PID (e.g., PID <NUM>). As another example, the complaint portion of the repair order can include text that indicates a check engine light is on the vehicle <NUM> and the coolant gauge is malfunctioning.

In a first respect, the processor <NUM> can select the at least one VDV based on a DTC set (i.e., active) within the vehicle <NUM>. In the first respect, the at least one VDV can include a first VDV that indicates a DTC has been set in the vehicle and some VDV captured prior to that first VDV and some VDV captured after that first VDV. In a second respect, the processor <NUM> can select the at least one VDV based on a VDV that exceeds a threshold VDV. In the second respect, the at least one VDV can include a second VDV including a VDV that exceeds the threshold VDV and some VDV captured prior to that second VDV and some VDV captured after that second VDV. Additional details pertaining to generating a TDS are shown in <FIG>.

Next, block <NUM> includes storing, by the computer-readable medium, the TDS. Storing the TDS can include the computer-readable medium <NUM> storing a TDS (generated at block <NUM>) within the TDS <NUM>.

Next, block <NUM> includes outputting, by at least one of the user interface <NUM> and the network interface <NUM>, the stored TDS in response to a TDS request. Outputting the TDS by the user interface <NUM> can include displaying a visual portion of the TDS or playing an audible portion of the TDS. Outputting the TDS by the network interface <NUM> can include the network interface <NUM> transmitting the TDS over the network <NUM> to another device (e.g., TDS presentation device <NUM>).

In an alternative arrangement, generating the TDS (at block <NUM>) can be based on selection of a vehicle identifier and a C/C/C associated with the vehicle. The processor <NUM> can retrieve data from the database <NUM> to generate the TDS based on the vehicle identifier (e.g., Y/M/M-<NUM>) and a C/C/C (e.g., DTC P0301). The processor <NUM> can generate the TDS based on VDV that indicate a sequence of multiple PID values for engine RPM and intake MAP. The database <NUM> can include load instructions that indicate how a vehicle such as the vehicle <NUM> or <NUM> can be loaded such that the vehicle is operated at the engine RPM and intake MAP indicated by the sequence of multiple PID values indicated by the TDS. The load instructions may indicate a transmission gear, an accessory state (e.g., vehicle air conditioning (AC) on or off), and a throttle position, but are not so limited. A TDS generated in this alternative manner can include the sequence of VDV and the load instructions as shown in example TDS data within Table <NUM>. A TDS generated in this alternative manner can include a different number of time sequence values, VDVs, and load instructions than shown in Table <NUM>.

Block <NUM> includes determining, by the processor <NUM>, a path that corresponds to a selection of at least one VDV (e.g., the at least one VDV selection discussed with respect to block <NUM>). The processor <NUM> can execute CPRI <NUM> to cause the network interface <NUM> to transmit location identifiers associated with the at least one VDV to the DCP provider <NUM> to request path data regarding the location identifiers. In response to that request for path data, the DCP provider <NUM> can transmit path data that indicates one or more paths corresponding to the location identifiers. The path data can include, but is not limited to, road names and a map showing the paths associate with the road names. The path data can indicate explicitly or impliedly an order of multiple paths (e.g., Path-<NUM> (<NUM>), Path-<NUM> (<NUM>), Path-<NUM> (<NUM>), Path-<NUM> (<NUM>), and Path-<NUM> (<NUM>), as shown in <FIG>).

Block <NUM> includes determining, by processor <NUM>, instructions for following the determined path (e.g., follow-path instructions). The DCP provider <NUM> can transmit the follow-path instructions to the TDS computing device <NUM>. The follow-path instructions can indicate explicitly or impliedly an order of the follow-path instructions. With reference to <FIG>, the follow-path instructions could include instructions such as, but not limited to, (i) proceed north on Path-<NUM>, (ii) stop at the intersection of Path-<NUM>, Path-<NUM>, and Path-<NUM>, (iii) proceed northwest on Path-<NUM>, (iv) continue north on Path-<NUM>, (v) veer right onto Path-<NUM> and then proceed East on Path-<NUM>. The VDV including motion values determined by the motion detector <NUM> can be used to determine follow-path instructions that indicate a speed, an acceleration level, or a braking level.

Block <NUM> includes adding, by processor <NUM>, the instructions within a TDS. As an example, the processor <NUM> can first allocate a portion of the computer-readable medium <NUM> (e.g., a portion of the TDS <NUM>) for storage of the TDS, and add descriptors to the TDS, such as the descriptors <NUM> shown in <FIG>. The processor <NUM> can then add the follow-path instructions to the TDS. The processor <NUM> can add a map to the TDS, such as map <NUM> showing the determined paths.

In some cases, the TDS presentation device <NUM> may be at a first location away from a starting point of the determined path the vehicle followed. The processor <NUM> can determine a start path from the first location to a starting point of the determined path. The processor <NUM> can add the start path (e.g., follow-path instructions, notifications, and a map corresponding to the start path) to the TDS. The follow-path instructions for the start path can be added prior to the follow-path instructions for the determined path the vehicle followed.

In those same cases or other cases, a user of the TDS presentation device <NUM> may desire to return to the first location or go to a second location after traveling along the determined path the vehicle followed. The processor <NUM> can determine a return path from an intermediate or ending point of the determined path the vehicle followed to the first location or the second location. The processor <NUM> can add the return path (e.g., follow-path instructions, notifications, and a map corresponding to the return path) to the TDS. The follow-path instructions for the return path can be added after the follow-path instructions for the determined path the vehicle followed.

Block <NUM> includes, adding, by the processor <NUM>, a notification within the TDS. The notification can include a notice regarding a VDV, a DCP or the TDS. The user interface <NUM> can present a TDS notification visually or audibly. As an example, the notification can include a notification <NUM> (shown in <FIG>) regarding two DTC that were set along a particular point of Path-<NUM><NUM>. The notification can alert a user of the TDS presentation device <NUM> regarding a location where the two DTC were set by a vehicle. In a similar manner, a notification could alert a user to locations along a path at which the vehicle provided VDV that exceeded a threshold value or fell within a certain range of VDV. As another example, the notification can include a notification <NUM> (shown in <FIG>) regarding a path circumstance, such as occurrence of a stop sign along Path-<NUM>. Other examples of the notification are also possible.

Block <NUM> includes determining, by the processor <NUM>, an alternate path. The alternate path can be different than the baseline path, but have at least one path characteristic that matches or approximates a path characteristic of the baseline path. An approximate path characteristic can be one that falls within a range of path characteristics of the baseline path. For example, an approximate path speed characteristic can be a speed within <NUM> kilometers per hour (kph), <NUM> kph, <NUM> kph, <NUM> kph or another number of kph of the baseline path speed characteristic (e.g., a <NUM> kph speed limit on the baseline path). As another example, an approximate path grade characteristic can be a maximum change in grade per distance such as, but not limited to, <NUM> meters per kilometer (mpk), <NUM> mpk, <NUM> mpk, <NUM> mpk, or <NUM> mpk. As another example, an approximate path curvature can be a maximum turn in degrees per kilometer (dpk), such as, but not limited to, <NUM> dpk, <NUM>, dpk, or <NUM> dpk. The path characteristics can have units other than the example units listed above.

The processor <NUM> can receive a location identifier and a distance range within a TDS request. The location identifier can indicate a location of the TDS presenter <NUM>. The distance range can indicate, for example, (i) a maximum distance the technician is willing to drive to get to a starting point of a baseline or alternate path, or (ii) a maximum distance the technician is willing to drive to get to the starting point of the baseline or alternate path, to drive the baseline or alternate path, and to drive from an ending point of the baseline or alternate path back to the technician's repair shop or other location.

The processor <NUM> can request and receive from the DCP provider <NUM> path characteristics pertaining to the baseline path. The processor <NUM> can request and receive from the DCP provider <NUM> path characteristics of paths at or proximate to the location identified by the location identifier, and determine whether any of those paths have characteristics that match or approximately match the path characteristics of the baseline path. The processor <NUM> can determine the alternate path using some or all of the paths, at or proximate to the location identified by the location identifier, that have characteristics that match or approximately match the path characteristics of the baseline path.

Determining the alternate path can include the processor <NUM> determining notifications, follow-path instructions for the alternate path, a start path with follow-path instructions, a return-path with follow-path instructions, and a map, among other aspects of an alternate path, and then adding any of the items to a TDS pertaining to the alternate path.

Block <NUM> includes generating, by the TDS presentation device <NUM>, a TDS request. A TDS request can include a vehicle identifier for selection of a TDS pertaining to a vehicle corresponding to at least a portion of the vehicle identifier. As an example, the vehicle identifier can include a VIN of a vehicle-under-service or a portion of the VIN. The selection of the TDS can be based on a year, make, and model indicated by the VIN or a portion thereof. The vehicle identifier can include the year, make, or model selected from a list of selectable vehicle identifiers. The vehicle identifier can be entered by use of the user interface <NUM> or received by the network interface <NUM> or the vehicle interface <NUM>. The vehicle identifier is not limited to a VIN, year, make, and model, but can include other information such as vehicle accessories, regular production option (RPO) codes, etcetera.

A TDS request can include a use value for selection of a TDS pertaining to a vehicle associated with an identical or similar use value. As an example, the use value can include a distance value (e.g., miles or kilometers) or a time value (e.g., hours) that indicate an amount of use of the vehicle-under-service. The use value can be entered by use of the user interface <NUM> or received by the network interface <NUM> or the vehicle interface <NUM>.

A TDS request can include a location identifier of the vehicle-under-service for selection of a TDS that includes instructions for driving a vehicle-under-service on paths proximate a location indicated by the location identifier. The location identifier can be entered by use of the user interface <NUM>, received by the network interface <NUM>, or determined by the processor <NUM> without use of the user interface <NUM> and the network interface <NUM>.

A TDS request can include at least one of a C/C/C associated with the vehicle-under-service for selection of a TDS associated with a vehicle that had a similar C/C/C while under service. The C/C/C of the TDS request can be obtained from a repair order. The C/C/C of the TDS request can be entered by use of the user interface <NUM> or received by the network interface <NUM>. As an example, the TDS request can include a DTC number (e.g., one or more DTC numbers). As another example, the TDS can include text of a complaint such as, but not limited to, "check engine light on," "engine hesitates on acceleration," or "engine dies at idle.

Block <NUM> includes transmitting, by the TDS presentation device <NUM>, the TDS request. Transmitting the TDS request can include the network interface <NUM> transmitting the TDS request over the network <NUM>. The TDS request can include a destination identifier, such as an IP address, of the TDS computing device <NUM>. The TDS request can include a source identifier, such as an IP address, of the TDS presentation device <NUM>. The TDS computing device <NUM> can output a TDS in response to and based on the TDS request. Outputting the TDS by the TDS computing device <NUM> can include transmitting the TDS from the TDS computing device <NUM> or the database <NUM> over the network <NUM> to the TDS presentation device <NUM>.

Block <NUM> includes receiving, by the TDS presentation device <NUM>, the TDS. Receiving the TDS can include the network interface <NUM> receiving the TDS over the network <NUM> and the computer-readable medium <NUM> storing the TDS received by the network interface <NUM> within the TDS <NUM>.

Block <NUM> includes outputting, by the TDS presentation device <NUM>, the TDS. In one respect, outputting the TDS can include the user interface <NUM> or the network interface <NUM> outputting the TDS. Outputting the TDS by the user interface <NUM> can include displaying a visual portion of the TDS or playing an audible portion of the TDS. Outputting the TDS by the network interface <NUM> can include the network interface <NUM> transmitting the TDS over the network <NUM> to another device.

In another respect, outputting the TDS can include TDS presentation device <NUM> transmitting the TDS or a portion thereof to an ECU <NUM> within the vehicle <NUM> over at least one of the vehicle interface link <NUM>, the vehicle communication link <NUM>, and a network communication link <NUM>. As an example, the ECU <NUM> can be configured to present the TDS visually on a display within the vehicle <NUM> or audibly using an audio speaker within the vehicle <NUM>. As another example, the ECU <NUM> can control a vehicle driving aspect, such as, but not limited to, controlling an engine to operate at a particular RPM, controlling a steering module within an autonomous vehicle to guide the vehicle along a path, or applying a vehicle brake system to stop or slow down the vehicle <NUM>.

In yet another respect, outputting the TDS can include TDS presentation device <NUM> outputting control commands over the local communication link <NUM> to the dynamometer <NUM>. The TDS presentation device <NUM> can generate the control commands to control operation of the dynamometer <NUM> so that the dynamometer <NUM> provides a load to the vehicle <NUM> that results in the vehicle <NUM> experiencing load conditions indicated by the TDS.

While the functions in the sets <NUM>, <NUM>, <NUM>, and <NUM> could be carried out in an order (e.g., a sequential order) as shown in <FIG>, <FIG>, <FIG>, and <FIG>, respectively, the functions in the sets <NUM>, <NUM>, <NUM>, and <NUM> do not have to be carried out in a sequential order as shown.

Next, <FIG> shows aspects of a TDS <NUM> in accordance with the example embodiments. TDS <NUM> includes a map <NUM> showing paths <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>. TDS <NUM> can include path names of the paths, such as Path-<NUM>, Path-<NUM>, U. Highway <NUM>, State Street, or Pennsylvania Avenue. TDS <NUM> can include notifications, such as notification <NUM>, to alert a person regarding aspects of a path featured in the TDS or aspects regarding VDV or DCP used to determine the TDS.

TDS <NUM> can also include TDS descriptor <NUM> to describe the TDS. TDS descriptor <NUM> includes a vehicle identifier (namely vehicle ID <NUM> (VID-<NUM>)), a time reference (e.g., Time-<NUM> to Time-<NUM>) that corresponds to times when a vehicle was driven along the path or a baseline path, and C/C/C data so that a user can confirm the TDS pertains to at least a portion of the C/C/C data pertaining to a vehicle-under-service (e.g., a complaint, such as DTC P0115 is set for a vehicle matching the vehicle type VID-<NUM>). Other example aspects of a TDS are also possible.

The DCP captured by the system <NUM> can include motion DCP that indicate motion of a vehicle. In accordance with at least some of the example embodiments, the motion DCP can be captured by a motion detector (e.g., the motion detector <NUM>) located within the data collector <NUM>. To avoid the motion detector <NUM> detecting motion of the data collector <NUM> relative to motion of a vehicle, the data collector <NUM> can be secured to a location within the vehicle while the data collector <NUM> is capturing motion DCP regarding the vehicle. Various means can be used to secure the data collector <NUM> to the vehicle, such as, but not limited to, a belt (e.g., a seat belt), a strap, a Velcro® fastener, or an adhesive tape.

<FIG> is a block diagram of a motion detector <NUM>. The motion detector <NUM> can be separate from other elements of the data collector <NUM> and secured to a position within a vehicle such that the other elements of the data collector <NUM> can be moved while the vehicle is being driven without affecting the motion DCP captured by motion detector <NUM>.

The motion detector <NUM> includes a removably-attachable plug-in connector <NUM>, a power circuit <NUM>, a processor <NUM>, a motion sensor <NUM>, a data communication interface (DCI) <NUM>, a communication bus <NUM>, a communication link <NUM>, and a housing <NUM>. One or more of the components shown in <FIG> within housing <NUM> can be mounted on or to a printed circuit board or other substrate (not shown) of the motion detector <NUM>.

The processor <NUM> can include or connect to a computer-readable medium (not shown) within the motion detector <NUM>. That computer-readable medium can include CRPI executable by the processor <NUM> to control functions performed by the motion detector <NUM>. Those functions can include, but are not limited to, causing motion sensor <NUM> to capture DCP pertaining to motion of a vehicle, providing the captured DCP to the DCI <NUM> using the communication bus <NUM>, and outputting the captured DCP by the DCI <NUM>.

The housing <NUM> can include or be connected to the plug-in connector <NUM>. The housing <NUM> can include or form an interior region in which at least a portion of the other elements of the motion detector <NUM> are located. Housing <NUM> can prevent damage to the components within the housing <NUM>.

The motion sensor <NUM> can include one or more accelerometers to detect motion DCP, such as acceleration parameters indicating a straight-line acceleration along a single axis (e.g., an x-axis, y-axis, and a z-axis) experienced by a vehicle (i.e., vehicle acceleration)). The motion sensor <NUM> can detect acceleration parameters for one or more axis. The motion sensor <NUM> can include one or more yaw rate sensors to detect motion DCP (e.g., angular acceleration or angular velocity) experienced by a vehicle.

The plug-in connector <NUM> can be plugged into (e.g., inserted into) a port (e.g., a connection point for a peripheral device, such as the motion detector <NUM>) within a vehicle, such as the vehicle <NUM> or <NUM>. The port can include, but is not limited to, a cigar lighter port, an accessory voltage (e.g., twelve volt) plug port, a universal serial bus (USB) port, or an Ethernet bus port. Plugging the plug-in connector <NUM> into a vehicle port attaches motion detector <NUM> to the vehicle. Removing the plug-in connector <NUM> from the vehicle port detaches the motion detector <NUM> from the vehicle.

The power circuit <NUM> can include a power bus <NUM> and a power bus <NUM>. The power circuit <NUM> can include circuit elements to condition the power received from the vehicle and circuit elements to provide the received power to the power bus <NUM> for distribution to one or more of the processor <NUM>, the motion sensor <NUM>, and the DCI <NUM>. Insertion of the plug-in connector <NUM> into the vehicle port can result in the power circuit <NUM> being connected to a power source within the vehicle, such as a vehicle battery, by way of the power bus <NUM>.

The DCI <NUM> can include a semi-conductor device that is configured to insert DCP received from the motion sensor <NUM> or the processor <NUM> into a data stream (e.g., one or more messages) and to output the data stream and DCP using communication link <NUM>. The communication link <NUM> can include a wireless communication link, such as, but not limited to a Bluetooth® communication link that outputs data using the Bluetooth® protocol. The communication link <NUM> can include a wired communication link, such as but not limited to an Ethernet or USB that outputs data using an Ethernet or USB protocol respectively. The motion DCP output by the motion detector <NUM> can be received by the network interface <NUM> of the data collector <NUM> or by another element of the system <NUM>.

In accordance with this description, the example embodiments can be arranged in the form of a motion detector that includes a power circuit, a processor, a motion sensor, and a data communication interface. This example motion detector can include a plug-in connector that is removably attachable to a vehicle port. The power circuit can obtain power from the vehicle when the plug-in connector is attached to the vehicle port.

Claim 1:
A method (<NUM>) comprising:
reading (<NUM>), by a processor (<NUM>) from a computer-readable medium (<NUM>), a plurality of vehicle data values pertaining to a vehicle, which plurality of vehicle data values was captured while the vehicle was driven and a vehicle symptom was exhibited by the vehicle during said driving, wherein the plurality of vehicle data values include vehicle data values selected from the group consisting of (i) a diagnostic trouble code, (ii) a vehicle data value associated with a parameter identifier (PID), and (iii) an electrical measurement of a component installed in the vehicle;
reading (<NUM>), by the processor (<NUM>) from the computer-readable medium (<NUM>), a plurality of driving circumstance parameters, including path data, corresponding to the plurality of vehicle data values and location identifiers associated with the plurality of vehicle data values;
generating (<NUM>), by a processor (<NUM>), a test drive script based on a selection of at least one of the vehicle data values and at least a portion of the driving circumstance parameters that correspond to the at least one of the vehicle data values, comprising:
determining, by the processor (<NUM>), a baseline path the vehicle was using when capture of the selection of the at least one vehicle data values occurred, based on path data corresponding to location identifiers associated to the at least one of the vehicle data values;
determining, by the processor (<NUM>), one or more characteristics of the baseline path;
requesting and receiving, by the processor, path characteristics of paths at or proximate to the baseline path;
determining, by the processor (<NUM>), an alternate path that is different than the baseline path,
wherein one or more characteristics of the alternate path match or approximate the one or more characteristics of the baseline path, and
generating, by the processor (<NUM>), the test drive script having instructions for following the alternate path;
storing (<NUM>), on the computer-readable medium (<NUM>), the test drive script; and
outputting (<NUM>), by at least one of a user interface (<NUM>) and a network interface (<NUM>), the stored test drive script, including said instructions to follow the alternate path, in response to a test drive script request, to guide a technician while driving the vehicle in an attempt to recreate the vehicle symptom.