Vehicle Communications

Abstract

The present disclosure relates to vehicle communications. A vehicle system includes a telematics control unit (TCU) connected to a plurality of vehicle controllers. The TCU is configured to periodically log wireless activity data related to authentication, attachment, signaling, detachment, and switching procedures of the TCU to provide one or more remote vehicle services. The TCU is also configured to, in response to detecting a cellular failure from the logged data, wirelessly send at least a portion of the log corresponding to the cellular failure to a remote server outside the vehicle, the remote server being configured to diagnose the operation of the TCU.

Description

Technical Field

[0001] The present disclosure relates to systems and methods for monitoring and resolving vehicle communication failures. Background Art

[0002] The importance of robust vehicle communications increases as vehicles become more advanced. The vehicle's systems communicate large amounts of data with each other to coordinate and ensure proper operation of the vehicle. Furthermore, given the mobile nature of vehicles, wireless vehicle communications enable important functions that may not otherwise be available. Therefore, there is a need to efficiently monitor and resolve vehicle communication failures to ensure optimal operation of the vehicle. Summary of the invention

[0003] The following summary of the invention may present a simplified overview of some embodiments of the invention in order to provide a basic understanding of certain aspects of the invention discussed herein. The summary of the invention is not intended to provide a broad overview of the invention, nor is it intended to identify any key or important elements, or to delineate the scope of the invention. The sole purpose of the summary of the invention is simply to present some concepts in a simplified form as an introduction to the specific embodiments presented below.

[0004] In one exemplary embodiment, a vehicle includes a telematics control unit (TCU), the TCU being configured to periodically log wireless activity data related to authentication, attachment, signaling, detachment, and handover procedures of the TCU to provide one or more remote vehicle services. The TCU is also configured to wirelessly send at least a portion of the log corresponding to a cellular fault to a remote diagnostic server outside the vehicle in response to detecting the cellular fault from the logged data.

[0005] In another exemplary embodiment, a method includes implementing the following operations by a TCU of a vehicle: periodically recording wireless activity data related to authentication, attachment, signaling, detachment, and handover procedures of the TCU in a log to provide one or more remote vehicle services. The method also includes: in response to detecting a cellular fault from the log, wirelessly sending at least a portion of the log corresponding to the cellular fault to a remote diagnostic server outside the vehicle by the TCU.

[0006] In another exemplary embodiment, a diagnostic server includes a processor geographically remote from a vehicle, the vehicle including a TCU. The TCU is configured to generate a first log of wireless activity specific to the TCU and a second log of component failures specific to the TCU. The processor is configured to send a request for the first log, wherein, in response to the request, the first log is received by the processor instead of the second log.

[0007] According to one embodiment of the present invention, the TCU is further configured to record in a log the wireless activity data transmitted outside the vehicle in response to detecting a cellular failure when the wireless activity data is periodically collected by the TCU.

[0008] According to one embodiment of the present invention, the log is a first log of the TCU, and the TCU is also configured to: in response to a component failure of the TCU, record data indicating the component failure in a second log of the TCU, and wirelessly send at least a portion of the first log and the second log to a remote diagnostic server outside the vehicle.

[0009] According to an embodiment of the present invention, the component failure includes a diagnostic trouble code, a firmware wireless update failure, an input / output failure, a global positioning failure, a message broker connection problem, or a memory read / write failure.

[0010] According to one embodiment of the present invention, the TCU is further configured to: in response to the component failure, identify data in the first log associated with a timestamp within a predefined time period immediately before the component failure, and wirelessly transmit the identified data to a remote diagnostic server outside the vehicle.

[0011] According to one embodiment of the present invention, the TCU is further configured to: in response to the component failure, discard data in the first log that is not related to a timestamp within a predefined time period immediately before the component failure, wherein the discarded data is not sent to a remote diagnostic server outside the vehicle.

[0012] According to one embodiment of the present invention, the TCU is also configured to: in response to a failure in log sending, insert at least a portion of the log into a cache memory for the failed sending log data, and in response to the data size of the failed sending log data in the cache memory exceeding a threshold, wirelessly retry sending at least a portion of the log to a remote diagnostic server outside the vehicle.

[0013] According to one embodiment of the present invention, the cellular fault is a slow cellular network connection, and the TCU is further configured to: in response to receiving a repair corresponding to the log from a remote diagnostic server, connect to a different cellular network, wherein the repair defines an instruction for the TCU to use the different cellular network.

[0014] According to one embodiment of the present invention, the TCU is also configured to: wirelessly send at least a portion of the log by being configured to wirelessly send the log and the associated topic to a data agent outside the vehicle, and in response to receiving the log, the data agent is configured to: send the log to the remote diagnostic server in response to identifying the remote diagnostic server as a subscriber of the associated topic. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 is a schematic diagram illustrating a system for monitoring and resolving vehicle communication failures.

[0016] Figure 2 is a line graph illustrating a process for monitoring and resolving vehicle communication failures. DETAILED DESCRIPTION

[0017] Figure 1 An exemplary system 100 is shown for monitoring and resolving communication problems with a vehicle 102 . The vehicle 102 may include a telematics control unit (“TCU”) 104 to wirelessly communicate with a remote system 106 , a data broker 108 , and a diagnostic server 110 via a network 112 .

[0018] The remote system 106 may include a mobile device and a server with which the TCU 104 may wirelessly communicate to provide remote services to the vehicle 102. For example, a user may issue a command from his or her mobile device to remotely lock, unlock, or start the vehicle 102. When the command is issued, the mobile device may send the command to the TCU 104 via the network 112, which may then cause the vehicle 102 to execute the command. As a further example, the TCU 104 may include a global positioning system (“GPS”) unit for tracking the location of the vehicle 102. When the vehicle 102 is involved in an accident, the TCU 104 may automatically send the location of the vehicle 102 to emergency personnel via the network 112. In another example, the TCU 104 of the vehicle 102 may transmit location, diagnostic, and driver behavior data to a remote fleet management system, which may then enable an administrator to manage the vehicle 102 and the driver based thereon.

