Vehicle health recording

Abstract

An example method involves receiving, at a computing system, vehicle diagnostic information from a vehicle. The vehicle diagnostic information may include one or more sets of parameters corresponding to a parameter identifier (PID). The method further involves identifying a first set of parameters corresponding to the PID representative of a state of a particular system of the vehicle, and determining a current value of the PID using the first set of parameters. The method may also involve performing a comparison between the current value of the PID and a predetermined value and determining a health condition of a particular system of the vehicle such that the health condition reflects a difference between the current value of the PID and the predetermined value. The method may also involve displaying, by the computing system, a vehicle health record representing a health of a particular system of the vehicle at the graphical interface.

Description

[0001] This application is a divisional application of the patent application for "Vehicle Health Record" with the filing date of August 5, 2020, application number 202080057251.7.

[0002] Cross - reference to related applications

[0003] This application claims the priority of U.S. Patent Application No. 16 / 541742, filed on August 15, 2019, the entire content of which is incorporated herein by reference. Background Art

[0004] Most vehicles are serviced at least once during their service life. In many cases, the vehicle is serviced by a professional mechanic (such as a technician) in a facility. In other cases, technicians and / or other people who service the vehicle can perform the service at other locations, such as on the shoulder of an urban street or a highway. When servicing a vehicle, the technician can refer to a repair order, which includes symptom data about the vehicle's condition (e.g., perceived faults) described by the vehicle owner. In some cases, the repair order is a paper repair order. In other cases, the symptom data of the repair order can be displayed on the display of a computer system.

[0005] Technicians and / or other individuals (hereinafter referred to as users) can use any of a variety of computerized tools and / or non - computerized tools to service (e.g., repair) various mechanical and / or electronic vehicle components on a vehicle. When servicing a vehicle, the user sometimes needs information for diagnosing and / or repairing the vehicle, as well as post - repair activities performed on the repaired vehicle. For example, the user can use a computing system that obtains and displays Parameter Identifier (PID) parameters from the vehicle being serviced. The computing system can use a menu with multiple levels to display the PID parameters, and the user must navigate through the menu to display the PID parameters. For example, the computing system can require the user to enter the vehicle year at an initial menu level, the vehicle make at another menu level, the vehicle model at another menu level, the engine identifier at another menu level, the vehicle system at another menu level, and the vehicle communication function at yet another menu level, such as selecting a PID. In the case where the computing system includes an option to display a repair order, the user may need to navigate back to the initial menu level in order to access the option to display the repair order.

[0006] Although the information provided by a computing system is helpful when servicing a vehicle, the PID parameters displayed by the computing system are often in a disordered format, which may make it difficult for a user to browse the available information and clearly understand which vehicle systems may require some form of maintenance. While an experienced user may be able to browse different menus to access and review the PID parameters associated with a particular vehicle system, there is still a need to simplify the presentation of vehicle information by clearly associating the PID parameters with the vehicle systems so that the user can understand the current health status of these vehicle systems. SUMMARY OF THE INVENTION

[0007] Several exemplary embodiments relate to the development and generation of a vehicle health record. The vehicle health record provides information related to the health status of various systems of a vehicle in an organized visual format that can be displayed via a graphical user interface (GUI) on a display interface. In particular, the vehicle health record can use health status graphics, such as charts, colors, numerical indicators, and other visual graphics, to present the current health status statistics of various vehicle systems in a clear and understandable manner.

[0008] The development of a vehicle health record for a vehicle may initially involve a computing system obtaining vehicle diagnostic information (VDI) from the vehicle and identifying within the VDI parameters that represent the current values of PIDs that represent the health status of various vehicle systems. The computing system can compare the current values of one or more PIDs with one or more predefined values of the PIDs to determine the health status statistics of various vehicle systems and incorporate these health status statistics into the vehicle's vehicle health record. In particular, the comparison of the current values of the PIDs relative to the predefined values can enable the computing system to determine whether the system represented by the PID requires some form of maintenance (e.g., rotation, replenishment, replacement). These determinations for various vehicle systems can be incorporated into the vehicle health record and can then be used for various purposes, including: (i) as a way to view and understand the current health status of various vehicle systems, (ii) tracking the maintenance records of one or more vehicle systems over time, and (iii) providing an estimate of when a vehicle system may require some form of attention (e.g., maintenance, replenishment, rotation, replacement).

[0009] In one aspect, an exemplary embodiment takes the form of a method that includes receiving, at a computing system, vehicle diagnostic information from a vehicle. The vehicle diagnostic information includes one or more sets of parameters corresponding to parameter identifiers (PIDs). The method further involves identifying a first set of parameters corresponding to a PID representative of the state of a particular system of the vehicle and using the first set of parameters to determine a current value of the PID. The method also involves comparing the current value of the PID with a predetermined value. The method further involves determining the health status of the particular system of the vehicle such that the health status reflects the difference between the current value and the predetermined value of the PID. The method also involves displaying, by the computing system at a graphical interface, a vehicle health record representative of the health status of the particular system of the vehicle.

[0010] In another aspect, an exemplary embodiment takes the form of a non-transitory computer-readable medium storing instructions executable by one or more processors to cause a computing system to perform functions. The functions include receiving vehicle diagnostic information from a vehicle. The vehicle diagnostic information includes one or more sets of parameters corresponding to parameter identifiers (PIDs). The functions also include identifying a first set of parameters corresponding to a PID representative of the state of a particular system of the vehicle and using the first set of parameters to determine a current value of the PID. The functions further include comparing the current value of the PID with a predetermined value and determining the health status of the particular system of the vehicle such that the health status reflects the difference between the current value and the predetermined value of the PID. The functions also include displaying, at a graphical interface, a vehicle health record representative of the health status of the particular system of the vehicle.

[0011] In another aspect, an exemplary embodiment takes the form of a system. The system includes a display interface and a computing device. The computing device is configured to receive vehicle diagnostic information from a vehicle. The vehicle diagnostic information includes one or more sets of parameters corresponding to parameter identifiers (PIDs). The computing device is also configured to identify a first set of parameters corresponding to a PID representative of the state of a particular system of the vehicle and use the first set of parameters to determine a current value of the PID. The computing device is also configured to compare the current value of the PID with a predetermined value. The computing device is further configured to determine the health status of the particular system of the vehicle such that the health status reflects the difference between the current value and the predetermined value of the PID. The computing device is also configured to display, at the display interface, a vehicle health record representative of the health status of the particular system of the vehicle.

[0012] By reading the following detailed description and referring to the drawings where appropriate, those of ordinary skill in the art will discover these and other aspects and advantages. Additionally, it should be understood that the embodiments described in this summary and elsewhere are merely examples and do not necessarily limit the scope of the invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Embodiments are described herein with reference to the accompanying drawings.

[0014] Figure 1 is a schematic diagram showing an operating environment in which an exemplary embodiment may operate.

[0015] Figure 2 is a communication flowchart according to one or more exemplary embodiments.

[0016] Figure 3 is a schematic diagram of a vehicle showing the placement of a computing system according to one or more exemplary embodiments.

[0017] Figure 4 is a block diagram of a computing system according to one or more exemplary embodiments.

[0018] Figure 5 is a schematic diagram of a VST with a display according to one or more exemplary embodiments.

[0019] Figure 6 is a block diagram of a server according to one or more exemplary embodiments.

[0020] Figure 7 shows a PID index according to one or more exemplary embodiments.

[0021] Figure 8 is a schematic diagram depicting a display presentation according to one or more exemplary embodiments.

[0022] Figure 9 is a schematic diagram depicting another display presentation according to one or more exemplary embodiments.

[0023] Figure 10 is a schematic diagram depicting multiple display presentations according to one or more exemplary embodiments.

[0024] Figure 11 is a flowchart for implementing vehicle health record according to one or more exemplary embodiments.

[0025] Figure 12 shows another flowchart for implementing vehicle health record according to one or more exemplary embodiments.

[0026] Figure 13A and Figure 13B show PIDs that can be used to analyze the health of vehicle systems according to one or more exemplary embodiments.

[0027] Figure 14is a graphical user interface for implementing vehicle health record options according to one or more exemplary embodiments.

[0028] Figure 15 is another graphical user interface for implementing vehicle health record options according to one or more exemplary embodiments.

[0029] Figure 16 is another graphical user interface for implementing vehicle health record options according to one or more exemplary embodiments.

[0030] Figure 17 is an additional graphical user interface for implementing vehicle health record options according to one or more exemplary embodiments.

[0031] Figure 18 is yet another graphical user interface for implementing vehicle health record options according to one or more exemplary embodiments. Detailed Description

[0032] I. Introduction

[0033] This specification describes several exemplary embodiments, including but not limited to exemplary embodiments related to the development and presentation of vehicle health records. As described above, vehicle health records can provide an organized way to store and display information describing the health of various systems of a vehicle (i.e., vehicle systems). A vehicle health record for a particular vehicle can be generated during the initial maintenance of the vehicle and can communicate health statistics for various vehicle systems, including which vehicle systems are operating within optimal ranges or conditions, and when certain vehicle systems may require subsequent inspection or some form of maintenance (e.g., at a particular mileage on the odometer). Once a vehicle health record has been generated for a vehicle, the vehicle health record can then be updated during subsequent vehicle servicing to maintain a record of the changing health of the different vehicle systems over time. In this way, vehicle health records can be used to track when a particular system was serviced, how the system was serviced, and by whom, and to provide other information to help the vehicle owner keep the vehicle in overall good condition.

[0034] To generate a new or update an existing vehicle health record associated with a vehicle, a computing system can initially receive a VDI from the vehicle. For example, the computing system can obtain the VDI using a wired or wireless connection to the vehicle. In some cases, the computing system can obtain the VDI during a maintenance inspection or servicing of the vehicle. Although the computing system is described as performing the various operations described herein to develop and display a vehicle health record, these operations can be performed by multiple computing systems in some examples. For example, the computing system can obtain the VDI from the vehicle and communicate the VDI to a server that performs one or more of the operations described for developing the vehicle health record. Thus, for illustrative purposes, the computing system is described herein as performing these operations.

[0035] Once the computing system obtains the VDI from the vehicle, the computing system can analyze the VDI to identify parameters that indicate current values of PIDs that represent the health of various vehicle systems. These PIDs can include one or more vehicle condition PIDs (VCPs), which are a specific type of PID configured to convey attributes related to the current health of a vehicle system. For example, a VCP can relate to consumables associated with a vehicle system, such as fluid levels used by the system (e.g., engine oil, windshield washer fluid), brake pad wear levels, or an indication of the oil life of the engine. Thus, a VCP can indicate a level of an attribute of a vehicle system that is consumed over time with use (e.g., washer fluid decreases with each use). Some VCPs can represent numerical values for one or more multi-point inspections, such as fluid levels, brake pad wear levels, oil life, tire pressure, the state of the battery, or a trailer bulb out signal. Thus, the exemplary embodiments described herein can relate to using a set of PIDs to determine the health of a vehicle system that includes one or more VCPs. The computing system can include a module that can map information to identify VCPs within the PIDs. In some cases, a VCP can include identification information that indicates that the VCP represents an aspect of vehicle health for use by the computing system. In some embodiments, the computing system can obtain information related to dozens, hundreds, or even thousands of health-related PIDs.

[0036] In some embodiments, a PID can include a tag that indicates that the PID represents health-related information. Thus, the computing system can identify these PIDs based on the respective tags. In other embodiments, the computing system can be configured to determine which PIDs convey information related to the health of a vehicle system.

[0037] Parameters determined within the VDI received from the vehicle can be used to determine the current value of the PID. In particular, the current value of the PID can represent information about the current condition of the vehicle system associated with the PID. For example, the current value of the PID can indicate the current condition of the brake pads or another vehicle system, the fluid level of the windshield washer, the oil level of the oil system, the battery voltage, or another aspect related to the health of the vehicle system. Thus, the specific health condition-related information conveyed by the current value of the PID can depend on the type of vehicle system.

[0038] Although the current value of the PID can convey some information related to the health of the system, the computing system can utilize a comparison process to determine whether the current value of the PID indicates that the vehicle system is currently healthy (e.g., the vehicle system is operating within an optimal range) or the vehicle system requires some form of maintenance. More specifically, the comparison of the current value of the PID with one or more predefined values can enable the computing system to determine: (i) whether the current condition of the associated vehicle system indicates that the vehicle system requires maintenance, (ii) if the vehicle system does not require immediate maintenance, estimate when the vehicle system should be inspected again (e.g., at a specific mileage on the odometer or other indication), or (iii) the vehicle system is in good health and may not require maintenance for a relatively long time (e.g., not a priority inspection during a service interval). The predefined values used for comparison with the current value of the PID can represent thresholds or other historical reference points as a benchmark for evaluating the health of the vehicle system. Then, each health condition assessment of the vehicle system can be incorporated into the vehicle's vehicle health record to develop an overall information presentation that can be used to understand which vehicle systems may require some form of maintenance.

[0039] One or more predefined values used to critique the current value of the PID to evaluate the health of the associated vehicle system can vary within the examples. In some cases, the predefined values can correspond to thresholds that can be used to assist the computing system in determining whether the current value of the PID is within the healthy condition range (i.e., the optimal range of operation). If the comparison results in the current value of the PID breaching the threshold, this can serve as an indication that the vehicle system associated with the PID requires some form of review or maintenance. Similarly, multiple predefined values can be used to evaluate the current value of the PID to determine whether the vehicle system requires maintenance.

[0040] In addition, one or more predefined values used in the comparison may depend on different factors, such as the type of vehicle system being analyzed, the mileage on the vehicle odometer, or the mileage driven since the last maintenance of the system, set during a previous maintenance of the system, and values set by the vehicle or system manufacturer. One or more of these factors can be used to derive one or more predefined values for comparison with the current value of the PID representing the current state of the vehicle system.

[0041] In an exemplary embodiment, the computing system can analyze the current value of the PID relative to a single predefined value (e.g., a single predefined threshold). Such a comparison can yield a binary result of the health of the vehicle system under analysis. For example, the computing system can determine that the vehicle system is operating within a healthy range unless the current value of the PID breaches the single predefined value. To illustrate an example, the computing system can use a single threshold when analyzing the fluid level of a windshield washer or similar fluid system. In particular, when the fluid level associated with the system drops below a certain amount (i.e., the predefined threshold amount), the computing system can determine that the fluid level is not within the optimal range for the system and that maintenance (i.e., refilling the fluid) is required. Thus, the computing system can include some type of maintenance alert for the specific system that indicates a refill is needed within the vehicle's vehicle health record. For example, the maintenance alert can include text, color, or some other signal to alert the user that the fluid level needs to be replenished.

[0042] In another embodiment, the computing system can analyze the current value of the PID relative to multiple predefined values. For example, the current value of the PID can be compared to a lower threshold and an upper threshold that together define the optimal operating range for a specific vehicle system. To illustrate an example, the computing system can compare the pressure level of a tire relative to an upper threshold and a lower threshold. When the comparison indicates that the pressure level of the tire is outside the range set by the thresholds, the computing system can include an indication within the vehicle health record that specifies maintenance of the tire. For example, the indication can include text, using color, a chart, or some other presentation to show the user that the tire is outside the optimal tire pressure range. Thus, the computing system can perform this process for each tire in order to provide a complete analysis of the tire pressure of the vehicle within the vehicle health record.

[0043] In another embodiment, the computing system may analyze the current value of a PID relative to a set of predefined values. For example, the computing system may compare the current value of the PID to a numerical scale that indicates the health of an associated vehicle system based on the position of the current value of the PID on the scale. For example, the computing system may compare the current voltage of a battery relative to a scale of voltage values. The computing system may determine the health of the battery based on the position of the current voltage on the scale and include an indication of the health relative to the scale in the vehicle health record. In the vehicle health record, the computing system may display the current voltage of the battery and indicate whether the current voltage is acceptable for vehicle operation.

[0044] Additionally, the computing system may analyze multiple PIDs to determine the health of certain types of vehicle systems. For example, an analysis of the health of a vehicle's engine may involve analyzing a first PID related to the oil level of the engine and a second PID related to the most recent mileage of the engine. Thus, the analysis of multiple PIDs may enable the computing system to determine whether a particular vehicle system requires maintenance.

