Cloud-based connectivity energy management system

Abstract

System, comprehensive: a memory configured to manage diagnostic data, cadence trigger criteria that define a periodic transmission of the diagnostic data, and priority trigger criteria that define an out-of-cadence transmission of the diagnostic data; and a processor that is programmed to To periodically send diagnostic data that has accumulated since a previous cadence transmission to a remote server based on the cadence trigger criteria, and To send out-of-range diagnostic data that meets the priority trigger criteria to the remote server, and to clear the out-of-cadence diagnostic data from memory in response to the sending of the out-of-cadence diagnostic data, in order to avoid re-sending the out-of-cadence diagnostic data in a subsequent cadence transmission.

Description

TECHNICAL AREA

[0001] Aspects of the revelation generally concern a cloud-based energy management system for connectivity functions. GENERAL STATE OF THE ART

[0002] Diagnostic data from a car, such as diagnostic trouble codes (DTCs), are concise, informative messages. Diagnostic data is designed to allow vehicle control units to indicate a system fault and / or the need for repair. While the DTC may be in an 'active' or 'confirmed' state for the ignition cycle in which the fault occurred, most DTCs will then revert to a 'history' or 'drowsy' state for a number of ignition cycles, ensuring that evidence of the fault remains available even if the vehicle is inspected by a technician weeks after the fault occurred. SUMMARY

[0003] In one or more illustrative embodiments, a system includes a memory configured to manage diagnostic data, cadence trigger criteria defining periodic transmission of diagnostic data, and priority trigger criteria defining out-of-cadence transmission of diagnostic data; and a processor programmed to periodically send diagnostic data accumulated during a previous cadence transmission to a remote server based on the cadence trigger criteria, and to send out-of-cadence diagnostic data that meets the priority trigger criteria for the server to the remote server.

[0004] In one or more illustrative embodiments, a method includes storing diagnostic trouble code (DTC) data received from other controllers via a vehicle bus in a telematics controller; sending the DTC data that meets the priority trigger criteria from the telematics controller to the remote server; deleting the sent DTC data based on priority trigger criteria; periodically sending all stored DTC data from the controller to a remote server based on cadence trigger criteria; and deleting the sent DTC data based on cadence trigger criteria.

[0005] In one or more illustrative embodiments, a non-transitory computer-readable medium includes instructions which, when executed by a processor of a telematics controller, cause the telematics controller to store diagnostic trouble code (DTC) data received via a vehicle bus from other controllers; to send the DTC data that meets the priority trigger criteria from the telematics controller to the remote server; to delete the sent DTC data based on the priority trigger criteria; to periodically send all stored DTC data from the controller to a remote server based on cadence trigger criteria; and to delete the sent DTC data based on the cadence trigger criteria. BRIEF DESCRIPTION OF THE DRAWINGS Fig. Figure 1 illustrates an exemplary system that implements efficient connected vehicle diagnostic data monitoring; and Fig. Figure 2 illustrates an exemplary process for efficient connected vehicle diagnostic data monitoring. DETAILED DESCRIPTION

[0006] Detailed embodiments of the present invention are disclosed herein as necessary; however, it is understood that the disclosed embodiments are merely exemplary of the invention, which may be implemented in various and alternative forms. The figures are not necessarily to scale; some features may be enlarged or reduced to show details of certain components. Accordingly, the specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis to teach a person skilled in the art the diverse uses of the present invention.

[0007] The DTC standard was created before the ubiquity of connected vehicles. With connected vehicles, DTC data can now be captured and transmitted with every ignition cycle, or even multiple times per ignition cycle. This capability presents both an opportunity and a challenge. If OEMs or third-party connectivity providers design their systems to capture and transmit DTCs with every ignition cycle, the amount of data captured can become overwhelming in terms of both size and repetition. Conversely, if the connectivity system is designed to capture only 'active' / 'confirmed' DTCs, then important information (e.g., historical DTCs) can be lost.

[0008] Thus, some benefits of ubiquitous connectivity may be lost, as the 'noise' in the data from a very frequent capture of 'historical' DTCs may reduce the effectiveness of an early warning / quality signal provided by the less frequent 'active' / 'confirmed' DTCs.