[0019] A TCU failure (such as the failures mentioned above) may occur that prevents the vehicle 102 from receiving and sending data for remote services. For example, a component (e.g., hardware or software) of the TCU 104 may fail (e.g., a software problem (such as, stuck in a loop), a hardware problem (such as, a damaged antenna)), thereby preventing the TCU 104 from operating properly. As a further example, a network (or cellular) failure may occur (e.g., a problem connecting to a wireless network, low network connectivity, or no network connection), which may result in a slow connection or an error in the connection. As another example, a remote system 106 may fail, which may prevent data transmission from and to the remote system 106. Given the passage of time and the movement of the vehicle 102, it is difficult to attempt to simulate the conditions that led to the TCU failure for diagnostic purposes after the fact. For example, cellular network conditions (e.g., signal strength) may change as the vehicle 102 changes location. The conditions of each TCU failure may also not recur after the failure occurs. Furthermore, because the root cause of a TCU fault is often unknown after the fact (to the extent such a fault can be diagnosed at all), diagnosing the fault may require a guess-and-check process that utilizes significant resources and time.

[0020] Therefore, instead of relying on post-facto simulation to diagnose TCU faults, the TCU 104 may be configured to generate one or more logs related to the activities and faults of the TCU 104. The TCU 104 may be configured to wirelessly send at least a portion of the logs to a diagnostic server 110 outside the vehicle 102 (such as via a data agent 108 and a message queue telemetry transmission (MQTT) protocol specifically designed for this embodiment) when a fault occurs, or periodically, or upon demand from the diagnostic server 110. The diagnostic server 110 may then determine or enable a user to determine based on the logs whether the TCU fault occurred due to a fault of a component of the TCU 104 or due to a network fault, and debug the fault accordingly.

[0021] The vehicle 102 may include various types of automobiles, hybrid utility vehicles (CUVs), sport utility vehicles (SUVs), trucks, recreational vehicles (RVs), boats, airplanes, or other mobile machines for transporting people or goods. In many cases, the vehicle 102 may be driven by an internal combustion engine. As another possible approach, the vehicle 102 may be a hybrid electric vehicle (HEV) driven 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 the vehicle 102 may be different, the operating characteristics of the vehicle 102 may be correspondingly different. As some other possible approaches, the vehicle 102 may have different characteristics in terms of passenger capacity, traction capacity and performance, and storage capacity.

[0022] The vehicle 102 may include various hardware components and software components, such as, but not limited to, one or more vehicle controllers 116 (represented in the system 100 as separate controllers 116A through 116G). The controller 116 may be configured to monitor and manage various functions of the vehicle 102 under the power of the vehicle battery and / or powertrain. The controller 116 may include one or more processors (e.g., microprocessors) configured to execute firmware or software programs stored in one or more memory devices of the controller 116. Although the controllers 116 are shown as separate components, the vehicle controllers 116 may share physical hardware, firmware, and / or software, such that functionality from multiple controllers 116 may be integrated into a single controller 116, and functionality of multiple such controllers 116 may be distributed among multiple controllers 116.

[0023] For example, the vehicle controllers 116 may include, but are not limited to, a powertrain controller 116A configured to manage engine operating components; a body controller 116B configured to manage various power control functions (such as exterior lighting, interior lighting, keyless entry, remote start, and access point status verification); a radio transceiver controller 116C configured to communicate with a key fob, mobile device, or other local device of the vehicle 102; an entertainment controller 116D configured to support voice commands and Bluetooth interaction with the driver and devices carried by the driver; a climate control management controller 116E configured to monitor and manage heating and cooling system components (e.g., compressor clutch, blower fan, temperature sensor, etc.); a global positioning system (GPS) controller 116F configured to provide vehicle location information; and a human-machine interface (HMI) controller 116G configured to receive user input via various buttons or other controls and to provide vehicle status information to the driver.

[0024] The vehicle bus 118 may include various communication methods available between the vehicle controllers 116 and between the TCU 104 and the vehicle controller 116. Thus, the TCU 104 may be connected to the controllers and may transmit data (e.g., diagnostic information) from the controllers 116 to the remote systems 106 via the vehicle bus 118, and may send data or commands (e.g., a remote start command) from the remote systems 106 to the controllers 116 via the vehicle bus 118. The vehicle bus 118 may include one or more of a vehicle controller area network (CAN), Ethernet, and / or a media oriented systems transport (MOST) network.

[0025] The TCU 104 may include a processor 120, a memory 122, and a modem 123. The processor 120 may include one or more devices selected from a microprocessor, a microcontroller, a digital signal processor, a microcomputer, a central processing unit, a field programmable gate array, a programmable logic device, a state machine, a logic circuit, an analog circuit, a digital circuit, or any other device that manipulates signals (analog or digital signals) based on operating instructions stored in the memory 122. The memory 122 may include a single storage device or multiple storage devices, including but not limited to: read-only memory (ROM), random access memory (RAM), volatile memory, non-volatile memory, static random access memory (SRAM), dynamic random access memory (DRAM), flash memory, cache memory or mass storage devices (such as hard disk drives, optical drives, tape drives, non-volatile solid-state devices) and any other devices capable of storing information. The memory 122 may be configured to store operating systems and applications executed by the processor 120 and databases of information accessed by the processor 120.

[0026] The processor 120 may be configured to execute firmware or software programs (such as a logger 124) stored on a memory 122 of the TCU 104. The TCU 104 may also include network hardware configured to facilitate communication between the vehicle controller 116 and between the vehicle 102 and other devices of the system 100 via the network 112. For example, a modem 123 of the TCU 104 may provide a wireless connection to the network 112 and thereby enable the TCU 104 to wirelessly transmit vehicle operating data from the vehicle controller 116 to one or more remote systems 106. Similarly, the modem 123 may enable the TCU 104 to send recorded data indicating TCU network activity and / or TCU component failures to the data broker 108 and the diagnostic server 110. The network 112 may include one or more interconnected communication networks, such as the Internet, a wide area network, a cable television distribution network, a satellite link network, a local area network, and a telephone network. The TCU 104 may also be configured to communicate via one or more of Bluetooth, Wi-Fi, and a wired USB network connection, and may facilitate data transfer between the vehicle 102 and the network 112 via a nomadic device (not shown) located within or paired with the vehicle 102 .