[0045] When generating a new vehicle health record or updating an existing health record, the computing system may use PID analysis to communicate health status statistics regarding various vehicle systems in a visual format that can be displayed on a display interface. In particular, the vehicle health record may be communicated using a GUI that includes vehicle graphics, text, charts, colors, and other representations to communicate the health of various vehicle systems. For some vehicle systems, the comparison of the current value of a PID to one or more predefined values may result in a binary health status outcome (i.e., the vehicle system is either healthy or requires some form of maintenance). Thus, a vehicle health record may be generated to reflect whether these vehicle systems are healthy or require some form of maintenance. For other vehicle systems, the comparison may result in a health status outcome that indicates the current condition of the vehicle system in some statistical form. As an example, the health of a vehicle brake may be determined based on a percentage scale from 0 - 100%, where "0%" represents an immediate need for new brake pads and "100%" represents brand new brake pads. Thus, for these systems, a vehicle health record may be generated to represent the health of these vehicle systems using a statistical form. Thus, the computing system may be configured to analyze each vehicle system based on specific analysis factors specific to that type of vehicle system in order to generate a vehicle health record.

[0046] To compile a vehicle health record that conveys the health of multiple vehicle systems, a computing system can iteratively perform a health analysis process on multiple PIDs related to various vehicle systems. In this way, the computing system can develop health statistics for numerous vehicle systems. In some examples, the computing system can be configured to perform a health analysis of vehicle systems according to a predetermined process. For example, the computing system can analyze two PIDs related to the engine system, then analyze two PIDs related to the braking system, and then analyze four PIDs from a tire pressure monitoring system (TPMS).

[0047] As described above, the computing system can compile the health statistics determined for various vehicle systems to generate (or update) a vehicle health record that organizes the determined health statistics in a visual format. In particular, the health statistics derived from evaluating VCPs and other PIDs can be displayed in an organized format using one or more GUIs. The GUI can include various health graphics that convey the health of various vehicle systems, including an indication of whether a vehicle system may need maintenance. Different elements of the GUI can be selected via the user interface to enable the user to browse health-related information in an efficient and compact manner. Additionally, screenshots of one or more GUIs can be printed to enable the user to review the vehicle health record in paper format. Some examples of the vehicle health record graphical user interface are described below. Other configurations are possible.

[0048] In an exemplary embodiment, the vehicle health record can use a vehicle graphic. In particular, the vehicle graphic can be an outline of the vehicle, which may or may not correspond to the vehicle type analyzed by the vehicle health record. Thus, the vehicle health record can use the vehicle graphic as a visual basis to locate other vehicle health graphics related to specific vehicle systems. In this way, the vehicle health graphics for individual systems can be located relative to the vehicle graphic at locations corresponding to the actual locations of the systems on the vehicle. As an example, the vehicle graphic can include a tire health graphic for each wheel that indicates the current pressure within the tire and the condition of the brake pads relative to the tire. The vehicle graphic can also include an engine health graphic that indicates the current health of the engine. These example graphics are described for illustrative purposes, but there may be other potential health graphics in the example.

[0049] Vehicle health records can be stored in an organized manner for subsequent access and modification. In this way, the vehicle health records can be updated to reflect changes in the health of the vehicle systems as the vehicle is further driven. A computing system can store the vehicle health records with information locally or remotely (e.g., at a server) that associates the records with a particular vehicle (e.g., an account of the vehicle). Thus, the computing system or other computing systems can access the vehicle health records during subsequent servicing of the vehicle. Additionally, the vehicle health records can be made available online for access by the owner of the vehicle or other potential users. This may involve using password protection features to ensure limited access to secure the vehicle health records. By storing the vehicle health records and making them available via wireless communication, the vehicle can be serviced at different locations and the vehicle health records can be updated accordingly. Thus, the vehicle health records can represent a compilation of multiple services, enabling the user to review the system health of the vehicle over a period of time. For example, the vehicle health records can indicate when each system was last serviced.

[0050] Some implementations may further involve using data from a multitude of vehicle health records to determine trends and other information to assist in maintaining the vehicle. In particular, one or more computing systems can analyze data from vehicle health records accumulated from similar vehicles (e.g., the same year, make, and model) to determine trends in health statistics, such as at what mileage certain systems need maintenance. Using this process, the (multiple) computing systems can develop a database of predefined values that can be used when analyzing the health of the vehicle systems. In some cases, the predefined values can be based on trends specific to the type of vehicle system or specific to the type of vehicle. In some examples, these trends can be used to help indicate when a vehicle system may need servicing. In turn, technicians can use the trend information and the vehicle health records to help increase the visibility of the services that the technicians may provide. For example, technicians can use the trends and the vehicle health records to indicate which systems may benefit from some form of preventive maintenance or replacement to avoid potential large costs to the vehicle owner.

[0051] In some examples, a computing system can organize PIDs into different categories, which can increase a user's understanding of vehicle health records. Some example categories include automatic transmission life, battery life, brake pad and rotor wear, camera failures, coolant level and temperature, diesel exhaust fluid level and quality, engine oil level and life, fuel filter life and quality, gear oil life, lidar and radar failures, lighting failures, maintenance time and distance to next maintenance, specific component failures, tire pressure and sensor battery life, and warning indicator based. The PIDs associated with each category can be grouped according to the specific system that the PID represents.

[0052] II. Example Systems

[0053] Figure 1 FIG. 1 is a schematic diagram showing an exemplary operating environment 1 in which an exemplary embodiment can operate. As shown, the operating environment 1 includes a computing system 2, a server 4, a communication network 6, a vehicle 8, and communication links 9, 10, 11, 12, but may include more or fewer elements in other exemplary embodiments.

[0054] The computing system 2 can take various forms, e.g., a specialized computing system that is configured in whole or in part for the purpose of servicing a vehicle (e.g., vehicle 8). In some cases, the specialized computing system can include unique elements for facilitating vehicle servicing, or can be configured in a unique way to distinguish the specialized computing from another type of computing system. In some examples, the specialized computing system can be configured to perform various functions associated with servicing a vehicle, can include a communication interface to other systems / servers / networks associated with servicing a vehicle, and can be configured to send and receive data through these interfaces according to one or more protocols associated with servicing a vehicle. Additionally, in some examples, the computing system 2 can be a general-purpose, non-specialized computing system, such as a general-purpose smartphone, desktop computer, laptop computer, etc. As a general matter, the computing system 2 - specialized or general-purpose - can take the form of a handheld device, laptop computer, desktop computer, and / or other types of devices.

[0055] The operating environment 1 further includes a server 4 connected to the computing system 2 via the communication network 6. Thus, the server 4 can also take various forms, such as a specialized server that is specifically / uniquely configured for the purpose of servicing vehicles, or a general-purpose server. In some examples, the server 4 can be scaled to be able to service any number of devices, such as one computing system (as Figure 1 shown), one hundred computing systems, one thousand computing systems, or other numbers of computing systems.

[0056] The communication network 6 may include communication links 9, 10, 11, 12 and other communication links ( Figure 1 not shown in Figure 1 ). The communication network 6 and the communication links 9, 10, 11, 12 may include various network elements such as switches, modems, gateways, antennas, cables, transmitters, and receivers. The communication network 6 may include a wide area network (WAN) that may carry data using packet switching and / or circuit switching techniques. The WAN may include air interfaces and / or wires to carry data. The communication network 6 may include a network or at least a portion of a network that communicates using the Transmission Control Protocol (TCP) and the Internet Protocol (IP), such as the communication network commonly referred to as the Internet. Additionally or alternatively, the communication network may include a private or other form of local area network (LAN).

[0057] The operating environment 1 further includes a vehicle 8 shown in communication with the computing system 2 and the communication network 6. A vehicle, such as vehicle 8, is a mobile machine that can be used to transport people, people and / or goods. As an example, any vehicle described herein may be driven and / or otherwise guided along a path (e.g., a paved road or otherwise) on land, in water, in the air, and / or in outer space. As another example, any vehicle described herein may be wheeled, tracked, rail, and / or ski. As yet another example, any vehicle described herein may include a vehicle, a motorcycle, an all-terrain vehicle (ATV) defined by ANSI / SVIA-1-2007, a snowmobile, a personal watercraft (e.g., personal watercraft), a light truck, a medium truck, a heavy truck, a semi-tractor, and / or farm machinery.

[0058] As an exemplary embodiment, the vehicle 8 may be guided along a path and may include a van (e.g., a dry or refrigerated van), a tank trailer, a flatbed trailer, or a vehicle transporter. As yet another example, any vehicle discussed herein may include or use any suitable voltage or current source, such as a battery, an alternator, a fuel cell, etc., to provide any suitable current or voltage, such as about 12 volts, about 42 volts, etc. As yet another example, any vehicle discussed herein may include or use any desired system or engine. These systems or engines may include items that use fossil fuels such as gasoline, natural gas, propane, etc., electricity such as that generated by batteries, magnets, fuel cells, solar cells, etc., wind power, and hybrid or combinations thereof. As yet another example, any vehicle discussed herein may include an electronic control unit (ECU), a data link connector (DLC) (i.e., an on-vehicle diagnostic connector), and a vehicle communication link that connects the DLC to the ECU.

[0059] A vehicle manufacturer may manufacture a different number of vehicles in each calendar year (i.e., from January 1st to December 31st). In some cases, the vehicle manufacturer defines a model year for a particular vehicle model to be manufactured. The model year may start on a date other than January 1st or end on a date other than December 31st. The model year may span part of two calendar years. A vehicle manufacturer may manufacture one vehicle model or multiple different vehicle models. Two or more different vehicle models manufactured by a vehicle manufacturer in a particular calendar year may have the same or different defined model years. A vehicle manufacturer may manufacture vehicles of a particular vehicle model with different vehicle options. For example, a particular vehicle model may include vehicles with a six-cylinder engine and vehicles with an eight-cylinder engine. A vehicle manufacturer or other entity may define vehicle identification information for each vehicle manufactured by the vehicle manufacturer. Particular vehicle identification information identifies a particular set of vehicles (e.g., all vehicles of a particular vehicle model year, or all vehicles of a particular vehicle model year and a particular set or sets of vehicle options).

[0060] As an example, particular vehicle identification information may include indicators of the characteristics of the vehicle, such as the time of construction of the vehicle (e.g., the vehicle model year), who built the vehicle (e.g., the vehicle brand (i.e., the vehicle manufacturer)), the marketing name associated with the vehicle (e.g., the vehicle model name, or more simply the "model"), and the characteristics of the vehicle (e.g., the engine type). According to this example, particular vehicle identification information may be referred to by the abbreviations YMME or Y / M / M / E, where each letter in the order shown represents a model year identifier, a vehicle manufacture identifier, a vehicle model name identifier, and an engine type identifier, respectively, or the abbreviations YMM or Y / M / M, where each letter in the order shown represents a model year identifier, a vehicle manufacture identifier, and a vehicle model name identifier, respectively. An exemplary Y / M / M / E is 2004 / Toyota / Camry / 4Cyl, where "2004" represents the year of manufacture of the vehicle, "Toyota" represents the name of Toyota Motor Corporation of Aichi Japan, the vehicle manufacturer, "Camry" represents the vehicle model manufactured by that manufacturer, and "4Cyl" represents the engine type of the vehicle (e.g., a four-cylinder internal combustion engine). Those skilled in the art will understand that other characteristics in addition to or in place of "engine type" may be used with particular vehicle identification information to identify a vehicle. These other characteristics may be identified in various ways, such as by regular production option (RPO) codes, such as those defined by General Motors Company LLC of Detroit, Michigan.

[0061] A vehicle communication link within a vehicle (e.g., vehicle 8) can include one or more conductors (e.g., copper wire conductors) or can be wireless. As an example, the vehicle communication link can include one or two conductors for carrying vehicle data information according to a vehicle data message (VDM) protocol. The VDM protocol can include a Society of Automotive Engineers (SAE) J1850 (PWM or VPW) VDM protocol, an International Organization for Standardization (ISO) 15764-4 Controller Area Network (CAN) VDM protocol, an ISO 9141-2 K-Line VDM protocol, an ISO 14230-4 KWP2000 K-Line VDM protocol, or some other protocol currently defined for performing in-vehicle communication. The computing system 2 or another computing system can include a vehicle communication transceiver 25 and a processor connectable to the vehicle communication link to send and receive vehicle communications via the vehicle communication link.

[0062] As described above, any vehicle described herein can include an electronic control unit (ECU), a data link connector (DLC), and a vehicle communication link connecting the DLC to the ECU. The ECU can control various aspects of vehicle operation or components within the vehicle. For example, the ECU can include a powertrain (PT) system ECU, an engine control module (ECM) ECU, a supplemental inflatable restraint (SIR) system (such as an airbag system) ECU, an entertainment system ECU, or some other ECU. The ECU can receive inputs (e.g., sensor inputs), control output devices (e.g., solenoids), generate vehicle data information (VDM) (e.g., VDM based on received inputs or controlled outputs), and set a diagnostic trouble code (DTC) to active or historical for detected faults or failure conditions within the vehicle. Execution of a functional test or reset procedure regarding the ECU can include the computing system 2 transmitting VDM to the vehicle. The VDM received by the ECU can include a PID request. The VDM transmitted by the ECU can include a response that includes a PID and a PID data value for the PID.

[0063] The DLC can include an on-board diagnostic (OBD) II connector. The OBD II connector can include a socket for holding up to 16 connector terminals, but can include a different number of sockets or no sockets at all. As an example, the DLC connector can include an OBD II connector compliant with SAE J1962 specifications, such as connector 16M, part number 12110252, available from Aptiv LLC in Dublin, Ireland. The DLC can include conductor terminals connected to conductors in the vehicle. For example, the DLC can include connector terminals connected to conductors that are respectively connected to the positive and negative poles of the vehicle battery. The DLC can include one or more conductor terminals connected to conductors of the vehicle communication link, thereby communicatively connecting the DLC to the ECU.

[0064] The computing system 2 and / or the vehicle 8 can be located at the same location as each other or can be located far apart at separate and distinct locations. For example, both the computing system 2 and the vehicle 8 can be located at a repair shop. As another example, both the computing system 2 and the vehicle 8 can be located on a road. As yet another example, the computing system 2 can be located at a repair shop while the vehicle 8 can be located on a road. One or more of these locations can also include various computerized shop tools (CSTs) and / or non-computerized shop tools, such as battery chargers, torque wrenches, brake lathes, fuel pressure gauges, wheel balancers, etc. In addition, one or more of the shop tools and / or the computing system 2 can operate outside of the repair shop. For example, the computing system 2 can operate within the vehicle 8 as the vehicle 8 travels on a road outside of the repair shop for various purposes.