[0009] An effective connected vehicle diagnostic data monitoring system can be used to address the problems of too much or too little data being collected using a hybrid approach. This approach introduces regular DTC data collection with in-vehicle logic to efficiently send data in two scenarios. In the first scenario, such as a time-based scenario, a regular cadence of DTC transmission is defined based on a time or number of ignition cycles. For example, a time-based scenario could involve data transmission at each predefined period (e.g., 30 days, 40 ignition cycles, etc.), regardless of the status of the collected DTC. In the second scenario, such as a trigger scenario, one or more triggers for data transmission based on DTC status can be defined.In one example, a trigger scenario could include logic that, in response to the detection of an 'active' or 'acknowledged' DTC, initiates a DTC transmission, sending it to a remote server. This can also allow for the configuration of other DTC status triggers, such as transmitting DTC data when a DTC is detected in an 'unresolved' status.

[0010] The two scenarios working together achieve two goals. First, regular data transmissions are required to obtain a regular heartbeat of data for analysis and to monitor the evolution of DTCs in the 'history' / 'outsourcing' state. Second, data transmissions triggered by the DTC status, such as 'active' / 'confirmed', allow the system to be aware of all 'active' DTCs in the ignition cycle in which the fault was confirmed.

[0011] Since 'active' DTCs are relatively infrequent and represent the most important DTC information to be transmitted from a connected vehicle, this dual approach thins the data to only the most valuable diagnostic information. Additionally, this reduces the data transmitted from connected vehicles by providing less frequent, periodic DTC data collection of 'historical' DTCs. Further aspects of the disclosure are described in more detail below.

[0012] Fig. Figure 1 illustrates an exemplary system 100 that implements efficient connected vehicle diagnostic data monitoring. As illustrated, the vehicle 102 includes a variety of vehicle controllers 104 communicating via one or more vehicle buses 106. The system 100 also includes a vehicle data server 122 configured to manage diagnostic data 120 received from various vehicles 102. The vehicle 102 further includes a telematics control unit (TCU) 108 configured to send diagnostic data 120, including diagnostic information, to the vehicle data server 122. The TCU 108 can utilize a diagnostic application 118 installed in the TCU 108 to send a regular cadence of diagnostic data 120, as well as to send triggered diagnostic data 120 in response to trigger criteria 124 being met.It should be noted that System 100 is merely an example and other arrangements or combinations of elements can be used.

[0013] Vehicle 102 can refer to various types of automobiles, including soft-roaders (crossover utility vehicles - CUVs), SUVs, trucks, recreational vehicles (RVs), boats, aircraft, or other mobile machinery used for transporting people or goods. In many cases, Vehicle 102 can be powered by an internal combustion engine. Alternatively, Vehicle 102 can 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).Since the type and configuration of Vehicle 102 can vary, its capabilities can also vary accordingly. For example, Vehicle 102s may have different capabilities in terms of passenger capacity, towing capacity, and storage volume. For ownership, inventory, and other purposes, Vehicle 102s may be linked to unique identifiers, such as a VIN (vehicle identification number).

[0014] The vehicle 102 can include a variety of controllers 104 configured to perform and manage different functions of the vehicle 102 when powered by the vehicle battery and / or the vehicle drive system. As shown, the exemplary vehicle controllers 104 are represented as individual controllers 104-A to 104-G. However, the vehicle controllers 104 can share physical hardware, firmware, and / or software, so that the functions of several controllers 104 can be combined into a single controller 104, and the functions of such different controllers 104 can be distributed across a variety of controllers 104.

[0015] Non-restrictive examples of some vehicle controls 104: a powertrain control 104-A may be configured to provide control of the engine operating components (e.g., idle control components, fuel supply components, emission control components, etc.) and to monitor the status of such engine operating components (e.g., engine code status); a body control 104-B may be configured to manage various performance control functions, such as exterior lighting, interior lighting, keyless entry, remote start, and access point status verification (e.g.,The vehicle 102 can monitor the closing status of the hood, doors, and / or trunk; a radio transceiver control 104-C can be configured to communicate with key fobs, mobile devices, or other local devices of the vehicle 102; an entertainment control 104-D can be configured to support voice commands and Bluetooth interfaces with the driver and devices worn by the driver; an air conditioning management control 104-E can be configured to provide control of heating and cooling system components (e.g., compressor clutch, fan blower, temperature sensors, etc.).); a controller 104-F of a global positioning system (GPS) can be configured to provide vehicle position data; and a controller 104-G of a human-machine interface (HMI) can be configured to receive user input via various buttons or other controls and to provide vehicle status information to a driver, such as fuel level information, engine operating temperature information and the current position of the vehicle 102.

