Highly efficient diagnostic data monitoring for connected vehicles

Abstract

This disclosure relates to efficient diagnostic data monitoring for connected vehicles. A system includes a memory and a processor, the memory being configured to store diagnostic data, defining regularity triggering criteria for periodic transmission of the diagnostic data, and defining priority triggering criteria for irregular transmission of the diagnostic data, the processor being configured to: periodically send diagnostic data accumulated since previous regular transmissions to a remote server according to the regularity triggering criteria, and send irregular diagnostic data that satisfies the priority triggering criteria to the remote server.

Description

Technical Field

[0001] Several aspects of this disclosure generally relate to efficient monitoring of diagnostic data for connected vehicles. Background Technology

[0002] Motor vehicle diagnostic data (such as Diagnostic Trouble Codes (DTCs)) forms dense, information-rich messages. This diagnostic data is designed to allow vehicle controllers to indicate system malfunctions and / or repair needs. Although a DTC for the ignition cycle in which the malfunction occurred is in an "active" or "confirmed" state, most DTCs for multiple ignition cycles subsequently revert to a "historical" or "aged" state, ensuring that evidence of the malfunction remains available even when a technician inspects the vehicle weeks after the incident. Summary of the Invention

[0003] In one or more illustrative embodiments, a system includes a memory and a processor, the memory being configured to store diagnostic data, defining a cadence triggering criterion for periodic transmission of the diagnostic data, and defining a priority triggering criterion for irregular transmission of the diagnostic data, the processor being configured to: periodically send diagnostic data accumulated since previous cadence transmissions to a remote server according to the cadence triggering criterion, and send irregular diagnostic data that satisfies the priority triggering criterion to the remote server.

[0004] In one or more illustrative embodiments, a method includes: storing diagnostic fault code (DTC) data received from other controllers via a vehicle bus to a telematics controller; transmitting DTC data that meets a priority triggering criterion from the telematics controller to a remote server; deleting DTC data transmitted according to the priority triggering criterion; periodically transmitting all stored diagnostic data from the telematics controller to the remote server according to a regularity triggering criterion; and deleting DTC data transmitted according to the regularity triggering criterion.

[0005] In one or more illustrative embodiments, a non-transitory computer-readable medium includes instructions that, when executed by a processor of a telematics controller, cause the telematics controller to perform the following operations: store diagnostic fault code (DTC) data received from other controllers via a vehicle bus; transmit DTC data satisfying a priority triggering criterion from the telematics controller to a remote server; delete DTC data transmitted according to the priority triggering criterion; periodically transmit all stored DTC data from the telematics controller to a remote server according to a regularity triggering criterion; and delete DTC data transmitted according to the regularity triggering criterion.

[0006] According to one embodiment of the invention, the non-transitory computer-readable medium further includes instructions that cause the telematics controller to perform the following operation: setting the priority triggering criterion to send diagnostic data indicating the activation of a DTC.

[0007] According to one embodiment of the invention, the non-transitory computer-readable medium further includes instructions that cause the telematics controller to perform the following operation: setting the priority triggering criterion to send diagnostic data indicating a pending DTC. Attached Figure Description

[0008] Figure 1 An example system for achieving efficient monitoring of diagnostic data in connected vehicles is shown;

[0009] Figure 2 An example of efficient diagnostic data monitoring for connected vehicles is shown. Detailed Implementation

[0010] Detailed embodiments of the invention are disclosed herein as needed; however, it will be understood that the disclosed embodiments are merely examples of the invention and may be implemented in various forms and alternative forms. The drawings are not necessarily drawn to scale; some features may be exaggerated or minimized to show details of particular components. Therefore, the specific structural and functional details disclosed herein should not be construed as limiting, but rather as a representative basis for teaching those skilled in the art to utilize the invention in various ways.