[0065] The vehicle 8 can transmit various data to the computing system 2, such as OBD data (e.g., diagnostic trouble codes (DTCs), measurements read by shop tools from a VDM, real-time and / or non-real-time electrical measurements (e.g., sensor readings), VDIs, and / or other types of data. For example, the vehicle 8 can transmit data directly to the computing system 2 over the communication link 11. As another example, the vehicle 8 can transmit data indirectly to the computing system 2 by transmitting the data over the communication links 12, communication network 6, and communication link 10 to the server 4, after which the server 4 can transmit the data over the communication links 10, communication network 6, and communication link 9 to the computing system 2. The vehicle 8 can perform such indirect data transmission with or without specifying the computing system 2 as the destination of the data. For example, the vehicle 8 (and perhaps other vehicles communicating with the server 4) can transmit data to the server 4, specifying the server 4 as the destination of the data. Thereafter, the computing system 2 can transmit a request for the data to the server 4, and the server 4 can assemble the data and transmit the data in response to the request to the computing system 2.

[0066] The computing system 2, the server 4, and / or the vehicle 8 can also transmit data to (and receive data from) other devices on the communication network 6, such as one or more databases (not shown) that can be accessed by the computing system 2, the server 4, and / or the vehicle 8.

[0067] For any given computer system discussed herein, such as computing system 2, server 4, and / or vehicle 8, data received by the device can be stored within a computer-readable medium for use by the device. Additionally, for any given computer system discussed herein, such as computing system 2, server 4, and / or vehicle 8, data received by the device can be stored in the local memory of the device and / or can be stored remotely at a storage location accessible by the device (e.g., a remote server or remote database).

[0068] One or more computing systems and / or one or more vehicles can be connected via a network connection established by these devices, such as a vehicle-to-customer network, etc. Such a network can include a personal area network (PAN). The PAN can be configured according to any one of a variety of standards, protocols, and / or specifications. For example, the PAN can be configured according to the Universal Serial Bus (USB) Specification 2.0, 3.0, or 3.1 developed by the USB Implementers Forum. As another example, the PAN can be configured according to standards of the Institute of Electrical and Electronics Engineers (IEEE), such as the IEEE 802.11 standard (e.g., 802.11a, 802.11b, 802.11g, or 802.11n) or the IEEE 802.15 standard for wireless PANs (e.g., 802.15.1, 802.15.3, 802.15.4, or 802.15.5).

[0069] In exemplary operating environment 1, there can be a scenario where computing system 2 transmits a request to download information (e.g., information associated with a vehicle component of a specific vehicle) to server 4. Such a request can include, for example, the YMM of a specific vehicle and the name of a specific vehicle component. As another example, the request can include the YMME of a specific vehicle and an indication of a specific symptom associated with a specific vehicle component (e.g., a description or code). As yet another example, the request can include data received from the vehicle for which the information is requested, which can include the vehicle identification number (VIN) of the vehicle, a DTC indicating a specific vehicle component of the vehicle, an image of a specific vehicle component, and other possibilities.

[0070] In this case, upon receiving the request, server 4 can assemble the download. For example, upon receiving the request, server 4 can retrieve some or all of the information requested by the computing system from the memory at server 4. Additionally or alternatively, upon receiving the request, server 4 can in turn transmit a request for some or all of the information requested by the computing system to one or more databases located remotely from server 4 and then receive some or all of the information requested by the computing system from the one or more databases. When assembling the download including the information requested by the computing system, server 4 can transmit the download to computing system 2.

[0071] Next, Figure 2 an exemplary communication workflow between the computing system and the server is shown. More specifically, the computing system 2 can communicate with the server 4 to assist a user in servicing a vehicle 8. For example, the computing system 2 can send a request 14 to the server 4 over a communication network (e.g., the communication network 6). The request 14 can include information describing the vehicle 8 (e.g., YMM or YMME) and information related to the operation of the vehicle 8 (e.g., symptoms, VDI). Upon receiving the request 14, the server 4 can transmit a response 15 to the request 14 back to the computing system 2. The response can include various information that the computing system 2 can utilize, such as one or more predefined values for analyzing the health of various vehicle systems. For example, the server 4 can transmit thresholds, multiple thresholds, or other information related to one or more PIDs corresponding to the vehicle 8.

[0072] Accordingly, the response 15 to the request 14 provided by the server 4 can allow the computing system 2 to display contextually relevant data or information about the vehicle 8, such as a graphical display of vehicle data parameters (VDPs) indicating various PIDs, a list of PIDs, or perform tests for servicing the vehicle for PIDs that breach PID thresholds. The list of PIDs can include an indexed list of PIDs applicable to the vehicle and the operation of the vehicle described in the request 14. The VDP graphical display provided in the response 15 can be based on the PIDs provided to the server 4 by the computing system 2 prior to transmitting the request 14. The tests within the response 15 can include one or more tests. The one or more tests can include tests within an indexed list of tests, such as an indexed list of component tests, an indexed list of functional tests, or an indexed list of reset procedures.

[0073] In some examples, the computing system 2 can provide a request 14 for information related to the health of the vehicle 8. For example, the computing system 2 can request 14 a vehicle health record associated with the vehicle 8. The computing system 2 can provide an account reference number or other indication associated with the vehicle 8 to the server 4. In response, the server 4 can provide the vehicle health record associated with the vehicle 8 to the computing system 2. Similarly, the computing system 2 can request 14 from the server 4 a vehicle health record of the vehicle 8 that corresponds to a compilation of multiple vehicle health records. Additionally, the computing system 2 can also transmit the vehicle health record to other computing systems via the server 4.

[0074] In an exemplary embodiment, the computing system 2 can obtain one or more predefined values for analyzing the current value of a PID associated with the vehicle 8. For example, the computing system 2 can obtain predefined values specific to the vehicle 8 stored by the server 4. In other cases, the server 4 can provide predefined values based on the YMM of the vehicle 8, the manufacturer of a particular vehicle system associated with the vehicle 8, or based on trends detected from analyzing vehicle health records of vehicles similar to the vehicle 8.

[0075] Next, Figure 3 Exemplary details of the vehicle 8 and an example placement of the computing system 2 within the vehicle 8 are shown. In particular, the vehicle 8 is shown with an airbag system ECU 16, a traction control system ECU 17, a powertrain system (PT) ECU 18, an anti-lock braking system (ABS) ECU 19, a DLC 20, and one or more sensors 38, each connected to a vehicle communication link 21. Other examples of ECUs within the vehicle 8 are possible.

[0076] The DLC 20 can have various locations within the vehicle 8. For example, the DLC 20 can be located within the passenger compartment of the vehicle 8, within the engine compartment of the vehicle 8, or within the storage compartment of the vehicle 8. In particular, the computing system 2 can include and / or be communicatively connected to the DLC 20 via a DLC to display device communication link 22. Thus, the computing system 2 can be removed after the vehicle 8 has been serviced in a repair shop. In this way, the computing system 2 can be used to diagnose other vehicles, such as vehicles that subsequently arrive at the repair shop. As described above, the DLC 20 can include connectors, such as an OBD I connector, an OBD II connector, or some other connector. In particular, the DLC 20 can include one or more conductor terminals of conductors connected to the vehicle communication link such that the DLC 20 is communicatively connected to the ECUs within the vehicle 8.

[0077] (One or more) sensors 38 can represent various types of sensors that can measure the operation of the systems of the vehicle 8, including the systems shown in Figure 3 . In some examples, one or more sensors 38 can communicate with the computing system 2 via the vehicle communication link 21 and / or the DLC to display device communication link 22, through the DLC 20. In further examples, one or more sensors 38 can communicate directly with the computing system 2 via a wireless connection.

[0078] Figure 4is a block diagram of computing system 2. As described above, computing system 2 can operate as a vehicle diagnostic tool, scanner, or other type of VST. In some examples, computing system 2 can be a tablet computing system, cellular phone (e.g., smartphone), laptop or desktop computer, head-mounted device (HMD), wearable computing system, or different types of fixed or mobile computing systems. Thus, the configuration and type of the computing system can vary within the examples. For example, computing system 2 can have various physical designs and additional components in other examples.

[0079] As Figure 4 shown, computing system 2 includes a processor 23, a communication interface 24, a vehicle communication transceiver (VCT) 25, a user interface 26, and a memory 27. Two or more of these components, as well as other components, can be communicatively coupled or connected together via a system bus, network, or other connection mechanism 35. In other examples, computing system 2 can include more or fewer components.

[0080] Processor 23 (and any other processor discussed in this description, such as Figure 6 processor 60 shown) can include one or more processors, such as one or more processors discussed below. In some embodiments, processors 23, 60 can include general-purpose processors, such as a single-core microprocessor or a multi-core microprocessor. A general-purpose processor can be configured to operate within a general-purpose computer and / or can be configured within a general-purpose computer, such as a personal computer (PC).

[0081] In some embodiments, processors 23, 60 can include special-purpose processors, such as a neural network processor, a graphics processor, or an embedded processor. A special-purpose processor can, but does not have to be, configured as an application-specific integrated circuit (ASIC) processor.

[0082] An embedded processor refers to a processor with specialized functions within a larger electronic, mechanical, pneumatic, and / or hydraulic device, in contrast to a general-purpose computer. In some embodiments, an embedded processor can execute an operating system, such as a real-time operating system (RTOS). As an example, an RTOS can include that developed by Micro Digital, Inc. RTOS, such that the processors 23, 60 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 of San Jose, California), or (b) a processor provided by NXP Semiconductors N.V. of Eindhoven, Netherlands (e.g., a 52259 processor). General-purpose processors, special-purpose processors, and / or embedded processors may perform analog signal processing and / or digital signal processing.

[0083] In some embodiments, the processor 23 may be configured to execute computer-readable program instructions (CRPI) 28 stored in the memory 27. The CRPI configured to perform the functions discussed in this disclosure, such as CRPI 28, 64, may include assembler instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status-setting data, and / or source code or object code written in any combination of one or two or more programming languages. As an example, the programming languages may include object-oriented programming languages such as Java, Python, or C++, or traditional procedural programming languages such as the "C" programming language. The processors 23, 60 may also be configured to perform hardware encoding functions in addition to or as an alternative to (e.g., via CRPI 28) performing software encoding functions. Within an example implementation, the processor 23 may be programmed to perform any function or combination of functions performed by the computing system 2 described herein. Similarly, the processor 60 may be programmed to perform any function or combination of functions performed by the server 4 described herein.

[0084] The communication interface 24 of the computing system 2 may include one or more communication interfaces. Each communication interface may include one or more transmitters configured to transmit data onto a network (e.g., the communication network 6). Thus, the data transmitted by the communication interface 24 may include any data transmitted, output, and / or provided by the computing system 2 described herein. Additionally, each communication interface may include one or more receivers configured to receive data carried on the network, such as the communication network 6. The data received by the communication interface 24 may include any data received by the computing system 2 described herein, such as vehicle identification information or DTCs.

[0085] The VCT 25 may include (a) a transmitter configured to transmit a VDM to the vehicle and / or an ECU within the vehicle 8, and (b) a receiver configured to receive a VDM transmitted by the vehicle 8 and / or the ECU. As an example, the transmitter and receiver of the VCT 25 may be integrated into a single semiconductor chip. As another example, the transmitter and receiver of the VCT 25 may be separate semiconductor chips.

[0086] The VCT 25 may include and / or be connected to a wiring harness. The wiring harness may be configured to provide a wired connection between the computing system 2 and the vehicle 8. In some embodiments, the wiring harness may be removably connected to the DLC 20 within the vehicle 8. In those embodiments, the DLC 20 may provide an indirect connection for the computing system 2 to the ECU, such as an ECU that provides PID parameters. In some other embodiments, the wiring harness may provide a direct connection for the computing system 2 to the ECU. The VCT 25 may include and / or be connected to one or more connectors, and one of the one or more connectors may be located at the end of the wiring harness.

[0087] The VCT 25 may be configured to communicate wirelessly with the vehicle 8 and / or an ECU within the vehicle 8. The VCT 25 that communicates wirelessly may transmit radio signals carrying data or communications, such as a request for PID parameters, and may receive radio signals carrying data or communications, such as a response including PID parameters.

[0088] The VCT 25 may be configured to transmit a VDM according to the VDM protocol and receive a VDM according to the VDM protocol. In one embodiment, the VCT 25 may be configured to transmit a VDM according to multiple VDM protocols and receive a VDM according to multiple VDM protocols. As an example of this embodiment, the VCT 25 may include multiple semiconductor chips, each semiconductor chip dedicated to transmitting and receiving a VDM according to at least one VDM protocol.

[0089] The user interface 26 may include one or more display interfaces and other potential elements configurable to display information to the user. For example, the user interface 26 may represent a user interface that allows the user to interact with the computing system 2 through graphical icons and visual indicators. The user interface 26 may also enable the user to use the computing system 2 to communicate with other devices (such as sensors) that measure various aspects of the vehicle. Various exemplary graphical user interfaces will be described below in conjunction with Figure 5 describe various exemplary graphical user interfaces.

[0090] The user interface 26 may also include various types of interfaces configurable to receive user input and other information. For example, the user interface 26 may include one or more microphones configured to detect and receive voice input from the user and / or other sounds. In some examples, the microphone may detect and receive any sound when it occurs (e.g., when the user provides vocal input, the microphone captures it). Alternatively, the microphone may be configured to detect audio in response to the user pressing a button, using a related application, or other forms of activation technology. In some examples, the microphone may operate as a device physically separate from the computing system 2.

[0091] In further examples, the user interface 26 may include buttons, switches, joysticks, or other physical structures configurable to receive input from one or more users. For example, the computing system 2 may include a button that the user can use to record the date and time of the button press, such as recording button presses during vehicle operation. The user interface 26 may include other mechanical structures that enable the user to provide input to the computing system 2. For example, the user interface 26 may include a motion sensor configured to detect and measure the user's movement.

[0092] The memory 27 may include one or more types of memory. "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". If the memory is transient, any of these alternative terms may be prefixed with "transient", and if the memory is non-transient, "non-transient" may be added. For example, the memory 27 may include non-transient memory, transient memory, or both non-transient memory and transient memory. Non-transient memory, or a portion thereof, may be located within the processor or as part of the processor (e.g., within a single integrated circuit chip). Non-transient memory or a portion thereof may be separate and distinct from the processor.

[0093] The memory 27 stores computer-readable data such as CRPI 28, index 29, and default diagnostic checklist 30. The CRPI 28 can include multiple program instructions, and can also include data structures, objects, programs, routines, or other program modules that can be accessed by and executed by a processor to perform specific functions or groups of functions, and are examples of program code for implementing the steps of the methods described in this specification. Generally, the CRPI 28 can include program instructions to cause the computing system 2 to perform any function performed by the computing system 2 described herein, or to cause any component of the computing system 2 to perform any function performed by that component of the computing system 2 described herein. As an example, the CRPI 28 can include program instructions to perform a set of functions 200 or similar functions described herein.

[0094] The index 29 can include a list of PIDs, component tests, functional tests, and / or reset procedures, as well as other possible information. In some examples, the index 29 can also include additional associated information. For example, as part of a PID index (e.g., Figure 7 the PID index 70 described in ), the PID descriptor can also be stored for display by the computing system 2. As a further example, information indicating how requests for each PID value are communicated to the vehicle 8 can also be stored as part of the PID index.

[0095] The default diagnostic checklist 30 can indicate specific PIDs, VCPs, functional tests, component tests, and / or reset procedures to display a given symptom or set of symptoms of the vehicle 8. In other examples, the default diagnostic checklist 30 can indicate which PIDs, functional tests, component tests, and / or reset procedures to display for any symptom when the symptom-based filter list is not available from the server 4.

[0096] The memory 27 can further store sensor measurements 31, images / videos 32, predefined values 33, and PID values / PID index 34, as well as other possible information. The sensor measurements 31 can correspond to sensor data provided by various sensors that can communicate with the computing system 2. For example, the computing system 2 can communicate with and store temperature measurements from a thermal sensor. In a further example, the computing system 2 can communicate with other sensors that can measure various aspects of the operation of the vehicle.

[0097] In some examples, the computing system 2 may include or communicate with a digital oscilloscope to obtain sensor data. The digital oscilloscope may display voltage over a period of time, which can help identify vehicle faults associated with vehicle symptoms, such as engine knocking, engine misfires, or vehicle braking pulses. In other examples, the computing system 2 may receive sensor data from pressure sensors configured to measure pressure fluctuations in the exhaust, intake, crankcase, and fuel rails of the vehicle 8. Similarly, the computing system 2 may communicate with pressure sensors that can measure pressure-related data of the vehicle 8. In some examples, the computing system 2 may communicate with a laser thermometer, a sniffer, and / or a gas analyzer, which are configured to detect certain odors (e.g., richness) in gases, gas components, exhaust, coolant, etc.

[0098] In addition, the computing system 2 may communicate with a microphone system (e.g., an electronic sound finder). The microphone system may include microphones that can be connected to various parts of the vehicle 8. For example, a user may place a microphone near the engine and other components of the vehicle 8. The microphone system may enable the user to listen for sounds from gears, bearings, and suspensions when the vehicle 8 is under load, so that problems can be pinpointed more accurately. In some examples, when a noise is heard, the microphone system may provide an alert to the user through the computing system 2. For example, the microphone may receive sound waves above a specific decibel (dB) level or within a specific frequency range and cause the computing system 2 to drop a flag to mark that moment. The microphone system may also detect audible signals and provide the audible signals to a processing circuit for capture and comparison with known audible signals. The result of the comparison may be that the computing system 2 drops a flag to mark the time when the audible signal was captured.

[0099] As an example, the microphone system may detect a "knocking sound" from the engine. In response, the computing system 2 may trigger an oil pressure sensor measurement to determine whether the oil pressure sensor or the oil pump needs to be replaced. In another example, the microphone system may be placed near the brakes of the vehicle 8, detect sounds from the brakes when the vehicle 8 is traveling uphill, and respond by causing the computing system 2 to drop a flag for subsequent review as a result. In another example, the microphone system may detect a leak in the turbocharger via a high-pitched sound.

[0100] In other examples, other communications can occur between various devices operating in a vehicle. For example, a user can use the computing system 2 to trigger the operation of one or more sensors that measure various aspects of the operation of one or more vehicle systems. For example, the user can provide a voice command or a physical input to the computing system 2 to cause the computing system 2 to trigger the operation of one or more sensors. In some cases, triggering the operation of one or more sensors may involve causing the computing system 2 or another system to start recording sensor measurements from the one or more sensors from that time period. The time period can end when the computing system 2 transmits a stop signal or after a predetermined duration. Additionally, some examples may involve a sensor similarly triggering one or more sensors to capture information about the operation of one or more systems of the vehicle for later review by the user.

[0101] In some embodiments, a sensor can be connected to an analog or digital input of the processor 23. In these or other embodiments, the sensor can be connected to an analog-to-digital converter that is connected to a digital input of the processor 23. As an example, the sensor can output an analog voltage signal between zero volts and five volts. As another example, the sensor can output a pulse-width modulation signal between zero volts and twelve volts. Other examples of sensor outputs and sensor output voltage ranges are possible.