[0027] When the engine of the vehicle 102 is powered on or started, the recorder 124 may be configured to record fault data of the TCU 104. Specifically, the recorder 124 may be configured to record wireless activity data indicating a network fault (such as a network connection problem) in the log. The wireless activity data may indicate one or more network faults (such as a cellular network failure) that occurred when the TCU 104 provided one or more remote services for the vehicle 102 (such as downloading or receiving data, uploading or transmitting data, and connection processes and procedures performed by or related to the operation of the TCU 104). The connection processes and procedures may include protocol signaling procedures performed by the TCU 104 when connecting and communicating via the network 112, such as signaling, authentication, attachment, detachment, and handover activities of the TCU 104. In other words, the recorded wireless activity data may identify faults associated with TCU 104 activities, including authentication, attachment, signaling, detachment, and switching procedures performed by the TCU 104 to wirelessly send data from the vehicle controller 116 to the remote system 106, and / or to receive data or commands for the vehicle controller 116 from the remote system 106.

[0028] With respect to the protocol signaling procedures described above, signaling may be performed to determine whether the TCU 104 is located in an area with sufficient network or cellular coverage, rather than in an area with little or no coverage (e.g., an area of ​​-113 db or less). When sufficient network or cellular coverage is available, authentication may be performed to authenticate the TCU 104 with the network or cellular provider, and the TCU 104 may receive an "accept" or "reject" message from the provider in response to the authentication. Whenever a session is initiated between the TCU 104 and the network 112 (such as via a data attach request (e.g., a PDP (Packet Data Protocol) attach request)), an attach may be performed, and the TCU 104 may receive an "accept" or "reject" message in response to the request. When the session between the TCU 104 and the network 112 ends, a detach may be performed, in which case the TCU 104 may receive a disconnect message. A handoff may be performed while the vehicle 102 is in motion, and the TCU 104 needs to change its cellular or network connection from one access point or cellular tower to another.

[0029] The recorder 124 may be configured to periodically or continuously monitor for faults related to wireless activities performed by the TCU 104 (such as errors that occur during the connection process and procedures described above), which are included as part of the recorded wireless activity data. To this end, the recorder 124 may be configured to periodically or continuously collect and temporarily store (such as in a main memory (e.g., RAM) of the TCU 104) wireless activity data related to the wireless activities of the TCU 104. The wireless activity data may include a number of periodically recorded entries, each entry detailing one or more wireless activities performed by the TCU 104 at a given time. Each entry may include a timestamp indicating when the data for the entry was collected, the current location of the vehicle 102 when the data for the entry was collected, the current network coverage of the vehicle 102 when the data for the entry was collected, and / or whether the TCU 104 was engaged in any wireless activity when the data entry was collected. For each wireless activity, the entry may also include the start time of the wireless activity, the end time of the wireless activity, the elapsed time of the wireless activity, the speed for the selected activity, the status of the wireless activity (e.g., waiting, idle), and the result of the wireless activity (e.g., success, failure).

[0030] In response to detecting a network failure (such as slow connection speed, insufficient network coverage, inability to connect to an available network, and / or a failure of one of the wireless activities described above) from the temporarily stored data, the recorder 124 may be configured to record the identified failure in a log (such as a wireless log 126 dedicated to storing wireless activity data of the TCU 104 and / or network-related failures). To this end, the recorder 124 may also record at least a portion of the wireless activity data collected before the failure in the log. For example, the log may include the identified network failure, details corresponding to the wireless activities of the TCU 104 corresponding to the network failure included in the wireless activity data, and / or other wireless activity data collected correspondingly before the failure. In particular, the log may also include wireless activity data associated with a timestamp falling within a predetermined time period immediately before the network failure. Unlike temporary storage, the log may be stored in a permanent storage device (such as a mass storage device of the memory 122) and may include one or more log files, the one or more log files including at least a portion of the wireless activity data (e.g., the aforementioned portion).

[0031] Alternatively, the recorder 124 may be configured to periodically or continuously record all wireless activity data (such as wireless activity data collected regardless of whether a cellular failure occurs) in a log (such as the wireless log 126). In this case, when a network failure is detected, the recorded data may include wireless activity data of the TCU 104 associated with the network failure, and wireless activity data of the TCU 104 that is not associated with the cellular failure. In this case, before sending the log outside the vehicle 102, the recorder 124 may be configured to remove and / or discard at least a portion of the wireless activity data that is not associated with the cellular failure from the log (or at least the sent log). For example, the recorder 124 may be configured to remove and / or discard all wireless activity data that is not associated with the network failure or wireless activity data associated with a timestamp that does not fall within a predefined time period immediately before the network failure from the log (or at least the sent log).

[0032] The recorder 124 may also be configured to collect data related to the network activity and / or operation of the TCU 104, such as the status of the components of the TCU 104 (e.g., component operating normally, parameter value of the component, component reporting abnormal operating conditions) after a cellular fault is detected for a predetermined time (e.g., a duration of five seconds) or a predetermined data size, and may record the data in a log associated with the fault. In this manner, the log may include data identifying a cellular fault, data related to the network activity and the condition of the TCU 104 that caused the fault, and data related to the condition and / or network activity of the TCU 104 after the fault was detected. Network activity data of the TCU 104 that is collected by the recorder 124 and does not correspond to a fault may be discarded without ever being recorded and / or within the range of being sent outside the vehicle 102.