[0011] The DTC standard was created before the widespread availability of connected vehicles. Today, with connected vehicles, DTC data can be collected and transmitted with every ignition cycle, or even multiple times per ignition cycle. This capability creates both opportunities and challenges. If OEMs (Original Equipment Manufacturers) or third-party connectivity providers design their systems to collect and transmit DTCs with every ignition cycle, the amount of data collected can become enormous and repetitive. Alternatively, if a connectivity system is designed to collect only “active” / “confirmed” DTCs, important information (e.g., historical DTCs) may be lost. Therefore, some of the advantages of ubiquitous connectivity may be lost because the “noise” in the data from frequently collected ’historical’ DTCs can reduce the effectiveness of early warnings / quality signals provided by low-frequency “active” / “confirmed” DTC events.

[0012] A highly efficient connected vehicle diagnostic data monitoring system can be used to address the problem of collecting too much or too little data through hybrid methods. The method establishes the use of onboard logic to periodically collect DTC data, enabling efficient data transmission according to two schemes. In the first scheme (e.g., a time-based scheme), regular DTC transmissions are defined based on time or the number of ignition cycles. In an example, the time-based scheme may include data transmission at each predefined time interval (e.g., 30 days, 40 ignition cycles, etc.), regardless of the state of the collected DTCs. In the second scheme (e.g., a trigger-based scheme), one or more triggers for data transmission can be defined based on the DTC state. In an example, the trigger-based scheme may include logic that triggers the transmission of DTCs to be sent to a remote server in response to the collection of an "active" or "acknowledged" DTC. This also allows for the establishment of triggers for other DTC states, such as the transmission of DTC data in the case of a DTC in a "pending" state.

[0013] The two collaborative approaches achieve two objectives. First, regular data transmission is needed to obtain consistent, recurring data for analytical purposes, and to monitor the development of DTCs in a "historical" / "aging" state. Second, data transmission triggered by DTC status (such as "active" / "confirmed") allows the system to be aware of all "active" DTCs in the ignition cycle where the fault is confirmed.

[0014] Because "active" DTCs are relatively few, and "active" DTCs are the most important DTC messages transmitted from connected vehicles, both schemes reduce the data to only the most valuable diagnostic information. Furthermore, by providing low-frequency routine DTC data collection of "historical" DTCs, the amount of data transmitted from connected vehicles is reduced. Other aspects of this disclosure are discussed in further detail below.

[0015] Figure 1 An example system 100 for efficient monitoring of diagnostic data in a connected vehicle is shown. As shown, vehicle 102 includes multiple vehicle controllers 104 communicating via one or more vehicle buses 106. System 100 also includes a vehicle data server 122 configured to store diagnostic data 120 received from various vehicles 102. Vehicle 102 also includes a telematics control unit (TCU) 108 configured to send diagnostic data 120, including diagnostic information, to vehicle data server 122. TCU 108 can use a diagnostic application 118 installed on TCU 108 to send regular diagnostic data 120, and to send triggered diagnostic data 120 in response to a trigger criterion 124 being met. It should be noted that system 100 is merely an example, and other arrangements or combinations of elements may be used.

[0016] Vehicle 102 may include various types of motor vehicles (CUVs, SUVs, trucks, RVs), boats, aircraft, or other mobile machinery used for transporting people or goods. In many cases, vehicle 102 may be powered by an internal combustion engine. As another feasible option, vehicle 102 may be a hybrid electric vehicle (HEV) powered by both an internal combustion engine and one or more electric motors, such as a series hybrid electric vehicle (SHEV), a parallel hybrid electric vehicle (PHEV), or a parallel / series hybrid electric vehicle (PSHEV). Because the type and configuration of vehicle 102 may differ, the performance of vehicle 102 may vary accordingly. As some other feasible options, vehicle 102 may have different performance characteristics regarding passenger capacity, towing capacity and storage capacity. For ownership, inventory, and other purposes, vehicle 102 may be associated with a unique identifier (such as a VIN).

[0017] Vehicle 102 may include multiple controllers 104 configured to perform and manage various functions of vehicle 102 under the drive of vehicle battery and / or powertrain. As depicted, example vehicle controllers 104 are represented as discrete controllers 104-A to 104-G. However, vehicle controllers 104 may share physical hardware, firmware, and / or software, such that functions from multiple controllers 104 can be integrated into a single controller 104, and that functions of various such controllers 104 can be distributed across multiple controllers 104.