[0016] The vehicle bus 106 can incorporate various communication methods available between the vehicle ECUs 104 and between the TCU 108 and the vehicle ECUs 104. As some non-limiting examples, the vehicle bus 106 can include one or more vehicle control unit networks (CAN), an Ethernet network, or a media-oriented system transport (MOST) network. Further aspects of the design and number of vehicle buses 106 are described in detail below.

[0017] The TCU 108 may include network hardware configured to enable communication between the vehicle ECU 104 and other devices of the system 100. For example, the TCU 108 may include or otherwise access a cellular modem 110 configured to enable communication with the Wide Area Network 112. The Wide Area Network 112 may include one or more interconnected communication networks, such as, but not limited to, the Internet, a cable television distribution network, a satellite connection network, a local area network, a wide area network, and a telephone network. As another example, the TCU 108 may utilize one or more Bluetooth, Wi-Fi, and wired USB network connectivity options to enable communication with the Wide Area Network 112 via the user's mobile device.

[0018] The TCU 108 may further include various types of computing devices to support the performance of the functions of the TCU 108 described herein. For example, the TCU 108 may include one or more processors 114 configured to execute computer instructions and a storage medium 116 on which the computer-executable instructions and / or data can be managed. A computer-readable storage medium (also referred to as a processor-readable medium or memory 116) includes any non-transitory (e.g., physical) medium involved in providing data (e.g., instructions) that can be read by a computer (e.g., by the processor(s)). In general, a processor 114 receives instructions and / or data, e.g., from memory 116, etc., to a working memory and executes the instructions using the data, thereby carrying out one or more processes, including one or more of the processes described herein. Computer-executable instructions can be compiled or evaluated by computer programs created using a variety of programming languages ​​and / or technologies, including, but not limited to, and either individually or in combination, Java, C, C++, C#, Fortran, Pascal, Visual Basic, Python, JavaScript, Perl, PL / SQL, etc.

[0019] The TCU 108 can be configured to include one or more interfaces from which vehicle information can be sent and received. For example, the TCU 108 can be configured to allow the acquisition of DTC data and / or other vehicle information from the vehicle ECU 104, which is connected to one or more vehicle buses 106. This acquired information can be referred to as diagnostic data 120. The TCU 108 can store the acquired diagnostic data 120 in the memory 116 of the TCU 108 or, in other examples, in another memory in communication with the TCU 108. The vehicle information retrieved by the TCU 108 can include, as some non-limiting examples, accelerator pedal position, steering wheel angle, vehicle speed, vehicle position (e.g., GPS coordinates, etc.), unique vehicle identifier (e.g., VIN), and other vehicle information.The diagnostic data includes the VIN, engine revolutions per minute (rpm), and vehicle HMI information, such as steering wheel button press information. Therefore, the diagnostic data can include 120 captured DTC information and / or other vehicle information stored in memory 116 of the TCU 108.

[0020] The diagnostic application 118 can be an application contained in the memory 116 of the TCU 108. The diagnostic application 118 can contain instructions which, when executed by the processor 114 of the TCU 108, cause the TCU 108 to periodically acquire the diagnostic data 120 information from the controllers 104 (e.g., including DTC information), store the information for transmission, and transmit the diagnostic data 120 to the vehicle data server 112 via the Wide Area Network 122.

[0021] The vehicle data server 122 can comprise various types of computing devices, such as a computer workstation, a server, a desktop computer, a virtual server instance running on a mainframe server, or another computing system and / or device. Similar to the TCU 108, the vehicle data server 122 generally includes working memory on which computer-executable instructions can be stored, the instructions being executable by one or more processors (not shown for clarity). Such instructions and other data can be stored using a variety of computer-readable media. For example, the vehicle data server 122 can be configured to manage the diagnostic data 120 received by the vehicle's TCU 108 over the network 112.

[0022] The diagnostic application 118 can also include instructions for performing functions in response to trigger criteria 124. The trigger criteria 124 can include one or more conditions which, if met, cause at least a subset of the diagnostic data 120 to be transmitted. The trigger criteria 124 can also include information specifying which acquired diagnostic data 120 should be transmitted to the vehicle data server 122 based on the fulfillment of the condition(s) of the trigger criteria 124.