[0033] The recorder 124 may also be configured to record a TCU component failure indicating a component failure of the TCU 104 in a log (such as a component log 128 in the memory 122) in response to a component (e.g., hardware, software) failure of the TCU 104. The component log 128 may be specific to TCU component failure data and may include one or more log files included in a permanent storage device (such as a mass storage device) of the memory 122. Component failures recorded by the TCU 104 may include diagnostic trouble codes (DTCs), firmware over the air (FOTA) failures, input output (I / O) failures, global positioning system (GPS) failures, MQTT message broker connection problems, and memory read / write failures. The recorder 124 may be configured to record TCU component failures in a log based on an event (e.g., in response to receiving a DTC).

[0034] As previously described, the recorder 124 may store the recorded TCU network activity data in the wireless log 126 of the memory 122, and may store the recorded TCU component failure data in the component log 128 of the memory 122. Alternatively, the recorder 124 may store the recorded network activity data and the recorded component failure data in a single log of the memory 122, or may store each entry of the recorded network activity data and the recorded component failure data in separate logs of the memory 122.

[0035] The TCU 104 may include a non-volatile memory dedicated to storing logs compiled by the recorder 124. Specifically, the memory 122 may include a non-volatile memory, and a portion of the non-volatile memory may be dedicated to storing logs. In some embodiments, the portion may be up to 2MB. The TCU 104 and / or the recorder 124 may be configured to efficiently store and transmit logs using a combination of allocated non-volatile memory (e.g., flash memory) and RAM included in the memory 122. For example, the TCU 104 and / or the recorder 124 may implement a switching algorithm that may require storing the log or recorded data in RAM and then moving the log or recorded data to flash memory (such as when the recorder 124 cannot successfully send the recorded data to the diagnostic server 110 or the data agent 108). In addition, the recorder 124 may periodically compile the log (such as from the data stored in the RAM) and store the log in the non-volatile memory, and the stored log may be formatted in UTF-8 plain text format. When logging, data may be divided into smaller data blocks (such as data blocks of 128 bytes each). In certain embodiments, for a stored log, a maximum of 16 data blocks may be placed in non-volatile memory.

[0036] In response to a TCU fault (e.g., a network fault or a component fault) occurring, being detected, and being recorded in a log, the recorder 124 may be configured to cause the TCU 104 to wirelessly transmit recorded data to a diagnostic server 110 outside the vehicle 102. For example, the recorder 124 may be configured to wirelessly transmit recorded network activity data to a diagnostic server 110 outside the vehicle 102 in response to a network fault (the recorded network activity data may be stored in the wireless log 126). Similarly, the recorder 124 may be configured to wirelessly transmit recorded component failure data to a diagnostic server 110 outside the vehicle 102 in response to a TCU component failure (the recorded component failure data may be stored in the component log 128).

[0037] As a further example, in response to a TCU component failure or a network failure, the recorder 124 may be configured to send all or at least a portion of the recorded TCU component failure data and all or at least a portion of the recorded wireless activity data to the outside of the vehicle 102. In this way, the diagnostic server 110 may cross-reference the network activity of the TCU 104 before and after the time when the TCU component failure occurs, and may cross-reference the TCU component failure data before and after the time when the network failure occurs. For example, in response to a component failure, the recorder 124 may be configured to send all of the recorded component failure data and the recorded wireless activity data associated with a timestamp, wherein the timestamp falls within a predefined time period immediately before the time of the component failure and / or within a predefined timer time period immediately after the time of the component failure. To this end, in response to a component failure, the recorder 124 may be configured to identify data associated with a timestamp within a predefined time period immediately before the component failure and / or within a predefined timer time period immediately after the component failure in the recorded wireless activity data, and send the identified data and the recorded component failure data. Similarly, in the event of a network failure, the recorder 124 may be configured to send all of the recorded network activity data associated with a time within a predefined time period before the time of the component failure and / or a time within a predefined time period after the time of the component failure, as well as the recorded component failure data. Any recorded data filtered out by the above processing (e.g., recorded data associated with a timestamp outside of the above predefined time period) may be discarded and not used as a timestamp for the diagnostic server 110 outside the vehicle 102.

[0038] The logger 124 may also be configured to send one or more of the logs to a diagnostic server 110 external to the vehicle 102 in response to a storage allocation for the logs becoming full or nearly full (e.g., 85% full, 95% full), or in response to receiving a request for stored logs from the diagnostic server 110, or periodically.

[0039] When sending the recorded data to the diagnostic server 110 outside the vehicle 102, the recorder 124 can be configured to divide the recorded data into smaller data blocks for transmission (if not already divided), such as, each 128 kilobyte data block. The recorder 124 can also generate a data header for identifying the total number of data blocks that constitute the transmitted log or transmission, and attach the data header to each data block. The data header enables the diagnostic server 110 and / or the data agent 108 to understand and decode the message transmission when receiving the data block by reading the data header of each data block, and recompile the log based on this. Before sending the log, the recorder 124 can encrypt the log to ensure higher security.

[0040] In response to successfully sending the recorded data to the diagnostic server 110 or the data agent 108, the recorder 124 may receive a confirmation message. In response, the recorder 124 may remove the sent recorded data from the memory 122. However, in the event of a failed transmission (such as due to a wireless connection problem caused by a busy communication channel (e.g., MQTT channel) or by not receiving a confirmation from the data agent 108 or the diagnostic server 110 for the transmission), the recorder 124 and / or the TCU 104 may save the recorded data (such as by moving the data to a non-volatile memory and / or inserting the recorded data into a cache memory for the failed transmission log data 130). The cache memory may include each instance of the recorded data or each log file that the data agent 108 or the diagnostic server 110 did not successfully receive. Thereafter, the recorder 124 may perform a retry mechanism. For example, the recorder 124 and / or the TCU 104 may perform a periodic memory check on the cache memory for the failed transmission log data 130 and retry to send the data. Additionally or alternatively, in response to the data size of the failed transmission log data 130 in the cache memory being equal to or exceeding a predetermined threshold (e.g., 85% or 95% of the space allocated for storing the failed transmission log data), the recorder 124 may be configured to automatically and wirelessly retry sending the transmission log data of the fault to the diagnostic server 110 outside the vehicle 102.