[0018] As examples of some non-limiting vehicle controllers 104: Powertrain controller 104-A may be configured to provide control over engine operating components (e.g., idle speed control components, fuel delivery components, emission control components, etc.) and to monitor the status of such engine operating components (e.g., the status of engine codes); Body controller 104-B may be configured to manage various power control functions, such as exterior lighting, interior lighting, keyless entry, remote start, and access point status verification (e.g., the closing status of the hood, doors, and / or trunk of vehicle 102); Radio transceiver controller 104-C may be configured to communicate with a remote key, mobile device, or vehicle 102. The vehicle 102 communicates with other local devices; the entertainment controller 104-D can be configured to support voice commands and Bluetooth interfaces with the driver and driver-carried devices; the climate control management controller 104-E can be configured to provide control over heating and cooling system components (e.g., compressor clutch, blower fan, temperature sensor, etc.); the global positioning system (GPS) controller 104-F can be configured to provide vehicle location information; and the human-machine interface (HMI) controller 104-G can be configured to receive user input via various buttons or other controls, and to provide the driver with vehicle status information (such as fuel level information, engine operating temperature information, and the current location of vehicle 102).

[0019] Vehicle bus 106 may include a variety of communication methods available between vehicle ECUs 104 and between TCU 108 and vehicle ECUs 104. As some non-limiting examples, vehicle bus 106 may include one or more of a vehicle controller area network (CAN), Ethernet, and media-oriented system transport (MOST) network. Other aspects of the layout and number of vehicle buses 106 are discussed in further detail below.

[0020] TCU 108 may include network hardware configured to facilitate communication between vehicle ECUs 104 and with other devices in system 100. For example, TCU 108 may include or otherwise access cellular modem 110, configured to facilitate communication with wide area network 112. As some non-limiting examples, wide area network 112 may include one or more interconnected communication networks, such as the Internet, cable television distribution networks, satellite link networks, local area networks, and telephone networks. As another example, TCU 108 may utilize one or more of Bluetooth, Wi-Fi, and wired USB network connections to facilitate communication with wide area network 112 via a user's mobile device.

[0021] TCU 108 may also include various types of computing devices for supporting the execution of the functions of TCU 108 described herein. In an example, TCU 108 may include one or more processors 114 and a storage medium 116, the one or more processors 114 being configured to execute computer instructions, on which computer-executable instructions and / or data may be stored. A computer-readable storage medium (also referred to as a processor-readable medium or memory 116) includes any non-transitory (e.g., tangible) medium involved in providing data (e.g., instructions) that can be read by a computer (e.g., by a processor). Generally, processor 114 receives instructions and / or data from, for example, memory 116 to transfer to memory, and executes the instructions using the data, thereby performing one or more processes, including one or more of the processes described herein. Computer executable instructions can be compiled or interpreted by computer programs created using various programming languages ​​and / or technologies, including but not limited to one or a combination of Java, C, C++, C#, Fortran, Pascal, Visual Basic, Python, JavaScript, Perl, PL / SQL, etc.

[0022] TCU 108 may be configured to include one or more interfaces through which vehicle information can be sent and received. In an example, TCU 108 may be configured to facilitate the collection of DTC data and / or other vehicle information from vehicle ECUs 104 connected to one or more vehicle buses 106. The information collected in this way may be referred to as diagnostic data 120. TCU 108 may store the collected diagnostic data 120 in the memory 116 of TCU 108, or in other examples, in other memories communicating with TCU 108. As some non-limiting examples, the vehicle information acquired by TCU 108 may include: accelerator pedal position, steering wheel angle, vehicle speed, vehicle location (e.g., GPS coordinates, etc.), vehicle unique identifier (e.g., VIN), engine revolutions per minute (RPM), and vehicle HMI information (such as steering wheel button press information). Therefore, diagnostic data 120 may include the collected DTC information and / or other vehicle information stored in the memory 116 of TCU 108.