[0023] The trigger criteria 124 can include cadence trigger criteria 124. The cadence trigger criteria 124 can include conditions that cause the majority of the captured diagnostic data 120 to be transmitted. The cadence trigger criteria 124 can include a time scenario that determines that data transmission occurs at each predefined interval (e.g., 30 days). Additionally or alternatively, the cadence trigger criteria 124 can include a time scenario that determines that data transmission occurs after a predefined number of occurrences of a specific event (e.g., 40 ignition cycles).

[0024] Trigger criteria 124 can also include priority trigger criteria 124. Priority trigger criteria 124 can include conditions that cause the data triggering the condition to be transmitted. For example, one or more of the trigger criteria 124 can be defined for transmitting data according to DTC status. As one possibility, trigger criteria 124 can include a transmission trigger in response to the capture of an 'active' or 'confirmed' DTC. Alternatively, trigger criteria 124 can include a transmission trigger in response to a different DTC status, such as transmitting DTC data when a DTC is captured in an 'unresolved' status.

[0025] The vehicle data server 122 may also be configured to manage an analysis service 126, which is configured to analyze the managed diagnostic data 120 provided by the vehicles 102. The analysis service 126 may include instructions which, when executed by a processor of the vehicle data server 122, cause the vehicle data server 122 to check the diagnostic data 120 and provide statistics regarding common DTCs or other conditions.

[0026] Variations of the system 100 are possible. For example, instead of or in addition to using the TCU 108 to provide remote connectivity to the vehicle data server 122, the TCU 108 can use communication features of a modem in a user's mobile device, coupled with the entertainment control unit 104-D, to perform communication via the Wide Area Network 112.

[0027] Fig.Figure 2 illustrates an exemplary process 200 for efficient connected vehicle diagnostic data monitoring. In one example, process 200 can be performed by the diagnostic application 118, which is executed by the TCU 108.

[0028] In process 202, the TCU 108 acquires diagnostic data 120. In one example, the TCU 108 acquires DTC data and / or other vehicle information from the vehicle ECU 104, which is connected to one or more vehicle buses 106. In another example, the TCU 108 acquires other vehicle information that passes through one or more vehicle buses 106.

[0029] In process 204, the TCU 108 determines whether a cadence transmission is due. For example, the TCU 108 can determine whether cadence trigger criteria 124 have been met. Cadence trigger criteria 124 can include a time scenario that specifies a data transmission for every predefined period (e.g., 30 days). Additionally or alternatively, cadence trigger criteria 124 can include a time scenario that specifies a data transmission after a predefined number of occurrences of a defined event (e.g., 40 ignition cycles). If cadence trigger criteria 124 have been met, the controller proceeds to process 206. Otherwise, the controller returns to process 202.

[0030] At step 206, TCU 108 sends the recorded history of diagnostic data 120. For example, TCU 108 sends the recorded diagnostic data 120 to the vehicle data server 122, regardless of the status of the recorded DTCs. For instance, the diagnostic data 120 can include both 'active' / 'confirmed' DTCs and 'historical' DTCs. After step 206, the control system proceeds to step 208.

[0031] At point 208, TCU 108 determines whether a triggered transfer is required. For example, TCU 108 can determine whether priority trigger criteria 124 have been met. One or more of the trigger criteria 124 may be defined for transferring data according to the DTC status. As one possibility, the trigger criteria 124 may include a transfer trigger in response to the detection of an 'active' or 'acknowledged' DTC. Alternatively, the trigger criteria 124 may include a transfer trigger in response to a different DTC status, such as transferring DTC data when a DTC is detected in an 'unresolved' status. If the priority trigger criteria 124 have been met, the controller proceeds to operation 210. Otherwise, the controller returns to operation 202.

[0032] At step 210, the TCU 108 sends the information that triggered the transmission. In one example, the TCU 108 sends the one or more DTCs that were triggered for transmission during step 208 to the vehicle data server 122. In other examples, the TCU 108 can additionally or alternatively send further information to the vehicle data server 122. For example, the TCU 108 can also send additional stored diagnostic data 120 to the vehicle data server 122 that has been acquired since the previous cadence transmission. After step 210, the control unit returns to step 202.