[0102] The image / video 32 can correspond to images and / or videos captured by a camera or camera system associated with a vehicle (e.g., vehicle 8). For example, the computing system 2 can activate and send instructions to a camera or camera system associated with the vehicle. For example, the camera can capture an image or video of an instrument, the interior of the vehicle, the exterior of the vehicle, or a driving path in response to receiving instructions from the computing system 2.

[0103] The predefined value 33 can include one or more predefined values for comparison with the current value of the PID. For example, the predefined value 33 can include a predefined threshold or other types of values that can be used to analyze the current condition of a vehicle system.

[0104] The PID value / PID index 34 can include information indicating a specified value (e.g., a sensor value) associated with a vehicle component and the PID arranged in an index. The computing system 2 can obtain the PID value from the vehicle (e.g., vehicle 8) or another device (e.g., server 4). In some examples, when obtaining the PID value from vehicle 8, the computing system 2 can arrange the PID value into the PID index within the PID value / PID index 34.

[0105] The computing system 2 may also include a power supply 36. A power supply such as power supply 36 or any other power supply discussed in this disclosure may include (1) a connection to an external power supply, and (2) circuitry to provide current to the electrically operable component(s) connected to the power supply. As an example, the external power supply may include a wall outlet where alternating current can be connected. As another example, the external power supply may include an energy storage device (e.g., a battery) or a generator. As another example, the processor 23, communication interface 24, VCT 25, user interface 26, and / or memory may be electrically operable components.

[0106] Additionally or alternatively, a power supply such as power supply 36 or any other power supply discussed in this disclosure may include (1) a connection to an internal power supply, and (2) a power transfer circuit to provide current flow to the electrically operable component(s) connected to the internal power supply. As an example, the internal power supply may include an energy storage device such as a battery.

[0107] Furthermore, a power supply such as power supply 36 or any other power supply discussed in this disclosure may include a circuit protector and / or a signal regulator.

[0108] The computing system 2 may include a housing 37 that provides support for the processor 23, communication interface 24, VCT 25, user interface 26, memory, connection mechanism 35, and / or power supply 36. The support provided by the housing 37 may be direct support, where another component of the computing system 2, such as the display of the user interface 26, directly contacts the housing 37. Alternatively and / or additionally, the support provided by the housing 37 may be indirect support, where another component of the computing system 2 is located on or within another component of the computing system 2 that directly contacts the housing 37. For example, the computing system 2 may include a circuit board or other substrate that directly contacts the housing 37, and the processor 23, communication interface 24, VCT 25, user interface 26, memory, connection mechanism 35, and / or power supply 36 are disposed on the circuit board or other substrate.

[0109] Next, Figure 5 is a display of an exemplary vehicle service tool according to an exemplary embodiment. The VST 40 may operate using Figure 4 the computing system 2 shown or using another computing system. In some examples, the VST 40 may represent a physical configuration of the computing system 2. Thus, the VST 40 includes a display 41, a user input section 42, and a housing 43, where the display 41 and the user input section 42 form part of a user interface that is configured to receive input from a user and provide output to the user of the VST 40.

[0110] In some examples, the display 41 of the VST 40 may include a touchscreen interface / display, such as the color touchscreen or other types of touchscreen interfaces used on the MODISTM Ultra Integrated Diagnostic System (reference number EEMS328W) provided by Snap-on Incorporated of Kenosha, Wisconsin. In other examples, the display 41 may include a backlit color liquid crystal display (LCD), plasma display, or light-emitting diode (LED) display with a capacitive, resistive, or infrared touchscreen interface or panel. In further examples, the display 41 may include a display such as that used as part of a tablet device (such as the tablet device, or the SAMSUNG GALAXY TAB tablet device from Samsung Electronics Co., Ltd.). As another example, the display 41 may include a display similar to that used on a smartphone (such as the smartphone, or the GALAXY smartphone from Samsung Electronics Co., Ltd. of Maetan-Dong, Yeongtong-Gu, Suwon-Si, Gyeonggi-Do, Republic of Korea).). Other examples of the display 41 on the VST 40 are also possible.

[0111] As Figure 5 shown, the display 41 may have a shape similar to a rectangle, such as a rectangle with square corners or a general rectangle with rounded corners, but the display 41 is not limited to this shape. For example, in other examples, the display 41 may have a circular or triangular shape. Additionally, in other examples, the VST 40 may include multiple displays (e.g., a front display and a back display).

[0112] The VST 40 further includes a user input section 42, which may include various types of input mechanisms that enable a user to communicate with the VST 40. For example, as Figure 5As shown, the user input section 42 may include one or more input selectors, such as input keys 44, 45, 46, 47, and 48. The user input keys may be arranged in any of a variety of configurations. For example, input key 44 may represent an upward direction selection, input key 45 may represent a rightward direction selection, input key 46 may represent a downward direction selection, input key 47 may represent a leftward direction selection, and input key 48 may represent an input selection. Pressing one of the input keys may cause the display pointer 49 to move in the direction represented by the pressed input key. Pressing input key 48 may result in the selection of the display data element pointed to by the display pointer 49. In other examples, the user input section 42 may include input controls arranged in other configurations, such as a joystick, a touchpad, or other button layouts (e.g., a steering wheel). In further examples, the VST 40 may include other components for receiving input from the user, such as a microphone for receiving verbal commands or a camera for detecting the user's movement.

[0113] In Figure 4 the computing system 2 shown in FIG. 2, the processor 23 may execute the program instructions of the CRPI 28 to cause the display 41 of the VST 40 to display one or more vehicle data parameter (VDP) graphical windows or other information. The VDP graphical window may represent information corresponding to one or more PIDs obtained from the vehicle 8. For example, the VDP graphical window may include a VDP line graph representing parameters related to a specific PID. The display 41 may display one or more VDP graphs using windows of different sizes that can be adjusted by the user. For example, as Figure 5 shown, the VST 40 may cause the display 41 to display the VDP graph 50 shown in a rectangular window. In other examples, the display 41 may display the vehicle parameters as numerical values. Other examples are possible.

[0114] The VDP graph 50 may include various elements, such as a VDP line graph 51 representing parameters corresponding to the PID. The VDP graph 50 may also display graphical text 52, which may include information such as the name of the parameter represented by the VDP line graph 51, the unit identifying the VDP line graph 51 (e.g., volts, percentage, or count), and the threshold range (e.g., the minimum and maximum thresholds associated with a specific PID). In some cases, the minimum and maximum ranges may be limited to the minimum and maximum values of the VDP line graph 51 currently displayed within the VDP graph 50. For example, the memory 27 may store the minimum and maximum values of one or more vehicle parameters, and these stored minimum and maximum values are used to populate the graphical text 52 when the parameters associated with the minimum and maximum values are displayed on the display 41 of the VST 40.

[0115] The processor 23 may execute program instructions of the CRPI 28 to cause the display 41 to display one or more scroll bars, such as the scroll bar 53. The scroll bar 53 can be used to scroll through a plurality of parameter graphs corresponding to various PIDs or other information that can be displayed on the display 41. In a further example, the processor 23 may execute program instructions of the CRPI 28 to cause the display 41 to display a graphical view slider that can be configured to modify the view of a parameter graph corresponding to a given PID on the display 41.

[0116] The housing 43 can provide support or protection for the components of the VST 40. Thus, in some examples, the housing 43 can include handles 54, 55 to enable a user to hold the VST 40. The housing 43 can include one or more port openings (not shown) for connecting one or more communication links, such as communication links 9, 11. In other examples, the housing 43 can have other configurations.

[0117] Next, Figure 6 is a block diagram of the server 4. In particular, the server 4 includes a processor 60, a communication interface 61, and a memory 62. Two or more of these components can be communicatively coupled or linked together via a system bus, network, or other connection mechanism 63. In other examples, the server 4 can include more or fewer components. The server 4 can include a power supply. At least one of the processor 60, the communication interface 61, and / or the memory 62 can include electrically operable components connected to the power supply in the server 4.

[0118] The processor 60 can be configured to execute computer-readable program instructions (CRPI), such as the CRPI 64 stored in the memory 62. The processor 60 can be configured to perform hardware encoding functions in addition to or as an alternative to performing software encoding functions (e.g., via the CRPI 64), and can be programmed to perform any function or combination of functions performed by the server 4 described herein. Examples of the processor 60 were discussed above.

[0119] The memory 62 stores computer-readable data, such as the CRPI 64, diagnostic session data (DSD) 65, diagnostic checklist 66, predefined values 67, PID index 68, and PID count 69. The memory 62 can correspond to various types of memory and can store other information within the examples.

[0120] The DSD 65 can include data that the server 4 can use to determine the operating state of the computing system 2. The data that the server 4 uses to determine the operating state of the computing system 2 can include vehicle identification information, data indicating the time elapsed since the server 4 last received a communication from the computing system 2, data indicating the most recent diagnostic checklist type requested by and / or transmitted to the computing system 2, and / or data indicating that a repair has been performed on a particular vehicle.

[0121] The DSD 65 can include data indicating the determined operating state of the computing system 2. Examples of operating states include (i) the computing system 2 is connected to the server 4, (ii) the computing system 2 is not connected to the server 4 (i.e., is disconnected from the server 4), (iii) the computing system 2 is connected to a particular vehicle (e.g., vehicle 8), (iv) the computing system 2 is no longer connected to a particular vehicle (i.e., is disconnected from a particular vehicle), (v) the computing system 2 is in a mode of requesting and / or displaying a diagnostic checklist for a particular vehicle, (vi) the computing system 2 has exited the mode of requesting and / or displaying a diagnostic checklist for a particular vehicle, and (vii) the computing system 2 has returned to the mode of requesting and / or displaying a diagnostic checklist for a particular vehicle.

[0122] The DSD 65 can also include data indicating whether the diagnostic session of the computing system 2 is active or inactive. The server 4 can determine that a new diagnostic session is active when it receives the vehicle identification information of a particular vehicle, and the DSD 65 does not include data indicating that the diagnostic session of a particular vehicle is active. The server 4 can determine that the active diagnostic session of a particular vehicle has transitioned to inactive when it receives the vehicle identification information of a different particular vehicle. The server 4 can determine that the active diagnostic session of a particular vehicle has transitioned to an inactive session when it determines that a threshold time has elapsed since a particular activity of the active diagnostic session. As an example, a particular activity can include receiving a request from the computing system 2, receiving a communication indicating that the computing system 2 is connected to the communication network 6, and / or transmitting a response with a diagnostic checklist 66 to the computing system 2. Other examples of particular activities are possible.

[0123] The diagnostic checklist 66 can include OBD data or other information from the vehicle. For example, the diagnostic checklist 66 can indicate particular PIDs, functional tests, component tests, and / or reset procedures to display a particular symptom or set of symptoms of vehicle 8. In other examples, the diagnostic checklist 66 can indicate which PIDs, functional tests, component tests, and / or reset procedures to display for any symptom.

[0124] The predefined value 67 can include a threshold value of the PID and other values. These values can be predefined and, in some examples, are used to analyze the current value of the PID. In particular, this analysis can compare the current value of the PID with one or more predefined values 67 to determine a difference in information that can be used to indicate the vehicle system associated with the PID. When the PID is configured to convey aspects of the health of the vehicle system, such as the VCP, this information can represent the health of the vehicle system.

[0125] Each value can be predefined before being compared with the current value of the PID. For example, a vehicle manufacturer, technician, or user can predefined one or more values for use during the analysis of the health of the vehicle system. In some examples, the predefined value can be a threshold value.

[0126] For example, one or more threshold values for each PID can include a maximum data value and a minimum data value. The predefined value 67 includes one or more threshold values of the PID from each set of vehicles that can be identified by certain specific vehicle information. In this way, the server 4 can provide the computing system 2 with applicable threshold values for a specific vehicle connected to the computing system 2.

[0127] In one aspect, the predefined value 67 can include a threshold value defined by the vehicle manufacturer. For a specific PID associated with a DTC, the vehicle manufacturer can define the maximum data value as the maximum data value of the specific PID that the ECU will output when the associated DTC is set to inactive, and the vehicle manufacturer can define the minimum data value as the lowest data value of the specific PID that the ECU will output when the associated DTC is set to inactive. In another aspect, the predefined value 67 can include a threshold value determined by the server 4 from the PID data values received in a communication including the PID data values. The server 4 can store the received PID data values in the predefined value 67 and determine the maximum and minimum data values for each PID of each set of vehicles that can be identified by specific vehicle identification information.

[0128] In another aspect, the predefined value 67 for a specific PID can be associated with a specific vehicle type and specific operating conditions of the specific vehicle type. The specific operating conditions can be based on one or more operating condition values of the specific vehicle type. For example, one or more operating condition values can include an engine speed value, an engine coolant temperature value, and / or a value indicating that the engine emission system is operating in a closed-loop control mode. The operating condition values can include a range of values, such as an engine speed value from 500 RPM to 1000 RPM, or an engine coolant temperature range from 90 °C to 102 °C. When the vehicle is operating under specific operating conditions defined by the operating condition values, a health check can be performed based on the predefined values associated with the specific operating conditions.

[0129] The PID index 68 can include a list of indices of PIDs applicable to one or more vehicles and the operation of one or more vehicles. For example, the PID index 68 can include various PIDs arranged according to one or more parameters associated with the PIDs. As an example, the PID index 68 can include a combination of a PID and a VCP. In another example, the PID index 68 can include one or more VCPs. In some examples, the server 4 can store PIDs for a vehicle (e.g., vehicle 8) in the PID index 68.

[0130] The server 4 can maintain a PID count 69 that indicates how many PID data values of a particular PID have been received and / or stored. The server 4 can compare the PID count with a first threshold PID count value stored in the predefined value 67. If the server 4 determines that the PID count is less than the first threshold PID count value, the server 4 can generate a first threshold for the particular PID. As an example, the server 4 can determine that the first threshold of the PID is the average maximum PID data value plus X standard deviations of the average maximum PID data value, and the average minimum PID data value minus X standard deviations of the average minimum PID data value. The average maximum PID data value is the average of the maximum PID data values of a particular PID on vehicles that can be identified by a particular vehicle identification information, where all DTCs from the ECU providing the particular PID are set to inactive. The average minimum PID data value is the average of the minimum PID data values of a particular PID on vehicles that can be identified by a particular vehicle identification information, where all DTCs from the ECU providing the particular PID are set to inactive.

[0131] As the server 4 continues to receive PID data values of a particular PID, the server 4 can determine that the number of received PID data values of the particular PID exceeds the first threshold PID count value but is less than the second threshold PID count value. In this case, the server 4 can generate a second threshold for the particular PID. As an example, the server 4 can determine that the second threshold of the PID is the average maximum PID data value plus X - 1 standard deviations of the average maximum PID data value and the average minimum PID data value minus X - 1 standard deviations of the average minimum PID data value. The first threshold can be referred to as a loose threshold relative to the second threshold. The second threshold can be referred to as a strict threshold relative to the first threshold.

[0132] Server 4 can determine the loose and strict thresholds in various ways. For example, before the number of PID data values of a specific PID received by server 4 exceeds a first threshold PID count value, server 4 can add a first percentage of the average maximum PID data value of the specific PID to the average maximum PID data value, or add a first percentage of the maximum PID data value of the specific PID to the maximum PID data value. Additionally, before the number of PID data values of a specific PID received by server 4 exceeds a first threshold PID count value, server 4 can subtract a first percentage of the average minimum PID data value of the specific PID from the average minimum PID data value, or subtract a first percentage of the minimum PID data value of the specific PID from the minimum PID data value.

[0133] As server 4 continues to receive PID data values of a specific PID, server 4 can determine that the number of PID data values of the specific PID received exceeds the first threshold PID count value but is less than the second threshold PID count value. In this case, server 4 can add a second percentage of the average maximum PID data value of the specific PID to the average maximum PID data value, or add a second percentage of the maximum PID data value of the specific PID to the maximum PID data value, and server 4 can subtract a second percentage of the average minimum PID data value of the specific PID from the average minimum PID data value, or subtract a second percentage of the minimum PID data value of the specific PID from the minimum PID data value. The second percentage can be less than the first percentage, and thus, compared to the thresholds determined using the first percentage, the thresholds determined using the second percentage are generally a more strict threshold range.

[0134] Server 4 can provide the computing system 2 with the threshold or thresholds of a specific PID without any tolerance value so that the computing system 2 does not need to calculate one or more thresholds to be displayed on the graphical interface of the computing system 2. Alternatively, server 4 can provide the computing system 2 with the threshold or thresholds of a specific PID with at least one tolerance value. For example, the at least one tolerance value can be the first percentage or the second percentage discussed above, or the value of X standard deviations or X - 1 standard deviations. Other examples of the at least one tolerance value are also possible.