[0023] Diagnostic application 118 may be an application included in memory 116 of TCU 108. Diagnostic application 118 may include instructions that, when executed by processor 114 of TCU 108, cause TCU 108 to periodically collect information (e.g., including DTC information) of diagnostic data 120 from controller 104, store the information for transmission, and transmit the diagnostic data 120 to vehicle data server 122 via wide area network 112.

[0024] Vehicle data server 122 may include various types of computing devices, such as computer workstations, servers, desktop computers, virtual server instances executed by a host server, or other computing systems and / or devices. Similar to TCU 108, vehicle data server 122 typically includes memory on which computer-executable instructions may be stored, which can be executed by one or more processors (not shown for simplicity). These instructions and other data may be stored using various computer-readable media. In this example, vehicle data server 122 may be configured to store diagnostic data 120 received from TCU 108 of vehicle 102 via network 112.

[0025] The diagnostic application 118 may also include instructions for performing functions in response to trigger criteria 124. Trigger criteria 124 may include one or more conditions that, when met, cause at least a subset of diagnostic data 120 to be transmitted. Trigger criteria 124 may also include information indicating which collected diagnostic data 120 should be transmitted to the vehicle data server 122 based on the satisfaction of the conditions of trigger criteria 124.

[0026] Triggering criteria 124 may include regularity triggering criteria 124. Regularity triggering criteria 124 may include conditions that cause a majority of the collected diagnostic data 124 to be transmitted. Regularity triggering criteria 124 may include a timing scheme for determining data transmission at each predefined time interval (e.g., 30 days). Additionally or optionally, regularity triggering criteria 124 may include a timing scheme for determining data transmission after a specified number of occurrences of a given event (e.g., 40 ignition cycles).

[0027] Triggering criterion 124 may also include priority triggering criterion 124. Priority triggering criterion 124 may include a condition that causes data to be transmitted. For example, one or more triggers of triggering criterion 124 may be defined as transmitting data based on DTC status. As one possible approach, triggering criterion 124 may include a transmission trigger in response to the collection of an "active" or "acknowledged" DTC. As another possible approach, triggering criterion 124 may include a transmission trigger in response to other DTC statuses, such as the transmission of DTC data in the case of a DTC in a "pending" status.

[0028] The vehicle data server 122 can also be configured to store an analysis service 126, which is configured to analyze stored diagnostic data 120 provided from the vehicle 102. The analysis service 126 may include instructions that, when executed by the processor of the vehicle data server 122, cause the vehicle data server 122 to examine the diagnostic data 120 and provide statistics on common DTCs or other conditions.

[0029] Variations of system 100 are possible. In the example, instead of using TCU 108 to provide a remote connection to vehicle data server 122, or in addition to using TCU 108 to provide a remote connection to vehicle data server 122, TCU 108 may utilize the communication capabilities of a modem of a user's mobile device paired with infotainment controller 104-D to perform communication via wide area network 112.

[0030] Figure 2 An example processing 200 for efficient monitoring of diagnostic data in a connected vehicle is shown. In this example, processing 200 can be performed via a diagnostic application 118 running by the TCU 108.

[0031] In operation 202, TCU 108 collects diagnostic data 120. In one example, TCU 108 collects DTC data and / or other vehicle information from vehicle ECUs 104 connected to one or more vehicle buses 106. In another example, TCU 108 collects additional vehicle information via one or more vehicle buses 106.

[0032] In operation 204, TCU 108 determines whether a regular transmission has expired. In this example, TCU 108 may determine whether a regularity trigger criterion 124 has been met. Regularity trigger criterion 124 may include determining a timing scheme for data transmission at each predefined time interval (e.g., 30 days). Additionally or optionally, regularity trigger criterion 124 may include determining a timing scheme for data transmission after a specified number of occurrences of a given event (e.g., 40 ignition cycles). If regularity trigger criterion 124 has been met, control proceeds to operation 206. Otherwise, control proceeds to operation 208.