[0041] In addition to the aforementioned advantages, the embodiments described herein are designed to overcome technical challenges associated with monitoring and resolving TCU faults of the vehicle 102. Optimization of available space and power utilization are factors in designing the vehicle 102, and for this reason, reliable local electronic storage is not an endless resource for monitoring and resolving TCU faults. Therefore, while one solution for monitoring and resolving TCU faults of the vehicle 102 may require local storage of TCU fault logs until a laptop or other device is directly connected to the vehicle 102 to download the stored logs, such a solution may not be efficient or practical. Specifically, in this solution, when the vehicle 102 is operated, the local capacity required to store the TCU fault logs and TCU activities may be large, especially when there is a long interval when the logs are downloaded from the vehicle 102 via a laptop. Therefore, storing the TCU fault logs and activities until the laptop can be directly connected to the vehicle 102 and download the logs may greatly increase the resources consumed by the vehicle 102. In addition, in this solution, since the data is not available for diagnosing the fault until the data is read directly from the vehicle 102 via a laptop or other hardware device, the response time for diagnosing the TCU fault is also increased.

[0042] Therefore, in order to minimize the resource consumption and response time associated with monitoring and resolving TCU faults, the recorder 124 may be configured to continuously monitor and / or record TCU faults (including TCU component faults and network faults). If no fault is detected, no data may be recorded and any temporarily stored data may be discarded. Alternatively, data related to the network activity of the TCU 104 may be recorded and the data may be discarded after a period of time when no faults are detected. In other words, the recorder 124 may be configured to delete recorded network activity data that is a predefined time earlier than the current time based on the timestamp included in the data, thereby freeing up resources for other data.

[0043] Alternatively, if a TCU fault is detected, the recorder 124 may be configured to record data indicative of the fault (if not already recorded), and possibly data relating to network activity and operating states of the TCU 104 before and / or after the fault. Once a fault is recorded and detected, the recorded data may be automatically sent to the diagnostic server 110 (such as via the data agent 108), and thereafter removed from the memory 122 of the TCU 104. In this manner, the data load sent over the network 112 is reduced because the recorder 124 may be configured to send fault data as it is recorded rather than as it accumulates data for multiple faults. The cost of recorded data on the storage resources of the vehicle 102 is also reduced because the recorded data may be sent as it is recorded and removed from the TCU 104 once it is sent, rather than being accumulated for direct download by a laptop computer. Additionally, the types of data and faults logged by logger 124 may be limited (e.g., specific values, parameters, and measurements to be filtered / tagged / logged may be defined, such as via diagnostic server 110) to further reduce the data footprint of the stored logs.

[0044] The diagnostic server 110 may be configured to diagnose the operation of the TCU 104 via the received logs. The diagnostic server 110 (as well as the remote system 106 and the data agent 108) may include a processor, memory, and a modem or other network transceiver (not shown) similar to those components of the TCU 104. When the log is received, the diagnostic server 110 may be configured to automatically store the log in a permanent storage device, process the log, and display the log in an optimal format for debugging the fault of the TCU 104 via the processor of the diagnostic server 110. Specifically, the diagnostic server 110 may read the data header in each data block received in the transmission, thereby determining the total number of data blocks included in each log of the transmission. As described in more detail below, the diagnostic server 110 may use this information to decode the data block into one or more transmitted logs and process the logs.

[0045] The diagnostic server 110 may be configured to store logs from multiple TCUs 104 of multiple vehicles 102. For each TCU 104, the diagnostic server 110 may be configured to store logs received during a specific time frame (such as the past six months). The diagnostic server 110 may include a graphical user interface (GUI) for displaying logs from one or more TCUs 104 and for customizing the information displayed by the GUI. For example, the diagnostic server 110 may enable a user to push and display different configurations of the same stored log by entering a date and a log content type (e.g., a wireless log or a component log). In the case where a log transmission request is initiated by the diagnostic server 110, the GUI of the diagnostic server 110 may also enable a user to request a specific log from the TCU 104 of the vehicle 102 via user-submitted criteria (such as entering a date and identifying a content type). When such a request is received, the TCU 104 may be configured to compile and buffer the log transmission so that the data transmitted by the log meets the requested criteria.

[0046] The diagnostic server 110 may also be connected to or include a repair database 111. The repair database 111 may include automatic repairs for TCU faults experienced by the TCU 104. In response to receiving recorded data (such as data indicating a network connection fault or a TCU component fault), the diagnostic server 110 may be configured to query the repair database 111 to identify a suitable repair for the fault. Thereafter, the diagnostic server 110 may send the repair to the TCU 104 to be implemented by the TCU 104. In some embodiments, the diagnostic server 110 may be configured to dynamically determine a suitable repair for the fault (such as based on one or more repair data entries included in the repair database 111). This process may be fully automatic. Additionally or alternatively, a user may interact with the GUI of the diagnostic server 110 to select, upload, or generate a repair, after which the repair is selectively sent to the TCU 104.

[0047] Similar to the TCU 104, the diagnostic server 110 may include a retry mechanism from which a request for a log is initiated. The diagnostic server 110 may execute a retry mechanism when a network communication problem occurs or when the TCU 104 stops working so that no data is received in response to a log request sent from the diagnostic server 110 (e.g., the TCU 104 is in a sleep state, turned off).

[0048] Although Figure 1 An exemplary system 100 is shown in FIG. Figure 1 The example components shown in are not intended to be limiting. In practice, the system 100 may have more or fewer components, and additional or alternative components and / or implementations may be used. As a non-limiting example, the recorder 124 and its corresponding functionality may reside in one or more controllers 116 of the vehicle 102 in addition to the TCU 104.