[0135] The CRPI 64 may include multiple program instructions. The CRPI 64 and any other CRPI described in this specification may include data structures, objects, programs, routines, or other program modules that can be accessed by a processor and executed by the processor to perform specific functions or groups of functions, and are examples of program code for implementing the steps of the methods described in this specification. Generally, the CRPI 64 may include program instructions to cause the server 4 to perform any function performed by the server as described herein, or to cause any component of the server 4 to perform any function performed by that component of the server 4 as described herein.

[0136] As another example, the CRPI 64 may include program instructions to perform session management related to the computing system 2. The processor 60 may use the DSD 65 to determine the operating state of the computing system 2. Once and / or in response to determining that the computing system 2 is in a request and / or display diagnostic checklist mode of a particular vehicle, the processor 60 may determine the requested diagnostic checklist and provide a response to the computing system 2 that includes the requested diagnostic checklist.

[0137] Once and / or in response to determining that the computing system 2 has exited the request and / or display diagnostic checklist mode of a particular vehicle and that repairs have been performed on the particular vehicle, the processor 60 may provide a session change response to the computing system 2 to instruct the computing system 2 to display previously displayed data, such as the diagnostic checklist 66. The session change response may include the previously displayed diagnostic checklist or a different diagnostic checklist.

[0138] Once and / or in response to determining that the computing system 2 has returned to the request and / or display diagnostic checklist mode of a particular vehicle, the processor 60 may provide a session change response to the server or 4 display device to instruct the computing system 2 to display the previously displayed diagnostic checklist or a different diagnostic checklist.

[0139] A communication interface such as the communication interface 61 or any other communication interface discussed in this specification may include one or more communication interfaces. Each communication interface may include one or more transmitters configured to transmit data onto a network, such as the communication network 6. The data transmitted by the communication interface 61 may include any data transmitted, output, and / or provided by the server 4 as described herein. Additionally, each communication interface may include one or more receivers configured to receive data carried on the network, such as the communication network 6. The data received by the communication interface 61 may include any data received by the server as described herein, such as PIDs and PID data values and any requests as described herein.

[0140] The transmitter can transmit radio signals carrying data, and the receiver can receive radio signals carrying data. The communication interface with the transmitter and receiver can include one or more antennas and can be referred to as a "radio communication interface", "RF communication interface", or "wireless communication interface". The radio signals transmitted or received by the radio communication interface can be arranged according to one or more wireless communication standards or protocols, such as the IEEE 802.15.1 standard for WPAN, the Bluetooth version 4.1 standard developed by the Bluetooth Special Interest Group (SIG) in Kirkland, Washington, or the IEEE 802.11 standard for wireless LAN (sometimes referred to as the standard), or cellular wireless communication standards such as the Long Term Evolution (LTE) standard, Code Division Multiple Access (CDMA) standard, Integrated Digital Enhanced Network (IDEN) standard, Global System for Mobile Communications (GSM) standard, General Packet Radio Service (GPRS) standard, Universal Mobile Telecommunications System (UMTS) standard, GSM Enhanced Data Rate for GSM Evolution (EDGE) standard, or Multichannel Multipoint Distribution Service (MMDS) standard.

[0141] Additionally or alternatively, the transmitter can transmit a signal (e.g., one or more signals or one or more radio waves) carrying or representing data onto a line (e.g., one or more lines), and the receiver can receive a signal carrying or representing data via the line. The line can be part of a network, such as communication network 6. The signal carried on the line can be arranged according to a wired communication standard, such as the Transmission Control Protocol / Internet Protocol (TCP / IP), the IEEE 802.3 Ethernet communication standard for LAN, the Cable Service Interface Data Specification (DOCSIS standard), such as DOCSIS 3.1, the USB specification (as previously mentioned), or some other wired communication standard.

[0142] The data transmitted by the communication interface can include the destination identifier or address of the network device to which the data is to be transmitted. The data transmitted by the communication interface can include the source identifier or address of the system component that includes the communication interface. The source identifier or address can be used to send a response to the network device that includes the communication interface that sent the data.

[0143] A communication interface configured to communicate on communication network 6, such as communication interface 61, can include a modem, a network interface card, and / or a chip that can be mounted on a circuit board. As an example, the chip can include the CC3100 network processor provided by Texas Instruments from Dallas, Texas, the CC256MODx host controller interface (HCI) module, and / or for communicating via or different chips communicating via other communication protocols.

[0144] Next, Figure 7 An exemplary PID index 70 is shown, which includes an ordered list of PIDs. In particular, three exemplary representatives of PIDs are shown within the PID index 70, which use PID number 71, index value 72, and PID name 73 (e.g., at least one word describing the PID) to represent the PID. Different PID indexes (for exemplary embodiments) can represent the PID using only one of these three exemplary representatives, a combination of any two of these three exemplary representatives, or by using different exemplary PID representatives. The VST 40 can use the PID index 70 to display on the display 41 parameters related to a set of associated PIDs. As shown, some PIDs (e.g., PIDs 31 - 36) can correspond to VCPs. In other examples, these PIDs can be indicated as VCPs in the PID index 70.

[0145] For example, the index value 72 can include numbers in decimal, hexadecimal, or some other base to represent the PIDs within the PID index 70. Other exemplary PID indexes can include multiple PID indexes, such as separate PID indexes for each of multiple different specific identification information sets (e.g., separate PID indexes for each Y / M / M or Y / M / E). Thus, the separate PID indexes can be arranged like the PID index 70 or in another way. The PID index 70 can include or be associated with specific vehicle identification information. The server 4 can provide the PID index to the computing system 2 for identifying PIDs recommended to be requested from the vehicle 8 to diagnose the vehicle 8.

[0146] III. Exemplary Display Presentation

[0147] Next, Figure 8 is a schematic diagram depicting an exemplary display presentation (DP) 76 that the VST 40 can display on the display 41. The DP 76 is shown horizontally, but in other examples can have a vertical (e.g., portrait) orientation. Thus, the DP 76 includes a VDP graphic window 78, where there are a VDP line graph 80, VDP graphic text 81, and VDP threshold indicators 82, 83 placed on the VDP line graph 80. The DP 76 also displays vehicle operating condition indicators 84, 85, 86, 87, 88, and 89 as well as a time - based indicator 90, and further includes a view selector 91 for selecting different views for a set of VDPs, at least one of which in the set can include the currently displayed VDP. In addition to Figure 8 the graphical views described in, other views can include, but are not limited to, numerical views and list views.

[0148] The VDP line graph 80 is an example of a line graph where the area below the line graph is not shaded. The VDP line graph 80 can represent a parameter associated with a specific PID, such as a first PID that is part of a group of associated PIDs. The VDP line graph 80 can include or display other information related to the operation of the vehicle 8. For example, this other information can include VDP graphic text 81. Generally, the VDP graphic text 81 can include graphic text related to any VDP associated with or from the vehicle 8. As an example, the VDP graphic text 81 can include text indicating a threshold associated with a particular vehicle component (e.g., throttle position sensor (TPS) position) or a PID associated with that vehicle component. The threshold can specify its unit, such as a percentage, volt, or ampere.

[0149] The VDP threshold indicator 82 positioned above the VDP line graph 80 in the VDP graphic window 78 can represent the VDP upper threshold associated with the percentage of TPS position shown in the VDP graphic text 81. Similarly, the VDP threshold indicator 83 can represent the lower VDP threshold associated with the percentage of TPS position. In some exemplary embodiments, the VDP threshold indicators 82 and 83 can include visual indicators (e.g., horizontal lines) indicating the thresholds. VDP indicators, such as the VDP threshold indicators 82 or 83, can also include vehicle operation condition (VOC) indicators. The VOC indicators can have unique features to distinguish different types of VOC indicators. Additionally, the VDP graphic window 78 includes an upper threshold indicator 94 that indicates the numerical value of the upper threshold of the VDP displayed in the VDP graphic window 78. The VDP graphic window 78 includes a lower threshold indicator 95 that indicates the numerical value of the lower threshold of the VDP displayed in the VDP graphic window 78.

[0150] As Figure 8 Further shown, the VOC indicator of the VDP threshold indicator 82 includes a dark flag icon 92, while the VOC indicator of the VDP threshold indicator 83 includes a light flag icon 93. The dark flag icon 92 and the light flag icon 93 will be combined Figure 10 for further discussion.

[0151] The time-based indicator 90 depicted in DP 76 can represent various time periods on the display of VST 40. In other examples, the time-based indicator 90 can have other locations or configurations. As shown, the time-based indicator 90 can include a cursor locator 96 and time periods 97, 98, and 99 to convey time information to a user of VST 40. The cursor locator 96 can correspond to the cursor 100 positioned within the VDP graphics window 78 or to the numeric VDP value 101 indicating the current value of the VDP at the cursor 100. DP 76 shows the time-based indicator near the bottom of DP 76. The time-based indicator 90 can be displayed at other locations within the DP.

[0152] The time period 97 provides an indication of the amount or percentage of time that the frame or data value of the VDP being displayed was captured before the frame or data value of the VDP currently being displayed within the VDP graphics window 78, relative to time periods 98 and 99. The time period 98 provides an indication of the amount or percentage of time represented by the VDP value being displayed within the VDP graphics window 78, relative to time periods 97 and 99. The time period 99 provides an indication of the amount or percentage of time that the VST can receive additional frames or data values of the VDP before the previous instance of the received VDP is overwritten or otherwise deleted to store additional frames or data values of the VDP, relative to time periods 97 and 98.

[0153] The VDP line graph 80 can be zoomed in or out within the VDP graphics window 78 via the user interface of VST 40. As an example, the cursor locator 96 can be moved in a first direction (e.g., to the right) to zoom in on the VDP line graph 80 and in a second direction (e.g., to the left) to zoom out on the VDP line graph 80. As another example, the cursor 100 or the cursor bar 102 can be moved in the first and second directions to zoom in on and out of the VDP line graph 80, respectively. As another example, zooming in on the VDP line graph can include reducing the time represented horizontally within the VDP graphics window 78, while zooming out on the VDP line graph can include increasing the time represented horizontally using the VDP graphics window 78. Alternatively, repositioning the cursor 100 or the cursor bar 102 can include representing the current value of the VDP at another location within the VDP chart window 78.

[0154] Next, Figure 9It is a schematic diagram depicting another exemplary display rendering 103 that VST 40 can display on the display 41. DP 103 is shown in a vertical direction, but in other examples it can be displayed in another direction (e.g., horizontal). Thus, DP 103 displays VDP graphic windows 104, 105, 106, 107, 108, and 109, which respectively include VDP graphic lines 116, 117, 118, 119, 120, and 121, as well as VDP graphic texts 110, 111, 112, 113, 114, and 115. Other examples are also possible.

[0155] The VDP graphic texts 110 - 115 can provide texts identifying different PIDs of each VDP graphic window shown in DP 103. For example, the VDP graphic text 110 can be associated with a specific PID and can specify a unit for the data value of the VDP graphic line 116 and at least one of the minimum data value and the maximum data value. The minimum and maximum data values can respectively indicate a low VDP threshold and a high VDP threshold, but are not limited thereto. For example, the minimum and maximum data values can indicate the minimum data value and the maximum data value of the VDP currently displayed within or associated with the VDP graphic window including the VDP graphic text.

[0156] DP 103 further includes a text view selector 122 and a graphic view selector 123. When the display 41 of VST 40 Figure 9 displays the VDP graphic window in the graphic view as shown, the text view selector 122 can be selected by a display pointer or other means (e.g., via a touchscreen interface or a voice command) to cause the display to start displaying the VDP shown in one or more of the VDP graphic windows 104, 105, 106, 107, 108, and 109, or the data represented therein, in text format. When the display displays the VDP in text format, the graphic view selector 123 can be selected by a display pointer or other means (e.g., via a touchscreen, voice input) to cause the display to start displaying the VDP graphic windows 104, 105, 106, 107, 108, and 109.

[0157] DP 103 includes a time - based indicator 124 with time periods 610, 612, 614, a cursor locator 616, and a cursor 228 within each of the VDP graphic windows 104, 105, 106, 107, 108, and 109. The cursor locator 416 can be moved in either direction along the time - based indicator 124 to cause the cursor 228 to move uniformly within each of the VDP graphic windows 104, 105, 106, 107, 108, and 109.

[0158] Next, Figure 10It is a schematic diagram depicting exemplary display renderings 125 and 126 that can be provided by a device via a display or a graphical user interface. For example, exemplary devices that can display DPs 125, 126 can include a VST 40, a smartphone, or another device with a graphical user interface. DPs 125, 126 include a DP selector 127 that can allow viewing of different VDP display renderings or display of other information (e.g., viewing a list of PIDs by selecting "LIST VIEW" or viewing a graph of PIDs by selecting "GRAPH VIEW"). For example, selecting the DP selector 127 causes DP 126 to display a different VDP display rendering (e.g., a list view rendering or a graph view rendering). Either DP 125 or DP 126 can be entered from another type of view by selecting the list view from the DP selector 127 in another type of view, such as a graph view or a digital view.

[0159] Each of DPs 125 and 126 includes a time-based indicator 128 and a frame or data value indicator 129. As an example, the frame or data value indicator 129 indicates 3834 out of 5000 frames or data values. In some cases, the VST 40 may have received the same number of data values for each VDP identified in the list view of the VDP. In accordance with these cases, the cursor locator 130 can be moved to select a different frame or data value out of 5000 frames or data values. In other cases, the VST 40 can receive different numbers of data values for two or more VDPs identified in the list view of the VDP. In accordance with these other cases, the cursor locator 130 can be moved to select a different frame or a different value of the received frames or data values for specifying a VDP. The data values of other VDPs can be changed to other data values related to the time at which different frames or data values are received.

[0160] As Figure 10 shown, the list view of the VDP can include multiple VDP text identifiers (e.g., VDP text identifiers 131, 139) and multiple VDP values (e.g., VDP values 132). For a VDP whose data value breaches a VDP threshold (e.g., greater than an upper threshold or lower than a lower threshold), a VOC indicator 133 will be displayed. The processor 23 can detect a drag-and-drop input of a VDP displayed in the list view and move the VDP from its initial position to a position that includes the location to which the VDP is dragged by the drag-and-drop input when the drag-and-drop input is initiated.

[0161] DP 125 and DP 126 may include at least one scroll bar for inputting a scrolling input to display virtual VD values that are not currently displayed by DP125 or DP 126 and to reposition one or more currently displayed VD values to virtual VD values that are not currently displayed by DP 125 or DP 126.

[0162] The processor 23 may execute program instructions of the CRPI 28 to provide a VDP threshold selection display by the display 41. The selection display may include selecting a VDP. The selection display may include selecting at least one VDP threshold associated with the selected VDP, or default selecting (a plurality of) VDP thresholds when selecting a VDP. The selection display may include selecting a VOC indicator for the VDP or VDP threshold, or the VOC indicator selection may be default selected when selecting a VDP or VDP threshold.

[0163] Figure 10 Further shown are VOC indicators 134, 135, 136, and 137 as examples of VOC indicators that may be displayed by the display 41 on the VST40. As Figure 10 shown in this and other figures, each VOC indicator may include a flag and a flagpole icon, but the VOC indicator is not limited thereto. Additionally, the display 41 may display the VOC indicator in different colors or shadings to indicate various characteristics related to the VDP threshold or VOC. In one aspect, the VOC indicator 134 includes a contoured flag (e.g., a white flag outlined in red), and the VOC indicator 135 includes a solid flag (e.g., a red flag). The contoured flag may be displayed to indicate that the VDP threshold is armed, but the VDP value received for the VDP has not breached the VDP threshold. The solid flag may be displayed to indicate that the VDP value received for the VDP has breached the associated armed VDP threshold. Preparing the VDP threshold may be performed by selecting a VDP for display, selecting a VDP threshold for the VDP, or other means. When preparing the VDP threshold, the processor 23 may compare the VDP received by the VST to determine whether the VDP is associated with the VDP threshold and whether it breaches the VDP threshold.

[0164] In addition, the display 41 may display text associated with the VDP (e.g., PID) near the VOC indicator. The display 41 may display the associated text in various ways to further indicate whether the VDP threshold has been breached. For example, when the VDP threshold is armed but not yet breached, the text associated with the VDP may be blue, and when the armed VDP threshold is breached, the associated text may be red. The processor 23 may cause the associated text to change color in response to detecting that the VDP threshold has been breached.

[0165] In another aspect, the VOC indicator 137 (e.g., a white flag) can indicate that the VDP high threshold has been breached, while the VOC indicator 136 (e.g., a grey shaded flag) can indicate that the VDP low threshold has been breached. In another aspect, if VDP thresholds have been set and are ready for multiple VDPs, the VOC indicator for each VDP can be associated with a respective color or respective shading to distinguish the VOC indicators for each of the multiple VDPs. Other colors, visual representations, and configurations are possible.

