Method and system for test driving a mobile machine

Abstract

A method includes determining a test drive script (TDS) to be executed during a test drive of a mobile machine while a tool monitors an electronic system in the mobile machine. The TDS includes an ordered sequence of drive cycle programs (DCPs). The ordered sequence of DCPs begins with an initial DCP and ends with a final DCP. Each DCP indicates a corresponding mobile machine state. The TDS includes a first specific DCP associated with both a first specific mobile machine state and a first condition related to the first specific mobile machine state. The method also includes outputting a representation of at least a portion of the TDS. Additionally, the method includes determining and outputting one or more of: state information corresponding to achieving the first specific mobile machine state or state information corresponding to achieving the first condition related to the first specific mobile machine state.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Patent Application No. 16 / 785,585, filed on February 8, 2020. The entire contents of U.S. Patent Application No. 16 / 785,585 are incorporated herein by reference. Background Art

[0003] As more and more components and systems in mobile machines are controlled by computers on average, the skills and knowledge required to maintain mobile machines have also increased. In at least some mobile machines, the computer that controls the components and systems is an electronic control unit (ECU). In addition, for at least some types of repairs to mobile machines, the technician who repaired the mobile machine will usually test drive the mobile machine after completing the repair to ensure the correctness of the repair. For example, after replacing the brake pads on a mobile machine that was brought to a repair shop due to complaints of grinding brakes, the technician who replaced the brake pads will usually drive the mobile machine and apply one or more brakes to ensure that the brakes do not make grinding sounds. This type of test drive usually does not require the use of tools. However, in contrast, after repairing a computer-controlled component or system or ECU in a mobile machine, the technician may feel compelled to bring a tool that communicates with the ECU during the test drive. Due to the complexity of the systems controlled by the ECU in the mobile machine, it would be very beneficial if the tool used during the test drive could provide the technician with a driving cycle program so that the technician can control the mobile machine in an efficient manner to ensure that the mobile machine is properly repaired. Summary of the invention

[0004] In a first embodiment, a method is provided. The method includes determining, by one or more processors, a test drive script to be executed during a test drive of a mobile machine when a tool monitors an electronic system in the mobile machine. The test drive script includes an ordered sequence of drive cycle programs. The ordered sequence of drive cycle programs starts with an initial drive cycle program and ends with a final drive cycle program. Each drive cycle program indicates a corresponding mobile machine state. The test drive script includes a first specific drive cycle program associated with both a first specific mobile machine state and a first condition related to the first specific mobile machine state. The method also includes outputting, by the one or more processors, a representation of at least a portion of the test drive script. Additionally, the method includes determining, by the one or more processors, one or more of the following: state information corresponding to the realization of the first specific mobile machine state or state information corresponding to the realization of the first condition related to the first specific mobile machine state. In addition, the method includes outputting, by the one or more processors, one or more of the following: state information corresponding to the realization of the first specific mobile machine state or state information corresponding to the realization of the first condition related to the first specific mobile machine state. In addition, the method includes outputting, by the one or more processors, one or more of the following: state information corresponding to the realization of the first specific mobile machine state or state information corresponding to the realization of the first condition related to the first specific mobile machine state.

[0005] In a second embodiment, a computing system is provided. The computing system includes one or more processors and a computer-readable data storage storing executable instructions. The computing system is caused to perform a function by executing the executable instructions by the one or more processors. The function includes determining a test drive script to be executed during a test drive of a mobile machine when a tool monitors an electronic system in the mobile machine. The test drive script includes an ordered sequence of drive cycle programs. The ordered sequence of drive cycle programs starts with an initial drive cycle program and ends with a final drive cycle program. Each drive cycle program indicates a corresponding mobile machine state. The test drive script includes a first specific drive cycle program associated with both a first specific mobile machine state and a first condition related to the first specific mobile machine state. The function also includes outputting a representation of at least a portion of the test drive script. In addition, the function includes determining one or more of the following: state information corresponding to the realization of the first specific mobile machine state or state information corresponding to the realization of the first condition related to the first specific mobile machine state. In addition, the function also includes outputting one or more of the following: state information corresponding to the realization of the first specific mobile machine state or state information corresponding to the realization of the first condition related to the first specific mobile machine state.

[0006] In a third embodiment, a computer readable medium is provided. The computer readable medium stores therein instructions executable by one or more processors to cause a computing system to perform a function. The function includes determining a test drive script to be executed during a test drive of a mobile machine when a tool monitors an electronic system in the mobile machine. The test drive script includes an ordered sequence of drive cycle programs. The ordered sequence of drive cycle programs starts with an initial drive cycle program and ends with a final drive cycle program. Each drive cycle program indicates a corresponding mobile machine state. The test drive script includes a first specific drive cycle program associated with both a first specific mobile machine state and a first condition related to the first specific mobile machine state. The function also includes outputting a representation of at least a portion of the test drive script. In addition, the function includes determining one or more of the following: state information corresponding to the realization of the first specific mobile machine state or state information corresponding to the realization of the first condition related to the first specific mobile machine state. In addition, the function includes outputting one or more of the following: state information corresponding to the realization of the first specific mobile machine state or state information corresponding to the realization of the first condition related to the first specific mobile machine state.

[0007] In a fourth embodiment, a computing system is provided. The computing system includes a component for determining a test drive script to be executed during a test drive of a mobile machine when a tool monitors an electronic system in the mobile machine. The test drive script includes an ordered sequence of drive cycle programs. The ordered sequence of drive cycle programs starts with an initial drive cycle program and ends with a final drive cycle program. Each drive cycle program indicates a corresponding mobile machine state. The test drive script includes a first specific drive cycle program associated with both a first specific mobile machine state and a first condition related to the first specific mobile machine state. The computing system also includes a component for outputting a representation of at least a portion of the test drive script. Additionally, the computing system includes a component for determining one or more of the following: state information corresponding to the realization of the first specific mobile machine state or state information corresponding to the realization of the first condition related to the first specific mobile machine state. In addition, the computing system also includes a device for outputting one or more of the following: state information corresponding to the realization of the first specific mobile machine state or state information corresponding to the realization of the first condition related to the first specific mobile machine state. In addition, the computing system also includes a device for outputting one or more of the following: state information corresponding to the realization of the first specific mobile machine state or state information corresponding to the realization of the first condition related to the first specific mobile machine state.

[0008] Other embodiments will become apparent to those of ordinary skill in the art by reading the following detailed description and, where appropriate, referring to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Example embodiments are described herein with reference to the accompanying drawings.

[0010] Figure 1 is a block diagram of a system according to one or more example embodiments.

[0011] Figure 2 According to one or more example embodiments, Figure 1 Details of the vehicle and vehicle systems shown.

[0012] Figure 3 and Figure 4 An example vehicle is shown.

[0013] Figure 5 An example of a tool according to one or more example embodiments is shown.

[0014] Figure 6 An example of a vehicle-to-tool link device is shown in accordance with one or more example embodiments.

[0015] Figure 7 is a block diagram of a tool according to one or more example embodiments.

[0016] Figure 8 A test drive script is shown according to one or more example embodiments.

[0017] Fig. 9 A parameter identifier (PID) diagram is shown in accordance with one or more example embodiments.

[0018] Fig.10 Monitoring diagrams are shown according to one or more example embodiments.

[0019] Fig.11 A diagram of a test drive script is shown in accordance with one or more example embodiments.

[0020] Fig.12 , Fig.13 , Fig.14 and Fig.15 Test drive status data is shown according to one or more example embodiments.

[0021] Fig.16 is a block diagram of a system including a server according to one or more example embodiments.

[0022] Fig.17 A flowchart illustrating an example method according to an example embodiment is depicted.

[0023] Fig.18 , Fig.19 , Fig. 20 , Fig.21 , Fig. 22 , Fig.23 , Fig.24 , Fig.25 , Fig.26 , Fig. 27 , Fig.28 , Fig.29 , Fig.30 , Fig.31 , Fig.32 and Fig.33 A graphical user interface (GUI) is shown in accordance with one or more example embodiments.

[0024] Fig.34 is a schematic diagram illustrating diagnostic and repair map data according to an example embodiment.

[0025] Fig.35 is a schematic diagram illustrating an index according to an example embodiment.

[0026] Fig.36 is a schematic diagram illustrating mapping data according to an example embodiment.

[0027] Fig.37 A component test index according to an example embodiment is shown.

[0028] Fig.38 is a schematic diagram illustrating example symptom-to-component mapping data according to an example embodiment.

[0029] Fig.39 is a schematic diagram illustrating example mapping data according to an example embodiment.

[0030] Fig.40 PID indexing according to an example implementation is shown.

[0031] Fig.41 A functional test index according to an example embodiment is shown.

[0032] Fig.42 A reset procedure index according to an example embodiment is shown.

[0033] Fig.43 and Fig.44 A wearable device according to an example embodiment is shown.

[0034] All the figures are schematic and not necessarily to scale and generally show only parts which are necessary in order to elucidate the example embodiments, wherein other parts may be omitted or merely suggested. DETAILED DESCRIPTION

[0035] I. Introduction

[0036] This specification describes several example embodiments, at least some of which involve using a test drive script when test driving a mobile machine (or, more simply, a vehicle). In particular, the description describes an example embodiment in which a processor determines a test drive script that is executed when a tool monitors an electronic system in a mobile machine. The processor can output a representation of at least a portion of the test drive script. For example, the processor can display at least a portion of the test drive script and / or play at least a portion of the test drive script through a speaker. The processor can determine and output state information corresponding to a specific operating state of the mobile machine being tested. Similarly, the processor can determine and output state information corresponding to conditions for achieving a specific operating state of the mobile machine being tested. The output of the aforementioned state information may include information that can guide the driver on how to drive the mobile machine during the test drive. Such information can indicate that the driver should continue to drive the mobile machine without making any changes, or indicate that the driver should change the driving style of the mobile machine, such as increasing or decreasing the speed of the mobile machine.

[0037] II. Example System

[0038] Figure 14 is a block diagram of a system 410, which includes a vehicle 412, a tool 414, a processor 416, and a test drive script 418. The vehicle 412 includes a vehicle system 420. The test drive script 418 includes a plurality of drive cycle programs. The processor 416 is configured to communicate with the tool 414 and / or communicate within the tool. The processor 416 is also configured to access the test drive script 418 and output the test drive script 418 to the tool 414 and / or another component of the tool 414. The tool 414 is configured to communicate electrically with the vehicle 412 (i.e., using electric current and / or using electromagnetic waves). The tool 414 communicating with the vehicle 412 may include communicating with the vehicle system 420 and / or any component within the vehicle system 420. The tool 414 may determine and output state information corresponding to a specific operating state of the vehicle 412 because the vehicle 412 is being test driven based on a drive cycle program of the test drive script 418. The tool 414 may also determine and output status information corresponding to conditions that achieved a particular operating state related to the vehicle 412 during the test drive.

[0039] Next, Figure 2 4 is a block diagram showing example details of vehicle 412 and example details of vehicle system 420. Figure 2 As shown, vehicle 412 includes vehicle systems 420 , an on-board diagnostic connector (OBDC) 422 , a power source 424 , and a vehicle network 432 . Figure 2 Also shown, the vehicle system 420 includes an electronic control unit (ECU) 426, an input device 428 connected to the ECU, and an output device 430 connected to the ECU. The power source 424 may include a battery or battery pack. The tool 414 is configured to be operably coupled to the OBDC 422. The tool 414 is also configured to be operably decoupled from the OBDC 422 so that the tool 414 can be operably coupled to an OBDC in another vehicle (not shown).

[0040] The input device 428 connected to the ECU includes one or more input devices. As an example, the input device 428 connected to the ECU includes a sensor, a relay, or a switch. The output device 430 connected to the ECU includes one or more output devices. As an example, the output device 430 connected to the ECU includes a pump, a motor, a solenoid, a valve, a relay, an injector, a horn, a light, a display, or a sound output device (e.g., a speaker). An example of a vehicle data message (VDM) protocol for communicating on the vehicle network 432 is listed in Section 6 of this specification. An example of the ECU 426 is listed in Section 7 of this specification. Figure 3 , examples of vehicle systems 420 are listed in Section 6 of this specification.

[0041] As another example, the output device 430 connected to the ECU can include a tactile feedback component of the vehicle. In at least some embodiments, the tactile feedback component of the vehicle includes a component that is typically contacted by an occupant of the vehicle during a test drive of the vehicle, such as a steering wheel, seat belt, seat, dashboard, or pedal (such as an accelerator pedal, clutch pedal, or brake pedal).

[0042] Next, Figure 3 A vehicle 440 is shown in accordance with an example embodiment. The vehicle 440 includes a supplemental inflatable restraint (SIR) system ECU 442, a traction control system ECU 444, a display ECU 446, a powertrain system ECU 448, an anti-lock brake system (ABS) ECU 450, and an OBDC 452, wherein each ECU is connected to both a power source 454 and a vehicle network 458 using a power bus 456. Other examples of ECUs within the vehicle 440 are possible.

[0043] Display ECU 446 includes a display, such as a liquid crystal display (LCD). Display ECU 446 may, but need not, display audio system controls, heating, ventilation, and air conditioning (HVAC) controls, and / or navigation information, and / or other content, in addition or in lieu thereof. Similar to Figure 2 As shown in ECU 426, each ECU of a vehicle 440 may be connected to one or more input devices 428 connected to the ECU and one or more output devices 430 connected to the ECU. Display ECU 446 may display at least a portion of the test drive script provided to it from the tool 100.

[0044] OBDC 452 may be located in a passenger compartment of vehicle 440, in a powertrain compartment of vehicle 440 (e.g., engine compartment), or in a storage compartment of vehicle 440. Additional details regarding the vehicle, ECU, OBDC, and vehicle communication buses are located in Section VI of this description. Figure 1 and Figure 2 The illustrated vehicle 412 may be arranged like the vehicle 440 . Figure 1 The illustrated system 410 may include a vehicle 440 in place of the vehicle 412 .

[0045] Next, Figure 4A vehicle 460 is shown according to an example embodiment. The vehicle 460 may be arranged as a motorcycle and includes a fuel injection ECU 462, a dashboard ECU 464, an ABS ECU 466, an ignition ECU 468, and / or an OBDC 470. The ECUs on the vehicle 460 are connected to a power source (not shown) and may be connected to the OBDC 470 via a vehicle network (not shown). Figure 2 As shown, ECU 426 , each ECU of vehicle 460 may be coupled to one or more ECU-coupled input devices 28 and one or more ECU-coupled output devices 430 . Figure 1 The illustrated vehicle 412 may be arranged like vehicle 460 . Figure 1 The illustrated system 410 may include a vehicle 460 in place of the vehicle 412 .