[0049] Figure 2A process 200 for monitoring, reporting, and resolving TCU faults is shown. The process 200 shows the communication between the TCU 104 and the diagnostic server 110 via the data agent 108. The TCU 104 can establish an MQTT session with the data agent 108 to facilitate the transmission of logged data from the TCU 104 to the diagnostic server 110. Compared to HTTP or HTTPS sessions (which must be established for each one-way communication), MQTT sessions can be established as a two-way communication channel for several hours (e.g., up to four hours) and support larger payloads of more than 200MB, each of which reduces system latency when transmitting logged data. In addition, as described in more detail below, the data agent 108 can be used as a buffer or cache for storing messages or transmitted data, so if one of the endpoints (e.g., the TCU 104 or the diagnostic server 110) cannot receive the message or data, the data agent 108 can save the message or data and retry the transmission later. This feature may enable the transmitting component (e.g., vehicle 102) to free up system resources more quickly by deleting the transmitted data from memory before it is received by diagnostic server 110. In an alternative embodiment, the communication between TCU 104 and diagnostic server 110 may be direct (i.e., log transmissions from TCU 104 are directed specifically to diagnostic server 110 and vice versa for log requests).

[0050] At index (A), the diagnostic server 110 may send a request to the data agent 108 to subscribe to one or more TCU logs of one or more TCUs 104. In this way, whenever the TCU 104 sends (also referred to as "publishing") TCU-recorded data to the data agent 108, the data agent 108 may push the TCU-recorded data to any subscribers of the TCU-recorded data (including the diagnostic server 110). In some embodiments, the subscription request may indicate one or more specific types (also referred to as "topics") of TCU-recorded data that the user expects the diagnostic server 110 to receive. For example, the subscription request may include a string such as "TCU104 / log / wireless", which may indicate that the diagnostic server 110 expects to receive logs published by the TCU 104, particularly those related to network failures. Alternatively, the subscription request may include a string such as "TCU104 / log / TCUcomponent", which may indicate that it is expected to receive logs published by the TCU 104, particularly those related to TCU component failures. As another alternative, the subscription request may indicate that the diagnostic server 110 desires to receive all TCU logs published by the TCU 104. The specific syntax of the topics associated with the data published by the TCU 104 (and by the diagnostic server 110) may be defined and coordinated between the TCU 104 and the diagnostic server 110 prior to any monitoring and transmission.

[0051] At index (B), wireless activity data of the TCU 104 may be collected and temporarily stored and / or recorded in a log. The wireless activity data may detail one or more wireless activities performed by the TCU 104 at a given time. At index (C), a TCU fault may be identified and / or recorded. For example, a network or cellular fault may occur, which may prevent the TCU 104 from establishing a connection with the network 112, preventing the wireless activity data from being temporarily stored or recorded. Alternatively, a component of the TCU 104 may fail. In response to detecting a TCU fault, if the fault has not been recorded in the log, the TCU 104 may record the fault data in an appropriate log (e.g., wireless log 126, component log 128) for identifying the fault. In the case of a network fault, the TCU 104 may record network fault data for identifying and / or detailing the network fault in the wireless log 126. In the case of a TCU component fault, the TCU 104 may record TCU component fault data for identifying and / or detailing the component fault in the component log 128.

[0052] At index (D), in response to a TCU fault occurring and / or being recorded, the TCU 104 may transmit at least a portion of one or more stored fault logs to the diagnostic server 110 outside the vehicle 102. More specifically, the TCU 104 may publish at least a portion of the one or more logs to the data agent 108. As part of the publication, the TCU 104 may include a defined topic (e.g., TCU104 / log / wireless) to which the diagnostic server 110 has previously subscribed, the defined topic being used to describe the publication and / or fault type. At index (E), the data agent 108 may send / publish to the TCU 104 an acknowledgment indicating receipt of the publication.

[0053] At index (F), the data proxy 108 may push one or more published recorded data to the diagnostic server 110. More specifically, when receiving a publication from the TCU 104, the data proxy 108 may identify that the diagnostic server 110 is a subscriber to the associated topic included in the publication from the TCU 104. In response, the data proxy 108 may send the recorded data to the diagnostic server 110. At index (G), the diagnostic server 110 may send or publish a confirmation to the data proxy 108 indicating that the recorded data was correctly received. At index (H), the data proxy 108 may send or publish a confirmation to the TCU 104 indicating that the subscriber (in this case, the diagnostic server 110) received the publication from the TCU 104.

[0054] When sending / publishing data, the TCU 104 and / or the data agent 108 may wait for at least one confirmation that the data was correctly received by the intended party or parties. In some embodiments, the TCU 104 may be configured to expect multiple confirmations, one confirmation from the data agent 108 indicating that the data was correctly received by the data agent 108, and another confirmation from the data agent 108 indicating that the data was correctly received by the subscriber of the publication (or in this case, the diagnostic server 110). If the TCU 104 and / or the data agent 108 does not receive the expected confirmation within a predetermined time after the sending / publishing, the TCU 104 and / or the data agent 108 may execute a retry mechanism and resend / republish the data to the intended recipient. For example, if the TCU 104 does not receive a confirmation at index (E), the TCU 104 may retry the sending / publishing.

[0055] With respect to data transmission / publishing failures, the data agent 108 helps alleviate the demand on the computing resources of the TCU 104. In addition to logging, the TCU 104 can provide communication between each controller 116, as well as between the controller 116 and the remote system 106 via the network 112. If the TCU 104 receives confirmation at index (E), but the diagnostic server 110 fails and cannot receive the published data, the TCU 104 can rely on the retry mechanism of the data agent 108 rather than attempting to retry the transmission itself. In this way, the TCU 104 does not need to expend computing resources to continuously store and attempt to resend the data to the diagnostic server 110, because the TCU 104 has confirmed that the data agent 108 has the data and will attempt to resend the data at each retry mechanism. This enables the TCU 104 to use its computing resources for other functions or subsequent logging, thereby improving the overall efficiency of the TCU 104 and the vehicle 102. Thus, in some embodiments, in response to receiving confirmation that the recorded data was received by the data agent 108 and before the recorded data is received by the diagnostic server 110 , the recorder 124 and / or the TCU 104 may delete the transmitted recorded data from the memory 122 of the TCU 104 .