[0033] In operation 206, TCU 108 sends the history of the collected diagnostic data 120. In this example, TCU 108 sends the collected diagnostic data 120 to vehicle data server 122, regardless of the status of the collected DTCs. For example, diagnostic data 120 may include DTCs that are “active” / “confirmed” and “historical” DTCs. After operation 206, control returns to operation 202.

[0034] In operation 208, TCU 108 determines whether a transmission needs to be triggered. In this example, TCU 108 may determine whether priority triggering criterion 124 has been met. For example, one or more triggers of triggering criterion 124 may be defined as data transmission based on DTC status. As one possible approach, triggering criterion 124 may include a transmission trigger in response to the collection of an "active" or "acknowledged" DTC. As another possible approach, triggering criterion 124 may include a transmission trigger in response to other DTC statuses, such as the transmission of DTC data in the case of a DTC in a "pending" state. If priority triggering criterion 124 has been met, control proceeds to operation 210. Otherwise, control returns to operation 202.

[0035] In operation 210, TCU 108 sends a message triggering a transmission. In this example, TCU 108 sends one or more DTCs that were triggered in operation 208 for transmission to vehicle data server 122. In other examples, TCU 108 may additionally or optionally send further information to vehicle data server 122. For example, TCU 108 may further send additional stored diagnostic data 120 collected since previous regular transmissions to vehicle data server 122. After operation 210, control returns to operation 202.

[0036] The computing devices described herein (such as controller 104, TCU 108, and vehicle data server 122) typically include computer-executable instructions, which can be executed by one or more computing devices (such as those listed above). The computer-executable instructions (such as the instructions for diagnostic application 118) can be compiled or interpreted by computer programs created using various programming languages ​​and / or technologies, including but not limited to Java. TM The processor is a combination of one or more of the following: C, C++, C#, Visual Basic, JavaScript, Python, Perl, PL / SQL, etc. Generally, a processor (e.g., a microprocessor) receives instructions from, for example, memory, a computer-readable medium, etc., and executes those instructions to perform one or more processes, including the one or more processes described herein. Various computer-readable media can be used to store and transmit such instructions and other data.

[0037] Regarding the processes, systems, methods, and teachings described herein, it should be understood that although the steps of the processes, etc., are described as occurring in a specific ordered sequence, these processes can also be implemented using the described steps performed in an order other than that described herein. It should also be understood that specific steps may be performed simultaneously, other steps may be added, or specific steps described herein may be omitted. In other words, the description of the processes provided herein is for illustrative purposes and should not be construed as limiting the claims in any way.

[0038] Therefore, it will be understood that the above description is intended to be illustrative and not limiting. Many embodiments and applications will become apparent when reading the above description, in addition to the examples provided. The scope should not be determined by reference to the above description, but rather by reference to the claims and the full scope of their equivalents. It is anticipated and expected that future developments will occur in the art discussed in this disclosure, and that the disclosed systems and methods will be incorporated into future embodiments of this art. In summary, it should be understood that applications are capable of modification and variation.

[0039] Unless expressly indicated otherwise herein, all terms used in the claims are intended to be given the broadest reasonable interpretation and their general meaning as understood by one of ordinary skill in the art to which the technology described herein pertains. In particular, unless the claims set forth an express limitation to the contrary, the use of singular articles (such as “a,” “the,” “the,” etc.) shall be understood to refer to one or more of the indicated elements.

[0040] An abstract of this disclosure is provided to enable the reader to quickly determine the essence of the technical disclosure. It should be understood that the abstract is submitted and is not intended to interpret or limit the scope or meaning of the claims. Furthermore, as can be seen from the foregoing detailed description, various features are combined in various embodiments for the purpose of simplifying this disclosure. The method of this disclosure is not to be construed as reflecting an intention that the claimed embodiments require more features than expressly recited in each claim. Rather, as reflected in the claims, the subject matter of the invention lies in fewer than all features of a single disclosed embodiment. Therefore, the claims are thus incorporated into the detailed description, each claim being a separately claimed subject matter.

[0041] While exemplary embodiments have been described above, they do not imply that these embodiments describe all possible forms of the invention. Rather, the terms used in this specification are descriptive rather than restrictive, and it should be understood that various changes may be made without departing from the spirit and scope of the invention. Furthermore, features of various embodiments may be combined to form further embodiments of the invention.