[0046] Next, Figure 5 Tablet device 480 and smartphone 482 are shown. According to an exemplary embodiment, the tool 414 and / or tool 100 (eg, Figure 7 ) may include and / or be arranged as a tablet device 480. The tablet device 480 may, but need not necessarily, include an Apple device from Apple Inc. of Cupertino, California. Tablet device or SAMSUNG GALAXY TAB tablet device from Samsung Electronics Co., Ltd. of Maetan-Dong, Yeongtong-Gu Suwon-Si, Gyeonggi-Do, Republic of Korea. According to some other example embodiments, the tool 414 and / or the tool 100 may include and / or be arranged as a smartphone 482 (e.g., a smartphone from Apple Inc. Smartphone, or from Samsung Electronics Co., Ltd. Smartphone). According to the above exemplary embodiment, at least a portion of the computer-readable data stored in the memory may include Online retail stores, from GOOGLE An online retail store or application or another source of computer readable data is downloaded to the transceiver ( Figure 5 According to at least some of the foregoing embodiments, the tablet device or smartphone may be programmed to include one or more applications for executing the CRPI to perform the functions described in this specification and / or display the GUI according to the example embodiments described in this specification.

[0047] Figure 5 Also shown is a vehicle-to-tool link 484 according to an example embodiment. The vehicle-to-tool link 484 includes a connector 486, a wiring harness 488, and an OBDC mating connector 490. The connector 486 may include a USB connector configured to connect to a USB port, a DB9 connectable to a port (such as a serial port arranged according to the EIA / TIA 232 serial interface standard), or some other connector. In some embodiments, the tool 414 (e.g., tablet device 480 or smartphone 482) may include a port arranged to connect to the connector 486. The OBDC mating connector 490 is configured to be operatively connected to an OBDC (e.g., OBDC 422 or OBDC 452) in a vehicle to allow a tool (e.g., the tool 414 or the tool 100) and a vehicle (e.g., vehicle 412, vehicle 440, or vehicle 460) to communicate with each other.

[0048] Next, Figure 6 A vehicle-to-tool link device 492 and a vehicle-to-tool link device 494 are shown. Each of the vehicle-to-tool link device 492 and the vehicle-to-tool link device 494 includes a transceiver to communicate with a transceiver in a tool (such as Figure 7 The vehicle-to-tool link device 492 includes a connector that conforms to the J1962 compliant and / or configured to connect to J1962 compliant OBDC. The vehicle-to-tool link device 494 includes a connector that complies with J1939_13 compliant and / or configured to connect to In another embodiment, the vehicle-to-tool link device 492 and / or the vehicle-to-tool link device 494 may include a connector that complies with a different vehicle data message protocol and / or is configured to connect to an OBDC that complies with a different vehicle data message protocol.

[0049] A. Tools

[0050] Figure 71 is a block diagram of a tool 100. The tool 100 includes a processor 102, a memory 104, a transceiver 106, a user interface 108, a global navigation satellite system (GNSS) receiver 110, and / or a data bus 156. The data bus 156 operatively connects the processor 102, the memory 104, the transceiver 106, the user interface 108, and / or the global navigation satellite system receiver 110 to each other. In other words, the data bus 156 provides an operative connection between two or more of the processor 102, the memory 104, the transceiver 106, the user interface 108, and / or the GNSS receiver 110. In at least some embodiments, the tool 100 also includes a power source 112 and a housing 114.

[0051] The operative connections provided by the data bus 156 allow the processor 102 to request and receive data from the memory 104. The operative connections provided by the data bus 156 allow the processor 102 to provide and store data within the memory 104. The operative connections provided by the data bus 156 allow the processor 102 to receive data input using the user interface 108 and to output data to the user interface 108 for output by the user interface 108. The operative connections provided by the data bus 156 allow the processor 102 to receive data received by the transceiver 106 and to provide data to the transceiver 106 to be transmitted by the transceiver 106.

[0052] 1. Processor

[0053] A processor (such as processor 102 or any other processor discussed in this specification) may include one or more processors. Thus, any processor discussed in this specification may be referred to as "at least one processor" or "one or more processors." Additionally, any processor discussed in this specification may include a general purpose processor (e.g., Single core microprocessor or A processor such as a multi-core microprocessor, and / or a special purpose processor (e.g., a digital signal processor, a graphics processor, an embedded processor, or an application specific integrated circuit (ASIC) processor). Additionally, any processor discussed in this specification may include or be operatively connected to a memory controller that controls the flow of data into and out of a memory such as memory 104.

[0054] Any processor discussed in this specification can be configured to execute computer readable program instructions (CRPI). For example, any CRPI discussed in this specification can include assembly instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data and / or source code or object code written in any combination of one or more programming languages. As an example, the programming language can include an object-oriented programming language, such as Java, Python or C++, or a procedural programming language, such as the "C" programming language. Any processor discussed in this specification can be configured to perform hardware-encoded functions to supplement or replace software-encoded functions (e.g., via CRPI). In at least some embodiments of the tool 100, the processor 102 can be programmed to perform any function described in this specification that is performed by the tool 414 or by the tool 100.

[0055] An embedded processor is a processor that has a specialized function or functionality within a larger electronic, mechanical, pneumatic, and / or hydraulic device, as opposed to a general-purpose computer. An embedded processor may include a central processing unit chip used in a system other than a general-purpose workstation, laptop, or desktop computer. In some embodiments, an embedded processor may execute an operating system, such as a real-time operating system (RTOS). As an example, an RTOS may include the RTOS developed by Micro Digital, Inc. RTOS, such that the embedded processor may, but need not necessarily, include (a) an Advanced RISC (Reduced Instruction Set Computer) Machine (ARM) processor (e.g., an AT91SAM4E ARM processor provided by Atmel Corporation, San Jose, California), or (b) an ARM processor provided by NXP Semiconductors NV, Eindhoven, Netherlands Processor (eg, 52259 processor). General purpose processors, special purpose processors, and / or embedded processors can perform analog signal processing and / or digital signal processing.

[0056] 2. Memory

[0057] A memory (such as memory 104 or any other memory discussed in this specification) may include one or more memories. Therefore, any memory discussed in this specification may be referred to as "at least one memory" or "one or more memories". A memory may include non-transitory memory, temporary memory, or both. A non-transitory memory or a portion thereof may be located within a processor or as part of a processor (e.g., within a single integrated circuit chip). A non-transitory memory or a portion thereof may be separate and distinct from a processor.

[0058] The non-transitory memory may include volatile or non-volatile storage components, such as optical, magnetic, organic or other memory or optical disk storage components. Additionally or alternatively, the non-transitory memory may include or be configured as a random access memory (RAM), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), a flash memory, an electrically erasable programmable read-only memory (EEPROM), or a compact disk read-only memory (CD-ROM). The RAM may include static RAM or dynamic RAM. The non-transitory memory may be configured as a removable storage device, a non-removable storage device, or a combination thereof. The removable storage and / or non-removable storage device may, but does not necessarily, include a magnetic disk device, such as a flexible disk drive or a hard disk drive (HDD), an optical disk drive, such as a compact disk (CD) drive and / or a digital versatile disk (DVD) drive, a solid state drive (SSD), or a tape drive.

[0059] The temporary storage may include, for example, CRPI provided via a communications network such as Fig.16 The data bus 156 and / or network 252 are shown.

[0060] "Memory" may be referred to by other terms, such as "computer-readable memory", "computer-readable medium", "computer-readable storage medium", "data storage device", "storage device", "computer-readable medium", "computer-readable database", "at least one computer-readable medium", "one or more computer-readable media". Any of these alternative terms may be preceded by the prefix "transitory" if the memory is transitory, or "non-transitory" if the memory is non-transitory. For a memory comprising a plurality of memories, two or more of the plurality of memories may be the same type of memory or different types of memory.

[0061] 3. Transceiver

[0062] A transceiver (such as transceiver 106 or any other transceiver discussed in this specification) may include one or more transceivers. Each transceiver includes one or more transmitters configured to transmit data to a network and / or data bus within a device (e.g., the tool 100) including the transceiver. Each transceiver includes one or more receivers configured to receive data or communications performed by a network and / or data bus within a device (e.g., the tool 100) including the transceiver. Unless otherwise specified, any data described as being transmitted to a device or system is considered to be received by the device or system. Similarly, unless otherwise specified, any data described as being received from a device or system is considered to be transmitted directly or indirectly by the device or system to a receiving device or system. For some embodiments, a transceiver may include a transmitter and a receiver in a single semiconductor chip. In at least some of those embodiments, the semiconductor chip may include a processor.

[0063] For the purpose of this specification, and with respect to a specific vehicle (e.g., vehicle 412, vehicle 440, or vehicle 460), the network can be configured as a vehicle network, a non-vehicle network, or a multi-purpose network. The vehicle network is at least partially mounted on a specific vehicle and has an OBDC and one or more electronic control units interconnected with the OBDC and / or each other. In at least some embodiments, the tool 100 includes a wiring harness that is operatively connected to the OBDC in the specific vehicle and allows the tool 100 to be set outside the specific vehicle. In these or other embodiments, the tool 100 is configured to communicate with the OBDC and can be set inside or outside the specific vehicle. The non-vehicle network is outside the vehicle of the specific vehicle and includes one or more network nodes outside the specific vehicle. The multi-purpose network is at least partially contained in the specific vehicle and at least partially outside the specific vehicle. The multi-purpose network can include a vehicle network and a non-vehicle network.

[0064] In at least some example embodiments, a transmitter (such as a transmitter within any transceiver described in this specification) transmits a radio signal carrying data, and a receiver (such as a receiver within any transceiver described in this specification) receives the radio signal carrying data. A transceiver with a radio transmitter and a radio receiver may include one or more antennas and may be referred to as a "radio transceiver," "RF transceiver," or "wireless transceiver." "RF" stands for "radio frequency."

[0065] The radio signals transmitted or received by the radio transceiver may be arranged in accordance with one or more wireless communication standards or protocols such as standards, such as (i) for wireless local area networks (wireless LANs) The 802.11 standard (sometimes called standards) (e.g., 802.11a, 802.11b, 802.11g, or 802.11n), (ii) for wireless personal area networks (PANs) 802.15 standards (e.g., 802.15.1, 802.15.3, 802.15.4 or 802.15.5), (iii) developed by the Bluetooth Special Interest Group (SIG) of Kirkland, Washington 4.1 or 4.2 version standards, (iv) cellular wireless communication standards, such as the Long Term Evolution (LTE) standard, (v) Code Division Multiple Access (CDMA) standard, (vi) Integrated Digital Enhanced Network (IDEN) standard, (vii) Global System for Mobile Communications (GSM) standard, (viii) General Packet Radio Service (GPRS) standard, (ix) Universal Mobile Telecommunications System (UMTS) standard, (x) Enhanced Data Rates for GSM Evolution (EDGE) standard, (xi) Multi-channel Multipoint Distribution Service (MMDS) standard, (xii) International Telecommunication Union (ITU) standards, such as the ITU-TG.9959 standard known as the Z-Wave standard, (xiii) 6LoWPAN standard, (xiv) Thread network protocol, (xv) International Organization for Standardization (ISO / International Electrotechnical Commission) standards, such as the ISO / IEC 18000-3 Near Field Communication (NFC) standard. (xvi) Sigfox communication standard, (xvii) Neul communication standard, (xviii) LoRaWAN communication standard, or 5G New Radio (5G NR) communication standard organized by the 3rd Generation Partnership Project (3GPP) standard, such as 5G NR Phase 1 or 5G NR Phase 2 communication standard. Examples of other wireless communication standards or protocols are also possible.

[0066] In at least some embodiments, a transmitter (such as a transmitter within any transceiver described herein) can be configured to transmit a signal (e.g., one or more signals or one or more electrical waves) carrying or representing data onto an electrical circuit (e.g., one or more electrical circuits). Similarly, a receiver (such as a receiver within any transceiver described herein) can be configured to receive, via the electrical circuit, a signal carrying or representing data through the electrical circuit. The electrical circuit can be part of a non-vehicle network, a vehicle network, or a multi-purpose network. The signals carried through the electrical circuit can be arranged in accordance with a wired communication standard, such as the Transmission Control Protocol / Internet Protocol (TCP / IP), a wireless communication standard for local area networks, or a wireless communication standard for wireless communications. 802.3 Ethernet communication standard, over cable service interface specification (DOCSIS standard), such as DOCSIS3.1, universal serial bus (USB) specification, vehicle data message (VDM) protocol, or some other wired communication standard or protocol. Examples of VDM protocols are listed in Section VI of this description. Electrical circuits may include wires, printed circuits on circuit boards, and / or network cables (e.g., single wire, twisted pair, optical cable, coaxial cable, wiring harness, power cord, printed circuit, CAT5 cable, and / or CAT6 cable). Wires may be referred to as "conductors". Data transmission through conductors may be performed electrically and / or optically.

[0067] According to at least some embodiments, transceiver 106 includes network transceiver 150 and / or vehicle communication transceiver 152. Network transceiver 150 is configured to communicate via a non-vehicle network and / or a multi-purpose network. Vehicle communication transceiver 152 is configured to communicate via a vehicle network and / or a multi-purpose network. Transceiver 106 can be configured as a gateway to communicate via a multi-purpose network. Transceiver 106 is also configured to communicate via data bus 156.

[0068] In at least some embodiments, the network transceiver 150 includes a modem, a network interface card, a local area network on a motherboard (LOM), and / or a chip that can be mounted on a circuit board. As an example, the chip can include the CC3100 provided by Texas Instruments, Dallas, Texas. Network processor, CC256MODx from Texas Instruments Host Controller Interface (HCI) module, or for or other communication protocols to communicate with different chips.

[0069] Network nodes within and / or coupled to a non-vehicle network and / or network nodes communicating via a non-vehicle network or a multi-purpose network using packet switching technology may be locally configured for the next "hop" in the network (e.g., a device or address where data is sent and expected). Devices (e.g., transceivers) that communicate using the 802.11 standard can be configured with a network name, network security type, and password. Some devices automatically negotiate this information through a discovery mechanism (e.g., cellular phone technology).

[0070] The network transceiver 150 may be arranged to transmit requests and / or receive responses using a transmission protocol such as the Hypertext Transfer Protocol (i.e., HTTP), HTTP over a Secure Sockets Layer (SSL) or Transport Layer Security (TLS) (i.e., HTTPS), the File Transfer Protocol (i.e., FTP), or the Simple Mail Transfer Protocol (SMTP). The network transceiver 150 may be arranged to transmit SMS messages using the Short Message Peer-to-Peer protocol or using some other protocol.

[0071] The data transmitted by the transceiver 106 may include a destination identifier or address of a computing device to which the data is to be transmitted. The data or communications transmitted by the transceiver 106 may include a source identifier or address of the tool 100. The source identifier or address may be used to send a response to the tool 100. The data described may include a test drive script or other data, alternatively or additionally.

[0072] 4. User Interface

[0073] In at least some embodiments, the user interface 108 includes a display 116 and an input device 118. In these or other embodiments, the user interface 108 also includes an audio output device 120 or a tactile feedback device 122. In other embodiments, the user interface 108 includes a display 116, an input device 118, an audio output device 120, and a tactile feedback device 122. Any of the above embodiments of the user interface 108 may include a camera 98, a scanner 154, or both a camera 98 and a scanner 154.

[0074] The display 116 may include one or more displays. As an example, each of the one or more displays includes a capacitive touch screen display, a resistive touch screen display, a plasma display, a light emitting diode (LED) display, a cathode ray tube display, an organic light emitting diode (OLED) display (such as an active matrix OLED or a passive matrix OLED), a liquid crystal display (LCD) (such as including a backlight, a color LCD), a touch screen display with an LCD, a capacitive touch screen display, or a resistive touch screen display. The display 116 may also include different types of displays, as an addition or an alternative.

[0075] In at least some embodiments, the display of display 116 is attached (e.g., removably attached) to a substrate of housing 114 and / or housing 114. In these or other embodiments, the display of display 116 is and / or is within a wearable device, such as a pair of glasses or goggles, a head-mounted display, or a wrist-mounted display, such as a wristwatch (e.g., a smartwatch).

[0076] The display 116 is configured to display the test drive script and / or a representation of the test drive script stored in the memory 104. The display 116 may also be configured to display a still image (such as a visible light image, a thermal image, and / or a hybrid image based on a visible light image and a thermal image), a video, a text file (such as a text file having a PDF file extension or an XML file extension), a hypertext markup language file, a web page (such as a web page including a search bar, a cursor, and / or a test drive script), and / or a graphical user interface (GUI). In at least some embodiments, the display 116 is configured to display a horizontal scroll bar and / or a vertical scroll bar. The horizontal scroll bar and the vertical scroll bar may be used to cause the display 116 to display content that is not currently displayed on the display 116. Web pages that may be displayed on the display 116 may include Figures 17 to 33 Any content displayed or described in any one or more of . Other examples of content that may be displayed on display 116 are also possible.

[0077] The input device 118 is configured to receive user input from a user of the tool 100. As an example, the input device 118 includes a keyboard or keypad including one or more keys configured to be pressed or otherwise manipulated by the user. As another example, the input device 118 includes a microphone configured to receive sound waves, such as sound waves generated by a user speaking a word in the vocabulary of the tool 100. The display 116 configured as a touch screen display can also receive user input from a user of the tool 100. Accordingly, when configured as a touch screen display, the input device 118 can include the display 116.

[0078] In embodiments including an auditory output device 120, the auditory output device 120 includes one or more speakers configured to convert electrical signals into audible sounds. In these or other embodiments, the auditory output device 120 includes wired headphones and / or wireless headphones. The wired headphones can be connected to an audio plug, which can be operably connected to an audio jack. The wireless headphones can include in-ear headphones, such as AIRPODS provided by Apple Inc. In-ear headphones.

[0079] In embodiments including a tactile feedback device 122, the tactile feedback device 122 may include an eccentric rotating mass motor, a linear resonant actuator, a piezoelectric actuator, and / or a forced impact (acceleration stamping) device. In at least some of those or other embodiments, the tactile feedback device 122 may be configured as a wearable tactile feedback device. As an example, the wearable tactile feedback device may include items such as clothing, a watch, a glove, or glasses. Other examples of tactile feedback devices 122 are also possible.

[0080] The camera 98 may include a visible light camera, a thermal camera, or both a visible light camera and a thermal camera. The scanner 154 may include a light source (such as a light emitting diode or a laser), a sensor (such as one or more photoelectric units), and a decoder. The decoder may be used to decode a code (such as a linear, one-dimensional barcode) or a matrix code (such as a quick response (QR) code). As an example, the decoder may decode the code to determine a vehicle identification code of a mobile machine, or a serial number or model number of a mobile machine component (e.g., an ECU).

[0081] Go to Fig.43 , a wearable device 751 is shown. The wearable device 751 includes a temple 752, a temple housing 753, a hinge 754, a top bar 755, a nose bridge 756, a lens 757, a nose pad 758, and a display 759. The display 759 may include a prismatic display. The content displayed on the display 116 described in this specification, a portion of the content, and / or other content may be displayed on the display 759.

[0082] The temple housing 753 may contain various components of the wearable device 751 (not shown). For example, the temple housing 753 may include a transceiver, a camera, a microphone, and / or a power source. The transceiver within the temple housing is configured to receive content to be displayed on the display 759 and transmit signals to the tool 100, such as signals indicating a cancel command, a start / restart command, and / or a complete test drive script command. The processor 102 may respond to the processor 102 in a manner such as, respectively, Figure 22 to Figure 25 and Figure 27 to Figure 29The processor 102 may respond to those commands in a manner similar to the manner in which the Cancel USC, Start / Restart USC, and Complete Test Drive Script USC 699 are determined to be selected. Additionally or alternatively, the signal may indicate a repeat command or a next command. The processor 102 may respond to those commands in a manner similar to the manner in which the processor 102 responds to the respective commands as shown. Fig.28 The illustrated determination of the repeat command USC 893 and the next command USC 895 being selected responds to those commands in the same manner. The transceiver within the temple housing may be configured to communicate with the network transceiver 150 and / or another transceiver.

[0083] Fig.43 The content 760 displayed on the display 759 is shown. The content 760 is Fig.28 A portion of schedule meter 866 is shown. Other examples of content that may be displayed on display 759 are also possible.

[0084] Go to Fig.44 , a wearable device 773 is shown. The wearable device 773 can be configured as a wristwatch having a strap 774, a crown 775, and a display 776. The content displayed on the display 116, a portion of the content, and / or other content described in this specification can be displayed on the display 776. The wearable device 773 may include a processor. The wearable device may include a transceiver configured to communicate with the network transceiver 150 and / or another transceiver.

[0085] Fig.44 776. The contents displayed on the display 776 include a progress meter 831, a repeat instruction USC 777, and a next instruction USC 778. The progress meter 831 is also displayed on the display 776. Fig.29 831, which includes a schedule start / end indicator 833, a completed segment indicator 835, an uncompleted segment indicator 837, a timer value 839, and a DCP indicator 841. For further details on those aspects of the schedule 831, refer to Fig.29 Describe and apply to Fig.44 .

[0086] In response to determining that the repeat instruction USC 777 has been selected, the processor of the wearable device 773 is configured to cause the auditory output device of the wearable device 773 to output the TDS instruction most recently output by the auditory output device. In response to determining that the next instruction USC 778 has been selected, the processor of the wearable device 773 is configured to cause the auditory output device of the wearable device 773 to output the TDS instruction that the processor of the wearable device 773 is scheduled to use when completing the DCP currently being executed. Other examples of content that can be displayed on the display 759 are also possible.

[0087] Additionally, the processor of the wearable device 773 can control a tactile feedback device within the wearable device 773 to notify the user of the wearable device of the occurrence of a drive cycle program event (such as transitioning to the next drive cycle program, completing the drive cycle program, passing the drive cycle program, or failing the drive cycle program).

[0088] 5. Additional components

[0089] Back to Figure 7 , the GNSS receiver 110 is configured to receive signals from GNSS satellites and generate GNSS data representative of the received signals. The processor 102 may determine the location of the tool 100, such as latitude and longitude, using the GNSS data. As an example, the GNSS data may be configured as GNSS data provided by the Global Positioning System associated with the United States, the Galileo system associated with Europe, the BeiDou system associated with the People's Republic of China, the Global Navigation Satellite System associated with the Russian Federation (sometimes referred to as GLONASS), or the Quasi-Zenith Satellite System (sometimes referred to as QZSS) associated with Japan.

[0090] A power source (such as power source 112 or any other power source discussed in this specification) can be arranged in any of a variety of configurations. As an example, the power source can be configured to include circuitry to receive an AC current from an AC power source (e.g., an electrical loop operatively connected to a wall outlet) and convert the AC current into a DC current to supply one or more components connected to the power source 112. As another example, the power source can be configured to include a battery or be operated by a battery. As yet another example, the power source can be configured to include a solar cell or be operated by solar energy. In addition, the power source can be configured to include an electrical loop to distribute current in a device or system that includes the power source. As an example, those electrical loops include an electrical bus 158 connected to the processor 102, the memory 104, the transceiver 106, the user interface 108, and the GNSS receiver 110. Other examples of power sources are also possible.

[0091] In at least some embodiments, the tool 100 includes a housing 114. The housing 114 surrounds at least a portion of the following: the processor 102, the memory 104, the transceiver 106, the user interface 108, the data bus 156, and / or the power supply 112. The housing 114 can support a substrate. In at least some example embodiments, at least a portion of the following is mounted on and / or connected to the substrate of the housing 114: the processor 102, the memory 104, the transceiver 106, the user interface 108, the data bus 156, and / or the power supply 112. The housing 114 can be made of various materials. For example, the housing 114 can be made of a plastic material (e.g., acrylonitrile-butadiene-styrene (ABS)) and a thermoplastic elastomer for forming a grip on the housing 114.

[0092] B. Memory Contents

[0093] Example embodiments may determine, generate, store, and / or use various computer-readable data. At least some of the computer-readable data may be stored in a memory, such as Fig.16 Memory 104 and / or memory 260 are shown. As an example, memory 104 includes computer readable programming instructions (CRPI) 124, test drive scripts 126, timers 128, maintenance status 130, test drive script (TDS) status 132, vehicle selection data 134, vehicle scanner function 136, PID map 138, monitor map 140, application 142, diagnostic and repair data 144, reports 146 and / or location data 148.

[0094] CRPI 124 includes a processor (such as Fig.16 As an example, the CRPI 124 may include program instructions that are executable to cause the tool 100 to perform any of the functions described as being performed by the tool 100 or the processor 102. As another example, the CRPI 124 may include program instructions that are executable to cause the tool 100 to perform any of the functions described as being performed by the tool 100 or the processor 102. Fig.16 The illustrated server 254 performs any functions described as being performed by the server 254 or the processor 256. In at least some embodiments, the timer 128 is implemented using program instructions of the CRPI 124. In at least some of those embodiments or in other embodiments, the processor 102 is in operative communication with one or more hardware timers to receive input for use by the timer 128. The CRPI 124 may include program instructions arranged as an application 142.

[0095] The test drive script 126 includes one or more test drive scripts. As an example, the test drive script 126 includes a test drive script that can be executed when the tool 100 monitors the electronic system in the vehicle 412. The test drive script of the test drive script 126 includes an ordered sequence of drive cycle programs. The ordered sequence of drive cycle programs begins with an initial drive cycle program and ends with a final drive cycle program. Each drive cycle program indicates a corresponding vehicle state. In at least some embodiments, the test drive script 126 includes a first specific drive cycle program associated with both a first specific vehicle state and a first condition related to the first specific vehicle state. The test drive script 418 (in Figure 1 ) may, but need not be, stored in the test drive script 126. The test drive script 126 may include Figure 8 The test drive script 160 is shown.

[0096] As an example, the vehicle state indicated by the drive cycle procedure may include acceleration rate, vehicle speed, temperature of a vehicle component (e.g., temperature of a particular vehicle fluid), engine load (representing that the transmission is in a particular gear or the vehicle is traveling on a road with a particular grade / incline), fluid level, or a particular state of a vehicle component (e.g., a particular throttle position, such as fifty percent throttle open; brake switch state on or off; air conditioning compressor on or off; window defroster on or off; powertrain ECU operating in open or closed loop, or malfunction indicator light on or off). As another example, the vehicle state may include a vehicle state occurring that is the same as a vehicle state of a drive cycle procedure previously executed in the test drive script. Thus, some test drive scripts may include the same drive cycle procedure at a different position in an ordered sequence of drive cycle procedures.

[0097] The timer 128 includes one or more timers. As an example, the timer 128 may include a countdown timer that starts at the beginning of the drive cycle program of the test drive script 126. The countdown timer may stop at the end of the drive cycle program of the test drive script 126. As another example, the timer 128 may include a countdown timer that starts at the beginning of the drive cycle program of the test drive script 126. The countdown timer may stop at the end of the drive cycle program of the test drive script 126. The processor 102, 256 may be configured to output the time indicated by the timer 128 to the user interface 108. The processor 102, 256 may be configured to pause or reset the timer 128, such as pausing the timer 128 in the event that the vehicle changes vehicle states, or resetting the timer 128 in the event that the vehicle transitions from operating in the vehicle state required for the drive cycle program to a different vehicle state and then returns to the vehicle state required for the drive cycle program.

[0098] The maintenance status 130 includes data indicating the status of maintaining the vehicle 412. In one aspect, the status of maintaining the vehicle may be a specific vehicle maintenance mode. The specific vehicle maintenance mode may be one of a plurality of vehicle maintenance modes arranged in a sequence of vehicle maintenance modes. As an example, the plurality of vehicle maintenance modes arranged in the sequence of vehicle maintenance modes may include a diagnostic mode, a repair mode, a test drive mode, and a post-repair report mode. The processor 102 may be configured to determine that the specific vehicle maintenance mode is a diagnostic mode when it is determined that a new vehicle type or a new specific vehicle has been selected. Additionally or alternatively, the processor 102 may be configured to recall a vehicle maintenance mode previously used for a specific vehicle. An advantage of tracking the maintenance status of the vehicle 412 is that the processor 102 may cause the display 116 to display an indicator of the status. A user who sees the indicator can see how much progress he / she has made in maintaining the vehicle, and / or other information displayed with the status indicator is applicable to the indicated vehicle maintenance mode.

[0099] The TDS status 132 includes data indicating the status of executing the test drive script. According to embodiments in which the test drive script includes one or more drive cycle programs, the TDS status 132 may include data indicating the status of executing each of the one or more drive cycle programs. According to these or other embodiments, the test drive script status 132 may include measured values ​​of measurements performed by the tool 100 during execution of the test drive script and / or parameter values ​​of PIDs received by the tool 100 during execution of the test drive script. The TDS status 132 may include a time value output by the timer 128. An advantage of storing the TDS status 132 is that the processor 102 can output at least a portion of the TDS status to the user interface 108 so that a user of the tool 100 can understand whether any changes in operating the vehicle 412 during execution of the test drive script 126 should be performed by the driver of the vehicle 412.

[0100] The vehicle selection data 134 may include one or more vehicle selection menus. The processor 102, 256 may output a vehicle selection menu to allow a user of the vehicle 100 to select a vehicle type or a specific vehicle. Fig.18An example of a GUI 600 including a vehicle selection menu is shown. The vehicle selection data 134 may also include data indicating a relationship between vehicle model years and vehicle types manufactured for each model year and / or during each model year. For example, for a given model year, the vehicle selection data 134 may include data indicating all vehicle brands that include at least one vehicle type for the given model year, and for each of these vehicle brands, the vehicle selection data 134 may include data indicating all vehicle models corresponding to one of the vehicle brands that manufactured at least one vehicle type for the given model year. The processor 102, 256 may generate the vehicle selection menu based on other data within the vehicle selection data 134.

[0101] The vehicle scanner function 136 includes one or more functions, and this function includes that this tool 100 transmits vehicle data message to vehicle 412 and / or receives vehicle data message from vehicle 412.As an example, the vehicle scanner function 136 includes such function, and this function includes that the vehicle communication transceiver 152 transmits vehicle data message to vehicle and / or receives vehicle data message from vehicle 412.The example that relates to vehicle data message is described in the sixth part below.In at least some embodiments, the vehicle data message received from vehicle 412 can include the data indicating vehicle type and / or specific vehicle.In these or other embodiments, the vehicle data message received from vehicle 412 can include the data indicating the DTC that is arranged in vehicle 412.

[0102] In at least some embodiments, a vehicle data message transmitted to a vehicle includes a PID, and a vehicle data message transmitted from the vehicle to the vehicle 100 in response to a vehicle data message transmitted to the vehicle including the PID includes a parameter value associated with the PID. The response message may, but need not, include the PID or an identifier representing the PID.

[0103] Table 1 shows an example of a request and response message including a PID according to an example vehicle data protocol called a controller area network protocol. In this example, the node identifier is an eleven-bit identifier written as one octal and two hexadecimal digits, and the remaining data bytes (DB) are written in hexadecimal. For example, for at least Fig. 9 The engine speed shown, PID$4D is equivalent to PID77 (decimal format). To determine Fig.25The engine speed shown in the PID parameter indicator 143 shown, the hexadecimal parameter value $3C90 can be converted to decimal and then divided by 4 to obtain an engine speed of 3876 revolutions per minute. The node identifier can indicate which device sent the vehicle data message. The $55 value indicates that the data byte is not used. Other examples of request and response messages including PIDs and / or formulas for converting hexadecimal PID parameter values ​​to decimal PID parameter values ​​using the same or another data protocol are possible.

[0104]

[0105] Table 1

[0106] The tool 100 can monitor an electronic system in a vehicle, such as the vehicle system 20, by requesting a PID parameter value from the vehicle system, receiving the PID parameter value, and comparing the PID parameter value to one or more PID parameter thresholds to determine whether the PID parameter value is within an expected operating range for proper operation of the vehicle system. Monitoring the electronic system can also include the tool 100 storing the PID parameter value in a memory. In at least some embodiments, the tool 100 monitors the electronic system in multiple vehicle maintenance modes of the tool 100, such as a diagnostic mode, a repair mode, a test drive mode, and a post-repair report mode. The tool 100 can store the PID parameter value as the test drive status data 206, such as Figures 13 to 15 shown.

[0107] PID map 138 includes a mapping of PIDs to parameter names. A processor (such as processor 102) may determine the PIDs contained in test drive script 126 (e.g., PIDs associated with a particular drive cycle program of the test drive script) and determine the corresponding parameter names from PID map 138. Processor 102 may then populate a parameter display portion within a GUI containing a representation of at least a portion of the test drive script, such as at least Fig. 22 Parameter display portion 760 is shown. The parameter display portion may include parameter names corresponding to the PIDs related to the specific drive cycle program when the specific drive cycle program is being executed. The processor 102 may request and receive parameters associated with the determined PID and display the received parameters in the parameter display portion.

[0108] A processor (such as processor 102) may determine monitor identifiers contained in the test drive script 126 (e.g., monitor identifiers associated with a particular drive cycle program of the test drive script) and determine corresponding monitor names from the monitor map 140. Processor 102 may then populate a ready monitor display portion within a GUI containing a representation of at least a portion of the test drive script, such as at least Fig. 22 The ready monitor display portion 772 is shown. The ready monitor display portion may include monitor names corresponding to monitor identifiers associated with a particular drive cycle program when the particular drive cycle program is executed. The processor 102 may request and receive monitor status data associated with the determined monitor identifier and display the received monitor status data in the ready monitor display portion.

[0109] Applications 142 include one or more applications executable by processor 102. In at least some embodiments, the one or more applications include a web browser application (or more simply, a web browser). The web browser application is arranged to use a non-vehicle network or a multi-purpose network (such as Fig.16 The web browser application can display a web page on the display 116. In at least some embodiments, the web page includes a GUI that includes, for example, Figures 17 to 33 The contents of the GUI are shown.

[0110] The repair data 144 includes data that the tool 100 is configured to use in one or more maintenance modes described herein for use with the tool 100. As an example, the tool 100 may use the repair data 144 in one or more of a diagnostic maintenance mode, a repair maintenance mode, a test drive maintenance mode, and / or a post-repair report maintenance mode. Each of these maintenance modes is further described below. Examples of repair data are described in Figures 34 to 42 and described in detail in Part 5 of this specification.

[0111] As an example, for a particular symptom exhibited by a vehicle (e.g., DTC P0171), the processor 102, 256 may refer to the following. Fig.36 Symptom to PID mapping data 551 is shown to determine a set of PIDs corresponding to a particular symptom. During a maintenance mode (such as a diagnostic maintenance mode), the tool 100 can transmit a vehicle data message to request the set of PIDs and display the set of PIDs with parameter values ​​on the display 116 to provide information that a user can use to determine how to proceed with repairing the vehicle.

[0112] As another example, for a particular symptom exhibited by a vehicle (e.g., DTC P0171), the processor 102, 256 may refer to the following. Fig.36 Symptom-to-component test mapping data 553 is shown to determine a set of component tests corresponding to a particular symptom. During a maintenance mode (such as a diagnostic maintenance mode), the tool 100 can display a corresponding component test user selectable control (USC) for each component test in the set of component tests. In response to determining that a particular component test USC has been selected, the processor 102 can cause the tool 100 to automatically configure the tool 100 to perform the component test and / or automatically initiate execution of the component test.

[0113] In any embodiments in which the processor 256 references the symptom-to-component test mapping data 553, the server 254 may transmit to the tool 100 an index value for the identified symptom within the symptom-to-component test mapping data 553, and the processor 102 may reference the symptom-to-component test mapping data 553 within the memory 104 to determine which component tests to perform by determining which component tests are associated with the index value provided by the server 254. The processor 102 may then cause the display 116 to display the component test USC to allow selection of the component test.

[0114] As yet another example, for a particular symptom exhibited by a vehicle (e.g., DTC P0171), the processor 102, 256 may refer to the following. Fig.36 Symptom to functional test mapping data 555 is shown to identify a set of functional tests corresponding to a particular symptom. According to this example, the functional tests are referred to as FT1, FT2, FT3, FT4 (where FT stands for "functional test"). During a maintenance mode (such as a diagnostic maintenance mode), the tool 100 can display a corresponding functional test USC for each functional test in the set of functional tests.

[0115] In response to determining that a particular functional test USC has been selected, the processor 102 may cause the tool 100 to automatically configure the tool 100 to perform the functional test and / or automatically initiate the execution of the functional test. In at least some embodiments, configuring the tool 100 to perform the functional test includes loading the vehicle communication transceiver 152 with a vehicle data message and transmitting the vehicle data message to the vehicle, the vehicle data message including an identifier of the functional test associated with the selected functional test USC. In any embodiment in which the processor 256 refers to the symptom to functional test mapping data 555, the server 254 may transmit to the tool 100 an index value for the identified symptom within the symptom to functional test mapping data 555, and the processor 102 may refer to the symptom to functional test mapping data 555 within the memory 104 to determine which functional tests are associated with the index values ​​provided by the server 254 and determine which functional tests to perform. The processor 102 then causes the display 116 to display the functional test USC to allow selection of the functional test.

[0116] As yet another example, for a particular symptom exhibited by a vehicle (e.g., DTC P0171), the processor 102, 256 may refer to the following. Fig.36 Symptom-to-reset procedure mapping data 557 is shown to identify a set of reset procedures corresponding to a particular symptom. During a maintenance mode (such as a repair maintenance mode), the tool 100 may display a reset procedure USC for each reset procedure of the set of reset procedures.

[0117] In response to determining that a particular reset procedure USC has been selected, the processor 102 may cause the tool 100 to automatically configure the tool 100 to perform the reset procedure and / or automatically initiate execution of the reset procedure. In at least some embodiments, configuring the tool 100 to perform the reset procedure includes loading the vehicle communication transceiver 152 with a vehicle data message and transmitting the vehicle data message to the vehicle, the vehicle data message including an identifier of the reset procedure associated with the selected reset procedure USC. In any embodiment in which the processor 256 references the symptom to reset procedure mapping data 557, the server 254 may transmit an index value for the determined symptom within the symptom to reset procedure mapping data 557 to the tool 100, and the processor 102 may reference the symptom to reset procedure mapping data 557 within the memory 104 to determine which reset procedures to execute by determining which reset procedures are associated with the index value provided by the server 254.

[0118] The repair data 144 may include data on components that are recommended for maintenance (e.g., adjustment or replacement) of the vehicle. The processor 102, 256 may determine which component to recommend based on the results of component tests and / or functional tests performed during the diagnostic maintenance mode. The decision may also be based on whether a monitor failed and / or a malfunction indicator light in the vehicle turned on during a test drive of the vehicle containing the component being maintained. The processor 102, 256 may be configured to reduce the confidence level in recommending the component to alleviate a specific symptom in the vehicle if the number of times the monitor failed and / or the malfunction indicator light in the vehicle turned on during the test drive reached a threshold number of times or percentages of maintenance for specific symptoms and vehicle components. Conversely, the processor 102, 256 may be configured to increase the confidence level in recommending the component to alleviate a specific symptom in the vehicle if the monitor did not fail and the number of times the malfunction indicator light in the vehicle turned on did not reach a threshold number of times or percentages of maintenance for specific symptoms and vehicle components during the test drive.

[0119] Report 146 includes one or more reports generated by a processor (such as processor 102, 256). Reports within report 146 include report content. Processor 102 may output reports to display 116, and display 116 may display reports output by processor 102. Examples of report content include Figure 31 to Figure 33 These figures will be discussed in Section 4.

[0120] The location data 148 may include GNSS data representative of GNSS signals received by the GNSS receiver 110 and / or a location determined based on the GNSS data by the processor 102. The processor 102 may transmit the determined location to the server 254.

[0121] The CRPI 124 may include program instructions executable by the processor to output the vehicle selection data 134 on the display 116 and determine the vehicle type or specific vehicle via the use of the vehicle selection data 134. Additionally or alternatively, the CRPI 124 may include program instructions executable by the processor to determine the vehicle type or specific vehicle via the use of the vehicle scanning function 136.

[0122] The CRPI 124 may include program instructions executable by a processor to determine a maintenance condition (e.g., a symptom) of a vehicle. As an example, the maintenance condition may include a DTC determined by the processor executing the CRPI to request and receive a DTC from the vehicle. As another example, the maintenance condition may include a vehicle system identifier, a vehicle component identifier, a DTC, and / or a customer complaint entered via a GUI, such as Fig.19 GUI 602 is shown.

[0123] Next, Figure 8 A test drive script 160 is shown according to an example embodiment. The test drive script 160 includes a drive cycle program number 162, a test drive script (TDS) instruction 164, a timer value 166, a PID 168, and a monitor identifier 170. The TDS instruction 164 includes instructions indicating how the vehicle should be operated during the test drive. As an example, Figure 8 The driving cycle programs numbered 1, 2, 3, 4, 5, 6, and 7 are associated with TDS instructions 161, 163, 165, 167, 169, 171, and 173, respectively. The timer value 166 may include a timer value counted using the timer 128. As an example, Figure 8 The drive cycle programs numbered 1, 2, 3, 4, 5, 6, and 7 are associated with timer values ​​175, 177, 179, 181, 183, 185, and 187, respectively. One or more of the timer values ​​166 may include a timer value indicating an estimated time required to execute the drive cycle program associated with the timer value. Additionally or alternatively, one or more of the timer values ​​166 may include a timer value indicating how long the ECU requires to execute the drive cycle program associated with the timer value.

[0124] although Figure 8 Each drive cycle program is shown to be associated with a single timer, but in at least some embodiments, a drive cycle program of a test drive script may be associated with multiple timers or no timer. Providing a drive cycle program with a monitor identifier allows the processor 102 to request and receive monitor status data while the drive cycle program is being executed. In at least some embodiments, if the processor 102 determines that the monitor status data indicates that the monitor has failed during execution of the drive cycle program, the processor 102 may output an indication that the monitor has failed via the user interface. Receiving such an indication during execution of the test drive program is beneficial because the driver may end the test drive program early and return to the repair shop to continue repairing the vehicle before fully executing the test drive program.

[0125] Additionally, the processor 102 can use the timer value 166 and the monitor identifier 170 to determine when to transmit a vehicle data message to the vehicle 12 to determine whether the monitor is passed or failed. In at least some embodiments, the processor 102 begins to send a vehicle data message to request the monitor status within a threshold amount of time before the timer of the driving cycle program expires. As an example, the threshold amount of time can be a fixed amount of time, such as one minute. As another example, the threshold amount of time can be a fixed percentage of the timer of the driving cycle program, such as twenty-five percent of the timer value of the driving cycle program. The advantage of waiting to send a vehicle data message to request the monitor status until closer to the time period when the monitor status may change is that the vehicle network 432 is not loaded with vehicle data messages to request the monitor status during the time period when the monitor status is unlikely to change. Additionally, if the monitor status is converted to pass or fail before the timer expires, the processor 102 can determine that the next driving cycle program of the test drive script can begin.

[0126] Next, Fig. 9 PID map 180 is shown according to an example embodiment. PID map 180 can be used alone or in combination with one or more other PID Figure 1 100 are included in the PID map 138. The PID map 180 includes one or more PIDs 182 and corresponding parameter names 184. According to at least some embodiments, the PIDs are numeric only and the parameter names are alphanumeric. The PID map can be associated with one or more different types of vehicles. A different PID map (not shown) can be associated with one or more other different types of vehicles. The PID map 180 can include a vehicle type identifier 186 so that the processor 102 can locate the PID map 180 for a specific type of vehicle being maintained using the tool 100. For purposes of this description, a vehicle type "A" in the figures can represent a vehicle type "2014 Chevrolet Tahoe (4WD)" shown in at least some of the figures.

[0127] According to an example embodiment, the processor 102 may determine a PID from the PID 168 in the test drive script 160 and determine a parameter name for the determined PID. The processor 102 may request and receive a parameter value from the vehicle 412 by transmitting at least the PID associated with the parameter value. Thereafter, the processor 102 may populate the GUI with at least a portion of the test drive script and a parameter display portion including a parameter name and a parameter value, both of which are associated with the PID sent to the vehicle.

[0128] Next, Fig.10A monitor diagram 189 is shown according to an example embodiment. The monitor diagram 189 may be used alone or in combination with one or more other monitors. Figure 1 The monitor map 189 includes one or more monitor identifiers 190 and corresponding monitor names 191 and ready monitor indicator (RMI) identifiers 192. According to at least some embodiments, the monitor identifiers 190 are only numbers, and the monitor names 191 are alphanumeric. The processor 102 may include the monitor identifier in the monitor identifier 190 in the VDM to request the status of the ready monitor associated with the corresponding monitor name. The monitor map may be associated with one or more different types of vehicles. Different monitor maps (not shown) may be associated with one or more other different types of vehicles. The monitor map 189 may include a vehicle type identifier 193 so that the processor 102 can locate the monitor map 189 for a specific type of vehicle that is maintained using the tool 100.

[0129] According to an example embodiment, the processor 102 may determine a monitor identifier from the monitor identifiers 170 in the test drive script 160 and determine a monitor name for the determined monitor identifier from the monitor name 191. The processor 102 may request and receive a status value of the monitor from the vehicle 412 by transmitting at least the monitor identifier associated with the monitor. Thereafter, the processor 102 may populate the GUI with a ready monitor display portion including the monitor name and the monitor status, both of which are associated with the monitor identifier sent to the vehicle.

[0130] Next, Fig.11 A test drive script diagram 194 according to an example embodiment is shown. The test drive script diagram 194 may be contained in a memory, such as memory 104, 260. In particular, the test drive script diagram 194 may be contained in a test drive script 126. The processor 102 may request and receive a test drive script by determining a test drive script associated with one or more identifiers, which are associated with the test drive script. As an example, the one or more identifiers associated with the test drive script 195 may include a vehicle type identifier 196, a system identifier 197, a component identifier 198, and / or a diagnostic trouble code (DTC) identifier 199. In some embodiments, one or more test drive scripts may be associated with multiple components. Those one or more test drive scripts may be used when multiple components are repaired on a vehicle or for other reasons. Fig.19 A GUI 602 is shown, configured to allow a user of the tool 100 to enter a system identifier, a component identifier, and a DTC. In an embodiment using the GUI 602, a vehicle type has already been entered.

[0131] Next, Fig.12 1 shows test drive status data 200 related to the test drive script 160. The test drive status data 200 may be stored in the TDS state 132. Fig.12 As shown, the test drive status data 200 includes the driving cycle program number 162 (such as Figure 8 The test drive status data 200 also includes a drive cycle program status 202, that is, the status of each drive cycle program of the test drive script 160. As an example, the drive cycle status may be "not started", "in progress", "stopped" or "completed". The test drive status data 200 includes PID parameters 203. The test drive status data 200 further includes monitor pass (M / P) status data 204, and monitor fail (M / F) status data 205. Fig.12 As shown, all drive cycle program states 202 are “Not Started.” Therefore, no PID parameters for the test drive script 160 have been received, and all M / P status data 204 and all M / F status data 205 indicate None because no monitor has been checked yet.

[0132] Next, Fig.13 Test drive status data 206 related to the test drive script 160 is shown. The test drive status data 206 may be stored in the TDS state 132. The test drive status data 206 is similar to the test drive status data 200, except that the state and PID parameter data of the DCP 1 have changed when the DCP 1 has started and is in progress. Fig.13 As shown, the PID parameters of PIDs 61, 77, 78, and 79 have been received, but monitors 25, 27, 30, 33, and 34 have not passed or failed. Figure 8 As shown, those are the monitors to be checked by DCP 1. Additionally, the PID parameters for DCPs 2 to 7 are not received, and the pass or fail of the monitors for DCPs 2 to 7 is not determined because DCPs 2 to 7 have not yet been started. Fig.13 Only a single parameter for each of the PIDs 61 , 77 , 78 , and 79 is shown, but the TDS status 132 may include multiple parameters for one or more PIDs for one or more drive cycle routines that have been at least partially executed.

[0133] Next, Fig.14 Test drive status data 207 related to the test drive script 160 is shown. The test drive status data 207 may be stored in the TDS state 132. Similar to the test drive status data 200, 206, the test drive status data 207 includes a drive cycle program number 201, a drive cycle program state 202, a PID parameter 203, an M / P state data 204, and an M / F state data 205. Fig.14As shown, the status of DCP 1 is completed and the status of DCP 2 is in progress. Fig.14 It is shown that the monitor associated with monitor ID 34 is passed as a result of and / or during the execution of DCP 1. Fig.14 It is also shown that the PID parameters of DCPs 3 to 7 are not received, and the pass or fail of the monitor of DCPs 3 to 7 is not determined because DCPs 3 to 7 have not yet started.

[0134] Next, Fig.15 The test drive status data 208 related to the test drive script 160 is shown. The test drive status data 208 may be stored in the TDS state 132. Similar to the test drive status data 200, 206, 207, the test drive status data 208 includes a drive cycle program number 201, a drive cycle program state 202, a PID parameter 203, an M / P state data 204, and an M / F state data 205. Fig.15 As shown, the status of DCP 1 and DCP 2 is completed, and the status of DCP 3 is in progress. Fig.15 It is shown that the monitor associated with monitor ID 34 passed as a result of and / or during execution of DCP 1, and the monitor associated with monitor ID 27 passed as a result of and / or during execution of DCP 2. Fig.15 It is also shown that the PID parameters for DCPs 4 to 7 are not received and the pass or fail of the monitor is not determined for DCPs 4 to 7 because DCPs 4 to 7 have not yet started.

[0135] C. Server computing system

[0136] Fig.16 2 is a block diagram of a system 250 according to one or more example embodiments. The system 250 includes a vehicle 412 with a vehicle system 20, the tool 414, a network 252, and a server 254. The network 252 may include a non-vehicle network or a multi-purpose network. The tool 414 within the system 250 may be as Figure 7 The vehicle 412 may be arranged like the vehicle 440, the vehicle 460, or any other vehicle or mobile machine described in this specification. The network 252 may include any wireless network and / or any wired network described in this specification, or another type or combination of two or more types of networks that allow the server 254 and the tool 414 to communicate with each other.

[0137] The server 254 includes a processor 256, a transceiver 258, a memory 260, and a data bus 262. The data bus 262 operably connects the processor 256, the transceiver 258, and / or the memory 260 to each other. In other words, the data bus 262 provides an operative connection between two or more of the processor 256, the transceiver 258, and / or the memory 260. In at least some embodiments, the server 254 also includes a power supply 264 and a housing 266. The power supply 264 can supply current to the processor 256, the transceiver 258, and / or the memory 260 using the power bus 268.

[0138] The above description of a processor refers to "any other processor discussed in this specification. Processor 256 is such a processor, so the above description refers to processor 256. Additionally, for processor 256, In an embodiment where the arrangement is like a multi-core microprocessor, the processor 256 may include one or more A processor having between four and twenty-eight cores. In at least some embodiments of server 254, processor 256 can be programmed to perform any of the functions described herein as being performed by server 254.

[0139] The above description of a transceiver refers to any other transceiver discussed in this specification. Transceiver 258 is such a transceiver, and thus the above description refers to transceiver 258.

[0140] The above description of memory refers to “any other memory discussed in this specification. Memory 260 is such a memory, so the above description refers to memory 260.

[0141] The above description of a power source refers to “any other power source discussed in this specification. Power source 264 is such a power source, and thus the above description refers to power source 264.

[0142] The housing 266 encloses at least a portion of the following items: the processor 256, the transceiver 258, the memory 260, the data bus 262, and / or the power supply 264. The housing 266 can support a substrate. In at least some example embodiments, at least a portion of the following items are mounted on and / or connected to the substrate of the housing 266: the processor 256, the transceiver 258, the memory 260, the data bus 262, and / or the power supply 264. In at least some embodiments, the housing 266 includes a rack and / or a cabinet having one or more shelves.

[0143] The memory 260 includes the CRPI 124, the test drive script 126, the timer 128, the maintenance status 130, the TDS status 132, the vehicle selection data 134, the vehicle scanner function 136, the PID map 138, the monitor map 140, the application 142, the diagnostic and repair data 144, the report 146 and the location data 148. The above description of the computer-readable data stored in the memory 104 applies to the computer-readable data in the memory 260. The server 256 can receive the location data generated at the tool 100 and then store the location data in the location data 148.

[0144] In at least some embodiments, the network 252 includes satellites of a global navigation satellite system (GNSS) configured to transmit signals that can be used by a processor (such as the processor 102 or a processor within an ECU in a vehicle 412, 440, 460) to determine the location of a receiver that receives signals from some GNSS satellites. The determined location can indicate the location of the vehicle 412, 440, 460, the location of the tool 100, or if the tool 100 is located within the vehicle 412, 440, 460, the location of both.

[0145] In embodiments where the application 142 in the tool 100 includes a browser, the processor 256 may output a GUI, such as any of the GUIs shown in the figures, to the network 252 for transmission to the tool 100. The processor 256 may receive data indicating the selection of a USC from within the GUI displayed on the display 116, as well as data received by the tool 100 from a vehicle connected to the tool 100 and other data so that the server 254 may include the maintenance status data 130 and the TDS status 132. The processor 256 may use at least the maintenance status 130 and / or the TDS data 132 to determine which GUI to provide to the tool 100 for display on the display 116.

[0146] III. Sample Operation

[0147] Fig.17 A flow chart depicting a set of functions 500 of a method according to one or more example embodiments is shown. Two or more functions of the set of functions 500 and / or a portion of two or more functions may, but not necessarily, be performed at the same time. The set of functions 500 may be performed by the one or more processors. For example, the set of functions 500 may be performed by one or more processors described in this specification.

[0148] Block 501 includes determining a test drive script to be executed during a test drive of a mobile machine while a tool monitors electronic systems in the mobile machine. The test drive script includes an ordered sequence of drive cycle programs. The ordered sequence of drive cycle programs begins with an initial drive cycle program and ends with a final drive cycle program. Each drive cycle program indicates a corresponding mobile machine state. The test drive script includes a first specific drive cycle program associated with both a first mobile machine state and a first condition related to a first specific mobile machine state.

[0149] As an example, determining the test drive script may include the processor determining one or more identifiers associated with the test drive script within the test drive script map 194, and then determining the test drive script associated with the one or more identifiers, such as the test drive script identified within the test drive script map 194. According to this example, the one or more identifiers may include a DTC. In some cases, the processor 102 may determine the DTC from a vehicle data message sent by the vehicle 412 to the tool 100. In other cases, the processor 102 may determine the DTC from a GUI, such as the GUI 602 shown in 19.

[0150] According to at least some embodiments, the first specific drive cycle program is an initial drive cycle program. According to at least some other embodiments, the first specific drive cycle program is a final drive cycle program. According to at least some other embodiments, the first specific drive cycle program is a drive cycle program after the initial drive cycle program and before the final drive cycle program.

[0151] Next, block 502 includes outputting a representation of at least a portion of the test drive script (or, more simply, a TDS representation). Outputting the TDS representation may include the processor 102 outputting the TDS representation to the user interface 108. In at least some embodiments, outputting the TDS representation includes the display 116, the auditory output device 120, and / or the tactile feedback device 122 outputting the TDS representation. As an example, outputting the TDS representation using the tactile feedback device 122 may include activating the tactile feedback device 122 to generate a first specific output to indicate success during a drive cycle procedure (e.g., the readiness monitor has not failed), a second specific output to indicate a failure during a drive cycle procedure (e.g., the readiness monitor has failed), a third specific output to indicate when the next drive cycle procedure begins or ends, and / or a fourth specific output to indicate an amount of time that has passed or remains in a drive cycle procedure that is currently being executed (e.g., outputting a number of pulses to indicate that the same number of minutes remain in the current drive cycle procedure).

[0152] In one aspect, the TDS representation may include only a portion of the test drive script due to the size of the test drive script and the size of the display 116. For example, although the test drive script includes more than three drive cycle procedures, the display 116 may be limited to displaying a maximum of three drive cycle procedures. In another aspect, the TDS representation may include only a portion of the test drive script because some other portion of the test drive script is not currently needed. For example, the TDS representation may include an auditory portion indicating a TDS instruction of the test drive script that will be executed immediately after the execution of a previous TDS instruction outputted via the auditory output device 120 has completed.

[0153] Next, block 503 includes determining one or more of: state information corresponding to achieving a first specific mobile machine state or state information corresponding to achieving a first condition related to the first specific mobile machine state. Examples of state information described elsewhere in this specification are applicable to the state information of block 503 .

[0154] Next, block 504 includes outputting one or more of status information corresponding to achieving the first specific mobile machine state or status information corresponding to achieving the first condition related to the first specific mobile machine state. Outputting one or both of the above status information may include the processor 102 providing the status information to the user interface 108. The status information may be displayed within a GUI, such as any one or more of the GUIs shown in the figures.

[0155] According to a first further embodiment including performing the set of functions 500, the first condition related to the first specific mobile machine state includes a time condition. Determining state information corresponding to achieving the first specific mobile machine state includes determining first state information. The first state information indicates whether the mobile machine is operating in the first specific mobile machine state. Determining state information corresponding to achieving the first condition related to the first specific mobile machine state includes determining second state information. The second state information corresponds to achieving the time condition.

[0156] In at least some examples of a first further embodiment including performing the set of functions 500, determining the first state information includes the one or more processors determining that the mobile machine is operating in a first specific mobile machine state. Additionally, the second state information indicates one or more of: an amount of time the mobile machine has been operating in the first specific mobile machine state, an additional amount of time the mobile machine will operate in the first specific mobile machine state, or a minimum amount of time the mobile machine will operate in the first specific mobile machine state.

[0157] In at least some other examples of the first further embodiment including performing the set of functions 500, determining, by the one or more processors, that the mobile machine switches from an operating state that is not the first specific mobile machine state to the first specific mobile machine state. Additionally, a timer for determining second state information corresponding to the implementation time condition is started, by the one or more processors, in response to determining that the mobile machine switches from an operating state that is not the first specific mobile machine state to the first specific mobile machine state.

[0158] In at least some other examples of the first further embodiment including performing the set of functions 500, the method further includes outputting, by the one or more processors, a request to an electronic system in the mobile machine, and receiving, by the one or more processors, a response from the electronic system in the mobile machine in response to the request. In addition, the response from the electronic system in the mobile machine includes a parameter identifier (PID) and a parameter value associated with the PID. Additionally, determining the first state information includes the one or more processors determining whether the parameter value associated with the PID exceeds a parameter value threshold associated with the first specific mobile machine state.

[0159] According to a second further embodiment including performing the set of functions 500, the first condition related to the first specific mobile machine state includes a spatial condition. Additionally, determining the state information corresponding to achieving the first specific mobile machine state includes determining the first state information. Moreover, the first state information indicates whether the mobile machine is operating in the first specific mobile machine state. Furthermore, determining the state information corresponding to achieving the first condition related to the first specific mobile machine state includes determining the second state information. Furthermore, the second state information corresponds to achieving the spatial condition.

[0160] In at least some examples of a second further embodiment including performing the set of functions 500, determining the first state information includes the one or more processors determining that the mobile machine is operating in a first specific mobile machine state. Furthermore, the second state information indicates one or more of: a distance that the mobile machine has traveled while operating in the first specific mobile machine state, a distance that the mobile machine has to travel while operating in the first specific mobile machine state, or a minimum distance that the mobile machine will travel while operating in the first specific mobile machine state.

[0161] In at least some other examples of a second further embodiment including performing the set of functions 500, the method includes determining, by the one or more processors, that the mobile machine switches from an operating state that is not the first specific mobile machine state to the first specific mobile machine state. Additionally, the method includes initiating, by the one or more processors, an odometer for determining second state information corresponding to the realization of the spatial condition in response to determining that the mobile machine switches from an operating state that is not the first specific mobile machine state to the first specific mobile machine state.

[0162] In at least some other examples of the second further embodiment of performing the set of functions 500, the method further includes outputting, by the one or more processors, a request to an electronic system in the mobile machine. The method also includes receiving, by the one or more processors, a response from the electronic system in the mobile machine in response to the request. In addition, the response from the electronic system in the mobile machine includes the PID and a parameter value associated with the PID. In addition, determining the first state information includes the one or more processors determining whether the parameter value associated with the PID exceeds a parameter value threshold associated with the first specific mobile machine state.

[0163] According to a third further embodiment including performing the set of functions 500, the method further includes determining, by the one or more processors, a speed of the mobile machine. The method also includes determining, by the one or more processors, whether the speed of the mobile machine exceeds a threshold speed. According to this embodiment, the mode of outputting the status information is conditional on whether the speed of the mobile machine exceeds a threshold speed. In one aspect, if the speed of the mobile machine exceeds the threshold speed, the mode of outputting the status information is a restricted mode. In another aspect, if the speed of the mobile machine does not exceed the threshold speed, the mode of outputting the status information is an unrestricted mode.

[0164] According to a fourth further embodiment including executing the set of functions 500, the test drive script includes a second specific drive cycle program associated with both the second specific mobile machine state and the second condition related to the second specific mobile machine state. In addition, the method of this embodiment further includes determining, by the one or more processors, that the first specific drive cycle program has ended, and in response to determining that the first specific drive cycle program has ended, outputting, by the one or more processors, an indication that the second specific drive cycle program is a current drive cycle program to be executed. In at least some examples of the third further embodiment, the first specific drive cycle program is an initial drive cycle program or the second specific drive cycle program is a final drive cycle program.

[0165] According to a fifth further embodiment including performing the set of functions 500, the test drive script is associated with a fault code set active by an electronic system in the mobile machine, and outputting a representation of at least a portion of the test drive script includes displaying a representation of the first specific drive cycle program on a display of the tool. In addition, the method of this embodiment further includes displaying a status indicator associated with a parameter identifier (PID) and a status indicator associated with a readiness monitor on the display of the tool, the electronic system in the mobile machine being configured to output the PID, and the electronic system in the mobile machine being configured to check whether the readiness monitor is in a ready state. The PID and the readiness monitor may be associated with the fault code.

[0166] In at least some cases, the method of the fifth further embodiment includes receiving a first parameter value by the one or more processors. The first parameter value is output by an electronic system in the mobile machine and is associated with the PID. The method also includes determining, by the one or more processors, whether the first parameter value is within a parameter value range defined for both the PID and the first specific driving cycle program. In one aspect, if the one or more processors determine that the first parameter value is within the parameter value range, displaying a status indicator for the PID includes displaying the PID, the first parameter value associated with the PID, and an indication that the first parameter value associated with the PID is within the parameter value range. In another aspect, if the one or more processors determine that the first parameter value is not within the parameter value range, displaying a status indicator for the PID includes displaying the PID, the first parameter value associated with the PID, and an indication that the first parameter value associated with the PID is not within the parameter value range. The indication that the first parameter value associated with the PID is within the parameter value range is different from the indication that the first parameter value associated with the PID is not within the parameter value range.

[0167] According to a sixth further embodiment including performing the set of functions 500, the first specific mobile machine state includes a thermal state of a mobile machine component. Additionally, determining state information corresponding to one or both of achieving the first specific mobile machine state and the first condition related to the first specific mobile machine state includes determining a temperature related to the mobile machine component. Additionally, outputting state information corresponding to one or both of achieving the first specific mobile machine state and the first condition related to the first specific mobile machine state includes outputting the temperature related to the mobile machine component.

[0168] According to a seventh further embodiment including performing the set of functions 500, the method further includes outputting, by the one or more processors, a first message to the electronic system in the mobile machine prior to executing the initial drive cycle program, the first message requesting the electronic system in the mobile machine to clear all fault codes set by the electronic system in the mobile machine. Additionally, the method includes receiving, by the one or more processors, a second message from the electronic system in the mobile machine in response to outputting the first message, the second message indicating a status of the electronic system in the mobile machine clearing fault codes set by the electronic system in the mobile machine. Additionally, the method includes outputting, by the one or more processors, data indicating a status of the electronic system in the mobile machine clearing fault codes set by the electronic system in the mobile machine.

[0169] According to an eighth further embodiment including performing the set of functions 500, the test drive script is associated with a readiness monitor, and the electronic system in the mobile machine is configured to check whether the readiness monitor is in a ready state. In addition, determining the state information corresponding to achieving the first specific mobile machine state includes the one or more processors determining that the readiness monitor is in the ready state. In addition, outputting the state information corresponding to achieving the first specific mobile machine state includes outputting an indication that the readiness monitor is in the ready state so as to notify the driver of the mobile machine that the test drive of the mobile machine can be ended.

[0170] In at least some examples of the eighth further embodiment including performing the set of functions 500 , the outputting of the indication that the readiness monitor is in the ready state occurs prior to completing the final drive cycle procedure.

[0171] According to a ninth further embodiment including performing the set of functions 500, the test drive script is associated with a readiness monitor, and the electronic system in the mobile machine is configured to check whether the readiness monitor is in a ready state. In addition, the readiness monitor is associated with a fault code, and the electronic system in the mobile machine is configured to set the fault code to active. In addition, determining the state information corresponding to achieving the first specific mobile machine state includes the one or more processors determining that the electronic system in the mobile machine has set the fault code to active before the final drive cycle procedure is completed. In addition, outputting the state information corresponding to achieving the first specific mobile machine state includes outputting an indication that the electronic system in the mobile machine has set the fault code to active so as to notify the driver of the mobile machine that the test drive of the mobile machine may end before the final drive cycle procedure is completed.

[0172] According to a tenth further embodiment comprising performing the set of functions 500 , the first specific drive cycle program is an initial drive cycle program, a final drive cycle program, or an intermediate drive cycle program between the initial drive cycle program and the final drive cycle program.

[0173] According to an eleventh further embodiment including executing the group of functions 500, the one or more processors include: one or more processors located within the tool, one or more processors located within a server operably connected to the tool, or one or more processors located within the tool and one or more processors located within a server operably connected to the tool.

[0174] According to a twelfth further implementation scheme including executing the group of functions 500, a representation of at least a portion of the test drive script is output and one or more of the following: status information corresponding to the realization of a first specific mobile machine state or status information corresponding to the realization of a first condition involving the first specific mobile machine state is output, including displaying a graphical user interface on a display, the graphical user interface including: a representation of at least a portion of the test drive script, status information corresponding to the realization of the first specific mobile machine state, and / or status information corresponding to the realization of the first condition involving the first specific mobile machine state.

[0175] According to a thirteenth further implementation scheme including executing the group of functions 500, a representation of at least a portion of the test drive script is output and one or more of the following: status information corresponding to the realization of a first specific mobile machine state or status information corresponding to the realization of a first condition involving the first specific mobile machine state is output, including using one or more speakers to output an audible sound indicating the representation of at least a portion of the test drive script, the status information corresponding to the realization of the first specific mobile machine state and / or the status information corresponding to the realization of the first condition involving the first specific mobile machine state.

[0176] According to a fourteenth further embodiment including performing the group of functions 500, the method includes determining, by the one or more processors, that the mobile machine is a mobile machine of a specific type. The method also includes determining, by the one or more processors, that the tool is operating in a diagnostic mode. The method also includes displaying a first GUI on a display of the tool after determining that the tool is operating in the diagnostic mode. The first GUI includes an indication that the tool is operating in the diagnostic mode. In addition, the method includes determining, by the one or more processors, that the tool is changing from operating in the diagnostic mode to operating in the repair mode. Additionally, the method includes displaying a second GUI on the display of the tool after displaying the first GUI and determining that the tool is changing from operating in the diagnostic mode to operating in the repair mode. The second GUI includes an indication that the tool is operating in the repair mode. The method also includes determining, by the one or more processors, that the tool is changing from operating in the repair mode to operating in the test drive mode. In addition, the method also includes displaying a third GUI on the display after displaying the second GUI and determining that the tool is changing from operating in the repair mode to operating in the test drive mode. The third GUI includes an indication that the tool is operating in a test drive mode, a representation of at least a portion of a test drive script, and one or more of: status information corresponding to achieving a first specific mobile machine state or status information corresponding to achieving a first condition involving a first specific mobile machine state. In addition, the method includes determining, by the one or more processors, that the tool transitions from operating in a test drive mode to operating in a post-repair report mode. Further, the method includes displaying a fourth GUI on the display after displaying the third GUI and determining that the tool transitions from operating in a test drive mode to operating in a post-repair report mode. The fourth GUI includes an indication that the tool is operating in a post-repair report mode. The first GUI, the second GUI, the third GUI, and the fourth GUI include information corresponding to a specific type of mobile machine.

[0177] According to a fifteenth further embodiment including executing the group of functions 500, outputting one or more of the following: status information corresponding to achieving a first specific mobile machine state or status information corresponding to achieving a first condition related to the first specific mobile machine state, including transmitting a data message through the tool, the data message including a request for an electronic control unit in the mobile machine to activate a tactile feedback component of the mobile machine with a specific signature, the specific signature being related to achieving the status information corresponding to the first specific mobile machine state or achieving the status information corresponding to the first condition related to the first specific mobile machine state. An advantage of using the tactile feedback component of the mobile machine to provide tactile feedback is that a separate wearable tactile feedback device is not required in this embodiment. In addition, providing tactile feedback through the tactile feedback component of the mobile machine or the wearable tactile feedback device during the test drive is beneficial because the tactile feedback does not require the driver to take his eyes off the road, nor does it require concern that noisy audible conditions during the test drive, such as audible noise from other mobile machines near the mobile machine, will interfere with any status information output in audible form.

[0178] According to a sixteenth further implementation scheme including executing the group of functions 500, one or more of the following are output: status information corresponding to the realization of a first specific mobile machine state or status information corresponding to the realization of a first condition involving the first specific mobile machine state, including transmitting a signal to the wearable tactile feedback device through the tool, the signal indicating that the wearable tactile feedback device is required to activate a tactile feedback component with a specific signature, which is related to the status information corresponding to the realization of the first specific mobile machine state or the status information corresponding to the realization of the first condition involving the first specific mobile machine state.

[0179] IV. Sample Graphical User Interface

[0180] Next, Figures 18 to 33 Example graphical user interfaces (GUIs) 600 through 630 are shown. Figures 18 to 33One or more of the GUIs in the may include a natural user interface (NUI) that includes one or more user interface elements that are combined with another user interface component and a processor to operate using voice recognition, motion detection, gesture detection, and / or auditory output. In one aspect, the processor 102 is configured to output the GUIs 600 to 630 to the display 116. The display 116 is configured to display the GUIs 600 to 630. One or more of the GUIs 600 to 630 may include a user selectable control (USC). The processor 102 is configured to detect the selection of a USC and cause one or more functions to be performed in response to determining that a USC has been selected. The selection of a USC may be performed through the input device 118. For example, a USC may be selected using a button key of the input device 118 or by touching the display 116 configured as a touch screen display. In another aspect, the processor 256 is configured to output the graphical user interfaces 600 to 630 to the network 252 for subsequent output to a tool (such as the tool 100).

[0181] Each of the GUIs 600 to 630 includes a GUI description 650. The GUI description 650 provides an indication of the subject matter of the GUI that includes the GUI description 650. Examples of GUI themes are provided below when discussing specific GUIs. Each of the GUIs 600 to 630 also includes a vehicle identifier 666. Fig.18 As shown, the vehicle identifier 666 uses the text "No Active Vehicle" to indicate that neither a vehicle type nor a specific vehicle has been selected. Other text or symbols may also be used to make the same indication. Figures 19 to 33 As shown, the vehicle identifier 666 indicates the type of vehicle selected for maintenance using the tool 100. In at least some embodiments, the vehicle identifier 666 can indicate a specific vehicle of the type of vehicle selected for maintenance using the tool 100.

[0182] Each of the GUIs 600 to 630 also includes an indicator 668 and an indicator 670 to indicate a hardware state related to the tool 100. As an example, the indicator 668 indicates whether the transceiver 106 is connected to a wireless communication network, such as a wireless vehicle network or a wireless non-vehicle network. As another example, the indicator 670 indicates whether the transceiver 106 is connected to a wired communication network, such as a wired vehicle network or a wired non-vehicle network. In at least some embodiments, a backslash 672 through the indicator 668 indicates that the tool 100 is not connected to a wireless communication network, and a backslash 672 without passing through the indicator 668 indicates that the tool 100 is connected to a wireless communication network. Similarly, a backslash 674 through the indicator 670 indicates that the tool 100 is not connected to a wired communication network, and a backslash 674 without passing through the indicator 670 indicates that the tool 100 is connected to a wired communication network.

[0183] GUIs 600 to 630 include some common GUI USCs. Those common USCs include a Fallback USC 652. In response to determining that the Fallback USC 652 is selected, the processor 102 may cause the display 116 to display a GUI that was displayed immediately before displaying the GUI containing the selected Fallback USC 652. The Fallback USC 652 may include an indicator that indicates a function that is performed when and / or in response to selecting the Fallback USC 652. As an example, the indicator may include text (such as "return" or "exit") and / or a symbol (such as an arrow).

[0184] The common GUI USC also includes a home screen USC 654. In response to determining that the home screen USC 654 is selected, the processor 102 may cause the display 116 to display the home screen GUI instead of displaying the GUI including the selected home screen USC 654.

[0185] The common GUI USC also includes an expand menu USC 658. In response to determining that the expand menu USC 658 is selected, the processor 102 is configured to display the menu in an expanded mode if the menu is currently available for the currently displayed GUI and is not currently expanded. The common GUI USC also includes a collapse menu USC 656. In response to determining that the collapse menu USC 656 is selected, the processor 102 is configured to display the menu in a collapsed mode if the menu is currently available for the currently displayed GUI and is currently expanded.

[0186] The universal GUI USC also includes a technical maintenance bulletin (TSB) USC 660. In response to determining that the TSB USC 660 is selected, the processor 102 is configured to search and / or request a TSB for a determined vehicle type or a specific vehicle. In at least some embodiments, if no vehicle is identified and / or no TSB for an identified vehicle type or a specific vehicle is available, the TSB USC 660 is not selectable. The processor 102 may cause a request for a TSB to be sent to the server 254 via the network 252. The server 254 may search for a TSB in the memory 260 in response to the request for a TSB to return to the tool 100.

[0187] The common GUI USC also includes a change vehicle USC 662. The change vehicle USC 662 can be selected to display a U / I screen with the vehicle selection data 134 for inputting one or more identifiers of a vehicle type and / or one or more identifiers of a specific vehicle. For example, the processor 102 can cause the display 116 to display the GUI 600 in response to determining that the change vehicle USC 662 has been selected.

[0188] The common GUI USC also includes a View Record USC 664. In some embodiments, if a specific vehicle has not yet been identified and / or if a vehicle record for a specific vehicle that has been identified is not available, the View Record USC 664 is not selectable. The vehicle record for a specific vehicle that has been identified may indicate information about previous instances of maintaining the specific vehicle that has been identified. The processor 102 may need identifiers beyond the year, make, and model of the vehicle to identify a specific vehicle. As an example, additional identifiers may include a customer name, a full VIN, a license plate number, and other additional identifiers.

[0189] GUI 600 may include a cursor 676 that is movable to point to a USC or another item of GUI 600. When cursor 676 is placed on a USC or other item of GUI 600, processor 102 may detect that the USC or other item of GUI 600 is selected. Figures 19 to 33 The illustrated GUI may also include a cursor similar to cursor 676 for selecting items of the GUI. For embodiments where display 116 includes a touch screen display, Figures 18 to 33 The GUI shown may or may not include a cursor.

[0190] Next, Fig.18 Specifically shown is GUI depiction 650, which indicates that GUI 600 is related to selecting a vehicle type or a specific vehicle. Fig.18As shown, the GUI 600 includes a year selection menu 680 in which a year selector 692 representing the year 2014 has been selected. The GUI 600 includes a brand selection menu 682 in which a brand selector 694 representing the Chevrolet brand has been selected. The GUI 600 includes a model selection menu 684 in which a model selector 696 representing the Tahoe model has been selected. The year selection menu 680 includes a scroll bar 686 to cause the year selection menu 680 to display years that are not currently displayed in the year selection menu 680. Similarly, the brand selection menu 682 includes a scroll bar 688 to cause the brand selection menu 682 to display brands that are not currently displayed in the brand selection menu 682. Similarly, the model selection menu 684 includes a scroll bar 690 to cause the model selection menu 684 to display models that are not currently displayed in the model selection menu 684.

[0191] In at least some embodiments, upon selecting a year from the year selection menu 680, the make selection menu 682 is populated with the vehicle make. Similarly, in at least some embodiments, upon selecting a year from the year selection menu 680 and selecting a brand from the make selection menu 682, the model selection menu 684 is populated with the vehicle model. In alternative embodiments, the year selection menu 680 is in the GUI without the make selection menu 682 and the model selection menu 684, and the make selection menu 682 is in the GUI without the year selection menu 680 and the model selection menu 684, and the model selection menu 684 is in the GUI without the year selection menu 680 and the brand selection menu 682.

[0192] In at least some embodiments, GUI 600 or a separate GUI includes a feature selection menu to select the type of vehicle being selected or other characteristics of a particular vehicle. As an example, other characteristics of the type of vehicle may include drive type (e.g., two-wheel drive (2WD), four-wheel drive (4WD), or all-wheel drive (AWD)), engine displacement (e.g., 3.8 liters (L) or 5.7 liters), or transmission type (e.g., automatic, automatic with overdrive, 3-speed manual, or 4-speed manual).

[0193] In other embodiments, other characteristics of the vehicle type may be selected using Previous USC 691, Yes USC 693, and Next USC 695. After selecting a set of characteristics (such as year, make, and model), the GUI 600 may display a vehicle type identifier 689, such as 2014 Chevrolet Tahoe (4WD), where "4WD" is a supplemental characteristic that may be selected using Yes USC 693. Previous USC 691 may be used to cause the GUI 600 to display a different vehicle type identifier, such as 2014 Chevrolet Tahoe (2WD), and Next USC 695 may be used to cause the GUI 600 to display yet another different vehicle type identifier, such as 2014 Chevrolet Tahoe (AWD). Selecting Previous USC 691 or Next USC 695 may cause the vehicle type identifier 689 to transition to a different vehicle type identifier.

[0194] The GUI 600 also includes a VIN USC 678 for inputting an identifier of a particular vehicle. As an example, the VIN USC 678 can be used to input or enter a vehicle identification number (VIN) associated with a particular vehicle. As another example, the VIN USC 678 can be used to cause the vehicle communication transceiver 152 to request a VIN from an ECU in the vehicle 412. The processor 102 can receive the requested VIN and determine at least the year, make, model, and serial number of the particular vehicle from the VIN.

[0195] The GUI 600 includes a vehicle selector USC 677 for capturing a visual indication of a particular vehicle. As an example, in response to the selection of the vehicle selector USC 677, the processor 102 may cause the camera 98 to capture an image (such as an image of a code 681 representing a VIN) and cause the GUI (such as the GUI or a different GUI) to display a window 679 showing an image of the code 681 and displaying a representation of an alphanumeric representation 683 of the VIN determined by decoding the code 681 by the processor 102. As another example, in response to the selection of the vehicle selector USC 677, the processor 102 may cause the scanner 154 to generate an image (such as an image of the code 681) and cause the GUI (such as the GUI or a different GUI) to display a window 679 showing an image of the code 681 and displaying a representation of an alphanumeric representation 683 of the VIN determined by decoding the code 681 by the processor 102. In at least some embodiments, the processor 102 may display the window 679 on a different GUI.

[0196] Next, Fig.19GUI 602 is shown. GUI description 650 indicates that GUI 602 involves selecting a test drive script. Fig.19 As shown, GUI 602 includes a symptom selection menu 700. In at least some embodiments, symptom selection menu 700 includes one or more vehicle system selectors, such as vehicle system selector 702. As an example, vehicle system selector 702 can represent an engine system. GUI 602 also includes one or more component selectors, such as component selector 704. As an example, component selector 704 can represent a component of an engine system, such as an oxygen sensor. GUI 602 also includes one or more DTC selectors, such as DTC selector 706. As an example, a DTC selector can represent a P0171 DTC, which represents an engine system fault in which the exhaust pipe group is discharging exhaust gases, indicating that the engine is running lean.

[0197] Fig.19 It is also shown that the GUI 602 may include a Complaint USC 708 for entering a customer complaint regarding a vehicle type or a specific vehicle. As an example, the Complaint USC 708 may be used to enter or type a customer complaint regarding a specific vehicle. As an example, a customer complaint entered via the Complaint USC 708 may indicate that the vehicle did not pass an emissions test. According to this example, the processor 102 may refer to the following example. Fig.11 The test drive script diagram 194 is shown to identify a test drive script for a vehicle type or a specific vehicle and a customer complaint, such as a test drive script 52 for vehicle type A, engine system (because the complaint involves engine emissions), and all components (because the complaint does not identify any specific component). The GUI 602 includes an OK USC 710 to indicate approval of the system / component / DTC or customer complaint. The GUI 602 includes a Cancel USC 712. The Cancel USC 712 can be used to clear any selections previously made via the GUI 602.

[0198] Next, Fig. 20 GUI 604 is shown. As an example, Fig. 20 as well as Figures 21 to 33 The GUI description 650 in FIG. 1 indicates that the GUI is for performing smart diagnostics related to symptoms (e.g., DTCs) using a scanner mode of the tool 100 (e.g., a mode in which the processor 102, 256 is configured to execute a vehicle scanner function from the vehicle scanner function 136). Alternatively, as Figures 20 to 33The GUI description 650 in any one or more of the illustrated GUIs may indicate different GUI themes while other content of any of the GUIs is displayed on the display 116. In at least some embodiments, performing intelligent diagnostics may include the processor 102, 236 searching the diagnostic and repair data 144 to determine if, in the example shown, Figures 20 to 33 The GUI shown is populated with data to guide the user in maintaining the vehicle.

[0199] GUI 604, and each GUI numbered between and including GUI 606 and GUI 630, includes a set of vehicle maintenance mode indicators 730, the set of vehicle maintenance mode indicators 730 including four vehicle maintenance mode indicators. The set of vehicle maintenance mode indicators 730 includes a first vehicle maintenance mode indicator 732 indicating a diagnostic maintenance mode, a second vehicle maintenance mode indicator 734 indicating a repair maintenance mode, a third vehicle maintenance mode indicator 736 indicating a test drive maintenance mode, and a fourth vehicle maintenance mode indicator 738 indicating a post-repair report maintenance mode (i.e., a report maintenance mode after repair). Fig. 20 , the third vehicle maintenance mode indicator 736 is highlighted to indicate that the tool 100 is currently operating in the test drive maintenance mode. Figures 21 to 30 is also highlighted, while the fourth vehicle maintenance mode indicator 738 is Figure 31 to Figure 33 is highlighted.

[0200] The GUI 604 also includes a DTC function USC 740, a start test drive USC 742, a smart data USC 744, a drive cycle program 746 USC, and a monitor USC 748. In response to determining that the DTC function USC 740 is selected from the GUI 604, the processor 102 sends a VDM to the ECU in the vehicle 412, requesting that the DTCs within the ECU be cleared. In response to determining that the start test drive USC 742 is selected, the processor 102 determines the TDS to be performed for the vehicle type identified by the vehicle identifier 666, and outputs a representation of at least a portion of the determined TDS. In response to determining that the smart data USC 744 is selected, the processor 102 outputs a GUI showing pre-repair and post-repair data. The pre-repair data may include data received by the processor 102 from the vehicle when the tool is operating in a diagnostic maintenance mode. The post-repair data may include data received by the processor 102 from the vehicle when the tool is operating in a test drive maintenance mode. An example GUI displaying pre-repair data and post-repair data is shown in FIG. Figure 31 to Figure 33In response to determining that the drive cycle program 746 USC is selected, the processor 102 can output a GUI to show the vehicle conditions required to run the readiness monitor. In response to determining that the monitor USC 748 is selected, the processor 102 can output a GUI to view the readiness monitor and observe the performance of the specific vehicle emission control system.

[0201] The GUI description 650 further indicates DTC P0171. The tool 100 may have determined DTC P0171 when the tool 100 was operating in the diagnostic maintenance mode. For example, during the diagnostic maintenance mode, the GUI may include a DTC function USC 740 to request a DTC. In response to selecting the version of the DTC function USC 740, the processor 102 sends a VDM to an ECU in the vehicle 412, requesting data indicating which DTCs are set in the ECU.

[0202] Next, Fig.21 GUI 606 is shown. GUI 606 is the same as GUI 604, except that DTC function USC 740 indicates that all DTCs in the ECU have been cleared (i.e., "All Codes Cleared!"). GUI 606 may be displayed in response to processor 102 receiving a VDM (from an ECU whose codes the tool 100 requested to clear) indicating that all DTCs in the ECU have been cleared.

[0203] Next, Fig. 22 GUI 608 is shown. GUI 608 includes parameter display portion 760, ready monitor display portion 772, and TDS display portion 784.

[0204] Each parameter display portion 760 as shown includes one or more PIDs and PID parameter indicators (PPIs). Each PPI includes a text representation of the PID and a parameter indicator associated with the PID. In some cases, the parameter indicator is blank or empty to indicate that the parameter associated with the PID has not yet been received. In other cases, the parameter indicator contains a numeric value. In other cases, the parameter indicator contains a non-numeric text value, such as "ON" or "OFF". If applicable, the PPI may include a unit symbol, such as "°F" representing Fahrenheit, "℃" representing Celsius, "kPa" representing kilopascals, "PSI" representing pounds per square inch, "V" representing volts, "%" representing percentages, or "RPM" representing revolutions per minute. Each PPI is displayed using a number of pixels of the display 116. According to an exemplary embodiment, the parameter display portion 760 included in any GUI may include any number of PPIs adapted within the parameter display portion 760.

[0205] exist Fig. 22 , the parameter display portion 760 includes PPI 143 related to the engine speed PID of the vehicle 412, PPI 145 related to the ambient air temperature PID of the vehicle 412, PPI 111 related to the engine coolant temperature PID of the vehicle 412, and PPI 147 related to the throttle position PID of the vehicle 412. The parameter display portion 760 of the GUI may include more or fewer PPIs and / or PPIs related to different PIDs. A processor (such as processor 102 or 256) may determine which PPIs to include within the parameter display portion 760 by determining which PIDs are associated with the current drive cycle program of the TDS 160 being executed and which PPIs are associated with those PIDs.

[0206] Reference Figure 8 PID 311 includes four PIDs (i.e., PIDs 61, 77, 78, 79) associated with DCP 1, which is the current DCP to be executed when GUI 608 is displayed. Fig. 9 The illustrated PID map 180 shows that PPIs 143, 145, 111, 147 are associated with PIDs 61, 77, 78, 79, respectively. A processor, such as processor 102, 256, may populate GUI 608 with PPIs 143, 145, 111, 147 after referencing TDS 160 and PID map 180.

[0207] In the figures, PPIs having parameters determined to be within a predetermined range for an associated PID are represented using forty-five degree cross-hatching relative to the top to the bottom of at least a portion of the PPI, such as Fig. 22 The PPI 147 is shown. In the figure, the PPI having a parameter determined to be outside the predetermined range of the associated PID is represented by horizontal hatching from left to right of the PPI, such as Fig. 22 PPI 143 is shown. In at least some embodiments, the GUI can show PPIs with shading to represent different colors to indicate whether the parameters displayed in a particular PPI are within or outside the predetermined range of the associated PID. For example, a green PPI can indicate that the parameters within the PPI are within the predetermined range, while a red PPI can indicate that the parameters within the PPI are outside the predetermined range. A PPI without shading can (but does not necessarily) indicate that a predetermined range or threshold is not associated with the PID of the PPI, and / or the PID associated with the PPI has not passed the vehicle check to determine whether the readiness monitor has passed or failed during the current drive cycle procedure.

[0208] exist Fig. 22, the ready monitor display portion 772 includes RMI 83 related to a fuel system monitor of the vehicle 412, RMI 99 related to a catalyst monitor of the vehicle 412, RMI 87 related to an oxygen sensor heater monitor of the vehicle 412, RMI 101 related to a heated catalyst monitor of the vehicle 412, and RMI 93 related to an oxygen sensor monitor of the vehicle 412. The ready monitor display portion 772 of the GUI may include more or fewer RMIs and / or RMIs related to different combinations of monitors. Each RMI is displayed using a number of pixels of the display 116.

[0209] Reference Figure 8 , monitor ID 309 includes five monitor IDs (i.e., monitor IDs 25, 27, 30, 33, 34) associated with DCP 1, which is the current DCP to be executed when GUI 608 is displayed. Fig.10 Monitor map 189 is shown showing that RMIs 83, 99, 87, 101, 93 are respectively associated with monitor IDs 25, 27, 30, 33, 34. A processor, such as processors 102, 256, may populate GUI 608 with RMIs 83, 99, 87, 101, 93 after referencing TDS 160 and monitor map 189.

[0210] Each ready monitor display portion 772 as shown includes one or more ready monitor indicators (RMIs). Each RMI includes a textual representation of the vehicle monitor and the status of the vehicle monitor. As an example, the status of the vehicle monitor may be "Not Started or In Progress", "Passed", or "Failed". In the accompanying drawings, the Not Started or In Progress status is represented using an RMI without horizontal hatching and without cross hatching, such as Fig. 22 The RMI 83 is shown. In the drawings, the RMI pass state is indicated using cross-hatching at forty-five degrees relative to the top to the bottom of the RMI, such as Fig.24 The RMI 101 shown. In the figures, the failure state of the RMI is represented by horizontal hatching from left to right of the RMI, such as in Fig.2483 shown in the figure. In at least some embodiments, the GUI can show the RMI with different colors to indicate that the monitoring state is "not started or in progress", "passed" or "failed". For example, a white RMI can indicate that the state of the monitor associated with the RMI is not started or in progress. A green RMI can indicate that the state of the monitor associated with the RMI is passed. A red RMI can indicate that the state of the monitor associated with the RMI is failed. According to an example embodiment, the ready monitor display portion 772 included in any GUI can include any number of RMIs adapted in the ready monitor display portion 772.

[0211] Each TDS display section 784 in the GUI includes one or more drive cycle programs. Fig. 22 As shown, the TDS display portion 784 includes drive cycle programs 790, 792, 794. Each DCP is displayed using a number of pixels of the display 116. In at least some embodiments, the current DCP program to be executed is highlighted in some manner. Fig. 22 As shown, DCP 790 is highlighted. TDS display portion 784 includes a drive cycle program number 786 and a timer indicator 788. Fig. 22 As shown, the DCP number and timer associated with DCP 790 are highlighted to indicate that DCP 790 is the current DCP to be executed. According to an example embodiment, a TDS display portion 784 included in any GUI may include any number of DCPs that fit within the TDS display portion 784.

[0212] Reference Figure 8 and Fig. 22 , DCP 790 for DCP 1 includes a TDS instruction that matches TDS instruction 161 and a timer value that matches timer value 175. Similarly, DCP 792 for DCP 2 includes a TDS instruction that matches TDS instruction 163 and a timer value that matches timer value 177. Similarly, DCP 794 for DCP 3 includes a TDS instruction that matches TDS instruction 165 and a timer value that matches timer value 179.

[0213] The GUI 608 includes a complete test drive script USC 699, a start / restart USC 798, and a cancel USC 796. In at least some embodiments, in response to determining that the complete test drive script USC 699 is selected, the processor 102 may cause the display 116 to display a GUI in a post-repair report maintenance mode. In some embodiments, the complete test drive script USC 699 is active at any time when a drive cycle program is executed. In other embodiments, the complete test drive script USC 699 readiness monitor is active after failure during execution of the test drive script or after all drive cycle programs of the TDS have been executed. In at least some embodiments, the processor 102 may be configured to automatically switch from a GUI showing a drive cycle program to a GUI in a post-repair report maintenance mode without requiring the user to select the complete test drive script USC 699.

[0214] Additionally, in at least some embodiments, in response to determining that start / restart USC 798 is selected, processor 102, 256 may initiate an action associated with the GUI including starting / restarting USC 798. For example, initiating the action includes starting or restarting a timer associated with a currently executing DCP, and / or starting or restarting a request for PID parameters for a PPI.

[0215] Additionally, in at least some embodiments, in response to determining that cancel USC 796 is selected, processor 102, 256 may stop actions associated with the GUI including canceling USC 796. For example, stopping the actions may include stopping a timer associated with the drive cycle program, stopping requests for PID parameter values ​​so that parameter values ​​in the PPI stop changing, and / or switching to a different GUI, such as a GUI that does not display the TDS.

[0216] Respectively Fig.23 , 24 , 25, 27, 28, 29 also show the GUI 610, 612, 614, 618, 620, 622 of the complete test drive script USC 699, the cancel USC 796 and the start / restart USC 798. The above description of the complete test drive script USC 699, the cancel USC 796 and the start / restart USC 798 is applicable to the GUI 610, 612, 614, 618, 620, 622.

[0217] The GUI 608 includes an audio mode icon 814 and a visual mode icon 816. In at least some embodiments, if the selected TDS is to be output using the auditory output device 120, the audio mode icon 814 is highlighted in some manner, and if the selected TDS is to be output using the display 116, the visual mode icon 816 is highlighted in some manner. In those or other embodiments, the audio mode icon 814 is configured as an audio mode selection USC, and the visual mode icon is configured as a visual mode selection USC. In response to determining that the audio mode selection USC is selected when the tool 100 is outputting the TDS using the display 116, the processor (such as the processor 102, 256) is configured to switch the tool 100 to output the TDS using the auditory output device 120. In response to determining that the visual mode selection USC is selected when the tool 100 is outputting the TDS using the auditory output device 120, the processor (such as the processor 102, 256) is configured to switch the tool 100 to output the TDS using the display 116.

[0218] GUI 608 includes a progress meter 821. In some embodiments, progress meter 821 is configured as a timer bar 822. The timer progress indicator may include a timer value 824 (i.e., a numerical value related to the output of timer 128, such as the elapsed time since the DCP was initiated and / or the amount of time until the DCP is completed).

[0219] Next, Fig.23 GUI 610 is shown. GUI 610 includes parameter display portion 760, ready monitor display portion 772, and TDS display portion 784.

[0220] like Fig.23 As shown, the TDS display portion 784 includes drive cycle programs 790, 792, 794, and DCP 792 is highlighted to indicate that it is the current DCP to be executed. The DCP number and timer associated with DCP 792 are also highlighted to indicate that it is the current DCP to be executed. According to the embodiment in which the display 116 changes from displaying GUI 606 to displaying GUI 608, Fig. 22 and Fig.23 Thus illustrated is an example of two DCPs in an ordered sequence of DCPs being executed according to a test drive script containing the two DCPs.

[0221] Reference Figure 8 and Fig.23, DCP 792 for DCP 2 includes a TDS instruction that matches TDS instruction 163 and a timer value that matches timer value 177. Similarly, DCP 792 for DCP 1 includes a TDS instruction that matches TDS instruction 161 and a timer value that matches timer value 175. Similarly, DCP 794 for DCP 3 includes a TDS instruction that matches TDS instruction 165 and a timer value that matches timer value 179.

[0222] exist Fig.23 , the parameter display portion 760 includes a PPI 117 related to the vehicle speed of the vehicle 412, a PPI 121 related to the fuel level indicator PID of the vehicle 412, a PPI 125 related to the first oxygen sensor in the first group of oxygen sensors PID of the vehicle 412, a PPI 127 related to the second oxygen sensor in the first group of oxygen sensors PID of the vehicle 412, and a PPI 129 related to the first oxygen sensor in the second group of oxygen sensors PID of the vehicle 412.

[0223] The GUI 610 includes an expanded display portion USC 825 within the parameter display portion 760. In response to determining that the expanded display portion USC is selected, the processor (such as the processor 102, 256) may cause the display portion to expand so that additional indicators and / or other information are displayed within the display portion. For example, in response to determining that the expanded display portion USC 825 is selected, the processor (such as the processor 102, 256) may cause the parameter display portion 760 to expand so that the PPI 131 of the second oxygen sensor in the second group of oxygen sensors PID related to the vehicle 412 and the PPI 141 of the catalyst monitor PID related to the vehicle 412 are displayed as shown in FIG. Fig.23 The PPI shown is displayed together in the parameter display portion 760. The processor can refer to the Figure 8 The current DCP being executed within the illustrated TDS 160 determines which PPI(s) are also to be displayed in the parameter display portion 760 .

[0224] Reference Figure 8 PID 313 includes seven PIDs (i.e., PIDs 64, 66, 68, 69, 70, 71, 76) associated with DCP 2, which is the current DCP to be executed when GUI 610 is displayed. Fig. 9The illustrated PID graph 180 shows that PPIs 117, 121, 125, 127, 129, 131, 141 are respectively associated with PIDs 64, 66, 68, 69, 70, 71, 76. A processor (such as processor 102, 256) may populate GUI 610 with PPIs 117, 121, 125, 127, 129 after referencing TDS 160 and PID graph 180 and after extended display portion USC 825 is selected when GUI 610 is displayed.

[0225] exist Fig.23 In, as Fig. 22 Similar to the illustrated GUI 608, the readiness monitor display portion 772 includes RMI 83 relating to a fuel system monitor for the vehicle 412, RMI 99 relating to a catalyst monitor for the vehicle 412, RMI 87 relating to an oxygen sensor heater monitor for the vehicle 412, RMI 101 relating to a heated catalyst monitor for the vehicle 412, and RMI 93 relating to an oxygen sensor monitor for the vehicle 412. Each RMI is displayed using a number of pixels of the display 116.

[0226] Reference Figure 8 , monitor ID 315 includes four monitor IDs (i.e., monitor IDs 25, 27, 30, 33) associated with DCP 2, which is the current DCP to be executed when GUI 610 is displayed. Fig.10 The monitor map 189 shown shows that RMIs 83, 99, 87, 93 are associated with monitor IDs 25, 27, 30, 33, respectively. A processor (such as processor 102, 256) can populate GUI 610 with RMIs 83, 99, 87, 93 after referencing TDS 160 and monitor map 189. GUI 610 shows highlights in RMIs 83, 99, 87, 93 to indicate the status (such as a failed status) of the monitors with monitor IDs 25, 27, 30, 33.

[0227] In at least some embodiments, only the monitors associated with the current TDS are displayed in the ready monitor display portion 772. However, in at least some other embodiments, the ready monitor display portion 772 displays one or more other RMIs except those RMIs associated with the current TDS. The tool 100 can use the latter embodiment to show the status of the RMIs tested during the previous DCP of the TDS. For example, the GUI 610 shows that RMI 101 is highlighted to indicate that the heated catalyst monitor in the monitor ID 34 executed for DCP 1 has passed. According to the latter embodiment, the ready monitor display portion 772 can display the RMIs of all monitors to be checked during the execution of the TDS.

[0228] GUI 610 includes an audio mode icon 814 and a visual mode icon 816. Fig.23 As shown, the visual mode icon 816 is highlighted to indicate that the selected TDS is to be output using the display 116 .

[0229] GUI 610 includes a progress meter 821. In some embodiments, progress meter 821 is configured as a timer bar 822. The timer progress indicator may include a timer value 824 (i.e., a numerical value related to the output of timer 128, such as the elapsed time since the DCP was started and / or the amount of time until the DCP is completed). Fig.23 In the example of FIG. 8 , the progress meter 821 also includes an indicator 823 within the timer bar 822 to indicate how far the timer of the DCP has progressed (i.e., 3:23 of 4:00). In at least some embodiments, the timer value 824 increments by one second each second as the DCP 2 executes, and the indicator 823 fills up an additional 1 / 240 portion of the timer bar 822 each second as the DCP 2 executes.

[0230] Next, Fig.24 GUI 612 is shown. GUI 612 includes parameter display portion 760, ready monitor display portion 772, and TDS display portion 784.

[0231] like Fig.24 As shown, the TDS display portion 784 includes drive cycle programs 790, 792, 794, and DCP 794 is highlighted to indicate that it is the current DCP to be executed. The DCP number and timer associated with DCP 794 are also highlighted to indicate that it is the current DCP to be executed.

[0232] Reference Figure 8 and Fig.24, DCP 794 for DCP 3 includes a TDS instruction that matches TDS instruction 165 and a timer value that matches timer value 179. Similarly, DCP 792 for DCP 1 includes a TDS instruction that matches TDS instruction 161 and a timer value that matches timer value 175. Likewise, DCP 794 for DCP 2 includes a TDS instruction that matches TDS instruction 163 and a timer value that matches timer value 177.

[0233] exist Fig.24 , the parameter display portion 760 includes a PPI 117 related to the vehicle speed of the vehicle 412, a PPI 121 related to the oil level indicator PID of the vehicle 412, a PPI 123 related to the evaporator emission purge valve duty cycle PID of the vehicle 412, a PPI 125 related to the first oxygen sensor in the first group of oxygen sensors PID of the vehicle 412, and a PPI 127 related to the second oxygen sensor in the first group of oxygen sensors PID of the vehicle 412.

[0234] The GUI 612 includes an expanded display portion USC 825 within the parameter display portion 760. In response to determining that the expanded display portion USC 825 is selected from the GUI 612, the processor (such as the processor 102, 256) may cause the parameter display portion 760 to expand so that the PPI 129 of the first oxygen sensor in the second group of oxygen sensors PID related to the vehicle 412, the PPI 131 of the second oxygen sensor in the second group of oxygen sensors PID related to the vehicle 412, and the PPI 141 of the catalyst monitor PID related to the vehicle 412 are displayed in the same manner as described above. Fig.24 The PPI shown is displayed together in the parameter display portion 760.

[0235] Reference Figure 8 PID 317 includes eight PIDs (i.e., PIDs 64, 66, 67, 68, 69, 70, 71, 76) associated with DCP 3, which is the current DCP to be executed when GUI 612 is displayed. Fig. 9The illustrated PID graph 180 shows that PPIs 117, 121, 123, 125, 127, 129, 131, 141 are respectively associated with PIDs 64, 66, 67, 68, 69, 70, 71, 76. A processor, such as processor 102, 256, may populate GUI 612 with PPIs 117, 121, 123, 125, 127, 129 after referencing TDS 160 and PID graph 180 and with PPIs 117, 121, 123, 125, 127 displayed after extended display portion USC 825 is selected when GUI 612 is displayed.

[0236] exist Fig.24 In, as Fig. 22 Similar to the illustrated GUI 608, the ready monitor display portion 772 includes RMI 83 relating to a fuel system monitor for the vehicle 412, RMI 99 relating to a catalyst monitor for the vehicle 412, RMI 87 relating to an oxygen sensor heater monitor for the vehicle 412, RMI 101 relating to a heated catalyst monitor for the vehicle 412, and RMI 93 relating to an oxygen sensor monitor for the vehicle 412.

[0237] Reference Figure 8 , monitor ID 319 includes three monitor IDs (i.e., monitor IDs 25, 30, 33) associated with DCP 3, which is the current DCP to be executed when GUI 612 is displayed. Fig.10 The monitor map 189 shown shows that RMIs 83, 99, 93 are associated with monitor IDs 25, 30, 33, respectively. A processor (such as processor 102, 256) can populate GUI 612 with RMIs 83, 99, 93 after referencing TDS 160 and monitor map 189. GUI 612 shows highlights in RMIs 83, 99, 93 to indicate the status (such as a failed status) of the monitors with monitor IDs 25, 30, 33.

[0238] Although monitors with monitor IDs 25, 30, 33 are associated with DCP 3, as previously described, the tool 100 may show the status of RMIs tested during previous DCPs of the TDS. Fig.24 In the illustrated case, GUI 614 shows RMI 87 highlighted to indicate that both the oxygen sensor heater monitor with monitor ID 27 executed for DCP 2 and the heated catalyst monitor with monitor ID 34 executed for DCP 1 have passed.

[0239] GUI 612 includes an audio mode icon 814 and a visual mode icon 816. Fig.24 As shown, the visual mode icon 816 is highlighted to indicate that the selected TDS is to be output using the display 116 .

[0240] GUI 612 includes a progress meter 821. Fig.24 In the example of FIG. 8 , the progress meter 821 includes a timer value 824 and an indicator 823 within a timer bar 822 to indicate how far the timer of the DCP has progressed (i.e., 6:34 of 10:00). In at least some embodiments, the timer value 824 increments by one second each second while the DCP 3 is executing, and the indicator 823 fills up an additional 1 / 600 portion of the timer bar 822 each second while the DCP 3 is executing.

[0241] Next, Fig.25 GUI 614 is shown. GUI 614 includes parameter display portion 760, ready monitor display portion 772, and TDS display portion 784. Parameter display portion 760 includes add USC 840. In response to the selection of add USC 840, the processor (such as processor 102, 256) outputs a GUI to allow the user to add one or more PPIs to parameter display portion 760. An example of the above GUI, i.e., GUI 624, is shown in FIG. Fig.30 As a result of selecting Add PPI 159 from GUI 624, Fig.25 The illustrated PPI 159 may be shown in the GUI 614 .

[0242] The TDS display portion 784 includes a drive cycle program number 786, a timer indicator 788, a scroll bar 832, and a selector 834 within the scroll bar 832. The selector 834 can be moved within the scroll bar 832. The processor (such as processor 102, 256) can cause the GUI 614 to display a different drive cycle program combination for the test drive script than the drive cycle program combination from the test drive script that was displayed before the selector 834 was moved in response to determining that the selector 834 has been moved. The drive cycle program numbers 786 displayed within the TDS display portion 784 include DCPs 1 through 6. According to at least some embodiments, the current drive cycle program to be executed is highlighted to assist the user of the tool 100. As shown in FIG. Fig.25 As shown, the timer value and TDS instruction of DCP 2 are highlighted.

[0243] exist Fig.25In the embodiment of the present invention, each of the RMIs within the ready monitor display portion 772 includes a graphics mode selector, such as the graphics mode selector 655 within the RMI 83. The graphics mode selector 655 can be used to increase the size of the RMI 83. The display 116 can display the RMI 83 with the increased size so that the RMI 83 includes graphics. The graphics mode selectors of other RMIs can also be used to increase the size of the RMI including the graphics mode selector. For the ready monitor state that can only be indicated via two values ​​(such as pass or fail), the graphics in the increased size window can display an indication of the current value associated with the ready monitor related to the RMI. When the size of the RMI increases, the RMI can also include a graphics mode selector. When the size of the RMI increases, selecting the graphics mode selector can reduce the size of the RMI, such as the size of the RMI before the graphics mode selector is selected to increase the size of the RMI.

[0244] Readiness monitor portion 772 includes RMI 83, 87, 93, 99, 101 and RMI 843. RMI 843 is associated with a comprehensive component readiness monitor that is executed on some vehicles. In at least some embodiments, the comprehensive component readiness monitor is executed at any time when the vehicle is operating and does not require any drive cycle program execution. Therefore, unlike many other readiness monitors, the comprehensive component readiness monitor can cause DTCs to be set and fault indicators to turn on without having to execute a drive cycle program.

[0245] Next, Fig.26 GUI 616 is shown. GUI 616 includes audio TDS USC 810 and visual TDS USC 812. In response to determining that audio TDS USC 810 is selected, processor 102 switches to a mode in which processor 102 outputs a representation of at least a portion of the TDS using auditory output device 120. Additionally, processor 102 may output a GUI with a limited visual representation of the TDS as compared to a more comprehensive visual representation of the TDS included in the GUI output in response to determining that visual TDS USC 812 is selected. Figure 27 to Figure 29 Each of 812 shows an example GUI with a limited visual representation of the TDS. In response to determining that the visual TDS USC 812 is selected, the processor 102 switches to a mode in which the processor 102 outputs a representation of at least a portion of the TDS using the display 116. Figure 24 to Figure 26 Each of the examples GUIs depicts a more complete visual representation of a test drive script. In at least some embodiments, the limited visual representation of a TDS does not include a textual representation of a DCP of the TDS, while the more complete visual representation of the TDS includes a textual representation of at least one DCP of the TDS.

[0246] Next, Fig. 27 GUI 618 is shown. GUI 618 includes an icon 850 that indicates that the tool 100 is operating in a mode in which the TDS and / or the drive cycle program of the TDS are audibly output using the audible output device 120. GUI 618 also includes an audio mode icon 814 and a visual mode icon 816 configured as described above. GUI 618 also includes Start USC 852 and Cancel USC 854. For at least some embodiments, in response to determining that Start USC 852 is selected, the processor 102 audibly outputs the first or next drive cycle program of the TDS. For those or at least some other embodiments, in response to determining that Cancel USC 854 is selected, the processor 102 cancels the audible output of the drive cycle program of the TDS and / or the TDS. In addition, in response to determining that Cancel USC 854 is selected, the processor 102 may switch from displaying GUI 618 to a different GUI, such as Fig.21 GUI 606 is shown.

[0247] Next, Fig.28 GUI 620 is shown. GUI 620 includes a progress meter 866 to show the progress of completing a TDS, such as TDS 160. Progress meter 866 includes drive cycle program announcement icons 868, 870, 872, 874, 876, 878, 880, a TDS completion announcement icon 882, and drive cycle program timing icons 884, 886, 888, 890, 892, 894. Drive cycle program timing icons 884, 886, 888, 890, 892, 894 represent timer values ​​177, 179, 181, 183, 185, 187 of TDS 160. Progress meter 866 does not show a drive cycle program timing icon related to timer value 175 because timer value 175 has a value of 0:00. In an alternative embodiment, schedule gauge 866 may include a drive cycle program timing icon corresponding to any timer value having a value of 0:00, such as timer value 175 .

[0248] In at least some example embodiments, the progress of completing the TDS is shown using highlighting within the progress meter 866. The highlighting within the progress meter 866 may be related to the output of the timer 128 and / or the timer value 166. An example of highlighting 896 (using shading) is shown in Fig.28 According to these embodiments, highlighting 896 of drive cycle program advisory icon 868 indicates that TDS instruction 161 has been output via audible output device 120 , and highlighting 896 of drive cycle program advisory icon 870 indicates that TDS instruction 163 has been output via audible output device 120 .

[0249] In at least some embodiments, the size of the drive cycle program timing icon indicates the length of time associated with the drive cycle program, while other sizes of other drive cycle program timing icons indicate other lengths of time associated with other drive cycle programs. For example, a first amount of time indicated by a longer drive cycle program timing icon is greater than a second amount of time indicated by a shorter drive cycle program timing icon. In particular, the times indicated by drive cycle program timing icon 884 and drive cycle program timing icon 886 may be four minutes and ten minutes, respectively.

[0250] The processor 102 may cause highlights within the drive cycle program timing icons 884, 886, 888, 890, 892, 894 to be added as the associated TDS instructions are being completed, in relation to the percentage of completion of the associated TDS instructions. In at least some embodiments, the highlights fill the drive cycle program timing icons 884, 886, 888, 890, 892, 894 starting from the leftmost portion of the icons. For embodiments where the drive cycle program timing icons are associated with a four-minute DCP, the highlight 896 may be incremented by 1 / 240 for each second counted by the timer 128 within the drive cycle program timing icon, and the incomplete segment indicator 827 may be decremented by 1 / 240 for each second counted by the timer 128. For example, the highlight 896 within the drive cycle program timing icon 884 extends to eighty percent of the total length of the drive cycle program timing icon 884 to indicate that the DCP 2 within the TDS 160 is eighty percent complete. The portion 919 of the drive cycle program timing icon 884 that is not shown highlighted is twenty percent of the total length of the drive cycle program timing icon 884 to indicate that twenty percent of the time required to execute the DCP 2 has not yet been executed.

[0251] GUI 620 includes icon 891 to inform the user of tool 100 that he can speak one or more words in the vocabulary of tool 100 to cause TDS instructions to be output through auditory output device 120. As an example, icon 891 includes text "Say 'repeat' to replay TDS instructions" and text "Say 'next' to play the next TDS instruction." When display 116 is displaying a GUI with icon 891 (such as Fig.29 620 or GUI 622 shown in the figure, the processor 102 can detect that the sound wave representing the word "repeat" is received through the microphone of the input device 118. In response to this detection, the processor (such as the processor 102, 256) can cause the TDS instructions of the currently executing DCP to be played using the auditory output device 120. When the display 116 is displaying a GUI with icon 891 (such as Fig.29When the GUI 620 or GUI 622 is displayed, the processor (such as the processor 102, 256) can detect that the sound waves representing the word "next" are received through the microphone of the input device 118. In response to the detection, the processor (such as the processor 102, 256) can cause the TDS instructions for the next DCP to be executed to be played using the auditory output device 120.

[0252] Configuring the tool 100 to be able to repeat the most recently output TDS instructions using the tool 100 is advantageous because the user of the tool 100 can be provided with instructions to continue operating the vehicle to meet the requirements of the DCP currently being executed in the TDS. In some aspects, being able to repeat the most recently output TDS instructions in response to voice commands is even more advantageous because the user of the tool 100 is likely driving the vehicle 412 and can keep his or her eyes on the road rather than looking at the display 116 to have to read the TDS instructions from the display 116. In addition, in the event that the user of the tool 100 driving the vehicle has not yet changed the operating state of the vehicle to meet the requirements of the most recently output TDS instructions and cannot recall the most recently output TDS instructions, repeating the most recently output TDS instructions using the voice output device 120 can remind the user how to change the operating state of the vehicle to meet the requirements of the most recently output TDS instructions.

[0253] Configuring the tool 100 to output TDS instructions for the next DCP scheduled to be executed (i.e., the next scheduled DPS) is advantageous because new operating state information can be provided to the user of the tool regarding how the vehicle 412 needs to operate in the next scheduled DPS. The user of the tool 100 can take into account the new operating state information to plan out a future portion of the route on which the TDS instructions for the next scheduled DPS will be executed.

[0254] The GUI 620 includes a repeat instruction USC 893 and a next instruction USC 895. In response to determining that the repeat instruction USC 893 has been selected, the processor 102, 256 is configured to cause the auditory output device 120 to output the TDS instruction most recently outputted by the auditory output device 120. In response to determining that the next instruction USC 895 has been selected, the processor 102, 256 is configured to cause the auditory output device 120 to output the TDS instruction that the processor 102, 256 intends to output using the auditory output device 120 when the DCP currently being executed is completed.

[0255] and Fig. 22 Similar to the illustrated GUI 608, GUI 620 includes an audio mode icon 814 and a visual mode icon 816. The description of the operation of these icons is described above with respect to GUI 608 and is applicable to GUI 620. Fig. 22 Similar to the illustrated GUI 608, GUI 620 includes Start / Restart USC 798 and Cancel USC 796. The description of the operation of these USCs has been described above with respect to GUI 608 and is applicable to GUI 620.

[0256] Next, Fig.29 GUI 622 is shown. GUI 622 includes a progress meter 831 to show the progress of completing a DCP of a TDS (such as DCP 2 of TDS 160). Progress meter 831 includes a progress meter start / end indicator 833, a completed segment indicator 835, an uncompleted segment indicator 837, a timer value 839, and a DCP indicator 841. Fig.29 , DCP indicator 841 indicates that the second DCP (i.e., DCP 2) of the seven DCPs of TDS 160 is being executed. Figure 8 As shown, DCP 2 includes a timer value of four minutes. Timer value 839 may indicate the output of timer 128. Timer value 839 may, for example, indicate the amount of time remaining to complete the DCP indicated by DCP indicator 841.

[0257] The completed segment indicator 835 and the incomplete segment indicator 837, in combination, may represent one hundred percent of the timer value associated with the DCP indicated by the DCP indicator 841. For an embodiment in which the timer value associated with the DCP is four minutes, while the timer 128 is counting the timer value, the completed segment indicator 835 may increase by 1 / 240 of the schedule 831 for each second counted by the timer 128, and the incomplete segment indicator 837 may decrease by 1 / 240 of the schedule 831 for each second counted by the timer 128. According to this embodiment, at three minutes and twenty-three seconds remaining in the four minutes, the completed segment indicator 835 covers approximately fifteen percent of the schedule 821, and the incomplete segment indicator 837 covers approximately eighty-five percent of the schedule 831.

[0258] GUI 622 includes icon 891 to inform the user of the tool 100 that he can speak a voice command to cause the TDS instructions to be output via the auditory output device 120. Fig.28 The description of the operation using icon 891 applies to Fig.29 GUI 622 also includes a repeat command USC 893 and a next command USC 895. Fig.28 The description of the operation using the repeat instruction USC 893 and the next instruction USC 895 applies to the following: Fig.29The use of the repeat instruction USC 893 and the next instruction USC 895 is shown.

[0259] In at least some embodiments, the GUI includes a progress meter for showing the progress of completing the TDS and a progress meter for showing the progress of completing the DCP of the TDS. As an example, the GUI can be arranged like GUI 620, except that the GUI also includes a progress meter for showing the progress of completing the DCP of the TDS, such as progress meter 821.

[0260] An advantage of displaying a GUI with a progress meter (such as progress meter 821, 866) is that it provides a way for the user of the tool to quickly determine how far the currently executing DCP is from completion, so that the user can anticipate the need to change the operating state of the vehicle 412. In order to determine how the operating state of the vehicle 412 needs to change when the currently executing DCP is completed, the user can request that the tool 100 play the next TDS instruction in response to selecting the next instruction USC 895, or wait for the tool 100 to play the next TDS instruction when the currently executing DCP is completed. An advantage of displaying a GUI with a progress meter (such as progress meter 866) is that it provides a way for the user of the tool to quickly determine how far the currently executing TDS is from completion.

[0261] Next, Fig.30 GUI 624 is shown. As described above, GUI 624 allows a user to add one or more PPIs to parameter display portion 760 of the GUI. In at least some embodiments, processor 102, 256 is configured to respond to a selection to add a USC (such as Fig.25 The GUI 624 is output by adding USC 840 as shown.

[0262] The GUI 624 includes a parameter display portion 760 that includes PPIs 143, 113, 115, 111, 145. The GUI 624 also includes a PPI selection menu 917 that includes PPIs 111, 113, 115, 117, 119, 121, 123, 125, 127, 129, 131, 133, 135, 137, 139, 141, 143, 145, 147, 149, 151, 153, 155, 157, 159. Each of these PPIs is selectable. In at least some embodiments, the processor 102, 256 is configured to highlight the PPI that has been selected from the PPI selection menu 917. Fig.30The highlighted PPI 159 is shown to indicate that the PPI 159 has been selected. In at least some embodiments, the processor 102, 256 can add the PPI selected from the PPI selection menu 917 to the parameter display portion 760 after determining that the PPI has been selected. In those or other embodiments, the processor 102, 256 can add the PPI selected from the PPI selection menu 917 in response to determining that the add selection USC 799 within the GUI 624 has been selected. Other approaches that result in the addition of a PPI to the parameter display portion 760 are also possible.

[0263] Next, Fig.31 , Fig.32 , Fig.33 GUIs 626, 628, 630 are shown respectively. GUIs 626, 628, 630 show that the tool 100 is operating in a post-repair report maintenance mode. GUIs 626, 628, 630 show reports 897, 898, 899 respectively. Each report 897, 898, 899 includes a report selection USC 900, 902, 904. In at least some embodiments, the report selection USC 900 includes text and / or symbols to select a report, such as a report 897 customized for a customer. Therefore, it can be considered that report 897 is a customer post-repair report. Similarly, the report selection USC 902 includes text and / or symbols to indicate that report 898 is customized for a maintenance person. Therefore, it can be considered that report 898 is a maintenance person post-repair report. The report selection USC 904 includes text and / or symbols to indicate that report 899 is customized for a technician. Therefore, it can be considered that report 899 is a technician post-repair report.

[0264] In response to selecting report selection USC 900 while display 116 is displaying reports 898, 899, processor 102, 256 may cause display 116 to begin displaying report 897 instead of reports 898, 899. In response to selecting report selection USC 902 while display 116 is displaying reports 897, 899, processor 102, 256 may cause display 116 to begin displaying report 898 instead of reports 897, 899. In response to selecting report selection USC 904 while display 116 is displaying reports 897, 898, processor 102, 256 may cause display 116 to begin displaying report 899 instead of reports 897, 898.

[0265] The GUI 626, 628, 630 includes a symptom portion 906. The symptom portion 906 includes a description of a symptom diagnosed when the tool 100 is operated in the diagnostic maintenance mode. As an example, the symptoms displayed in the symptom portion 906 may include a DTC identifier, such as a P0171 DTC identifier.

[0266] The GUIs 626, 628, 630 include a monitor portion 908. The monitor portion 908 includes an indicator indicating whether the readiness monitor tested during the test drive maintenance mode passed or failed. Fig.32 As shown, GUI 630 includes RMIs 83, 87, 93, 99, 101 to provide an indication of whether a readiness monitor tested during the test drive maintenance mode has passed or failed.

[0267] The GUI 626, 628, 630 includes a vehicle data portion 910. In at least some embodiments, the vehicle data portion 910 includes pre-repair vehicle data captured when the tool 100 is operated in a diagnostic maintenance mode and post-repair data captured when the tool 100 is operated in a test drive maintenance mode or a post-repair report maintenance mode. As an example, the vehicle data portion 910 includes a PPI 912 related to a mass air flow sensor voltage PID of the vehicle 412. The PPI 912 includes a pre-repair parameter 914 and a post-repair parameter 916 corresponding to the mass air flow sensor voltage PID. As another example, the vehicle data portion 910 includes a PPI 918 related to a mass air flow sensor frequency PID of the vehicle 412. The PPI 918 includes a pre-repair parameter 920 and a post-repair parameter 922 corresponding to the mass air flow sensor frequency PID. As yet another example, the vehicle data portion 910 includes a PPI 924 related to a mass air flow sensor mass / time PID of the vehicle 412. The PPI 924 includes pre-repair parameters 926 and post-repair parameters 928 corresponding to the mass air flow sensor mass / time PID. The pre-repair parameters 914, 920, 926 may include parameters captured when the parameter display portion 760 is displayed on the GUI during a diagnostic vehicle maintenance mode.

[0268] The GUIs 626, 628, 630 include a repair data portion 930. The repair data portion 930 includes data related to repairs performed on the vehicle. Fig.31 As shown, repair data section 930 may include a text description 936 describing the repairs performed on vehicle 412 and a visual description 938 related to the repairs performed on vehicle 412. Fig.31 and Fig.32As shown, the repair data section 930 may include a top repair graph 940 and a cost summary 942. The top repair graph 940 may indicate whether the repairs performed on the vehicle 412 to overcome the symptoms experienced by the vehicle 412 are among the most frequently performed repairs on a particular type of vehicle corresponding to the vehicle 412, or among the most frequently performed repairs on all types of vehicles. The cost summary 942 may include cost information regarding parts, labor, supplies, and taxes associated with repairing the vehicle 412.

[0269] The GUIs 626, 628, 630 include downloading the USC 932 and printing the USC 934. In at least some embodiments, in response to determining that downloading the USC 932 is selected, the processor 102 can request the server 254 to transmit a version of the report 897, 898, 899 to be stored in the memory 104. In at least some embodiments, in response to determining that printing the USC 934 is selected, the processor 102, 256 can cause the report 897, 898, 899 to be sent to a printer.

[0270] V. Diagnosis and Repair

[0271] Next, Fig.34 An example of diagnostic and repair mapping data 550 is shown. As shown, the diagnostic and repair mapping data 550 may include symptom-to-PID mapping data (MD) 551, component-to-PID MD 552, symptom-to-component test MD 553, component-to-component test MD 554, symptom-to-functional test MD 555, component-to-functional test MD 556, symptom-to-reset procedure MD 557, and component-to-reset procedure MD 558. More specific examples of the above-mentioned mapping data will be discussed below.

[0272] Next, Fig.35 Examples of different indexes that may be stored within index 560 are shown. As shown, index 560 may include PID index 561, component test index (CTI) 562, functional test index (FTI) 563, and reset procedure index (RPI) 564. Two or more of these indexes may be combined and stored as a single index. More specific examples of the aforementioned indexes will be discussed below.

[0273] Next, Fig.36 An example of diagnostic and repair map data 550 is shown. In particular, Fig.36 An example of the Symptom-to-PID MD 551 is shown for four symptoms: Symptom 1 maps to sixteen PIDs, Symptom 2 maps to three PIDs, Symptom 3 maps to two PIDs, and Symptom 4 maps to two PIDs. Fig.36Also shown is an example of a symptom-to-component test MD 553 for four symptoms: symptom 1 maps to two component tests, symptom 2 maps to two component tests, symptom 3 maps to zero component tests, and symptom 4 maps to two component tests. Fig.36 Also shown is an example of a symptom-to-functional test MD 555 for four symptoms: symptom 1 maps to four functional tests, symptom 2 maps to four functional tests, symptom 3 maps to four functional tests, and symptom 4 maps to four functional tests. Fig.36 Also shown is an example of a symptom-to-reset procedure MD 557 for five symptoms: symptom 1 maps to one reset procedure, symptom 2 maps to one reset procedure, symptom 3 maps to zero reset procedures, symptom 4 maps to one reset procedure, and symptom 5 maps to two reset procedures. Fig.36 In the example symptoms are shown in parentheses, and the PID, component tests, functional tests, and reset procedures are listed after the colon.

[0274] Next, Fig.37 Shown is an example component test index (CTI) 570. CTI 570 includes an ordered list of component tests. Fig.37 Three example representations of component tests within CTI 570 are shown. Fig.37 As shown, CTI 570 may represent a component test using component test number 571, index value 572, and component test name 573 (i.e., at least one word describing the component test). Different CTIs (for example embodiments) may represent component tests using only one of these three example representations, a combination of any two of these three example representations, or using different example component test representations. For example, index value 572 may include a number in decimal, hexadecimal, or some other base to represent a component test within CTI 570. CTI 562 (e.g., Fig.35 570) may include multiple component test indexes, such as a separate CTI for each of a plurality of different specific identification information sets (e.g., a separate CTI for each Y / M / M or Y / M / M / E). Those separate CTIs may be arranged like CTI 570, or arranged in another manner. CTI 570 may include or be associated with specific vehicle identification information.

[0275] Next, Fig.38 is a schematic diagram illustrating example symptom-to-component mapping data 575 that may be stored in the diagnostic and repair map data 550 . Fig.38 Symptom 576 is shown as a DTC, but if Fig.36 As shown, the mapped symptoms may include symptoms other than DTCs. Fig.38A symptom count 577 is shown within parentheses for each symptom. Server 254 may determine symptom count 577 based on repair order data generated for other instances of the vehicle type identified by vehicle identifier 666.

[0276] like Fig.38 The DTC shown may be referred to as a "P Code" from the powertrain controller ECU. Fig.38 As shown, symptoms (such as symptoms P01551 and P01552) can be mapped to multiple components. The mapping between symptoms and components is shown in Fig.38 This is represented by mapping line 578.

[0277] Next, Fig.39 Other examples of diagnostic and repair map data 550 are shown. In particular, Fig.39 An example of a component-to-PID MD 552 is shown for four components: component 1 is mapped to three PIDs, component 2 is mapped to three PIDs, component 3 is mapped to two PIDs, and component 4 is mapped to one PID. Fig.39 Also shown is an example of a component-to-component test MD 554 for five components: component 1 maps to two component tests, component 2 maps to three component tests, component 3 maps to three component tests, component 4 maps to two component tests, and component 5 maps to one component test. Fig.39 Also shown is an example of a component to functional test MD 556 for six components: component 1 maps to two functional tests, component 2 maps to zero functional tests, component 3 maps to two functional tests, component 4 maps to zero functional tests, component 5 maps to zero tests, and component 6 maps to one functional test. Fig.39 Also shown is an example of component-to-reset procedure MD 558 for eight components: components 1, 2, 3, 4, 5, and 6 are each mapped to zero reset procedures, component 7 is mapped to two reset procedures, and component 8 is mapped to two reset procedures. Fig.39 In the examples, example symptoms are shown in parentheses, and the PID, component tests, functional tests, and reset procedures are listed after the colon.

[0278] Next, Fig.40 An example PID index 585 is shown. PID index 585 includes an ordered list of PIDs. Fig.40 Three example representations of PIDs within PID Index 585 are shown. Fig.40As shown, PID index 585 may use PID number 586, index value 587, and PID name 588 (i.e., at least one word describing the PID) to represent the PID. Different PID indexes (for example embodiments) may represent the PID using only one of these three example representations, a combination of any two of these three example representations, or a different example PID representation. For example, index value 587 may include a number in decimal, hexadecimal, or some other base to represent the PID within PID index 585. PID index 561 (e.g., Fig.35 585 ) may include multiple PID indexes, such as a separate PID index for each of a plurality of different specific identification information sets (e.g., a separate PID index for each Y / M / M or Y / M / M / E). Those separate PID indexes may be arranged like PID index 585, or arranged in another manner. PID index 585 may include or be associated with a specific type of vehicle.

[0279] Next, Fig.41 Shown is an example functional test index (FTI) 590. FTI 590 includes an ordered list of functional tests. Fig.41 Three example representations of functional tests within FTI 590 are shown. Fig.41 As shown, FTI 590 may represent a functional test using a functional test number 591, an index value 592, and a functional test name 593 (i.e., at least one word describing the functional test). Different FTIs (for example embodiments) may represent functional tests using only one of these three example representations, a combination of any two of these three example representations, or a different example functional test representation. For example, index value 592 may include a number in decimal, hexadecimal, or other bases to represent a functional test within FTI 590. FTI 563 (e.g., Fig.35 590) may include multiple functional test indexes, such as a separate FTI for each of a plurality of different specific identification information sets (e.g., a separate FTI for each Y / M / M or Y / M / M / E). Those separate FTIs may be arranged like FTI 590, or arranged in another manner. FTI 590 may include or be associated with specific vehicle identification information.

[0280] Next, Fig.42 An example reset procedure index (RPI) 595 is shown. The RPI 595 includes an ordered list of reset procedures. Fig.42 Three example representations of the reset procedure within the RPI 595 are shown. Fig.42As shown, RPI 595 may represent a reset procedure using a reset procedure number 596, an index value 597, and a reset procedure name 598 (i.e., at least one word describing the reset procedure). Different RPIs (for example embodiments) may represent reset procedures using only one of these three example representations, a combination of any two of these three example representations, or a different example reset procedure representation. For example, index value 597 may include a number in decimal, hexadecimal, or other bases to represent a reset procedure within RPI 595. RPI 564 (e.g., Fig.35 590) may include multiple reset procedure indexes, such as a separate RPI for each of a plurality of different specific identification information sets (e.g., a separate RPI for each Y / M / M or Y / M / M / E). Those separate RPIs may be arranged like RPI 595, or arranged in another manner. RPI 595 may include or be associated with specific vehicle identification information. Index value 597 may be different from the index values ​​of other indexes (such as PID index 585, CTI 570, and FTI 590) so that a single index is formed using the index numbers of multiple indexes without any overlap of index numbers.

[0281] VI. Example Transportation

[0282] A vehicle is a moving machine that can be used to transport one or more people and / or cargo. A vehicle can be driven along a path (e.g., paved roads or otherwise) and / or guided in other ways on land, water, air, and / or in outer space. A vehicle can be wheeled, tracked, railed, and / or skied. Vehicles can include automobiles, motorcycles (e.g., two- or three-wheeled motorcycles), all-terrain vehicles (ATVs) as defined by ANSI / SVIA-1-2007, snowmobiles, jet skis (e.g., A vehicle may include and / or use any suitable voltage and / or current source that provides any suitable current and / or voltage (such as about 12 volts, about 42 volts, etc.), such as a battery, an alternator, a fuel cell, etc. The vehicle may, but need not, include and / or use any system and / or engine to provide its mobility. These systems and / or engines may include vehicle components that use fossil fuels (such as gasoline, natural gas, propane, etc.), electricity (such as electricity generated by batteries, magnets, fuel cells, solar cells, etc.), wind and hybrid power, and / or combinations thereof. The vehicle may, but need not, include an electronic control unit (ECU), an OBDC, and a vehicle network connecting the OBDC and the ECU. The vehicle may be configured to operate as an autonomous vehicle.

[0283] Some vehicles and vehicle types can be identified by vehicle characteristics, such as characteristics that indicate when the vehicle was built (e.g., the year of the vehicle), who built the vehicle (e.g., the vehicle brand), a marketing name associated with the vehicle (e.g., the vehicle model name, or more simply "model"), and characteristics of the vehicle (e.g., the engine type). This specification uses the abbreviations YMME and / or Y / M / M / E, where each letter represents the model year, vehicle brand, vehicle model name, and engine type, respectively, in the order shown. This specification uses the abbreviations YMM and / or Y / M / M, where each letter represents the model year, vehicle brand, and vehicle model name, respectively, in the order shown. An example Y / M / M / E is 2020 / Toyota / Camry / 4Cyl, where "2020" represents the year of manufacture of the vehicle, "Toyota" represents the name of the vehicle brand Toyota Motor Corporation, Aichi Japan, "Camry" represents the vehicle model manufactured by the manufacturer, and "4Cyl" represents the engine type in the vehicle (i.e., a four-cylinder internal combustion engine). Those skilled in the art will appreciate that other features in addition to or as an alternative to "engine type" can be used to identify the vehicle. These other features can be identified in various ways, such as a regular production option (RPO) code, such as the RPO codes defined by General Motors Company LLC, Detroit Michigan.

[0284] Some vehicles, such as automobiles, are associated with a unique VIN. Some VINs include seventeen alphanumeric characters. For at least some seventeen-character VINs, the last six characters represent a unique serial number associated with a particular type of vehicle represented by the first eleven alphanumeric characters of the VIN. The first eleven alphanumeric characters typically represent at least YMME or YMM. In some cases, a vehicle includes a one-dimensional barcode indicating the VIN associated with the vehicle.

[0285] A vehicle network, such as vehicle network 32, may include one or more conductors (e.g., copper wire conductors) and / or may be wireless. As an example, a vehicle network may include one or two conductors for carrying vehicle data messages in accordance with a vehicle data message (VDM) protocol, such as a bidirectional VDM protocol. A bidirectional VDM protocol may include J1850 (PWM or VPW) VDM protocol, based on J1939_201808 Serial Control and Communication Networks for Heavy Vehicles - Top Level Documentation J1939 VDM protocol and / or any other core J1939 standard, 15764-4 Controller Area Network (CAN) VDM protocol, 9141-2K-Line VDM protocol, 14230-4 KWP2000K-Line VDM protocol, 17458 (e.g., parts 1-5) FlexRay VDM protocol, 17987 Local Interconnect Network (LIN) VDM protocol, CAN 2.0 VDM protocol, some use 11898-1:2015 Road Vehicles - CAN - Part 1: Standardization of the Data Link Layer and Physical Signaling Protocol, CAN FD VDM Protocol (i.e. CAN with Flexible Data Rate VDM Protocol), Collaborative VDM protocols (such as MOST specification version 3.0E2, or Dynamic Specification Version 3.0.2), Ethernet VDM protocol (e.g., using BROADR- The VDM protocol may be a VDM protocol that implements the Ethernet 802.3 protocol of the physical layer transceiver specification, or some other VDM protocol for performing communications with or within the vehicles 412, 440, 460. Each VDM discussed in this specification is arranged according to a VDM protocol.

[0286] The VDM protocol can be unidirectional rather than bidirectional. For example, the SENT VDM protocol (i.e., the unilateral hopping transmission VDM protocol) is a unidirectional VDM protocol. The SENT VDM protocol has been standardized as the SAE J2716 VDM protocol. Sensors in a vehicle may include a transmitter (i.e., a SENT VDM transmitter) configured to communicate using the SENT VDM protocol. A vehicle communication bus may operatively connect the SENT VDM transmitter and an ECU within the vehicle. The transceiver 106 (e.g., a vehicle communication transceiver 152) may include a SENT VDM receiver connectable to a vehicle communication bus that is operatively connected to the SENT VDM transmitter. The SENTVDM receiver may receive a SENT VDM protocol message representing a sensor value output by a sensor with a SENT VDM transmitter.

[0287] An OBDC (such as OBDC 422, 452) may include an on-board diagnostic (OBD) connector, such as an OBD II connector. The OBD II connector may include slots for retaining up to sixteen connector terminals, but may include a different number of slots or no slots at all. As an example, the OBDC may include an OBD II connector that complies with the SAE J1962 specification, such as connector 16M, part number 12110252, available from Aptiv LLC of Dublin, Ireland. The OBDC may include conductor terminals connected to conductors in the vehicle. For example, the OBDC may include connector terminals connected to conductors that are connected to the positive and negative poles of a battery or battery pack, respectively. The OBDC may include one or more conductor terminals of a conductor connected to a vehicle communication bus, such that the OBDC is operatively connected to one or more ECUs. A tool (such as the tool 414) may be operatively connected to the OBDC to receive a VDM from a vehicle that includes the OBDC. The VDM may carry VDM data. The VDM data may, but does not necessarily, include a parameter identifier (PID) and data (PID data) parameters associated with the PID. VDM data may, but does not necessarily, include DTCs.

[0288] The ECU may control various aspects of vehicle operation and / or components within a vehicle system. For example, the ECU may include a powertrain (PT) system ECU, an engine control module (ECM) ECU, a supplemental inflatable restraint (SIR) system (i.e., an airbag system) ECU, an entertainment system ECU, or some other ECU. The ECU may receive electrical or optical inputs from an input device (e.g., a sensor input) connected to the ECU, control an output device (e.g., a solenoid) connected to the ECU via an electrical or optical signal output by the ECU, generate a vehicle data message (VDM) (such as a VDM based on the received input or the output of the control), and set a diagnostic trouble code (DTC) to a state (e.g., active or historical). The ECU may perform a functional test in response to receiving a VDM requesting the execution of a functional test. Functional tests may be used to test output devices connected to the ECU.

[0289] VII. Conclusion

[0290] It should be understood that the arrangements described herein and / or shown in the accompanying drawings are for illustrative purposes only and are not meant to be limiting. Therefore, those skilled in the art will understand that other arrangements and elements (e.g., machines, interfaces, functions, commands and / or groupings of functions) may be used instead, and some elements may be omitted entirely. In addition, the various functions performed by one or more elements described and / or shown in the accompanying drawings may be performed by a processor executing computer-readable program instructions or by a combination of hardware, firmware and / or software. For purposes of this specification, executing a CRPI contained in a computer-readable medium to perform certain functions may include executing all program instructions of such CRPI or only executing a portion of such CRPI.

[0291] Although various aspects and embodiments are described herein, other aspects and embodiments are also apparent to those skilled in the art. The various aspects and embodiments disclosed herein are intended to illustrate the problem, not to limit, and the true scope is represented by the claims and the scope of all equivalents granted by these claims. It should also be understood that the terms used herein are only used to describe the embodiments and are not meant to be limiting.

[0292] In this specification, the articles “a,” “an,” and “the” are used to introduce elements and / or functions of example embodiments. Use of these articles is intended to indicate that there are one or more of the introduced elements and / or functions.

[0293] In this specification, the purpose of using the term "and / or" in a list of at least two elements or functions, and the use of the terms "at least one", "at least one of the following", "one or more" and "one or more of the following" immediately before the list of at least two elements or functions, is to cover every embodiment that independently includes the listed elements or functions and every embodiment that includes a combination of the listed elements or functions. For example, an embodiment described as including A, B, and / or C, or at least one of A, B, and C, or at least one of A, B, and C, or at least one of A, B, and C, or one or more of A, B, and C, or one or more of A, B, and C, or one or more of A, B, or C, or one or more of A, B, or C, is intended to cover each of the following possible embodiments: (i) an embodiment including A but not B and not C; (ii) an embodiment including B but not A and not C; (iii) an embodiment including C but not A and not B; (iv) an embodiment including A and B but not C; (v) an embodiment including A and C but not B; (v) an embodiment including B and C but not A; and / or (vi) an embodiment including A, B, and C. For an embodiment including component or function A, the embodiment may include one A or multiple A. For an embodiment including component or function B, the embodiment may include one B or multiple B. For embodiments including a component or function C, the embodiment may include one C or multiple Cs. The use of ordinal numbers (such as "first", "second", "third", etc.) is to distinguish the respective elements, and does not indicate the order of these elements, unless the context of the use of these terms clearly indicates. The use of the symbol "$" as a prefix to a number indicates that the number is a hexadecimal number.

[0294] Therefore, embodiments of the present disclosure may be directed to one of the Enumerated Example Implementations (EEE) listed below.

[0295] EEE 1 is a method comprising determining, by one or more processors, a test drive script to be executed during a test drive of a mobile machine while a tool monitors an electronic system in the mobile machine, wherein the test drive script comprises an ordered sequence of drive cycle programs, wherein the ordered sequence of drive cycle programs begins with an initial drive cycle program and ends with a final drive cycle program, wherein each drive cycle program indicates a corresponding mobile machine state, and wherein the test drive script comprises a first specific drive cycle program associated with both a first specific mobile machine state and a first condition related to the first specific mobile machine state; outputting, by the one or more processors, a representation of at least a portion of the test drive script; determining, by the one or more processors, one or more of: state information corresponding to achieving the first specific mobile machine state or state information corresponding to achieving the first condition related to the first specific mobile machine state; and outputting, by the one or more processors, one or more of: state information corresponding to achieving the first specific mobile machine state or state information corresponding to achieving the first condition related to the first specific mobile machine state.

[0296] EEE 2 is the method of EEE 1, wherein the first condition relating to the first specific mobile machine state includes a time condition, wherein determining state information corresponding to achieving the first specific mobile machine state includes determining first state information, wherein the first state information indicates whether the mobile machine is operating in the first specific mobile machine state, wherein determining state information corresponding to achieving the first condition relating to the first specific mobile machine state includes determining second state information, and wherein the second state information corresponds to achieving the time condition.

[0297] EEE 3 is the method of EEE 2, wherein determining the first state information includes the one or more processors determining that the mobile machine is operating in a first specific mobile machine state, and wherein the second state information indicates one or more of: an amount of time the mobile machine has been operating in the first specific mobile machine state, an additional amount of time the mobile machine will operate in the first specific mobile machine state, or a minimum amount of time the mobile machine will operate in the first specific mobile machine state.

[0298] EEE 4 is a method of any one of EEEs 2 to 3, further comprising: determining, by the one or more processors, that the mobile machine switches from an operating state that is not a first specific mobile machine state to a first specific mobile machine state; and in response to determining that the mobile machine switches from an operating state that is not the first specific mobile machine state to the first specific mobile machine state, starting, by the one or more processors, a timer for determining second state information corresponding to an implementation time condition.

[0299] EEE 5 is the method of EEE 4, further comprising: outputting, by the one or more processors, a graphical user interface including a representation of the timer on a display.

[0300] EEE 6 is the method of EEE 5 , wherein the representation of the timer is arranged as a schedule including a plurality of drive cycle program announcement icons, a plurality of drive cycle program timing icons, and / or a test drive script completion announcement icon.

[0301] EEE 7 is the method of EEE 6, wherein the progress meter indicates progress of completing the test drive script using highlighting.

[0302] EEE 8 is the method of any of EEE 6 or 7, wherein a size of the first drive cycle program timing icon indicates a time length associated with the first drive cycle program, while other sizes of other drive cycle program timing icons indicate other time lengths associated with other drive cycle programs.

[0303] EEE 9 is the method of EEE 5, wherein the representation of the timer is arranged as a schedule that includes a schedule start / end indicator, a completed segment indicator, and an incomplete segment indicator if the drive cycle routine has been started but not completed.

[0304] EEE 10 is the method of EEE 9, wherein the schedule further includes a timer value and a drive cycle program indicator.

[0305] EEE 11 is the method of EEE 10 , wherein the drive cycle program indicator includes a first number indicating how many drive cycle programs of the test drive script have been started since the test drive script was initiated and a total number of drive cycle programs in the test drive script.

[0306] EEE 12 is the method of any one of EEEs 2 to 11, further comprising: outputting a request to an electronic system in the mobile machine through the one or more processors, and in response to the request, receiving a response from the electronic system in the mobile machine through the one or more processors, wherein the response from the electronic system in the mobile machine includes a parameter identifier (PID) and a parameter value associated with the PID, and determining the first state information includes the one or more processors determining whether the parameter value associated with the PID exceeds a parameter value threshold associated with a first specific mobile machine state.

[0307] EEE 13 is the method of EEE 1, wherein the first condition relating to the first specific mobile machine state includes a spatial condition, wherein determining state information corresponding to achieving the first specific mobile machine state includes determining first state information, wherein the first state information indicates whether the mobile machine is operating in the first specific mobile machine state, wherein determining state information corresponding to achieving the first condition relating to the first specific mobile machine state includes determining second state information, and wherein the second state information corresponds to achieving the spatial condition.

[0308] EEE 14 is the method of EEE 13, wherein determining the first state information includes the one or more processors determining that the mobile machine is operating in a first specific mobile machine state, and wherein the second state information indicates one or more of: a distance the mobile machine has traveled while operating in the first specific mobile machine state, a distance the mobile machine is yet to travel while operating in the first specific mobile machine state, or a minimum distance the mobile machine will travel while operating in the first specific mobile machine state.

[0309] EEE 15 is a method of any one of EEEs 13 to 14, further comprising: determining, by the one or more processors, that the mobile machine switches from an operating state that is not a first specific mobile machine state to a first specific mobile machine state; and in response to determining that the mobile machine switches from an operating state that is not the first specific mobile machine state to the first specific mobile machine state, starting, by the one or more processors, an odometer for determining second state information corresponding to the realization of the spatial condition.

[0310] EEE 16 is the method of any one of EEEs 13 to 15, further comprising: outputting a request to an electronic system in the mobile machine through the one or more processors, and receiving a response from the electronic system in the mobile machine through the one or more processors in response to the request, wherein the response from the electronic system in the mobile machine includes a parameter identifier (PID) and a parameter value associated with the PID, and determining the first state information includes the one or more processors determining whether the parameter value associated with the PID exceeds a parameter value threshold associated with a first specific mobile machine state.

[0311] EEE 17 is the method of any one of EEEs 1 to 16, further comprising: determining a speed of the mobile machine by the one or more processors; and determining by the one or more processors whether the speed of the mobile machine exceeds a threshold speed, wherein a mode of outputting status information is conditional on whether the speed of the mobile machine exceeds the threshold speed, wherein if the speed of the mobile machine exceeds the threshold speed, the mode of outputting status information is a restricted mode, and if the speed of the mobile machine does not exceed the threshold speed, the mode of outputting status information is a non-restricted mode.

[0312] EEE 18 is the method of any one of EEEs 1 to 17, wherein the test drive script includes a second specific drive cycle program associated with both a second specific mobile machine state and a second condition related to the second specific mobile machine state, the method further comprising: determining, by the one or more processors, that the first specific drive cycle program has ended; and in response to determining that the first specific drive cycle program has ended, outputting, by the one or more processors, an indication that the second specific drive cycle program is a current drive cycle program to be executed, and optionally, wherein the first specific drive cycle program is an initial drive cycle program or the second specific drive cycle program is a final drive cycle program.

[0313] EEE 19 is the method of any one of EEEs 1 to 18, wherein the test drive script is associated with a fault code set active by an electronic system in the mobile machine, wherein outputting a representation of at least a portion of the test drive script includes displaying a representation of a first specific drive cycle program on a display of the tool, and wherein the method further includes: displaying on the display of the tool a status indicator associated with a parameter identifier (PID), the electronic system in the mobile machine configured to output the parameter identifier, and a status indicator associated with a readiness monitor, the electronic system in the mobile machine configured to check whether the readiness monitor is in a ready state, wherein both the PID and the readiness monitor are associated with the fault code.

[0314] EEE 20 is the method of EEE 19, further comprising: receiving, by the one or more processors, a first parameter value, wherein the first parameter value is output by an electronic system in the mobile machine and is associated with the PID; and determining, by the one or more processors, whether the first parameter value is within a parameter value range defined for both the PID and a first specific drive cycle program; wherein if the one or more processors determine that the first parameter value is within the parameter value range, displaying a status indicator for the PID includes displaying the PID, a first parameter value associated with the PID, and an indication that the first parameter value associated with the PID is within the parameter value range, wherein if the one or more processors determine that the first parameter value is not within the parameter value range, displaying a status indicator for the PID includes displaying the PID, the first parameter value associated with the PID, and an indication that the first parameter value associated with the PID is not within the parameter value range, wherein the indication that the first parameter value associated with the PID is within the parameter value range is different from the indication that the first parameter value associated with the PID is not within the parameter value range.

[0315] EEE 21 is a method of any one of EEEs 1 to 20, wherein the first specific mobile machine state includes a thermal state of a mobile machine component, wherein determining state information corresponding to one or both of achieving the first specific mobile machine state and a first condition involving the first specific mobile machine state includes determining a temperature involving the mobile machine component, and wherein outputting state information corresponding to one or both of achieving the first specific mobile machine state and a first condition involving the first specific mobile machine state includes outputting a temperature involving the mobile machine component.

[0316] EEE 22 is the method of any one of EEEs 1 to 21, further comprising: before executing the initial drive cycle program, outputting a first message to the electronic system in the mobile machine through the one or more processors, the first message requesting the electronic system in the mobile machine to clear all fault codes set by the electronic system in the mobile machine; in response to outputting the first message, receiving a second message from the electronic system in the mobile machine through the one or more processors, the second message indicating a status of the electronic system in the mobile machine clearing the fault codes set by the electronic system in the mobile machine; and outputting data through the one or more processors, the data indicating a status of the electronic system in the mobile machine clearing the fault codes set by the electronic system in the mobile machine.

[0317] EEE 23 is the method of any one of EEEs 1 to 22, wherein the test drive script is associated with a readiness monitor, an electronic system in the mobile machine is configured to check whether the readiness monitor is in a ready state, wherein determining state information corresponding to achieving a first specific mobile machine state includes the one or more processors determining that the readiness monitor is in a ready state, and wherein outputting the state information corresponding to achieving the first specific mobile machine state includes outputting an indication that the readiness monitor is in the ready state so as to notify a driver of the mobile machine that the test drive of the mobile machine can be ended.

[0318] EEE 24 is the method of EEE 23, wherein the indication that the output readiness monitor is in the ready state occurs before the final drive cycle procedure is completed.

[0319] EEE 25 is the method of any one of EEEs 1 to 22, wherein the test drive script is associated with a readiness monitor, an electronic system in the mobile machine is configured to check whether the readiness monitor is in a ready state, wherein the readiness monitor is associated with a fault code, and the electronic system in the mobile machine is configured to set the fault code to active, wherein determining state information corresponding to achieving a first specific mobile machine state includes the one or more processors determining that the electronic system in the mobile machine has set the fault code to active before a final drive cycle procedure is completed, and wherein outputting state information corresponding to achieving the first specific mobile machine state includes outputting an indication that the electronic system in the mobile machine has set the fault code to active so as to notify a driver of the mobile machine that the test drive of the mobile machine may end before completing the final drive cycle procedure.

[0320] EEE 26 is the method of any one of EEEs 1 to 25, wherein the first specific drive cycle program is an initial drive cycle program, a final drive cycle program, or an intermediate drive cycle program between the initial drive cycle program and the final drive cycle program.

[0321] EEE 27 is the method of EEE 1, wherein the one or more processors include: one or more processors located within the tool, one or more processors located within a server operatively connected to the tool, or one or more processors located within the tool and one or more processors located within a server operatively connected to the tool.

[0322] EEE 28 is a method of any one of EEEs 1 to 27, wherein a representation of at least a portion of a test drive script is output and one or more of the following are output: state information corresponding to achieving a first specific mobile machine state or state information corresponding to achieving a first condition involving the first specific mobile machine state, including displaying a graphical user interface on a display, the graphical interface including: a representation of at least a portion of the test drive script, state information corresponding to achieving a first specific mobile machine state and / or state information corresponding to achieving a first condition involving the first specific mobile machine state.

[0323] EEE 29 is a method of any one of EEEs 1 to 28, wherein a representation of at least a portion of a test drive script is output and one or more of the following is output: state information corresponding to achieving a first specific mobile machine state or state information corresponding to achieving a first condition involving the first specific mobile machine state, including using one or more speakers to output an audible sound, the audible sound indicating the representation of at least a portion of the test drive script, the state information corresponding to achieving the first specific mobile machine state and / or the state information corresponding to achieving the first condition involving the first specific mobile machine state.

[0324] EEE 30 is the method of any one of EEEs 1 to 29, further comprising: determining, by the one or more processors, that the mobile machine is a specific type of mobile machine; determining, by the one or more processors, that the tool is operating in a diagnostic mode; after determining that the tool is operating in the diagnostic mode, displaying a first graphical user interface (GUI) on a display of the tool, wherein the first GUI includes an indication that the tool is operating in the diagnostic mode; determining, by the one or more processors, that the tool is transitioning from operating in the diagnostic mode to operating in a repair mode; after displaying the first GUI and determining that the tool is transitioning from operating in the diagnostic mode to operating in the repair mode, displaying a second GUI on the display of the tool, wherein the second GUI includes an indication that the tool is operating in the repair mode; determining, by the one or more processors, that the tool is transitioning from operating in the repair mode to operating in the test drive mode; after displaying the second GUI and determining that the tool is transitioning from operating in the repair mode to operating in the test drive mode After the tool transitions from operating in the repair mode to operating in the test drive mode, displaying a third GUI on the display, wherein the third GUI includes an indication that the tool is operating in the test drive mode, a representation of at least a portion of a test drive script, and one or more of the following: status information corresponding to achieving a first specific mobile machine state, or status information corresponding to achieving a first condition involving the first specific mobile machine state; determining, by the one or more processors, that the tool transitions from operating in the test drive mode to operating in the post-repair report mode; and after displaying the third GUI and determining that the tool transitions from operating in the test drive mode to operating in the post-repair report mode, displaying a fourth GUI on the display, wherein the fourth GUI includes an indication that the tool is operating in the post-repair report mode, wherein the first GUI, the second GUI, the third GUI, and the fourth GUI include information corresponding to specific types of mobile machines.

[0325] EEE 31 is a method of any one of EEEs 1 to 30, wherein one or more of the following is output: status information corresponding to achieving a first specific mobile machine state or status information corresponding to achieving a first condition involving the first specific mobile machine state, including transmitting a data message through the tool, the data message including a request for an electronic control unit in the mobile machine to activate a tactile feedback component in the mobile machine with a specific signature, the specific signature being related to the status information corresponding to achieving the first specific mobile machine state or the status information corresponding to achieving the first condition involving the first specific mobile machine state.

[0326] EEE 32 is a method of any one of EEEs 1 to 30, wherein one or more of the following is output: status information corresponding to achieving a first specific mobile machine state or status information corresponding to achieving a first condition involving the first specific mobile machine state, including transmitting a signal to a wearable tactile feedback device through the tool, the signal indicating that the wearable tactile feedback device is required to activate a tactile feedback component with a specific signature, the specific signature being related to the status information corresponding to achieving the first specific mobile machine state or the status information corresponding to achieving the first condition involving the first specific mobile machine state.

[0327] EEE 33 is the method of any one of EEEs 1 to 32, further comprising: starting a specific drive cycle program of the test drive script for a first time, then starting the specific drive cycle program for a second time, and then starting a next drive cycle program in the ordered sequence of drive cycle programs, and outputting, by the one or more processors, an indication that the specific drive cycle program was started a second time.

[0328] EEE 34 is the method of any one of EEEs 1 to 33, further comprising: determining, by the one or more processors, the position of the mobile machine or the tool using position data from a global navigation satellite system, and outputting, by the one or more processors, instructions for guiding the mobile machine along a path having features compatible with achieving a first specific mobile machine state and / or achieving a first condition related to the first specific mobile machine state.

[0329] EEE 35 is the method of any one of EEEs 1 to 34, wherein the mobile machine is a vehicle configured as an automobile, a motorcycle, an all-terrain vehicle (ATV), a snowmobile, a water truck, a light truck, a medium truck, a heavy truck, a semi-tractor, a drone, or an agricultural machine.

[0330] EEE 36 is the method of any one of EEEs 1 to 35, wherein determining the test drive script comprises determining one or more identifiers within the test drive script map, and the test drive script is associated with the one or more identifiers.

[0331] EEE 37 is the method of EE36, wherein the one or more identifiers include one or more diagnostic trouble codes.

[0332] EEE 38 is the method of any of EEE 36 or 37, wherein the one or more identifiers include a vehicle identifier, a vehicle system identifier, and a vehicle component identifier.

[0333] EEE 39 is the method of any one of EEEs 36 to 38, wherein the one or more identifiers include a textual customer complaint.

[0334] EEE 40 is the method of any one of EEEs 1 to 39, wherein the ordered sequence of drive cycle programs is specified by an original equipment manufacturer that builds the mobile machine.

[0335] EEE 41 is the method of any one of EEEs 1 to 39, wherein the ordered sequence of drive cycle programs is specified by an aftermarket supplier of maintenance information about the vehicle.

[0336] EEE 42 is the method of any one of EEEs 1 to 41, wherein the electronic system in the mobile machine includes an electronic control unit for a powertrain in the mobile machine, and wherein the electronic control unit is programmed to control emissions of the mobile machine in compliance with European on-board diagnostic regulations.

[0337] EEE 43 is the method of any one of EEEs 1 to 41, wherein the electronic system in the mobile machine includes an electronic control unit for a powertrain system in the mobile machine, and wherein the electronic control unit is programmed to control emissions of the mobile machine in compliance with U.S. On-Board Diagnostics II regulations.

[0338] EEE 44 is the method of any one of EEEs 1 to 41, wherein the electronic system in the mobile machine includes an advanced driver assistance system.

[0339] EEE 45 is a computing system comprising: one or more processors; and a computer-readable data storage storing executable instructions, wherein execution of the executable instructions by the one or more processors causes the computing system to perform functions, the functions comprising: determining a test drive script to be executed during a test drive of a mobile machine while a tool monitors an electronic system in the mobile machine, wherein the test drive script comprises an ordered sequence of drive cycle programs, wherein the ordered sequence of drive cycle programs begins with an initial drive cycle program and ends with a final drive cycle program, wherein each drive cycle program indicates a corresponding mobile machine state, and wherein the test drive script comprises a first specific drive cycle program associated with both a first specific mobile machine state and a first condition related to the first specific mobile machine state; outputting a representation of at least a portion of the test drive script; determining one or more of: state information corresponding to achieving the first specific mobile machine state or state information corresponding to achieving the first condition related to the first specific mobile machine state; and outputting one or more of: state information corresponding to achieving the first specific mobile machine state or state information corresponding to achieving the first condition related to the first specific mobile machine state.

[0340] EEE 46 is the computing system of EEE 45, further comprising: the tool.

[0341] EEE 47 is a computer-readable medium having instructions stored therein that are executable by one or more processors to cause a computing system to perform functions, the functions comprising: determining a test drive script to be executed during a test drive of a mobile machine while a tool monitors an electronic system in the mobile machine, wherein the test drive script comprises an ordered sequence of drive cycle programs, wherein the ordered sequence of drive cycle programs begins with an initial drive cycle program and ends with a final drive cycle program, wherein each drive cycle program indicates a corresponding mobile machine state, and wherein the test drive script comprises a first specific drive cycle program associated with both a first specific mobile machine state and a first condition related to the first specific mobile machine state; outputting a representation of at least a portion of the test drive script; determining one or more of: state information corresponding to achieving the first specific mobile machine state or state information corresponding to achieving the first condition related to the first specific mobile machine state; and outputting one or more of: state information corresponding to achieving the first specific mobile machine state or state information corresponding to achieving the first condition related to the first specific mobile machine state.

[0342] EEE 48 is a computing system including: one or more processors, and a computer-readable data storage storing executable instructions, wherein the one or more processors execute the executable instructions to enable the computing system to perform any one of the methods of EEE 1 to EEE 44.

[0343] EEE 49 is a non-transitory computer-readable medium having stored therein instructions that can be executed by one or more processors to cause a computing system to perform the method of any one of EEE 1 to EEE 44.

[0344] EEE 50 is a computing system comprising means for determining a test drive script to be executed during a test drive of a mobile machine while a tool monitors an electronic system in the mobile machine, wherein the test drive script comprises an ordered sequence of drive cycle programs, wherein the ordered sequence of drive cycle programs begins with an initial drive cycle program and ends with a final drive cycle program, wherein each drive cycle program indicates a corresponding mobile machine state, and wherein the test drive script comprises a first specific drive cycle program associated with both a first specific mobile machine state and a first condition related to the first specific mobile machine state; means for outputting a representation of at least a portion of the test drive script; means for determining one or more of: state information corresponding to achieving the first specific mobile machine state or state information corresponding to achieving the first condition related to the first specific mobile machine state; and means for outputting one or more of: state information corresponding to achieving the first specific mobile machine state or state information corresponding to achieving the first condition related to the first specific mobile machine state.

Claims

1. A method comprising: A test drive script is determined, by a processor, to be executed during a test drive of the mobile machine while the tool monitors electronic systems in the mobile machine, wherein: The test drive script is associated with the first readiness monitor, The electronic system is configured to check whether the first readiness monitor passes or fails during the test drive, The test drive script consists of an ordered sequence of drive cycle procedures, An ordered sequence of drive cycle procedures begins with an initial drive cycle procedure and ends with a final drive cycle procedure. Each drive cycle program indicates a corresponding mobile machine state, and the corresponding mobile machine state of one or more drive cycle programs includes a speed of the mobile machine greater than zero miles or kilometers per hour; outputting, by a processor, a representation of at least a portion of the test drive script; determining, by the processor, status information corresponding to whether the first readiness monitor passed or failed during the test drive; and Status information corresponding to whether the first readiness monitor passed or failed during the test drive is output by the processor.

2. The method according to claim 1, wherein: The test drive script includes a first specific drive cycle program associated with both a first specific mobile machine state and a first condition related to the first specific mobile machine state, The first condition related to the first specific mobile machine state comprises a time condition, The method further comprises: determining first additional status information and second additional status information, The first additional state information indicates whether the mobile machine is operating in a first specific mobile machine state, and The second additional status information corresponds to the realization time condition.

3. The method according to claim 2, wherein determining the first additional state information comprises the processor determining that the mobile machine is operating in a first specific mobile machine state, and The second additional status information indicates one or more of the following: the amount of time the mobile machine has been operating in the first particular mobile machine state, the additional amount of time that the mobile machine will operate in the first specific mobile machine state, or The minimum amount of time that the mobile machine will operate in the first particular mobile machine state.

4. The method according to claim 2, further comprising: determining, by the processor, that the mobile machine switches from an operating state that is not the first specific mobile machine state to a first specific mobile machine state; as well as In response to determining that the mobile machine switches from an operating state that is not the first specific mobile machine state to the first specific mobile machine state, a timer for determining second additional state information corresponding to the fulfillment of the time condition is initiated by the processor.

5. The method according to claim 2, further comprising: outputting a request to an electronic system in the mobile machine via a processor, and In response to the request, receiving, by the processor, a response from an electronic system in the mobile machine, wherein the response from the electronic system in the mobile machine includes a parameter identifier and a parameter value associated with the parameter identifier, and Wherein determining the first additional state information includes the processor determining whether a parameter value associated with the parameter identifier exceeds a parameter value threshold associated with the first specific mobile machine state.

6. The method according to claim 1, wherein: The test drive script includes a first specific drive cycle program associated with both a first specific mobile machine state and a first condition related to the first specific mobile machine state, A first condition related to a first specific mobile machine state includes a spatial condition, and The method further comprises: determining first additional status information and second additional status information, The first additional state information indicates whether the mobile machine is operating in a first specific mobile machine state, and The second additional status information corresponds to the realization space condition.

7. The method according to claim 6, wherein determining the first additional state information comprises the processor determining that the mobile machine is operating in a first specific mobile machine state, and The second additional status information indicates one or more of the following: a distance the mobile machine has traveled while operating in the first specific mobile machine state, the distance the mobile machine has yet to travel while operating in the first specific mobile machine state, or The minimum distance the mobile machine will travel while operating in the first particular mobile machine state.

8. The method according to claim 6, further comprising: determining, by the processor, that the mobile machine switches from an operating state that is not the first specific mobile machine state to a first specific mobile machine state; as well as In response to determining that the mobile machine has switched from an operating state that is not the first specific mobile machine state to the first specific mobile machine state, an odometer for determining second additional state information corresponding to the realization of the spatial condition is initiated by the processor.

9. The method according to claim 6, further comprising: outputting, by the processor, a request to an electronic system in the mobile machine; as well as In response to the request, receiving, by a processor, a response from an electronic system in the mobile machine, wherein the response from the electronic system in the mobile machine includes a parameter identifier and a parameter value associated with the parameter identifier, and Wherein determining the first additional state information includes the processor determining whether a parameter value associated with the parameter identifier exceeds a parameter value threshold associated with the first specific mobile machine state.

10. The method according to claim 1, further comprising: determining, by a processor, the speed of the moving machine; as well as determining, by a processor, whether the speed of the mobile machine exceeds a threshold speed, The mode of outputting the status information is conditioned on whether the speed of the mobile machine exceeds a threshold speed. wherein if the speed of the mobile machine exceeds a threshold speed, the mode of outputting the status information is a restricted mode, and If the speed of the mobile machine does not exceed the threshold speed, the mode for outputting the status information is the unrestricted mode.

11. The method according to claim 1, wherein: The test drive script includes a first specific drive cycle program associated with both a first specific mobile machine state and a first condition related to the first specific mobile machine state, The test drive script includes a second specific drive cycle program associated with both a second specific mobile machine state and a second condition related to the second specific mobile machine state, and The method further comprises: determining, by the processor, that the first specific drive cycle routine has ended; and In response to determining that the first specific drive cycle routine has ended, an indication is outputted by the processor that the second specific drive cycle routine is the current drive cycle routine to be executed.

12. The method according to claim 1, wherein: The test drive script includes a first specific drive cycle program associated with both a first specific mobile machine state and a first condition related to the first specific mobile machine state, The test drive script is associated with a fault code that is set active by the electronic system in the mobile machine. Outputting a representation of at least a portion of the test drive script includes displaying a representation of the first specific drive cycle program on a display of the tool, and The method further comprises: displaying on a display of the tool a status indicator associated with a parameter identifier and a status indicator associated with a first readiness monitor, the electronic system in the mobile machine being configured to output the parameter identifier, Both the parameter identifier and the first readiness monitor are associated with the fault code.

13. The method according to claim 12, further comprising: receiving, by a processor, a first parameter value, wherein the first parameter value is output by an electronic system in the mobile machine and is associated with a parameter identifier; as well as determining, by a processor, whether the first parameter value is within a range of parameter values ​​defined for both the parameter identifier and the first specific drive cycle program, wherein if the processor determines that the first parameter value is within the parameter value range, displaying the status indicator of the parameter identifier includes displaying the parameter identifier, the first parameter value associated with the parameter identifier, and an indication that the first parameter value associated with the parameter identifier is within the parameter value range, wherein if the processor determines that the first parameter value is not within the parameter value range, displaying the status indicator of the parameter identifier includes displaying the parameter identifier, the first parameter value associated with the parameter identifier, and an indication that the first parameter value associated with the parameter identifier is not within the parameter value range, and wherein an indication that the first parameter value associated with the parameter identifier is within the parameter value range is different from an indication that the first parameter value associated with the parameter identifier is not within the parameter value range.

14. The method according to claim 1, wherein: The test drive script includes a first specific drive cycle program associated with both a first specific mobile machine state and a first condition related to the first specific mobile machine state, The first specific mobile machine state includes a thermal state of a mobile machine component, and The method further comprises: determining additional state information corresponding to one or both of achieving a first specific mobile machine state and a first condition related to the first specific mobile machine state, Determining additional status information includes determining the temperature of moving machine parts, and Outputs additional status information.

15. The method according to claim 1, further comprising: prior to executing the initial drive cycle routine, outputting, by the processor, a first message to an electronic system in the mobile machine, the first message requesting the electronic system in the mobile machine to clear all fault codes set by the electronic system in the mobile machine; receiving, by the processor, a second message from the electronic system in the mobile machine in response to outputting the first message, the second message indicating a status of the electronic system in the mobile machine clearing a fault code set by the electronic system in the mobile machine; as well as Data indicative of a status of an electronic system in the mobile machine clearing a fault code set by the electronic system in the mobile machine is outputted by the processor.

16. The method according to claim 1, wherein: determining the status information includes the processor determining that a first readiness monitor has passed, and Outputting the status information includes outputting an indication that the first readiness monitor has been passed, so as to notify the operator of the mobile machine that the test drive of the mobile machine can be concluded.

17. The method of claim 16, wherein outputting the indication occurs prior to completing a final drive cycle routine.

18. The method according to claim 1, wherein: The test drive script includes a first specific drive cycle program associated with both a first specific mobile machine state and a first condition related to the first specific mobile machine state, The first readiness monitor is associated with a fault code, the electronic system in the mobile machine being configured to set the fault code to active, and The method further comprises: determining additional state information corresponding to achieving a first specific mobile machine state, Determining the additional status information includes the processor determining that an electronic system in the mobile machine has set a fault code to active before the final drive cycle procedure was completed, and The method further comprises: Additional status information is output in order to inform the driver of the mobile machine that the test drive of the mobile machine may end before the final drive cycle procedure is completed.

19. The method according to claim 1, wherein: The test drive script includes a first specific drive cycle program associated with both a first specific mobile machine state and a first condition related to the first specific mobile machine state, and The first specific drive cycle program is an initial drive cycle program, a final drive cycle program, or an intermediate drive cycle program between the initial drive cycle program and the final drive cycle program.

20. The method of claim 1, wherein the processor comprises: One or more processors located within the tool, one or more processors located within a server operatively connected to the tool, or one or more processors located within the tool and one or more processors located within a server operatively connected to the tool.

21. The method according to claim 1, wherein: The test drive script includes a first specific drive cycle program associated with both a first specific mobile machine state and a first condition related to the first specific mobile machine state, The method further comprises: determining first additional state information corresponding to achieving a first specific mobile machine state and second additional state information corresponding to achieving a first condition related to the first specific mobile machine state, and outputting one or more of the first additional status information or the second additional status information, and Outputting a representation of at least a portion of the test drive script and outputting one or more of the following: first additional state information corresponding to achieving a first specific mobile machine state or second additional state information corresponding to achieving a first condition involving the first specific mobile machine state, including displaying a graphical user interface on a display, the graphical user interface including: a representation of at least a portion of the test drive script, the first additional state information corresponding to achieving the first specific mobile machine state and / or the second additional state information corresponding to achieving the first condition involving the first specific mobile machine state.

22. The method according to claim 1, wherein: The test drive script includes a first specific drive cycle program associated with both a first specific mobile machine state and a first condition related to the first specific mobile machine state, The method further comprises: determining first additional state information corresponding to achieving a first specific mobile machine state or second additional state information corresponding to achieving a first condition related to the first specific mobile machine state, and outputting one or more of the first additional status information or the second additional status information, and Outputting a representation of at least a portion of the test drive script and outputting one or more of the following: first additional state information corresponding to achieving a first specific mobile machine state or second additional state information corresponding to achieving a first condition involving the first specific mobile machine state, including using one or more speakers to output audible sounds, the audible sounds indicating the representation of at least a portion of the test drive script, the first additional state information corresponding to achieving the first specific mobile machine state and / or the second additional state information corresponding to achieving the first condition involving the first specific mobile machine state.

23. The method according to claim 1, further comprising: The test drive script includes a first specific drive cycle program associated with both a first specific mobile machine state and a first condition related to the first specific mobile machine state, The method further comprises: determining, by the processor, that the mobile machine is a particular type of mobile machine; determining, by a processor, that the tool is operating in a diagnostic mode; After determining that the tool is operating in a diagnostic mode, displaying a first graphical user interface on a display of the tool, wherein the first graphical user interface includes an indication that the tool is operating in a diagnostic mode; determining, by a processor, that the tool transitions from operating in a diagnostic mode to operating in a repair mode; after displaying the first graphical user interface and determining that the tool transitions from operating in the diagnostic mode to operating in the repair mode, displaying a second graphical user interface on a display of the tool, wherein the second graphical user interface includes an indication that the tool is operating in the repair mode; determining, by a processor, that the tool transitions from operating in a repair mode to operating in a test drive mode; after displaying the second graphical user interface and determining that the tool transitions from operating in the repair mode to operating in the test drive mode, displaying a third graphical user interface on the display, wherein the third graphical user interface includes an indication that the tool is operating in the test drive mode, a representation of at least a portion of a test drive script, and status information; determining, by a processor, that the tool transitions from operating in a test drive mode to operating in a post-repair reporting mode; and after displaying the third graphical user interface and determining that the tool transitions from operating in the test drive mode to operating in the post-repair report mode, displaying a fourth graphical user interface on the display, wherein the fourth graphical user interface includes an indication that the tool is operating in the post-repair report mode, The first graphical user interface, the second graphical user interface, the third graphical user interface, and the fourth graphical user interface include information corresponding to a specific type of mobile machine.

24. The method according to claim 1, wherein: The test drive script includes a first specific drive cycle program associated with both a first specific mobile machine state and a first condition related to the first specific mobile machine state, The method further comprises: determining first additional state information corresponding to achieving a first specific mobile machine state or second additional state information corresponding to achieving a first condition related to the first specific mobile machine state, and outputting one or more of the first additional status information or the second additional status information, and Outputting one or more of the following: first additional state information corresponding to the realization of a first specific mobile machine state or second additional state information corresponding to the realization of a first condition involving the first specific mobile machine state, including transmitting a data message through the tool, the data message including a request for an electronic control unit in the mobile machine to activate a tactile feedback component of the mobile machine with a specific signature, the specific signature being related to the first additional state information corresponding to the realization of the first specific mobile machine state or the second additional state information corresponding to the realization of the first condition involving the first specific mobile machine state.

25. The method according to claim 1, wherein: The test drive script includes a first specific drive cycle program associated with both a first specific mobile machine state and a first condition related to the first specific mobile machine state, The method further comprises: determining first additional state information corresponding to achieving a first specific mobile machine state or second additional state information corresponding to achieving a first condition related to the first specific mobile machine state, and outputting one or more of the first additional status information or the second additional status information, and Outputting one or more of the following: first additional state information corresponding to achieving a first specific mobile machine state or second additional state information corresponding to achieving a first condition involving the first specific mobile machine state, including transmitting a signal to a wearable tactile feedback device through the tool, the signal indicating that the wearable tactile feedback device is required to activate a tactile feedback component with a specific signature, wherein the specific signature is related to the first additional state information corresponding to achieving the first specific mobile machine state or the second additional state information corresponding to achieving the first condition involving the first specific mobile machine state.

26. The method according to claim 1, wherein: The test drive script includes a first specific drive cycle program associated with both a first specific mobile machine state and a first condition related to the first specific mobile machine state, The method further comprises: Initiating a first specific drive cycle program of the test drive script a first time, then initiating the first specific drive cycle program a second time, and then initiating a next drive cycle program in the ordered sequence of drive cycle programs; and An indication is outputted by the processor that the first specific drive cycle routine is initiated a second time.

27. The method according to claim 1, wherein: The test drive script includes a first specific drive cycle program associated with both a first specific mobile machine state and a first condition related to the first specific mobile machine state, The method further comprises: determining, by a processor, the position of the mobile machine or said implement using position data from a global navigation satellite system; and Instructions are outputted, by the processor, for directing the mobile machine along a path having characteristics compatible with achieving a first specific mobile machine state and / or achieving a first condition related to the first specific mobile machine state.

28. A computer system comprising: processor; as well as A computer-readable data storage device storing executable instructions, wherein execution of the executable instructions by the processor causes the computing system to perform functions, the functions comprising: A test drive script is identified to be executed during a test drive of the mobile machine while the tool monitors electronic systems in the mobile machine, wherein: The test drive script is associated with the first readiness monitor, The electronic system is configured to check whether the first readiness monitor passes or fails during the test drive, The test drive script consists of an ordered sequence of drive cycle procedures, An ordered sequence of drive cycle procedures begins with an initial drive cycle procedure and ends with a final drive cycle procedure. Each driving cycle program indicates the corresponding mobile machine status, The corresponding mobile machine state of the one or more drive cycle programs includes a speed of the mobile machine greater than zero miles or kilometers per hour, The test drive script includes a first specific drive cycle program associated with both a first specific mobile machine state and a first condition related to the first specific mobile machine state; outputting a representation of at least a portion of the test drive script; determining one or more of: status information corresponding to whether a first readiness monitor passed or failed during the test drive or a first condition related to a first specific mobile machine state; and Status information corresponding to whether the first readiness monitor passed or failed during the test drive or a first condition related to a first specific mobile machine state is output.

29. The computing system of claim 28, further comprising: The tool.

30. A non-transitory computer readable memory having stored therein instructions executable by a processor to cause a computing system to perform functions comprising: A test drive script is identified to be executed during a test drive of the mobile machine while the tool monitors electronic systems in the mobile machine, wherein: The test drive script is associated with the first readiness monitor, The electronic system is configured to check whether the first readiness monitor passes or fails during the test drive, The test drive script consists of an ordered sequence of drive cycle procedures, An ordered sequence of drive cycle procedures begins with an initial drive cycle procedure and ends with a final drive cycle procedure. Each driving cycle program indicates the corresponding mobile machine status, The corresponding mobile machine state of the one or more drive cycle programs includes a speed of the mobile machine greater than zero miles or kilometers per hour, The test drive script includes a first specific drive cycle program associated with both a first specific mobile machine state and a first condition related to the first specific mobile machine state; outputting a representation of at least a portion of the test drive script; determining one or more of: status information corresponding to whether a first readiness monitor passed or failed during the test drive or a first condition related to a first specific mobile machine state; and Status information corresponding to whether the first readiness monitor passed or failed during the test drive or a first condition related to a first specific mobile machine state is output.

Images