[0056] For the sake of brevity, the remaining exemplary embodiments shown in process 200 omit confirmation of sending or publishing. However, it will be understood that in response to sending or publishing data, any one or more of the sending or publishing systems may expect to receive at least one response in the form of a confirmation. If such a response is not received within a predetermined time of sending or publishing data, any one or more of the sending or publishing systems may include a retry mechanism.

[0057] Index (I) to index (K) illustrate another embodiment. At index (I), the non-volatile memory dedicated to storing the logs of the TCU 104 may become full or nearly full. When this occurs and / or periodically, the logger 124 may automatically publish the stored TCU logs to the data agent 108 at index (J). The published logs may include one or more topics describing the contents of the logs. At index (K), the data agent 108 may identify the diagnostic server 110 as a subscriber to one or more topics associated with the published logs, and may push the logs to the diagnostic server 110 based on the subscription.

[0058] Index (L) to index (O) illustrate another embodiment, in which the diagnostic server 110 requests TCU fault logs from the TCU 104 as needed. At index (L), the diagnostic server 110 may issue a log request to the data agent 108. Specifically, a user may request one or more logs from the TCU 104 via the GUI of the diagnostic server 110. Thereafter, the data agent 108 may identify that the TCU 104 is a subscriber to the request (such as based on the subject included in the request). At index (M), the data agent 108 may push the request to the TCU 104. In response to receiving the request, at index (N), the TCU 104 may publish the requested one or more logs to the data agent 108. At index (O), the data agent 108 may send the requested logs to the diagnostic server 110 (such as based on one or more associated topics sent with the logs subscribed by the diagnostic server 110) to satisfy the request.

[0059] Index (P) to Index (S) illustrate an embodiment of the process 200 after the recorded TCU data is received by the diagnostic server 110. At index (P), the diagnostic server 110 may generate a repair for a TCU fault included in the recorded TCU data. For example, the diagnostic server 110 may query a repair database 111 based on the TCU fault to identify a solution (such as a software patch, firmware update, etc.) for the fault. Alternatively, or in the event that no predetermined solution is accessible, the diagnostic server 110 may be configured to dynamically generate a solution for the fault. Additionally or alternatively, a user may generate or upload a solution using the GUI of the diagnostic server 110.

[0060] At index (Q), the diagnostic server 110 may publish the selected fix to the data proxy 108. At index (R), the data proxy 108 may recognize that the TCU 104 is a subscriber to the associated topic sent with the fix, and may push the fix to the TCU 104. At index (S), the TCU 104 may apply the fix (such as by installing a firmware update, etc.).

[0061] For example, the logged TCU data received by the diagnostic server 110 may identify a TCU component failure. Thus, in response to receiving the TCU log data, the diagnostic server 110 may be configured to identify a fix (such as a firmware update) from the fix database 111. In response to receiving the firmware update, the TCU 104 may be configured to install the firmware update on the TCU 104.

[0062] As another example, the recorded TCU data received by the diagnostic server 110 may identify a cellular network failure (such as a slower than expected cellular network connection). Therefore, in response to receiving the recorded TCU data, the diagnostic server 110 may be configured to identify a fix in the form of computer instructions to utilize a different cellular network, the selection of which may be based on the geographic location of the vehicle 102 included in the received recorded TCU data. In response to receiving the fix, the TCU 104 may be configured to utilize a different cellular network to achieve a better cellular network connection.

[0063] In general, routines executed to implement embodiments of the present invention (whether implemented as part of an operating system, or implemented as a specific application, component, program, object, module or sequence of instructions, or even as a subset thereof) may be referred to herein as "computer program code" or "program code". Program code typically includes computer-readable instructions that reside in various memories and storage devices in a computer at various times, and when one or more processors in a computer read and execute the computer-readable instructions, cause the computer to perform the operations and / or operations necessary to embody the various aspects of the embodiments of the present invention. The computer-readable program instructions for performing the operations of embodiments of the present invention may be source code or object code written, for example, in assembly language or in any combination of one or more programming languages.

[0064] Various program codes described herein can be identified based on the application, and various program codes in the application can be implemented in the specific embodiments of the present invention. However, it should be understood that any specific program terminology below is used only for convenience, and therefore the present invention should not be limited to being used only in any specific application identified and / or implied by such terminology. In addition, considering that computer programs can be organized into routines, processes, methods, modules, objects, etc. in countless ways, and considering that program functions can be distributed in various ways among various software layers (e.g., operating systems, libraries, APIs, applications, applets, etc.) residing in typical computers, it should be understood that embodiments of the present invention are not limited to the specific organization and distribution of program functions described herein.

[0065] The program code embodied in any application / module described herein can be distributed individually or jointly as a program product in various different forms. Specifically, the program code can be distributed using a computer-readable storage medium having computer-readable program instructions thereon, and the computer-readable program instructions are used to cause a processor to perform various aspects of an embodiment of the present invention.

[0066] Computer-readable storage media that are non-transitory in nature may include volatile and non-volatile, as well as removable and non-removable tangible media implemented in any method or technology for storing information (e.g., computer-readable instructions, data structures, program modules, or other data). Computer-readable storage media may also include RAM, ROM, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other solid-state memory technology, portable compact disk read-only memory (CD-ROM) or other optical memory, cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be read by a computer. The computer-readable storage medium itself should not be interpreted as a transient signal (e.g., a radio wave or other propagating electromagnetic wave, an electromagnetic wave propagated through a transmission medium (such as a waveguide), or an electrical signal transmitted through a cable). Computer-readable program instructions may be downloaded from the computer-readable storage medium to a computer, another type of programmable data processing device, or another device, or downloaded to an external computer or external storage device via a network.