[0166] Figure 11 A flowchart depicting a set of functions 200 (or more simply "the set 200") is shown, which can be performed in accordance with the exemplary embodiments described in this specification. The set 200 includes the functions shown in blocks 202, 204, 206, 208, 210, 212. The following description of the set 200 includes references to elements shown in other figures described in this specification, but the functions of the set 200 are not limited to being performed only by the referenced elements. Various methods can be performed using all of the functions shown in the set 200 or any suitable subset of the functions shown in the set 200. Any one of these methods can be performed in conjunction with other functions, such as one or more other functions described in this specification.

[0167] Block 202 includes receiving vehicle diagnostic information from a vehicle. The computing system 2 or another type of computing system (e.g., a smartphone, a wearable computing system) can receive vehicle diagnostic information (VDI) from the vehicle 8. For example, the computing system 2 can receive vehicle diagnostic information via a wired or wireless connection with the vehicle 8. In some examples, the computing system 2 can perform one or more functions of the set 200 with the assistance of the server 4 or another computing device. For example, the computing system 2 can obtain vehicle diagnostic information from the vehicle and communicate the vehicle diagnostic information to the server 4 for processing.

[0168] The VDI can provide information related to the status, performance, and other aspects of the systems of the vehicle 8. In particular, the vehicle diagnostic information can include one or more sets of parameters corresponding to PIDs. For example, the vehicle diagnostic information can include vehicle data parameters (VDPs) associated with PIDs that reflect the current state of the vehicle systems. The current state can reflect the most recent operation of the system, the condition of the system, or a combination of information about the system. In some cases, the information conveyed in the vehicle diagnostic information may depend on the type of vehicle system being analyzed.

[0169] As described above, the vehicle diagnostic information can include parameters related to PIDs, which can be based on information obtained from Figure 6The PID index 68 received by the server 4 shown. In some examples, the vehicle diagnostic information may also include diagnostic trouble codes from the vehicle 8. The diagnostic trouble codes may indicate problems associated with one or more vehicle systems.

[0170] In some exemplary embodiments, the computing system 2 that obtains vehicle diagnostic information from the vehicle 8 may be Figure 5 the VST 40 described in. In particular, the VST 40 may request and obtain the VDP from the vehicle 8 using vehicle data information (VDM) (e.g., serial data information). For example, the VST 40 may communicate with the vehicle 8 using the DLC or another component to obtain the VDP that describes the operation of the vehicle 8. As an exemplary embodiment, the VST 40 may receive the VDP from the vehicle 8 in the form of an electrical signal.

[0171] In a further exemplary embodiment, the computing system 2 may receive vehicle diagnostic information from the on-board diagnostic (OBD) II reporting system of the vehicle 8 operating in OBD II mode $01. Similarly, the computing system 2 may receive vehicle diagnostic information from the OBD reporting system of the vehicle 8 operating in OBDII mode $02. In a further example, the computing system 2 may switch between receiving parameters from the OBD II reporting system of a vehicle operating in mode 1 mode $02 and receiving parameters from the OBDII reporting system of a vehicle operating in other OBD II modes.

[0172] Block 204 includes a first set of parameters corresponding to PIDs that identify the state of a particular system representative of the vehicle. The computing system 2 may analyze the vehicle diagnostic information to determine the parameters of the PIDs that represent the states of various vehicle systems. For example, the computing system may determine a first set of parameters for a first PID that represents the state of a first vehicle system (e.g., the engine), and a second set of parameters for a second PID that represents the state of a second vehicle system (e.g., the oil system). Within the examples, the parameters of the PIDs that represent various vehicle systems may be identified, including but not limited to (multiple) engines, braking systems, oil systems, coolant systems, tires, sensors, and steering systems, etc.

[0173] In some cases, the computing system 2 may identify the parameters of multiple PIDs that convey the same vehicle system information. For example, the computing system 2 may determine the parameters of multiple PIDs corresponding to the vehicle engine. Similarly, the computing system 2 may obtain the parameters of the PIDs of related systems. For example, the computing system may identify the parameters of the PIDs for each brake pad, each tire pressure, or other similar systems. In addition, the computing system 2 may be configured to identify a set of parameters corresponding to the PIDs that represent the state of the vehicle system based on one or more diagnostic trouble codes received from the vehicle 8.

[0174] The computing system 2 can be configured to obtain multiple sets of parameters corresponding to PIDs representative of different vehicle systems and then organize the parameter sets of the PIDs according to each vehicle system. For example, the computing system 2 can identify the parameters of the PIDs of each system, such as the parameters of the PID corresponding to the engine, the parameters of the PID corresponding to the braking system, and the parameters of the PID corresponding to the tires, etc. In some examples, the computing system 2 can be configured to identify the parameters of the PIDs of a specific vehicle system. For example, the computing system 2 can identify the parameters corresponding to the engine of vehicle 8.

[0175] Block 206 includes determining a current value of the PID using the first set of parameters. The computing system 2 can analyze the identified parameters to determine the current value of the PID. The current value of the PID can reflect the current state of the associated vehicle system. For example, when the PID corresponds to the oil system of a vehicle, the current value of the PID can reflect the current oil level of the oil system. Similarly, when the PID corresponds to the vehicle braking system, the current value of the PID can reflect the current state of the brakes (e.g., the amount of wear).

[0176] Block 208 includes comparing the current value of the PID with a predetermined value. After determining the current value of the PID, the computing system 2 can be configured to compare the current value with one or more predefined values of the PID. These predefined values can correspond to predetermined thresholds of the PID that help the computing system 2 determine the current health of the vehicle system. This comparison can enable the computing system 2 to compare the current value of the PID with at least one expected value. For example, this comparison can indicate whether the current value of the PID is within the optimal operating range of the system.

[0177] One or more predetermined thresholds of the PID used in this comparison can vary within examples. In certain cases, the predetermined thresholds of the PID may depend on multiple factors. Additionally, in some examples, the computing system can use multiple predetermined thresholds or ranges to compare with the current value of the PID.

[0178] In some examples, the predetermined thresholds of the PID can be based on the make and model of vehicle 8. Different types of vehicles may have systems with different performances. Therefore, the computing system 2 can be configured to utilize one or more predefined values of the PID developed based on the make and model of vehicle 8. In some examples, the computing system 2 can access these predefined values from the server 4 (e.g., the predefined value 67 shown in Figure 6 ). In particular, the server 4 can develop the predefined values based on the analysis of numerous vehicles with the same make and model as vehicle 8. Similarly, these predefined values can be set by the manufacturer of vehicles of a specific make and model.

[0179] The predetermined threshold of the PID can be based on the previously determined health status of the vehicle system. The computing system 2 or another computing device can establish one or more predetermined thresholds of the PID based on one or more prior inspections of the health status of the vehicle. In this way, the computing system 2 can compare the current state of the system indicated by the current value of the PID with the PID value representing the most recent condition of the system. By extension, in some cases, the predetermined threshold of the PID can be configured during the most recent maintenance of the vehicle system. For example, a user (e.g., a technician) can set one or more values for the PID based on the system state during maintenance. Thus, the user can pre-define the threshold as an alert for when to inspect or replace the vehicle system.

[0180] This comparison can use one or more values of the PID that depend on the general condition of the vehicle 8. For example, the computing system 2 can compare the current value of the PID with a predetermined threshold of the PID based on the current mileage of the vehicle 8.

[0181] In some examples, the computing system 2 can perform multiple comparisons. For example, the computing system 2 can compare the current value of the PID with a first predefined threshold of the PID. Based on the result of the comparison, the computing system 2 can compare the current value of the PID with a second predefined threshold of the PID. For example, the computing system 2 can utilize a first comparison that indicates whether the system is operating within a healthy range. If the computing system 2 determines that the system is not within the healthy range, the computing system 2 can utilize a second comparison to determine whether the vehicle system needs repair or replacement.

[0182] Block 210 includes determining the health status of a particular system of the vehicle such that the health status reflects the difference between the current value of the PID and the predetermined threshold. As described above, this comparison can enable the computing system 2 to compare the current value of the PID with one or more predefined values of the PID. This comparison can indicate whether the current value of the PID is within the optimal range of operation.

[0183] In some examples, the computing system 2 can determine the health status of the vehicle system such that the health status represents a numerical difference between the current value of the PID and the predetermined threshold. Similarly, the computing system 2 can determine the health status of the vehicle system such that the health status represents a percentage difference between the current value of the PID and the predetermined threshold.

[0184] The block 212 includes a vehicle health record that displays, at a graphical interface, the health status of a particular system of the vehicle. The vehicle health record can convey, in various formats within each example, the health status of one or more vehicle systems, such as a GUI including vehicle graphics, charts, colors, text, and other elements configured to display health status information related to the vehicle systems. These different elements of the GUI can be selectable to enable a user to browse various information associated with the generated vehicle health record.

[0185] In some examples, the computing system 2 can display, in a graph, the health status of a system of the vehicle, the graph indicating a numerical difference between a current value of a PID and a predetermined threshold. The graph can include an indication of the system.

[0186] The computing system 2 can perform the comparison and determine that the current value of the PID is higher than a predetermined threshold of the PID representing a lower bound threshold of the PID. Thus, the computing system 2 can display an indication conveying that the system is within a desired health status range. In one aspect, the desired health status range can be a range in which the value associated with the PID does not set a DTC. In another aspect, the desired health status range can be a range in which the value associated with the PID (e.g., VCP) indicates that the vehicle system is within an OEM-specified operating range (e.g., a desired tire pressure value). The computing system 2 can indicate that the system is healthy and does not require immediate attention (e.g., repair or replacement). Alternatively, the comparison can indicate that the current value of the PID is lower than the predetermined threshold of the PID representing the lower bound threshold. As the current value of the PID drops below the lower bound threshold, the computing system 2 can include, in the vehicle health record, an alert indicating that the system requires maintenance. Thus, the vehicle health record can clearly show that the system is not within the ideal operating range and may require attention (e.g., repair or replacement).

[0187] The computing system 2 can perform the comparison and determine that the current value of the PID is lower than a predetermined threshold of the PID representing an upper bound threshold of the PID. Thus, the computing system 2 can display an indication conveying that the system is within a desired health status range. In particular, the computing system 2 can indicate within the vehicle health record that the system is healthy and does not require immediate attention (e.g., repair or replacement). Alternatively, the comparison can indicate that the current value of the PID is higher than the upper bound threshold. Thus, the computing system 2 can include, in the vehicle health record, an alert indicating that the system requires maintenance. Thus, the vehicle health record can clearly show that the system is not within the ideal operating range and may require attention (e.g., repair or replacement).

[0188] The set 200 may further include identifying a second set of parameters corresponding to a second PID representative of the state of a particular system of the vehicle and using the second set of parameters to determine a second current value of the second PID. The set 200 may also include making a second comparison between the second current value of the second PID and a second predetermined threshold. Thus, determining the health of the particular system may be further based on the second comparison between the second current value of the second PID and the second predetermined threshold.

[0189] In some examples, the set 200 may further include executing a functional test script prepared for the vehicle. In particular, executing the functional test script may include requesting the vehicle to perform one or more functional tests and requesting PID parameters from the vehicle in a predefined order related to requesting the vehicle to perform one or more functional tests. In some examples, in response to requesting PID parameters from the vehicle in a predefined order, at least a portion of the one or more sets of parameters is received. In some examples, at least this portion of the one or more sets of parameters may include reactive PIDs indicating whether the one or more functional tests passed or failed. The health of a particular system of the vehicle may further reflect whether a functional test related to the particular system passed or failed. As an example, functional tests associated with reactive PIDs may include enabling an air conditioning compressor, enabling a heating, ventilation, and air conditioning (HVAC) fan, enabling an ABS pump. Other examples of such functional tests are possible.

[0190] In some examples, the computing system 2 may be coupled to the vehicle during execution of one or more blocks of the set 200. In particular, the computing system 2 may be coupled to the vehicle based on a wired connection or a wireless connection. In certain cases, the computing system 2 may be coupled to the vehicle during a subset of the blocks of the set 200.

[0191] In a further example, the computing system 2 may programmatically perform one or more functional tests on the vehicle 8. For example, the computing system 2 may perform one or more functional tests after a test drive of the vehicle 8. The functional tests performed by the computing system 2 may depend on certain conditions detected by the computing system 2 during the test drive. The computing system 2 may be configured to initiate one or more functional tests after detecting that the test drive is complete and in response to determining that the vehicle 8 is in a state suitable for functional testing.

[0192] In some examples, the computing system 2 may perform one or more functional tests during a test drive of the vehicle 8. For example, before the test drive, if the computing system 2 detects certain conditions, the computing system 2 may display a list of one or more functional tests to be performed during the test drive. In this way, the driver of the vehicle can be made aware of which functional tests can be performed to avoid being surprised during the test drive. Certain conditions detected by the computing system 2 may include preventive conditions to ensure the safe conduct of the functional tests. For example, the computing system 2 may require the vehicle 8 to be in an initial state (e.g., the vehicle 8 is stationary and the brakes are applied) before starting and performing the functional tests. The initial state of the vehicle 8 required by the computing system 2 before performing the functional tests may depend on the type of functional test being performed. Thus, the computing system 2 may be configured to stop performing the functional tests when it detects a change in the conditions that allow the functions to be performed (e.g., the brakes are no longer applied). The conditions may depend on sensor data from various vehicle sensors or other types of sensors communicating with the computing system 2.

[0193] In addition, the computing system 2 may include a prompt that asks the driver to confirm the one or more functional tests to be performed during the test drive before performing the (multiple) functional tests. In addition, the computing system 2 may be programmed so that it does not perform functional tests during the test drive when certain conditions are met (e.g., the vehicle is in a moving state). The system software associated with the computing system 2 (e.g., the instructions of the CRPI 28) may drop a flag during the test drive that enables the user to review the flag initiated by the software after the test drive is completed. In addition, the computing system 2 may initiate functional tests based on sensor data. For example, the computing system 2 may review and analyze sensor data and PID data (e.g., PID threshold break) to determine the functional tests to be performed. In some examples, the computing system 2 may perform a mass air flow sensor test, turn on or off the headlights, and / or turn on or off other sensors such as cameras, microphones, etc.

[0194] In a further example, capturing information about the operation of one or more systems may involve one or more sensors analyzing wheel speed PIDs and identifying when one or more PIDs change by a significant amount (e.g., a threshold speed). These measurements may enable the user to subsequently detect when the vehicle is turning during a PID review, or when the tires on the vehicle may have different sizes due to improper tire inflation or wear.

[0195] Figure 12is a flowchart depicting a process for generating an exemplary vehicle health record. The flowchart includes a set of steps 300. A computing system (e.g., computing system 2) or a server 4 may execute one or more of the set of steps 300 to generate a vehicle health record that conveys the current health status of one or more systems of a vehicle (e.g., vehicle 8). In some examples, executing one or more of the set of steps 300 may assist in developing the vehicle health record. The vehicle health record may represent a compilation of a series of vehicle health analyses performed on the vehicle over time. Thus, the vehicle health record may represent historical information regarding the health status of different vehicle systems, as well as the associated maintenance history of the vehicle systems. Within examples, the steps 300 may be executed in different orders. Additionally, the execution of the steps may occur automatically by the computing system 2 or in response to a user's selection at an interface of the computing system 2.

[0196] Block 302 pertains to the home page option. The home page option may represent the start screen of an interface (e.g., a GUI) provided by the computing system 2 to the user to initiate the development of the vehicle health record. In some examples, the home page option may enable the user to provide information related to the vehicle, such as a vehicle identification number (VIN), one or more images of the vehicle, and user information and other information. The home page option may include selectable icons that allow the user to trigger the computing system 2 or another device (e.g., server 4) to perform actions related to measuring the health status of the vehicle systems. Additionally, the home page option may also enable the user to review previously generated information related to the health status of the vehicle 8.

[0197] Block 304 involves the user selecting the scanner icon. From the home page option, the user can cause the computing system to initiate a scan of vehicle 8 by selecting the scanner icon using the interface of computing system 2. In some cases, the computing system can be configured to automatically perform a scan in response to being connected to vehicle 8. Thus, selecting the scanner can bring up the scanner system menu, as represented by block 306. The scanner system menu can provide one or more options related to information regarding the health of the scanned vehicle (e.g., vehicle diagnostic information). Thus, these options can be displayed within the scanner system menu. From the scanner system menu, the user can select a vehicle health scan, as represented by block 308. Selecting the vehicle health scan at block 308 can trigger the computing system to perform a health scan of the vehicle, which may involve accessing vehicle diagnostic information from vehicle 8 via a wired or wireless connection between computing system 2 and vehicle 8. For example, the health scan can enable the computing system to obtain PIDs that convey information regarding the health of the vehicle systems. Block 310 involves performing a code scan. In at least some embodiments, performing a code scan can include the computing system requesting the status of DTCs set in one or more ECUs in vehicle 8. In some cases, the code scan can involve pulling codes and showing the status of the readiness monitors associated with the vehicle. The code scan can enable the computing system to determine a summary of the vehicle information.