[0033] The computing devices described herein, such as the controllers 104, the TCU 108, and the vehicle data server 122, generally contain computer-executable instructions, the instructions of which can be executed by one or more computing devices such as those listed above. The computer-executable instructions, such as those of the diagnostic application 118, can be assembled or interpreted by computer programs created using a variety of programming languages ​​and / or technologies, including, but not limited to, either individually or in combination, Java™, C, C++, C#, Visual Basic, JavaScript, Python, Perl, PL / SQL, etc. In general, a processor (e.g., a microprocessor) receives instructions, e.g., from memory, a computer-readable medium, etc., and executes these instructions, thereby performing one or more processes, including one or more of the processes described herein.Such instructions and other data can be stored and transmitted using a variety of computer-readable media.

[0034] With regard to the processes, systems, procedures, heuristics, etc., described herein, it is understood that while the steps of such processes, etc., are described as occurring in a specific sequence, such processes could be carried out using the described steps in a sequence that differs from the sequence described here. It is further understood that certain steps could be performed simultaneously, other steps added, or certain steps described herein omitted. In other words, the descriptions of processes here serve the purpose of illustrating certain embodiments and should in no way be interpreted as limiting the claims.

[0035] Accordingly, it is understood that the foregoing description is intended to be illustrative and not limiting. Many embodiments and applications, other than the examples presented, would become apparent upon reading the foregoing description. The scope should not be determined by reference to the foregoing description, but instead by reference to the appended claims together with the full scope of equivalents to which such claims entitle. It is expected and intended that there will be future developments with respect to the technologies described herein and that the disclosed systems and methods will be incorporated into such future embodiments. Overall, it is understood that the application may be modified and varied.

[0036] All terms used in the claims shall be interpreted in their most comprehensive and comprehensible terms and general meanings as they are known to those skilled in the art in the technology described herein, unless expressly stated otherwise. In particular, the use of singular articles such as "a", "an", "an", "the", "the", etc., shall be interpreted as referring to one or more of the listed elements, unless a claim expressly limits this to the contrary.

[0037] The summary of disclosure is provided to enable the reader to quickly grasp the nature of the technical disclosure. It is filed with the understanding that it is not intended to interpret or limit the scope of protection or the meaning of the claims. Furthermore, it is evident from the foregoing detailed description that various features in different embodiments have been grouped together for the purpose of simplifying the disclosure. This method of disclosure is not to be construed as reflecting an intention that the claimed embodiments require more features than are expressly stated in the respective claim. Rather, the subject matter of the invention consists of fewer than all the features of a single disclosed embodiment, as reflected in the following claims.The following patent claims are hereby included in the detailed description, with each patent claim representing a separately claimed subject matter.

[0038] Although exemplary embodiments are described above, these embodiments are not intended to describe all possible forms of the invention. The terms used in the description are descriptive and not limiting, and it is understood that various modifications can be made without departing from the spirit and scope of the invention. Furthermore, the features of different implementing embodiments can be combined to form further embodiments of the invention.

Claims

[1] System, encompassing: a memory configured to manage diagnostic data, cadence trigger criteria that define a periodic transmission of the diagnostic data, and priority trigger criteria that define an out-of-cadence transmission of the diagnostic data; and a processor that is programmed to To periodically send diagnostic data that has accumulated since a previous cadence transmission to a remote server based on the cadence trigger criteria, and To send out-of-range diagnostic data that meets the priority trigger criteria to the remote server, and to clear the out-of-cadence diagnostic data from memory in response to the sending of the out-of-cadence diagnostic data, in order to avoid re-sending the out-of-cadence diagnostic data in a subsequent cadence transmission. [2] System according to claim 1, wherein the processor is further programmed to delete the diagnostic data that has accumulated since a previous cadence in response to the transmission of the diagnostic data. [3] System according to claim 1, wherein the cadence trigger criteria determine that the diagnostic data is sent periodically upon completion of a predefined number of vehicle ignition cycles. [4] System according to claim 1, wherein the cadence trigger criteria determine that the diagnostic data is sent periodically after a predefined number of days. [5] System according to claim 1, wherein the priority trigger criteria determine which diagnostic data from memory specifies the ‘active’ diagnostic codes to send as the out-of-range diagnostic data. [6] System according to claim 1, wherein the priority trigger criteria determine which diagnostic data from memory indicates 'unfinished' diagnostic codes to send as out-of-range diagnostic data.

Images