[0067] Computer-readable program instructions stored in a computer-readable medium may be used to instruct a computer, other type of programmable data processing device, or other apparatus to operate in a particular manner, so that the instructions stored in the computer-readable medium produce an article of manufacture including instructions that implement the functions, actions, and / or operations specified in the flowchart, sequence diagram, and / or block diagram. The computer program instructions may be provided to one or more processors of a special-purpose computer, a general-purpose computer, or other programmable data processing device to produce a machine, so that the instructions executed by one or more processors cause a series of calculations to be performed to implement the functions, actions, and / or operations specified in the flowchart, sequence diagram, and / or block diagram.

[0068] In some alternative embodiments, the functions, actions and / or operations specified in the flow chart, sequence diagram and / or block diagram may be reordered, serially processed and / or processed simultaneously according to embodiments of the present invention. In addition, any one of the flow chart, sequence diagram and / or block diagram may include more or less frames than the frames shown in embodiments of the present invention.

[0069] The terms used herein are only used for the purpose of describing specific embodiments and are not intended to limit embodiments of the present invention. Unless otherwise clearly indicated in the context, the singular form used herein is also intended to include the plural form. It will also be understood that when the term "comprising" is used in the specification, the existence of the features, wholes, steps, operations, elements and / or components described is specified, but the existence or addition of one or more other features, wholes, steps, operations, elements, components and / or combinations thereof is not excluded. In addition, with respect to the terms "comprising", "having", "consisting of..." or variations thereof used in the specific embodiments or claims, these terms are intended to be inclusive in a manner similar to the term "comprising".

[0070] Although all aspects of the present invention have been described by describing various embodiments and these embodiments have been described in considerable detail, the applicant does not intend to limit or in any way restrict the scope of the claims to such details. Additional advantages and modifications will be readily apparent to those skilled in the art. Therefore, the present invention in its broader aspects is not limited to the specific details, representative devices and methods, and illustrative examples shown and described. Therefore, different changes in such details may be made without departing from the spirit or scope of the applicant's overall inventive concept.

Claims

1. A vehicle comprising: The telematics control unit TCU is configured as follows: periodically recording wireless activity data associated with authentication, attachment, signaling, detachment, and handover procedures of the TCU in a first log to provide one or more remote vehicle services; In response to detecting a cellular failure from the logged data, wirelessly transmitting at least a portion of a first log corresponding to the cellular failure to a remote diagnostic server outside the vehicle, The TCU is further configured to perform the following operations in response to a component failure of the TCU: recording data indicating the component failure in a second log of the TCU; At least a portion of the first log and the second log are wirelessly transmitted to a remote diagnostic server outside the vehicle.

2. The vehicle according to claim 1, wherein: The at least a portion of the transmitted first log also includes data related to operation of the TCU collected by the TCU after the cellular failure is detected.

3. The vehicle according to claim 1, wherein: The periodically recorded wireless activity data includes first data and second data, wherein the first data is related to the authentication, attachment, signaling, detachment or switching activities of the TCU corresponding to the cellular fault, and the second data is related to the authentication, attachment, signaling, detachment or switching activities of the TCU not associated with the cellular fault.

4. The vehicle according to claim 3, wherein: The transmitted first log includes the first data but does not include the second data, and the TCU is further configured to: in response to detecting a cellular failure, discard the second data without transmitting the second data outside the vehicle.

5. The vehicle according to claim 1, wherein: The component failures include diagnostic trouble codes, firmware wireless update failures, input / output failures, global positioning failures, message broker connection issues, or memory read / write failures.

6. The vehicle according to claim 1, wherein: The TCU is further configured to perform the following operations in response to the component failure: identifying data in the first log associated with a timestamp within a predefined time period immediately prior to the component failure; The identified data is wirelessly transmitted to a remote diagnostic server external to the vehicle.

7. The vehicle according to claim 6, wherein: The TCU is further configured to, in response to the component failure, discard data in the first log that is not associated with a timestamp within a predefined time period immediately before the component failure, wherein the discarded data is not sent to a remote diagnostic server outside the vehicle.

8. A method for vehicle communication, comprising: The following operations are performed via the vehicle's telematics control unit TCU: periodically recording wireless activity data associated with authentication, attachment, signaling, detachment, and handover procedures of the TCU in a first log to provide one or more remote vehicle services; In response to detecting a cellular fault from the first log, wirelessly transmitting at least a portion of the first log corresponding to the cellular fault to a remote diagnostic server outside the vehicle, The method further includes performing the following operations in response to a component failure of the TCU: recording data indicative of a component failure in a second log; At least a portion of the first log and the second log are wirelessly transmitted to a remote diagnostic server outside the vehicle.

9. The method according to claim 8, wherein: The component failures include diagnostic trouble codes, firmware wireless update failures, input / output failures, global positioning failures, message broker connection issues, or memory read / write failures.

10. The method according to claim 8, wherein: The cellular failure is a slow cellular network connection, and the method further comprises: In response to receiving a fix corresponding to the first log from the remote diagnostic server, connecting to a different cellular network, wherein the fix defines instructions for the TCU to use the different cellular network.

11. The method according to claim 8, wherein: The step of sending at least a portion of the first log outside the vehicle includes: sending the first log and an associated topic to a data agent outside the vehicle, wherein, in response to receiving the first log, the data agent is configured to: send the first log to a remote diagnostic server in response to identifying the remote diagnostic server as a subscriber to the topic.

12. The method according to claim 11, further comprising: In response to receiving an acknowledgement from the data broker before the first log is received by the remote diagnostic server, the contents of the first log are deleted from the TCU.

13. The method according to claim 8, further comprising: In response to a sending failure, inserting the at least a portion of the first log into a cache memory for the failed sending log data; In response to a data size of the failed transmission log data in the cache memory exceeding a threshold, wirelessly retrying to transmit the at least a portion of the first log to a remote diagnostic server outside the vehicle.

14. A diagnostic server, comprising: A processor is geographically remote from a vehicle, the vehicle including a telematics control unit (TCU), the TCU configured to generate a first log of wireless activity specific to the TCU and a second log of component failures specific to the TCU, the processor configured to send a request for the first log and the second log, wherein, in response to the request, at least a portion of the first log and the second log are received by the processor.

Images