[0198] Block 314 involves computing system 2 obtaining recall and campaign information related to the vehicle. The computing system can obtain recall and campaign information using an Internet connection, from a database (e.g., server 4), or from other sources. By accessing this information, the computing system can warn the user of any recent relevant recalls or campaigns that may affect the performance of the vehicle. Block 316 involves the computing system determining a table of contents (TOC). The TOC can enable the user to quickly review information related to the vehicle.

[0199] Selecting code scan (VSR) at block 318 can trigger the computing system 2 to perform a code scan to implement a vehicle summary report. When developing a vehicle health record, the computing system 2 can be configured to analyze the health of different vehicle systems using one or more of the processes described herein. Thus, the computing system 2 can determine and prepare a maintenance interval at block 320. The maintenance interval can compare the current mileage of the vehicle's odometer and indicate at what future mileage, if any, certain vehicle systems may require some form of review or repair (e.g., rotation, change, replacement). The estimate may be based on previously set mileage, past trends derived from analyzing each vehicle system of one or more similar vehicles, or other information. Additionally, the computing system 2 can also provide a maintenance mode at block 322. The maintenance mode 322 can involve setting the vehicle computing system to a specific maintenance mode, enabling a technician to review additional information related to the operation of the vehicle systems.

[0200] In addition to generating a vehicle health record that conveys the health of one or more vehicle systems, the computing system 2 can also enable a user to print the vehicle health record at block 312. Printing can involve printing one or more pages (blocks 324, 326, 328) of the vehicle health record to enable the user to review the vehicle health record in a tangible form. For example, a technician can utilize the print option to provide a customer with a printout of the vehicle health record that allows the customer to carefully review any or all of the information to make subsequent maintenance decisions for the vehicle 8. Additionally, the print option can involve using one or more GUIs to display the vehicle health record on one or more display interfaces. In some examples, the computing system 2 can also include another option configured to display the vehicle health record.

[0201] Figure 13A and Figure 13B Show example PIDs that can be used to analyze the health of vehicle systems. These PIDs represent example PIDs that can be identified using VDI to analyze the health of various vehicle systems, such as brakes, tires, and engines. Other examples can include other PIDs that can be used to generate a vehicle health record.

[0202] Figure 13A Show an example of PIDs that can be used to analyze the health of the vehicle systems of a first vehicle. In particular, the first vehicle is shown as a 2013 Chevrolet Avalanche 5.3L, as shown in header 332 of table 330. The PID list further includes an ID column 334, a vehicle system column 336, a data list header column 338, a PID name column 340, a condition column 342 associated with the vehicle system, and a vehicle information column 344 for the first vehicle.

[0203] The ID column 334 can be used to organize various PIDs. For example, Figure 13A as shown, the ID column uses numbers that increase in numerical order to organize the PIDs. The vehicle system column 336 conveys the vehicle systems associated with the PIDs represented by the information in the rows of the table. In Figure 13A the example shown, the vehicle system column 336 includes various vehicle systems such as an anti-lock braking system, an instrument panel cluster, a maintenance (engine oil) interval reset, a tire pressure monitor, and a transmission. Some of these vehicle systems are associated with multiple PIDs in the table. The data list header column 338 provides various types of data associated with each PID, such as ABS data, signal data, data, maintenance data, tire pressure data (TPM) data, and Trans data.

[0204] The PID name column 340 conveys the various PID names associated with each PID. The PID name can provide a description of the information associated with the PID, such as the washer fluid level, the remaining life of the engine oil, etc. In some examples, the PID name can be modified by the user. The condition column 342 indicates aspects of the health of the vehicle systems represented by the PIDs in each row of the table 330. The vehicle information column 344 conveys vehicle information associated with the first vehicle, including the year, make, model, and engine type.

[0205] Figure 13B An example of PIDs that can be used to analyze the health of the vehicle systems of a second vehicle is shown. In particular, the second vehicle is shown as a 2012 Chevrolet Silverado 6.0L, as shown in the header 352 of the table 350. The list of PIDs further includes an ID column 354, a vehicle system column 356, a data list header column 358, a PID name column 360, a condition 362 associated with the vehicle system, and vehicle information 364 about the second vehicle. These columns are organized and convey information similar to the columns described with respect to the table 330 shown in Figure 13A above.

[0206] Figure 14 is an exemplary graphical user interface for displaying vehicle health records. The graphical user interface (GUI) 400 includes different visual elements that can be selected by the user. In particular, the GUI 400 includes a top toolbar 402, a vehicle health scan option 404, a code scan option 406, and a maintenance reset and relearning option 408. In addition, the GUI 400 also shows clearing all codes read by the code scan option 410, a common selection section 412, and a bottom toolbar 414. In some examples, the GUI 400 can correspond to the home page option 302 shown in Figure 12 above.

[0207] The GUI 400 represents a visual display that can be shown by the computing system 2 for a user to review the health of one or more vehicle systems of the vehicle 8. In particular, each element of the GUI 400 (and other GUIs described herein) can be selected using an input interface associated with the display interface that shows the GUI 400. For example, the elements of the GUI 400 can be selected via a touchscreen interface, a mouse, a keyboard, an audio input, or other selection means. Thus, these elements can allow for user-selectable control that can trigger various actions by the computing system 2 in response to the user's selection.

[0208] In addition, Figure 14 the elements shown in

[0209] are arranged in an example format in the GUI 400. Other examples can include more or fewer elements arranged in other configurations. The computing system can be configured to enable a user to customize the layout of the elements included in the GUI 400.

[0210] The vehicle health scan option 404 represents a selectable graphic that a user can choose to initiate the execution of a health scan of the vehicle 8. In some cases, selecting the vehicle health scan option 404 can cause the computing system 2 to receive vehicle diagnostic information from the vehicle 8 when connected to the vehicle 8. Alternatively, selecting the vehicle health scan option 404 can also be configured to cause the computing system 2 to display results associated with a previous vehicle health scan. In some examples, the computing system 2 can be coupled to the vehicle 8 to receive vehicle diagnostic information in response to selecting the vehicle health scan option 404. Selecting the health scan option 404 can cause the computing system 2 to scan one or more PIDs (e.g., one or more VCPs) that can be used to evaluate the health of one or more vehicle systems.

[0211] In response to the detection of the vehicle health scan option 404 or other options presented, the computing system 2 can detect one or more PIDs associated with the selected option (e.g., the vehicle health scan option 404). The computing system 2 can generate a VDM to request one or more PIDs (e.g., for the computing system 2) of a particular vehicle coupled to the scanner. The computing system 2 can transmit the (multiple) VDMs and receive a VDI including one or more PIDs (e.g., VCPs) as a response.

[0212] The code scan option 406 represents another selectable graphic that a user can select to perform a code scan of the vehicle 8. Selecting the code scan option 406 enables the computing system 2 to receive diagnostic codes from the vehicle 8 when connected to the vehicle 8. Alternatively, selecting the code scan option 406 can also be configured to cause the computing system 2 to display the results associated with the most recent code scan of the vehicle 8. In some cases, selecting the code scan option 406 can cause the computing system 2 to request one or more DTCs. In some examples, the code scan option 406 can enable the computing system 2 to obtain DTCs, while the health scan option 404 can enable the computing system 2 to obtain PIDs, such as PIDs that convey information related to the health of the vehicle systems.

[0213] The maintenance reset and relearning option 408 represents a selectable graphic that a user can select to display information related to maintenance reset and maintenance relearning. Selecting this option can enable the user to recalibrate the levels associated with specific vehicle systems. For example, the user can utilize this option to adjust the levels of one or more vehicle systems. Resetting and relearning can allow for resetting the vehicle systems and include indications to specify the changes made.

[0214] Clearing all codes read by the code scan option 410 can represent a selectable option that enables the user to clear the codes captured by a previous code scan performed by the computing system 2. For example, the computing system 2 can be configured to clear the existing vehicle diagnostic information stored at the computing system 2 to prepare for a subsequent scan.

[0215] The frequently selected section 412 shows different options that are often selected by users who utilize the GUI 400. In particular, the frequently selected section 412 is shown with the systems of the vehicle that are often analyzed, including the engine, transmission, anti-lock braking system, airbags, parking brake control module, passenger presence system, tire pressure monitor, and oil life. Additionally, the frequently selected section 412 also includes ADAS / driving assistance options, such as the parking assistance module, left and right object detection modules. In other examples, other systems can be included within the frequently selected section 412. For example, the user can program which systems are included within the frequently selected section 412. Alternatively, the frequently selected section 412 can display the systems that are often analyzed by the computing system 2.

[0216] The bottom toolbar 414 includes additional options that a user can select when analyzing the health of the vehicle. Thus, the user can use the additional options to browse the information captured and provided by the computing system 2.

[0217] Figure 15is another exemplary graphical user interface for displaying vehicle health records. GUI 420 represents an exemplary vehicle health record, including several elements that provide health and maintenance information about vehicle 8. Thus, one or more of these elements can be selected by the user when analyzing the health of vehicle 8. Additionally, a screenshot of GUI 420 can be printable and provided to the customer for viewing. Similar to the GUI 400 shown in Figure 14 , GUI 420 can have other arrangements, with more or fewer elements in each example. Additionally, computing system 2 can be configured to enable the user to customize the arrangement and available options of GUI 420. In some examples, GUI 400 and GUI 420 can be representatives of information related to the same vehicle health record.

[0218] As Figure 15 shown, GUI 420 includes vehicle information 422 and date and time 424 in a title format. Additionally, GUI 420 also includes recall and campaign options 426, a vehicle health graphic 428 configured to visually represent aspects of the health of vehicle 8, current mileage information 438, malfunction indicator lamp (MIL) information 440, code scan information 442, and maintenance interval information 444. In other examples, GUI 420 can convey other information using one or more selectable graphics, allowing for user-selectable controls.

[0219] Vehicle information 422 indicates "Vehicle Health Scan" to inform the reader of the information contained therein. As shown, vehicle information 422 can include a picture of vehicle 8. This picture can confirm to the user that the vehicle health record represents information about a specific vehicle. Additionally, vehicle information 422 also indicates the make, model, and year of the vehicle (e.g., 2016 Chevrolet Tahoe 5.3L). Vehicle information 422 can also indicate the vehicle identification number (VIN) and license plate number associated with vehicle 8. As shown, the title of GUI 420 also includes the date and time (e.g., January 29, 2019, 11:36 AM). The date and time can represent the generation time of the vehicle summary shown by GUI 420.

[0220] Recall and campaign options 426 represent selectable elements that can be selected by the user to show recalls and campaigns associated with vehicle 8. The link between recalls and campaigns can be based on a specific make, model, and year, a specific parts manufacturer, or other linkages. Thus, computing system 2 can obtain recall and campaign information from other sources (e.g., server 4). Thus, computing system 2 can provide current information about recalls and campaigns for vehicle 8.

[0221] A vehicle health graphic 428 is included within the GUI 420 to depict the current health of different vehicle systems. The vehicle health graphic 428 can be used to provide information related to the health condition in a clear and concise format. Thus, the health graphic can utilize charts, images, colors, and other features to indicate the health of various vehicle systems. As Figure 15 shown, the vehicle health graphic 428 in the GUI 420 includes a vehicle graphic 432 that serves as a guide for positioning other vehicle health graphics relative to the actual location of the vehicle systems. In this way, the health information determined during the analysis of PID values relative to predefined values can be communicated to the user in an easily understandable format. Although the vehicle graphic 432 is shown as a car, the vehicle graphic 432 can be customized within the various examples. For example, the vehicle graphic 432 can reflect the physical structure of the vehicle 8 associated with the vehicle health record.

[0222] In addition, the vehicle graphic 432 is also shown with additional graphics, such as four tire and brake graphics 430A, 430B, 430C, 430D, a battery graphic 434, and an oil graphic 436. The tire and brake graphics 430A - 430D respectively represent the current condition (i.e., health condition) of the tires and the corresponding brake pads. For example, the tire and brake graphic 430A includes an indication that the left front tire currently has 52 PSI and the left front brake has 15% of the brake pad remaining.

[0223] Code scan information 442 is an optional option that provides information about the number of vehicle systems analyzed (e.g., 12 systems have been analyzed), the number of codes present (e.g., 3 codes are present), and the number of readiness monitors completed (e.g., 4 out of 11). These codes can be selected to review further information about the vehicle. In some cases, the code scan information 442 can be displayed on the display interface.

[0224] Maintenance interval information 444 can communicate information related to maintenance involving mileage. Thus, the maintenance interval information 444 can indicate the current mileage of the vehicle's odometer and the recommended mileage for performing the next health code scan. In addition, the maintenance interval information 444 can indicate the remaining mileage before the next recommended mileage for performing a subsequent health code scan.

[0225] Figure 16is another exemplary graphical user interface for displaying vehicle health records. Similar to GUI 420, GUI 450 is shown with a header that includes service shop information 452, a vehicle graphic 454, vehicle information 456, and a date and time 458. Additionally, GUI 450 includes a snapshot 460 that includes various elements representing the health of vehicle 8. In particular, snapshot 460 includes maintenance interval information 462, a vehicle system report 464, a set of vehicle health graphics 466, and MIL status information 468. GUI 450 also includes page numbers 470 to convey the number of pages associated with the vehicle health record. Thus, GUI 450 can be part of a vehicle health record with one or more of the other GUIs described herein.

[0226] Figure 17 is another exemplary graphical user interface for displaying vehicle health records. GUI 480 represents another exemplary visual display that includes elements for displaying the health of vehicle 8. In particular, GUI 480 includes a vehicle system report header 482 that includes the corresponding time and date (e.g., January 29, 2019 11:36 a.m.). Additionally, GUI 480 displays code scan results 484 that indicate the number of codes present and code information related to one or more systems of vehicle 8. GUI 480 also shows a readiness monitor 486 with the number of tests and test information. GUI 480 further displays code scan results 488 and page numbers 490.

[0227] Figure 18 is another exemplary graphical user interface for displaying vehicle health records. GUI 500 represents another exemplary visual display that includes selectable elements configured to display the health of vehicle 8. As Figure 18 shown, GUI 500 includes code information 502, a header 504, vehicle health graphics 506, maintenance interval information 508, and recommended maintenance 510.

[0228] Code information 502 represents different codes that may have been obtained during a vehicle code scan by computing system 2. As shown, the code information can include different types of codes such as suspension control module codes, tire pressure monitor codes, assist step control module codes, telematics communication interface codes, transfer case codes, and OBD II codes. In Figure 18 the example shown, all of these codes are shown as zero "0", but can have other values during the vehicle health analysis process. Additionally, other codes can be listed within various embodiments.

[0229] The header 504 includes an indication of the maintenance of the vehicle and the date and time of the analysis (i.e., January 29, 2019, 11:36 AM). In this way, the user can understand that the information provided within the GUI 500 corresponds to the maintenance of the vehicle and the date and time when the vehicle health record is generated. Thus, the header 504 can convey other information within each example.

[0230] The vehicle health graph 506 includes graphs and information that convey the health of different vehicle systems analyzed during the health check. For example, the vehicle health graph 506 can represent information obtained from one or more VCPs, such as fluid levels, wear levels, and user-adjustable parameters (e.g., tire pressure). In particular, the vehicle health graph 506 is shown with health graphs that convey information about the front and rear brakes of the vehicle, the pressure of each tire, the battery, and the oil system. More specifically, the front brakes are shown to be in an area where they need to be replaced at the 15% level. Thus, when the GUI 500 uses 100 to represent brand-new brakes on a scale of 0 - 100, the 15% level may indicate that the front brakes need new brake pads or other forms of adjustment. Additionally, the graph can use a color (e.g., red) to indicate that these brakes require attention. In contrast, the rear brakes are shown to be in a health area at the 82% level. To convey that these brakes are currently in a non-maintenance required area (i.e., a health area), the GUI 500 can use a color (e.g., green) to represent the percentage of the brakes that are in a good range. Additionally, the health of the front and rear brakes is also indicated by circular graphs that convey the overall health of each brake group. The PSI of each tire is listed as a numerical value, and a color can be used to indicate whether that value is in a health area (e.g., green represents the PSI is in the optimal area, red represents the PSI is too high or too low). The battery voltage is listed, and the health of the oil system is conveyed using the oil life percentage (e.g., 71%) and whether the oil level is good or requires attention (e.g., oil level: OK). This health information of these vehicle systems can be represented in other graphs within each example.