Claims

1. A system for monitoring diagnostic data, comprising: The vehicle memory is configured to store diagnostic data, define a regular triggering criterion for the periodic transmission of the diagnostic data, and define a priority triggering criterion for the irregular transmission of the diagnostic data. The vehicle processor is configured to perform the following operations sequentially: Irregular diagnostic data that meets the aforementioned priority triggering criteria will be sent to a remote server. The irregular diagnostic data is deleted from the vehicle's memory to avoid retransmitting it in the next regular transmission. Diagnostic data accumulated since previous regular transmissions is periodically sent to a remote server according to a regular triggering criterion. Delete diagnostic data accumulated since previous regular transmissions.

2. The system according to claim 1, wherein, The regularity triggering criterion specifies that diagnostic data should be sent periodically when a predefined number of vehicle ignition cycles are completed.

3. The system according to claim 1, wherein, The regularity triggering criterion specifies that diagnostic data should be sent periodically after a predefined number of days.

4. The system according to claim 1, wherein, The priority triggering criterion specifies that diagnostic data of diagnostic codes indicating activation from the vehicle memory should be sent as the irregular diagnostic data.

5. The system according to claim 1, wherein, The priority triggering criterion specifies that diagnostic data indicating pending diagnostic codes from the vehicle memory should be sent as the irregular diagnostic data.

6. A method for monitoring diagnostic data, comprising: The diagnostic fault codes (DTCs) received from other controllers are stored in the telematics controller via the vehicle bus. DTC data that meets the priority triggering criteria from the stored DTC data is sent from the remote information processing controller to the remote server; Delete the DTC data that meets the priority triggering criteria from the stored DTC data to avoid retransmitting the DTC data that meets the priority triggering criteria according to the regularity triggering criteria; According to the regular triggering criteria, all stored diagnostic data is periodically sent from the remote information processing controller to the remote server; Delete the stored DTC data sent according to the aforementioned regularity triggering criteria.

7. The method according to claim 6, further comprising: The regular triggering criteria are set to periodically send the diagnostic data when a predefined number of vehicle ignition cycles are completed.

8. The method according to claim 6, further comprising: The regular triggering criteria are set to periodically send the diagnostic data after a predefined number of days.

9. The method according to claim 6, further comprising: The priority triggering criteria are set to send diagnostic data indicating the activation of DTCs.

10. The method of claim 6, further comprising: The priority triggering criteria are set to send diagnostic data indicating pending DTCs.

11. A non-transitory computer-readable medium comprising instructions that, when executed by a processor of a telematics controller, cause the telematics controller to perform the following operations: Stores diagnostic fault code (DTC) data received from other controllers via the vehicle bus; DTC data that meets the priority triggering criteria from the stored DTC data is sent from the remote information processing controller to the remote server; Delete the DTC data that meets the priority triggering criteria from the stored DTC data to avoid retransmitting the DTC data that meets the priority triggering criteria according to the regularity triggering criteria; According to a regular triggering criterion, all stored DTC data is periodically sent from the remote information processing controller to the remote server; Delete the stored DTC data sent according to the aforementioned regularity triggering criteria.

12. The non-transitory computer-readable medium of claim 11, further comprising instructions that cause the telematics controller to perform the following operation: setting the regularity triggering criterion to send diagnostic data upon completion of a predefined number of vehicle ignition cycles.

13. The non-transitory computer-readable medium of claim 11, further comprising instructions that cause the telematics controller to perform the following operation: setting the regularity triggering criterion to send diagnostic data after a predefined number of days.

14. The non-transitory computer-readable medium of claim 11, further comprising instructions that cause the telematics controller to perform the following operation: setting the priority triggering criteria to send diagnostic data indicating an activated DTC.

15. The non-transitory computer-readable medium of claim 11, further comprising instructions that cause the telematics controller to perform the following operation: setting the priority triggering criteria to send diagnostic data indicating a pending DTC.

Images