[0231] The maintenance interval information 508 can indicate the current level of the vehicle odometer (e.g., 83,538 miles). The current level of the odometer can also be used to further display the next recommended mileage number at which the vehicle should be inspected again (e.g., 90,000 miles). Thus, the GUI 500 can be used to convey to the user a recommendation as to when the vehicle should undergo the next maintenance. Additionally, the recommended maintenance 510 includes a recommendation to review the health of the vehicle at the recommended mileage of the odometer. Each section can include boxes for the user or technician to mark as part of the recommendation or after completion. In Figure 18In the example shown, the recommended maintenance 510 may include one or more of an inspection portion, a replacement portion, a reset portion, and a rotation portion, as well as other possible examples. The inspection portion indicates that the engine oil and filter, as well as the EVAP emission control system, may need to be inspected at the 90,000 - mile mark. The replacement portion indicates that the air cleaner / filter element, the automatic transmission filter, the automatic transmission, the engine oil, the cabin air filter, and the transfer case oil may be due for replacement at the 90,000 - mile mark. The reset portion indicates that the oil life monitor may need to be reset at the 90,000 - mile mark. The rotation portion indicates that the tires may need to be rotated at the 90,000 - mile mark. In other examples, other vehicle systems and maintenance techniques may also be included.

[0232] IV. Conclusion

[0233] Exemplary embodiments have been described above. Those skilled in the art will understand that changes and modifications can be made to the described embodiments without departing from the true scope and spirit of the invention, which is defined by the claims. For example, although many exemplary embodiments are described with respect to vehicles and vehicle maintenance tools, those skilled in the art will understand that the vehicles mentioned here can be replaced by some other maintainable devices, such as, but not limited to, medical devices, electrical appliances (e.g., refrigerators or washing machines), or televisions. In such cases, the vehicle maintenance tools described herein can be more simply referred to as "maintenance tools".

[0234] It should be understood that the arrangements described herein and / or shown in the figures are for illustrative purposes only. Thus, those skilled in the art will understand that other arrangements and elements (e.g., machines, interfaces, functions, sequences, and / or groupings of functions) can be used in place of them, and some elements can be completely omitted depending on the desired results. Additionally, the various functions performed by one or more elements described and / or shown in the figures can be performed by a processor executing computer - readable program instructions or by a combination of hardware, firmware, and / or software. For the purposes of this specification, executing CRPI included in certain computer - readable media to perform certain functions may include executing all or part of the program instructions of these CRPI.

[0235] The term "data" in this specification may be used interchangeably with the term "information" or similar terms such as "content". The data described herein can be transmitted and received. As an example, any transmission of the data described herein can occur directly from a transmitting device (e.g., a transmitter) to a receiving device (e.g., a receiver). As another example, any transmission of any data described herein can occur indirectly from a transmitter to a receiver via one or more intermediate network devices such as access points, antennas, base stations, hubs, modems, repeaters, routers, switches, or some other network device. Any transmission of any data described herein can include transmitting the data over an air interface (e.g., using radio signals (i.e., wirelessly)). Any transmission of any data described herein can include transmitting data over a line (e.g., a single line, twisted pair, fiber optic cable, coaxial cable, harness, power line, printed circuit, CAT 5 cable, or CAT 6 cable). A line may be referred to as a "conductor" or other terms. As an example, the transmission of data over a conductor can be performed electrically or optically.

[0236] These data can represent various things such as objects and conditions. Objects and conditions can be mapped to a data structure (e.g., a table). A processor can refer to the data structure to determine the object or condition represented by the data. As an example, the data received by a processor can represent a calendar date. The processor can determine the calendar date by comparing the data with a data structure that defines calendar dates. As another example, the data received by a processor can represent a vehicle component. The processor can determine the type of vehicle component represented by the data by comparing the data with a structure that defines various vehicle components.

[0237] Although various aspects and embodiments are described herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for illustrative purposes and not for limitation, and the true scope is indicated by the scope of the claims and the full scope of all equivalents given by those claims. It should also be understood that the terms used herein are for the purpose of describing particular embodiments and are not limiting.

[0238] In this description, the articles "a", "an", and "the" are used to introduce elements and / or functions of exemplary embodiments. The intention of using these articles is that there is one or more of the elements and / or functions being introduced. The purpose of using the conjunction "or" in a list of at least two terms is to indicate any one of the listed terms or any combination of two or more of the listed terms.

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

[0240] Accordingly, an implementation of the present disclosure may relate to one of the following exemplary implementations (EEE) listed.

[0241] EEE 1 is a method that includes receiving vehicle diagnostic information from a vehicle at a computing system, where the vehicle diagnostic information includes one or more sets of parameters corresponding to a parameter identifier (PID); identifying a first set of parameters corresponding to the PID that represents the state of a particular system of the vehicle; using the first set of parameters to determine a current value of the PID; comparing the current value of the PID with a predetermined value; determining the health status of the particular system of the vehicle such that the health status reflects the difference between the current value of the PID and the predetermined value; and displaying, by the computing system at a graphical interface, a vehicle health record representing the health status of the particular system of the vehicle.

[0242] EEE 2 is the method of EEE 1, where receiving vehicle diagnostic information from the vehicle includes: receiving one or more diagnostic trouble codes from the vehicle; and where identifying a first set of parameters corresponding to the PID that represents the state of a particular system of the vehicle includes: identifying the first set of parameters corresponding to the PID based on the one or more diagnostic trouble codes from the vehicle.

[0243] EEE 3 is a method of any one of EEE 1 and 2, wherein a predetermined value of the PID is based on the make and model of the vehicle.

[0244] EEE 4 is a method of any one of EEE 1 to 3, wherein a predetermined value of the PID is based on the previously determined health status of a particular system.

[0245] EEE 5 is a method of any one of EEE 1 to 4, wherein a predetermined value of the PID is configured during the most recent service of a particular system.

[0246] EEE 6 is a method of any one of EEE 1 to 5, wherein receiving vehicle diagnostic information from the vehicle is performed in response to the vehicle navigating at a particular altitude range; and wherein a predetermined value of the PID is based on the particular altitude range.

[0247] EEE 7 is a method of EEE 6, wherein displaying a vehicle health record representing the health status of a particular system of the vehicle includes: displaying a vehicle health record representing the health status of a particular system of the vehicle and indicating the particular altitude range.

[0248] EEE 8 is a method of any one of EEE 1 to 7, wherein a particular system of the vehicle corresponds to the engine of the vehicle; and wherein a predetermined value of the PID is based on the current mileage of the vehicle.

[0249] EEE 9 is a method of any one of EEE 1 to 8, wherein a particular system of the vehicle corresponds to the oil system of the vehicle; and wherein a predetermined value of the PID is based on an indicator of the most recent oil change of the vehicle's oil system and the number of miles the vehicle has traveled since the most recent oil change.

[0250] EEE 10 is a method of any one of EEE 1 to 9, wherein determining the health status of a particular system of the vehicle so that the health status reflects the difference between the current value and the predetermined value of the PID includes: determining the health status of a particular system of the vehicle so that the health status represents the percentage difference between the current value and the predetermined value of the PID.

[0251] EEE 11 is a method of EEE 10, wherein displaying a vehicle health record representing the health status of a particular system of the vehicle includes: displaying the health status of the particular system in a graph that indicates the percentage difference between the current value and the predetermined value of the PID, wherein the graph includes an indication of the particular system.

[0252] EEE 12 is a method of any one of EEE 1 to 11, wherein determining the health status of a particular system of a vehicle so that the health status reflects the difference between the current value and the predetermined value of the PID includes: determining the health status of a particular system of the vehicle so that the health status represents the numerical difference between the current value and the predetermined value of the PID.

[0253] EEE 13 is a method of EEE 12, wherein displaying a vehicle health status record representing the health status of a particular system of the vehicle includes: displaying the health status of the particular system in a graph that indicates the numerical difference between the current value and the predetermined value of the PID, wherein the graph includes an indication of the particular system.

[0254] EEE 14 is a method of any one of EEE 1 to 13, further including: based on the comparison, determining that the current value of the PID is higher than the predetermined value of the PID, wherein the predetermined value of the PID represents the lower bound threshold of the PID; and wherein displaying a vehicle health status record representing the health status of a particular system of the vehicle includes: displaying an indication that conveys that the particular system is within the desired health status range.

[0255] EEE 15 is a method of any one of EEE 1 to 14, further including: based on the comparison, determining that the current value of the PID is lower than the predetermined value of the PID, wherein the predetermined value of the PID represents the lower bound threshold of the PID; and wherein, displaying a vehicle health status record representing the health status of a particular system of the vehicle includes: displaying the vehicle health status record and issuing an alarm indicating that the particular system requires maintenance.

[0256] EEE 16 is a method of any one of EEE 1 to 15, further including: based on the comparison, determining that the current value of the PID is lower than the predetermined value of the PID, wherein the predetermined value of the PID represents the upper bound threshold of the PID; and wherein, displaying a vehicle health status record representing the health status of a particular system of the vehicle includes: displaying an indication that conveys that the particular system is within the desired health status range.

[0257] EEE 17 is a method of any one of EEE 1 to 16, further including: based on the comparison, determining that the current value of the PID is higher than the predetermined value of the PID, wherein the predetermined value of the PID represents the upper bound threshold of the PID; and wherein, displaying a vehicle health status record representing the health status of a particular system of the vehicle includes: displaying the vehicle health status record and issuing an alarm indicating that the particular system requires maintenance.

[0258] EEE 18 is a method according to any one of 1 to 17, further comprising: identifying a second set of parameters corresponding to a second PID representative of the state of a particular system of a vehicle; using the second set of parameters to determine a second current value of the second PID; and making a second comparison between the second current value of the second PID and a second predetermined value.

[0259] EEE 19 is the method of EEE 18, wherein determining the health of a particular system of a vehicle such that the health reflects the difference between the current value and the predetermined value of the PID is further based on the second comparison between the second current value of the second PID and the second predetermined value.

[0260] EEE 20 is a method according to any one of 1 to 19, further comprising: executing a functional test script prepared for a vehicle, wherein executing the functional test script includes requesting the vehicle to perform one or more functional tests, and requesting PID parameters from the vehicle in a predefined order related to requesting the vehicle to perform one or more functional tests, and wherein at least a portion of the one or more sets of parameters is received in response to requesting PID parameters from the vehicle in the predefined order.

[0261] EEE 21 is the method of any one of EEE 20, wherein at least that portion of the one or more sets of parameters includes reactive PIDs indicating whether the one or more functional tests passed or failed, and wherein the health of a particular system of the vehicle further reflects whether a particular functional test related to the particular system passed or failed.

[0262] EEE 22 is a system, comprising: a display interface and a computer device configured to execute a set of functions, the set of functions including a method according to any one of EEE 1 to EEE 21.

[0263] EEE 23 is a computer-readable medium storing program instructions that, when executed by one or more processors, cause a set of functions to be executed, the set of functions including a method according to any one of EEE 1 to EEE 22.

Claims

1. A method, comprising: Receiving vehicle diagnostic information from an electronic control unit within the vehicle at a computing system connected to the vehicle using a wired or wireless connection; Identifying a parameter corresponding to an on-vehicle diagnostic PID, wherein the on-vehicle diagnostic PID corresponds to a specific system of the vehicle; Determining a difference between a current value of the parameter and a predetermined value corresponding to the on-vehicle diagnostic PID, wherein the current value of the parameter represents the state of the specific system, and wherein the difference represents the health condition of the specific system; Obtaining, at the computing system and from a remote computing system, an existing vehicle health record of the vehicle, wherein the existing vehicle health record represents information specific to the vehicle; Updating the existing vehicle health record according to the health condition of the specific system of the vehicle; Displaying, via the computing system, on a display interface, the updated existing vehicle health record representing the health condition of the specific system of the vehicle.

2. The method according to claim 1, wherein, Receiving vehicle diagnostic information from the electronic control unit within the vehicle includes: Receiving a vehicle diagnosis from the electronic control unit of an electric vehicle.

3. The method according to claim 2, wherein, The specific system is a battery system; And Wherein, identifying the parameter corresponding to the on-vehicle diagnostic PID includes: Identifying the parameter representing the existing voltage of a battery corresponding to the battery system.

4. The method according to claim 3, wherein, Determining the difference between the current value of the parameter and the predetermined value includes: Comparing the existing voltage of the battery corresponding to the battery system with a voltage value range, wherein the health condition of the battery depends on the position of the existing voltage of the battery within the voltage value range.

5. The method according to claim 4, wherein, Displaying the updated existing vehicle health record includes: Displaying the existing voltage of the battery and indicating whether the existing voltage of the battery is suitable for the operation of the vehicle.

6. The method according to claim 1, wherein Displaying the updated existing vehicle health record includes: Displaying a graph based on the parameter corresponding to the on-vehicle diagnostic PID, wherein the graph includes a graph view slider for modifying the view of the graph.

7. The method according to claim 1, further comprising: Receiving, from a remote computing system, the predetermined value corresponding to the on-vehicle diagnostic PID, wherein the remote computing is configured to determine a trend based on vehicle health records of multiple vehicles and use the trend to generate the predetermined value corresponding to the on-vehicle diagnostic PID.

8. The method according to claim 7, wherein The trend depends on the make and model of the multiple vehicles.

9. The method according to claim 1, wherein Displaying the updated existing vehicle health record further includes: Displaying the updated existing vehicle health record and a maintenance alert for the specific system.

10. The method according to claim 1, further comprising: Determining the predetermined value corresponding to the on-vehicle diagnostic PID based on the make and model of the vehicle and the previous health condition of the specific system.

11. The method according to claim 1, wherein, Further comprising: Determining the predetermined value corresponding to the on-vehicle diagnostic PID based on the distance represented by the odometer of the vehicle.

12. The method according to claim 1, wherein, Determining the difference between the current value of the parameter and the predetermined value includes: Determine the percentage difference between the current value of the parameter and the predetermined value corresponding to the on-vehicle diagnostic PID.

13. The method according to claim 1, wherein Determining the difference between the current value of the parameter and the predetermined value includes: Determine the numerical difference between the current value of the parameter and the predetermined value corresponding to the on-vehicle diagnostic PID.

14. The method according to claim 1, further comprising: Transmit the updated existing vehicle health record to the remote computing system, wherein the remote computing system stores the updated existing vehicle health record in response to receiving the updated existing vehicle health record.

15. A system, comprising: A display interface; A computing device configured to: Receive vehicle diagnostic information from an electronic control unit within the vehicle, Identify a parameter corresponding to an on-vehicle diagnostic PID based on the vehicle diagnostic information, wherein the on-vehicle diagnostic PID corresponds to a specific system of the vehicle; Determine the difference between the current value of the parameter and the predetermined value corresponding to the on-vehicle diagnostic PID, wherein the current value of the parameter represents the state of the specific system, and wherein the difference represents the health condition of the specific system; and Obtain an existing vehicle health record of the vehicle from the remote computing system, wherein the existing vehicle health record represents information specific to the vehicle; Update the existing vehicle health record based on the health condition of the specific system of the vehicle; Display, via the display interface, the updated existing vehicle health record representing the health condition of the specific system of the vehicle.

16. The system according to claim 15, wherein, The vehicle is an electric vehicle.

17. The system according to claim 16, wherein, The specific system of the vehicle is a battery system.

18. The system according to claim 15, wherein The predetermined value corresponding to the on-vehicle diagnostic PID is based on the make and model of the vehicle and the previous health condition of the specific system.

19. The system according to claim 15, wherein, The predetermined value includes: An upper threshold and a lower threshold.

20. A non-transitory computer-readable medium storing instructions executable by one or more processors to cause a computing system to perform functions including the following: Receive vehicle diagnostic information from an electronic control unit within the vehicle, Identify a parameter corresponding to an on-vehicle diagnostic PID based on the vehicle diagnostic information, wherein the on-vehicle diagnostic PID corresponds to a specific system of the vehicle; Determine the difference between the current value of the parameter and a predetermined value corresponding to the on-board diagnostic PID, wherein, The current value of the parameter represents the state of the specific system, and wherein the difference represents the health condition of the specific system; Obtain the existing vehicle health record of the vehicle from a remote computing system, wherein the existing vehicle health record represents information specific to the vehicle; Update the existing vehicle health record based on the health condition of the specific system of the vehicle; Display, via a display interface, the updated existing vehicle health record representing the health condition of the specific system of the vehicle.

Images