Vehicle fault diagnosis system based on TBOX

Abstract

The invention provides a TBOX-based vehicle fault diagnosis system, which is characterized in that a TBOX is installed in a vehicle and is used for acquiring vehicle data and judging whether the vehicle has a fault based on the vehicle data, and when the vehicle has the fault, the TBOX enters a diagnosis and maintenance mode, and the diagnosis and maintenance mode comprises a field diagnosis mode and a remote diagnosis mode; the diagnosis end is used for establishing a data communication channel with the TBOX in a diagnosis maintenance mode; and the TBOX is also used for transmitting the vehicle fault data to the diagnosis end through the data communication channel, receiving a vehicle configuration instruction issued by the diagnosis end, and issuing the vehicle configuration instruction to a target ECU unit of the vehicle to realize vehicle fault diagnosis full-link diagnosis operation. According to the scheme, a traditional fault diagnosis instrument is omitted, hardware cost of vehicle service diagnosis is reduced, usability and convenience of vehicle diagnosis are provided, and transmission safety and reliability between the TBOX and a platform or a terminal are guaranteed through a self-developed data transmission protocol.

Description

Technical Field

[0001] This application relates to the field of after-sales service for automotive electronic control systems, and more specifically, to a vehicle fault diagnosis system based on TBOX. Background Technology

[0002] When a vehicle malfunctions or requires maintenance, repair personnel typically use a dedicated diagnostic tool connected to the vehicle's OBD interface to diagnose the problem. Diagnostics generally include testing and diagnosing the engine, the ECU (Electronic Control Unit), the body and accessories, and exhaust emissions and noise. Traditional automotive diagnostic tools primarily use a wired connection, accessing the vehicle's CAN bus based on the diagnostic communication protocols of various electronic control components. By reading and parsing data, the tool interacts with the user through its human-machine interface (HMI) to help repair personnel identify vehicle faults. However, due to software updates to the diagnostic protocols of various electronic control components, traditional diagnostic tools often suffer from outdated firmware and incompatibility with the vehicle's diagnostic protocols.

[0003] Currently, to meet regulatory requirements (GB32960 and HJ1239 protocols), most vehicles are equipped with TBOX (Telematics Vehicle Optimization Box), whose main function is to collect regulatory-related data and send it to the national platform. TBOX installation has become standard equipment in vehicles. On-site and remote vehicle diagnostics solutions based on TBOX can directly reduce the hardware cost of diagnostic tools. Whether it's possible to eliminate the hardware investment in OBD interface diagnostic tools and directly use TBOX for on-site and remote vehicle diagnostics is a hot research topic in this field. However, the current challenges mainly lie in: how to securely and reliably establish a communication channel between the remote diagnostic platform and mobile terminals (such as smart terminals with corresponding apps, like mobile phones, tablets, and laptops) and the TBOX for convenient remote or on-site diagnostics and repairs; and how to provide conditions adapted to different vehicle models to ensure system compatibility. Summary of the Invention

[0004] The purpose of this application is to provide a vehicle fault diagnosis system based on a TBOX. By using a TBOX installed in the vehicle itself, the traditional fault diagnostic instrument is eliminated, reducing the hardware cost of vehicle service diagnosis, providing ease of use and convenience for vehicle diagnosis, and ensuring the security and reliability of transmission between the TBOX and the platform or terminal through a self-developed data transmission protocol. When adaptation and compatibility are required, the OTA component can upgrade the vehicle ECU firmware through the TBOX, making it compatible with the diagnostic end of the vehicle fault diagnosis system. In order to ensure reliable flashing, an alternating upgrade strategy of A and B partitions is adopted to avoid flashing anomalies.

[0005] To achieve the above objectives, the embodiments of this application are implemented in the following manner: This application provides a vehicle fault diagnosis system based on a TBOX, comprising: a TBOX installed in the vehicle for acquiring vehicle data and determining whether a fault exists in the vehicle based on the data; when a fault exists, the TBOX enters a diagnostic and repair mode; wherein the vehicle has an integrated ECU unit that communicates with the TBOX via the vehicle's CAN bus; the diagnostic and repair mode includes an on-site diagnostic mode and a remote diagnostic mode; a diagnostic terminal for establishing a data communication channel with the TBOX in the diagnostic and repair mode; wherein the diagnostic terminal includes a mobile terminal and a remote diagnostic platform; in the on-site diagnostic mode, the TBOX establishes wireless communication with the mobile terminal via a wireless communication module; in the remote diagnostic mode, the TBOX establishes mobile communication with the remote diagnostic platform via a 4G or 5G mobile communication module; the TBOX also transmits vehicle fault data to the diagnostic terminal via the data communication channel and receives vehicle configuration commands issued by the diagnostic terminal, and then issues the vehicle configuration commands to the target ECU unit of the vehicle via the CAN bus, realizing a full-link vehicle fault diagnosis operation; wherein the full-link vehicle fault diagnosis operation includes intelligent fault code parsing, remote component testing, real-time data stream monitoring, ECU information management, and secure ECU data flashing.

[0006] Furthermore, TBOX is specifically used for: determining whether vehicle parts have fault information based on vehicle data; and when vehicle parts have fault information, determining whether the vehicle has a whole-vehicle fault based on the fault information of the vehicle parts.

[0007] Furthermore, when the diagnostic terminal is a mobile terminal, the diagnostic terminal is specifically used to: establish wireless communication with the TBOX through the TBOX's wireless communication module, and establish a secure communication link with the TBOX using a dynamic authentication mechanism based on digital certificates; after the diagnostic terminal triggers the TBOX's diagnostic and maintenance mode, it displays the diagnostic and maintenance interface on the diagnostic terminal according to the user role permissions of the authorized personnel, and determines the diagnostic permissions and data access scope of the authorized personnel.

[0008] Furthermore, when the diagnostic end is a remote diagnostic platform, the diagnostic end is specifically used to: establish mobile communication with the TBOX through the TBOX's 4G or 5G mobile communication module, and establish a secure communication link with the TBOX using a dynamic authentication mechanism based on digital certificates.

[0009] Furthermore, the TBOX internal software incorporates a multi-layered communication protocol architecture, specifically: the vehicle's CAN bus serves as the CAN physical layer, with TBOX integrating HJ1239, GB32960, UDS, and automaker-customized CAN protocols as the CAN communication protocol layer; the TCP application layer is based on Ethernet communication, with TBOX integrating GB32960, HJ1239, automaker-customized platform protocols, and diagnostic terminal communication protocol encapsulation components as the network application layer; TBOX integrates national standard platform, mobile terminal APP, and enterprise remote diagnostic platform application communication components as the application communication layer; the TBOX's built-in multi-layered communication protocol architecture is flexible and decoupled, supporting the formation of a full-link fault diagnosis architecture among the vehicle, TBOX, mobile terminal, remote diagnostic platform, and national standard platform.

[0010] Furthermore, when there is no vehicle malfunction, TBOX is also used to encapsulate vehicle data transmitted via the vehicle's CAN bus according to the GB32960 and HJ1239 protocols and transmit it to the national standard platform.

[0011] Furthermore, when communicating with the TBOX at the diagnostic end, a self-developed data transmission protocol is used for encrypted data transmission. The data packet structure corresponding to the self-developed data transmission protocol is as follows: frame header, frame type, frame length, frame content, and frame checksum. The frame header occupies 2 bytes and is used to reveal the transmission flow of the data packet. The frame type occupies 1 byte and is used to reveal the message frame type of the data packet. The frame length occupies 2 bytes and is used to reveal the data unit length of the data packet. The frame content occupies n bytes and reveals the transmitted data content. The frame checksum occupies 1 byte and is used for BCC verification.

[0012] Furthermore, the multi-layer communication protocol architecture also includes an OTA component, which is used to communicate with the TBOX through a custom protocol of the car manufacturer to upgrade the ECU firmware. The ECU firmware upgrade data is transmitted in TCP packets, with each packet having its own content verification and the entire firmware upgrade data being verified and signed.

[0013] Furthermore, TBOX employs an A / B partition strategy, alternating between partitions A and B during ECU firmware upgrades. When a firmware upgrade anomaly occurs in partition A, TBOX boots from partition B to run the unupgraded ECU firmware version and then re-executes the ECU firmware upgrade in partition A. Conversely, when a firmware upgrade anomaly occurs in partition B, TBOX boots from partition A to run the upgraded ECU firmware version and then re-executes the ECU firmware upgrade in partition B, ensuring reliable flashing.

[0014] Furthermore, the remote diagnostic platform adopts a microservice distributed architecture to support large-scale concurrent vehicle diagnostics and data analysis.

[0015] To achieve the above objectives, the embodiments of this application are implemented in the following manner: This solution, based on the TBOX, enables vehicle fault diagnosis, completely revolutionizing the hardware dependence and communication architecture of traditional diagnostic methods and achieving software-hardware decoupling of the diagnostic system. The core bottleneck of traditional diagnostic tools lies in their tangible, fixed, dedicated hardware. Their firmware updates are lagging, protocol compatibility is poor, and they must be wired through a physical OBD interface, resulting in limited application scenarios, high costs, and difficult maintenance. This solution reconstructs the TBOX, a network terminal standard in most vehicles, into a diagnostic middleware layer. It leverages its existing CAN bus access capabilities (for communication with the vehicle's ECU unit), mobile communication capabilities (4G / 5G modules), and wireless communication capabilities (wireless modules such as Bluetooth and Wi-Fi) to build a completely new diagnostic architecture. Specifically, the TBOX integrates GB32960, HJ1239, UDS, and automaker-customized protocol stacks, making it a standardized protocol conversion hub between the vehicle's CAN network and external diagnostic terminals. This eliminates the need for mobile terminals (on-site diagnostic mode) or remote diagnostic platforms (remote diagnostic mode) to directly interact with a variety of original vehicle protocols. Instead, they interact through the unified middleware layer of the TBOX, fundamentally solving the compatibility problem of adapting to multiple vehicle models. In on-site diagnostic mode, repair personnel can establish a secure wireless connection with the TBOX using a universal terminal (such as a mobile phone or tablet) to obtain the same human-machine interface and diagnostic functions as traditional diagnostic tools. This saves the cost of purchasing dedicated hardware (by reusing the vehicle's existing TBOX hardware, expensive and dedicated traditional diagnostic tools are completely eliminated, saving service outlets significant costs in equipment procurement, maintenance, and updates). It is also more convenient (repair personnel can quickly complete diagnostics using their smartphones, eliminating the time spent searching for, borrowing, and waiting for dedicated equipment, significantly improving on-site service efficiency). In remote diagnostic mode, the TBOX can connect to a remote diagnostic platform via its built-in mobile communication module. This allows technical support experts to monitor vehicle data in real time, analyze faults, and remotely configure the vehicle, overcoming geographical limitations. This centralizes diagnostic resources and improves service efficiency. Experts do not need to be physically present; they can obtain complete fault data and perform preliminary analysis and calibration through the remote platform, achieving "data travels more, experts travel less," significantly shortening the fault diagnosis cycle and reducing travel costs. This approach, centered on the existing vehicle hardware (TBOX) and utilizing its multi-mode communication capabilities (WiFi / Bluetooth / 4G / 5G), not only significantly reduces hardware investment and maintenance costs for diagnostics but also expands the diagnostic scenario from requiring physical presence at the vehicle to anytime, anywhere diagnostics. The seamless integration of "on-site mobile terminal + remote cloud" diagnostic solution breaks down geographical limitations of diagnostic operations, enabling both rapid on-site repairs and in-depth intervention by backend experts, greatly enhancing convenience.

[0016] This solution also constructs a secure, reliable, and scalable end-to-end diagnostic and data management system, providing enterprise-level technical support from communication security and protocol encapsulation to system upgrades. Addressing the core security and reliability challenges of remote diagnostics, this solution optimizes design at multiple levels: At the communication security level, a dynamic authentication mechanism based on digital certificates is used to establish a secure link for both on-site wireless connections and remote mobile communication, ensuring the trustworthiness of the diagnostic channel endpoints and the confidentiality of communication. At the data transmission level, when the diagnostic end is a mobile terminal, an innovative self-developed encrypted transmission protocol is designed. This protocol possesses a complete packet structure with frame header, type, length, content, and verification, defining not only the data flow and type but also ensuring data integrity during transmission through BCC verification. This protocol is suitable for achieving efficient and reliable data exchange in bandwidth-constrained mobile network environments. Regarding system reliability and maintainability, for the high-risk operation of ECU firmware upgrades (flashing), an organic combination of A / B partitioning strategy and OTA (Over-The-Air) technology is adopted. TBOX's A / B partition design enables seamless rollback, ensuring that even if a single partition upgrade fails, the device can still boot from another healthy partition, maintaining basic vehicle functions and automatically triggering a retry, greatly improving the reliability of the flashing process. Simultaneously, the OTA upgrade process employs TCP packet transmission, packet verification, and overall signature verification to ensure the integrity and authenticity of firmware data transmission. Through a modular, OTA-upgradeable diagnostic protocol stack, the system can keep pace with the times, quickly adapting to new vehicle models and standards, making the pain point of traditional diagnostic tools being "obsolete when firmware becomes outdated" a thing of the past.

[0017] Furthermore, TBOX, acting as both a "fault diagnosis middleware layer" and a "regulatory data reporting unit," serves multiple business functions, including diagnostics, national standard platform data reporting, and interaction with OTA components, through a unified multi-layered protocol architecture (CAN physical layer, CAN communication protocol layer, and application communication layer). This achieves a high degree of integration and reuse of hardware resources and software functions. The integrated design, encompassing secure links, reliable transmission, worry-free upgrades, and a flexible platform, not only ensures the security and stability of the diagnostic business itself but also lays a solid and flexible technical foundation for future iterations of diagnostic functions, rapid integration with new vehicle models, and the expansion of big data analysis and predictive maintenance services.

[0018] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a schematic diagram of a vehicle fault diagnosis system based on TBOX provided in an embodiment of this application.

[0021] Figure 2 This is a hardware resource diagram of TBOX.

[0022] Figure 3 This is a schematic diagram of a multi-layer communication protocol architecture.

[0023] Figure 4 This describes the diagnostic workflow for a TBOX-based vehicle fault diagnosis system.

[0024] Figure 5 This is the fault diagnosis process for TBOX based on vehicle data.

[0025] Figure 6 This is a schematic diagram of the functional modules of the mobile terminal software for a vehicle fault diagnosis system. Detailed Implementation

[0026] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0027] Please see Figure 1 , Figure 1 This diagram illustrates a vehicle fault diagnosis system based on a TBOX, as provided in an embodiment of this application. The system includes a diagnostic terminal and a TBOX built into the vehicle. The vehicle has an integrated ECU unit that communicates with the TBOX via the vehicle's CAN bus. The diagnostic terminal includes a mobile terminal (e.g., a smartphone, tablet, laptop, etc.) and a remote diagnostic platform (i.e., a server or server cluster). The remote diagnostic platform employs a microservice distributed architecture to support large-scale concurrent vehicle diagnostics and data analysis. This microservice distributed architecture allows the platform to scale elastically, handle massive concurrent vehicle diagnostic requests, and provide highly available data analysis services.

[0028] like Figure 2 As shown, Figure 2This is a hardware resource block diagram of TBOX. TBOX has a built-in MCU (microcontroller, i.e., single-chip microcomputer), 4G or 5G communication module, CAN transceiver, Bluetooth communication module (i.e., Bluetooth module), WIFI communication module (i.e., WIFI module), FLASH storage, and is powered by the vehicle's power supply to ensure the normal operation of TBOX.

[0029] like Figure 3 As shown, the TBOX internal software includes a multi-layered communication protocol architecture. Specifically, it uses the vehicle's CAN bus as the CAN physical layer, and incorporates HJ1939, UDS, and automaker-customized CAN protocols as the CAN communication protocol layer. The TBOX also incorporates GB32960, HJ1239, automaker-customized platform protocols, diagnostic terminal communication protocol encapsulation components, and fault classification and deduplication components as the fault diagnosis middleware layer. Finally, the TBOX incorporates national standard platform, mobile terminal APP, and enterprise remote diagnostic platform application communication components as the application communication layer. The TBOX's multi-layered communication... The protocol architecture is flexible and decoupled, supporting a full-link fault diagnosis architecture encompassing vehicles, TBOX, mobile terminals, remote diagnostic platforms, and national standard platforms. TBOX, as a key link in both on-site and remote fault diagnosis, can convert and encapsulate CAN data. For example, it can encapsulate data according to national standard protocols (such as HJ1939 and GB32960) and send it to the national standard platform (i.e., national standard platform communication), or according to automaker-defined protocols and send it to the remote diagnostic platform (i.e., enterprise platform communication), or according to the UDS protocol and send it to the mobile terminal (i.e., mobile app communication). As a fault diagnosis middleware layer, TBOX can also perform fault identification, fault deduplication, and fault classification.

[0030] The multi-layer communication protocol architecture also includes an OTA component, which is used to communicate with the TBOX through a custom protocol of the car manufacturer to upgrade the ECU firmware. The ECU firmware upgrade data is transmitted in TCP packets, with separate content verification for each packet, and the entire firmware upgrade data is verified and signed.

[0031] TBOX employs an A / B partition strategy, alternating between partitions A and B during ECU firmware upgrades. When a firmware upgrade anomaly occurs in partition A, TBOX boots from partition B to run the unupgraded ECU firmware version and then re-executes the ECU firmware upgrade in partition A. Conversely, when a firmware upgrade anomaly occurs in partition B, TBOX boots from partition A to run the upgraded ECU firmware version and then re-executes the ECU firmware upgrade in partition B, ensuring reliable flashing.

[0032] In terms of system reliability and maintainability, a combination of A / B partitioning strategy and OTA (Over-The-Air) technology is adopted for the high-risk operation of ECU firmware upgrade (flashing). TBOX's A / B partitioning design achieves "seamless rollback" capability, ensuring that even if a single partition upgrade fails, the device can still boot from another healthy partition, maintain basic vehicle functions, and automatically trigger a retry, greatly improving the reliability of the flashing process. Simultaneously, the OTA upgrade process uses TCP packet transmission, packet verification, and overall signature to ensure the integrity and authenticity of firmware data transmission. Through a modular, OTA-upgradable diagnostic protocol stack, the system can keep pace with the times and quickly adapt to new vehicle models and standards, making the pain point of traditional diagnostic tools being "obsolete when firmware becomes outdated" a thing of the past.

[0033] To facilitate understanding of the TBOX-based vehicle fault diagnosis system, the system's operation flow is described here. Please refer to [link / reference needed]. Figure 4 , Figure 4 This describes the diagnostic workflow for a TBOX-based vehicle fault diagnosis system.

[0034] First, the TBOX can acquire vehicle data (data from each ECU unit in the vehicle via the CAN bus) and perform fault monitoring. Based on the vehicle data, the TBOX can determine whether there is fault information in vehicle components, and when fault information is found in vehicle components, it can determine whether there is a vehicle-wide fault based on the fault information of the vehicle components.

[0035] For example, TBOX's fault diagnosis process based on vehicle data is as follows: Figure 5 As shown, TBOX performs the following judgment process: (1) Obtain vehicle component fault information; (2) Determine if the vehicle has any faults; (3) If yes, then determine the fault level of the whole vehicle; if no, then proceed to step (2). (4) If it is a Level 1 or Level 2 fault (Level 1 and Level 2 faults are faults that do not affect the normal use of the vehicle, such as high intake manifold pressure), then proceed to step (5); if it is a Level 3 fault (Level 3 faults will affect the normal use of the vehicle, and the vehicle will be in a reduced torque mode, such as an open circuit in the engine ignition coil), then proceed to step (6). (5) Enter the diagnostic and maintenance mode through the authorized operation command of the staff and execute step (2); (6) Automatically switch to diagnostic and maintenance mode.

[0036] If the vehicle data for a given period is determined to be free of vehicle malfunction, the TBOX will encapsulate the vehicle data for that period transmitted via the vehicle's CAN bus according to the HJ1239 and GB32960 protocols and transmit it to the national standard platform, thus completing step S101.

[0037] If a vehicle malfunction is found, the TBOX will enter diagnostic and repair mode, thus completing step S102.

[0038] At this point, the diagnostic terminal can establish a data communication channel with the TBOX in diagnostic and maintenance mode. Diagnostic and maintenance modes include on-site diagnostic mode and remote diagnostic mode. In on-site diagnostic mode, the TBOX establishes wireless communication with the mobile terminal via a wireless communication module. In remote diagnostic mode, the TBOX establishes mobile communication with the remote diagnostic platform via a 4G or 5G mobile communication module.

[0039] For example, when the diagnostic terminal is a mobile terminal, it can establish wireless communication with the TBOX via the TBOX's wireless communication module and use a dynamic authentication mechanism based on digital certificates to establish a secure communication link with the TBOX. After the diagnostic terminal triggers the TBOX's diagnostic and maintenance mode (the TBOX enters diagnostic and maintenance mode under the operation of authorized personnel, or automatically switches to diagnostic and maintenance mode), the diagnostic terminal can display the diagnostic and maintenance interface according to the authorized personnel's user role permissions and determine the authorized personnel's diagnostic permissions and data access scope. Figure 6 As shown, the mobile terminal software functional modules of the vehicle fault diagnosis system may include data stream monitoring, fault code reading, function switch setting, component testing, ECU version information, ECU data burning, etc.

[0040] The TBOX communicates with the mobile app (i.e., the mobile terminal) using a custom CAN-WIFI / Bluetooth protocol. The data packet structure corresponding to this self-developed data transmission protocol is shown in Table 1. Table 1 Data Packet Structure

[0041] Specifically, the data packet structure includes a frame header, frame type, frame length, frame content, and frame checksum. The frame header occupies 2 bytes and is used to reveal the transmission flow of the data packet. The frame type occupies 1 byte and is used to reveal the message frame type of the data packet. The frame length occupies 2 bytes and is used to reveal the length of the data unit of the data packet. The frame content occupies n bytes and reveals the transmitted data content. The frame checksum occupies 1 byte and is used for BCC verification.

[0042] At the data transmission level, when the diagnostic end is a mobile terminal, an innovative self-developed encrypted transmission protocol is designed. It has a complete packet structure with frame header, type, length, content, and verification. It not only defines the data flow and type, but also ensures the integrity of the data during transmission through BCC verification. This protocol is suitable for achieving efficient and reliable data exchange in bandwidth-constrained mobile network environments.

[0043] For example, when the diagnostic end is a remote diagnostic platform, the diagnostic end can establish mobile communication with the TBOX through the TBOX's 4G or 5G mobile communication module, and establish a secure communication link with the TBOX by adopting a dynamic authentication mechanism based on digital certificates.

[0044] This solution constructs a secure, reliable, and scalable end-to-end diagnostic and data management system, providing enterprise-level technical support from communication security and protocol encapsulation to system upgrades. Addressing the core security and reliability challenges of remote diagnostics, this solution employs a dynamic authentication mechanism based on digital certificates to establish secure links for both on-site wireless connections and remote mobile communication, ensuring the trustworthiness of endpoints in the diagnostic channel and the confidentiality of communication.

[0045] Once a secure communication link is established between the diagnostic terminal and the TBOX, the TBOX can operate in the data pass-through forwarding mode of the data custom protocol, enabling data transmission from the vehicle ECU to the national standard platform, remote diagnostic platform, and mobile terminal, as well as data transmission from the remote diagnostic platform, mobile terminal, OTA component, and vehicle ECU.

[0046] Depending on the different diagnostic and repair scenarios (on-site diagnostic and repair or remote diagnostic and repair), the vehicle fault diagnosis system has different workflows.

[0047] In on-site diagnostic and repair scenarios, the system operates in step S104. When the vehicle is in a faulty state and on-site diagnosis is required, the on-site personnel connect to the TBOX via WiFi or Bluetooth and switch the TBOX to diagnostic mode. In diagnostic mode, the TBOX forwards vehicle data to the mobile phone according to the custom CAN-WIFI / Bluetooth packet grouping and unpacking rules (i.e., the self-developed data transmission protocol). The mobile phone parses the data according to the automotive diagnostic protocol and opens the diagnostic application software interface. The software interface includes modules such as data flow monitoring, fault code reading, function switch settings, component testing, ECU version information, and ECU data burning to achieve on-site vehicle fault diagnosis.

[0048] In a remote diagnostic and repair scenario, the system operates in step S105. If a vehicle is in a faulty state and requires remote diagnosis across regions, based on the 4G (or 5G) mobile cellular network mounted on the TBOX, remote personnel use the vehicle remote diagnostic platform to switch the TBOX to diagnostic mode. In diagnostic mode, the TBOX forwards data according to a custom CAN-TCP packet assembly / disassembly rule (i.e., a self-developed data transmission protocol). The server parses the data according to the automotive diagnostic protocol and opens the corresponding WEB diagnostic interface. The interface includes modules such as data traffic monitoring, fault code reading, function switch settings, component testing, ECU version information, and ECU data burning to achieve remote vehicle fault diagnosis.

[0049] TBOX serves a dual role as both a "fault diagnosis middleware layer" and a "regulatory data reporting unit." Through a unified multi-layered protocol architecture (CAN physical layer, CAN communication protocol layer, and application communication layer), it supports multiple business functions, including diagnostics, national standard platform data reporting, and interaction with OTA components, achieving a high degree of integration and reuse of hardware resources and software functions. Its integrated design, encompassing secure links, reliable transmission, worry-free upgrades, and a flexible platform, not only ensures the security and stability of the diagnostic business itself but also lays a solid and flexible technical foundation for future iterations of diagnostic functions, rapid integration with new vehicle models, and the expansion of big data analysis and predictive maintenance services.

[0050] It should be noted that the vehicle fault diagnosis system based on TBOX can switch between on-site diagnosis and remote diagnosis. However, in the case of simultaneous command issuance and resource contention during the switching process (which may damage the ECU), this solution designs a coordination manager to prevent any conflicting commands from both ends (especially high-risk commands such as ECU flashing and ECU reset) from being issued to the vehicle bus during the short window of switching between on-site diagnosis mode and remote diagnosis mode, thus ensuring the absolute safety of vehicle status and diagnostic operation switching.

[0051] The entire switchover process (whether it's switching from on-site to remote or vice versa) is strictly regulated into the following three stages: (1) Switching between request initiation and silent state entry: When the currently connected device (such as the mobile app of the on-site maintenance personnel) actively triggers the "Request to switch to remote diagnostics" operation, the TBOX, upon receiving the request, immediately sends a "switch confirmation" request to the currently connected device and starts a short countdown (e.g., 5 seconds). During the countdown, the TBOX suspends the execution of any new non-query-type commands (such as flashing, testing, etc.) from the currently connected device. Simultaneously, the TBOX immediately responds, returning a "Entering silent state" prompt to the requesting device.

[0052] After the countdown ends, the TBOX officially enters silent mode. In this state, the TBOX immediately suspends and buffers all new commands (especially control commands) from the original connection, only responding to query commands (such as reading current fault codes) one last time. Simultaneously, the TBOX automatically generates a complete record of the current diagnostic session status (including: active fault codes, list of monitored data streams, ECU session status, security access level, etc.). At the same time, the TBOX notifies the original connection: Switching mode has been entered, control commands are paused, please wait.

[0053] (2) Secure channel establishment and session migration: The TBOX maintains its connection with the original endpoint but begins preparing to establish a new, fully authenticated, secure connection with the target endpoint (such as a remote diagnostic platform). Once the new connection is successfully established, the TBOX securely synchronizes the complete record generated in the previous phase to the new endpoint, ensuring that the remote expert sees the complete vehicle status at the moment of the switch, achieving a seamless transition. Internally, the TBOX performs a permission tag conversion, transferring control from the original endpoint's identifier to the new endpoint's identifier.

[0054] (3) Silence removal and new session activation: Once the complete record has been successfully synchronized to the new connection and the new connection is ready, the TBOX sends a notification to both the original and new connections: session migration complete, new control terminal ready. At this point, the TBOX checks the command queue buffered from the original connection during the silent state. All control commands are discarded and the original connection is notified to avoid command conflicts before and after the switchover, retaining only necessary status notifications. Afterward, the TBOX exits the silent state, activates the new session, and permissions from the original connection are automatically downgraded (observation only, no operation) or disconnected; commands from the new connection can then be received and executed normally, thus completing a seamless switch between on-site and remote diagnostics.

[0055] This switching scheme does not alter the normal diagnostic process. It only triggers a strict, predefined safety protocol during the specific, brief, and high-risk moment of "mode switching," resulting in extremely low system complexity and implementation risk. Through silent mode and buffered command discarding mechanisms, it fundamentally eliminates any possibility of conflicting commands being issued simultaneously at both ends of the switching window. Especially for long-cycle operations like ECU remapping, these are paused or required to complete at the start of the switch, ensuring they are never interrupted midway. Furthermore, the complete recording mechanism ensures that even with a brief delay during the switch, the diagnostic process of on-site or remote experts will not be interrupted due to a gap in vehicle status.

[0056] In summary, this application provides a vehicle fault diagnosis system based on a TBOX, which completely revolutionizes the hardware dependence and communication architecture of traditional diagnostic modes, achieving software-hardware decoupling of the diagnostic system. The core bottleneck of traditional diagnostic instruments lies in their tangible, fixed, dedicated hardware. Their firmware updates are lagging, protocol compatibility is poor, and they must be wired through a physical OBD interface, resulting in limited application scenarios, high costs, and difficult maintenance. This solution reconstructs the TBOX, a network terminal standard in most vehicles, into a diagnostic middleware layer. It utilizes its existing CAN bus access capability (for communication with the vehicle's ECU unit), mobile communication capability (4G / 5G module), and wireless communication capability (wireless modules, such as Bluetooth and WIFI) to construct a completely new diagnostic architecture. Specifically, the TBOX incorporates HJ1239, GB32960, UDS, and automaker-customized protocol stacks, making it a standardized protocol conversion hub between the vehicle's CAN network and external diagnostic terminals. This eliminates the need for mobile terminals (on-site diagnostic mode) or remote diagnostic platforms (remote diagnostic mode) to directly interact with a variety of original vehicle protocols. Instead, they interact through the unified middleware layer of the TBOX, fundamentally solving the compatibility problem of adapting to multiple vehicle models. In on-site diagnostic mode, repair personnel can establish a secure wireless connection with the TBOX using a universal terminal (such as a mobile phone or tablet) to obtain the same human-machine interface and diagnostic functions as traditional diagnostic tools. This saves the cost of purchasing dedicated hardware (by reusing the vehicle's existing TBOX hardware, expensive and dedicated traditional diagnostic tools are completely eliminated, saving service outlets significant costs in equipment procurement, maintenance, and updates). It is also more convenient (repair personnel can quickly complete diagnostics using their smartphones, eliminating the time spent searching for, borrowing, and waiting for dedicated equipment, significantly improving on-site service efficiency). In remote diagnostic mode, the TBOX can connect to a remote diagnostic platform via its built-in mobile communication module. This allows technical support experts to monitor vehicle data in real time, analyze faults, and remotely configure the vehicle, overcoming geographical limitations. This centralizes diagnostic resources and improves service efficiency. Experts do not need to be physically present; they can obtain complete fault data and perform preliminary analysis and calibration through the remote platform, achieving "data travels more, experts travel less," significantly shortening the fault diagnosis cycle and reducing travel costs. This approach, centered on the existing vehicle hardware (TBOX) and utilizing its multi-mode communication capabilities (WiFi / Bluetooth / 4G / 5G), not only significantly reduces hardware investment and maintenance costs for diagnostics but also expands the diagnostic scenario from requiring physical presence at the vehicle to anytime, anywhere diagnostics. The seamless integration of "on-site mobile terminal + remote cloud" diagnostic solution breaks down geographical limitations of diagnostic operations, enabling both rapid on-site repairs and in-depth intervention by backend experts, greatly enhancing convenience.

[0057] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A TBOX-based vehicle fault diagnosis system, characterized in that, The application relates to a vehicle fault diagnosis system, which comprises the following: a TBOX installed in a vehicle, used for acquiring vehicle data and judging whether the vehicle has a fault based on the vehicle data, wherein the TBOX enters a diagnosis and maintenance mode when the vehicle has a fault, the vehicle is provided with an ECU unit, communication between the vehicle and the TBOX is realized through a CAN bus of the vehicle, the diagnosis and maintenance mode comprises an on-site diagnosis mode and a remote diagnosis mode; a diagnosis end used for establishing a data communication channel with the TBOX in the diagnosis and maintenance mode, wherein the diagnosis end comprises a mobile terminal and a remote diagnosis platform, the TBOX establishes wireless communication with the mobile terminal through a wireless communication module in the on-site diagnosis mode, and the TBOX establishes mobile communication with the remote diagnosis platform through a 4G or 5G mobile communication module in the remote diagnosis mode; the TBOX is further used for transmitting vehicle fault data to the diagnosis end through the data communication channel, receiving vehicle configuration instructions issued by the diagnosis end, and issuing the vehicle configuration instructions to a target ECU unit of the vehicle through the CAN bus, so as to realize vehicle fault full-link diagnosis operation, wherein the vehicle fault full-link diagnosis operation comprises intelligent fault code analysis, component remote testing, data flow real-time monitoring, ECU information management and ECU data security rewriting.

2. The TBOX-based vehicle fault diagnosis system according to claim 1, characterized in that, The TBOX is specifically used for: determining whether a vehicle part has fault information based on vehicle data; judging whether the vehicle has a vehicle fault according to the fault information of the vehicle part when the vehicle part has fault information. 3.The TBOX-based vehicle fault diagnosis system according to claim 1, characterized in that, When the diagnosis end is a mobile terminal, the diagnosis end is specifically used for: establishing wireless communication with the TBOX through a wireless communication module of the TBOX, and establishing a secure communication link between the TBOX and the diagnosis end by adopting a dynamic authentication mechanism based on a digital certificate; after the diagnosis end triggers the diagnosis and maintenance mode of the TBOX, displaying a diagnosis and maintenance interface on the diagnosis end according to the user role authority of authorized personnel, and determining the diagnosis authority and data access range of the authorized personnel.

4. The TBOX-based vehicle fault diagnosis system according to claim 1, characterized in that, When the diagnosis end is a remote diagnosis platform, the diagnosis end is specifically used for: establishing mobile communication with the TBOX through a 4G or 5G mobile communication module of the TBOX, and establishing a secure communication link between the TBOX and the diagnosis end by adopting a dynamic authentication mechanism based on a digital certificate. 5.The TBOX-based vehicle fault diagnosis system according to claim 1, characterized in that, The internal software of the TBOX comprises a multi-layer communication protocol architecture, specifically: the CAN bus of the vehicle as a CAN physical layer, HJ1239, GB32960 protocol, UDS protocol and a self-defined CAN protocol of a vehicle enterprise built in the TBOX as a CAN communication protocol layer; a TCP application layer based on Ethernet communication, a network application layer of a GB32960 protocol, an HJ1239 protocol, a self-defined platform protocol of a vehicle enterprise and a diagnosis terminal communication protocol encapsulation component built in the TBOX; a national standard platform, a mobile terminal APP and an enterprise remote diagnosis platform application communication component built in the TBOX as an application communication layer; the multi-layer communication protocol architecture built in the TBOX is flexible and decoupled, and supports a full-link fault diagnosis architecture formed by the vehicle, the TBOX, the mobile terminal, the remote diagnosis platform and the national standard platform. 6.The TBOX-based vehicle fault diagnosis system according to claim 5, characterized in that, When the vehicle has no fault, the TBOX is also used for: encapsulating vehicle data transmitted through the CAN bus of the vehicle according to GB32960 protocol and HJ1239 protocol, and transmitting the vehicle data to the national standard platform. 7.The TBOX-based vehicle fault diagnosis system according to claim 5, characterized in that, When the diagnosis end communicates with the TBOX, self-developed data transmission protocol is used for data encryption transmission, wherein the data packet structure corresponding to the self-developed data transmission protocol is: frame header, frame type, frame length, frame content and frame check, wherein the frame header occupies 2 bytes, is used to reveal the transmission direction of the data packet, the frame type occupies 1 byte, is used to reveal the message frame type of the data packet, the frame length occupies 2 bytes, is used to reveal the data unit length of the data packet, the frame content occupies n bytes, reveals the data content of transmission, and the frame check occupies 1 byte, is used for BCC check. 8.The TBOX-based vehicle fault diagnosis system according to claim 7, characterized in that, The multi-layer communication protocol architecture further comprises an OTA component for communicating with the TBOX through a vehicle enterprise self-defined protocol to perform ECU firmware upgrade, wherein the ECU firmware upgrade data is transmitted by TCP packet, there is a separate content check for each packet, and the entire firmware upgrade data is signed. 9.The TBOX-based vehicle fault diagnosis system according to claim 8, characterized in that, The TBOX adopts A and B partition strategies, and alternately upgrades A and B partitions when the ECU firmware is upgraded, when the A partition has firmware upgrade exception, the TBOX starts running the un-upgraded ECU firmware version from the B partition, and re-executes the ECU firmware upgrade in the A partition, when the B partition has firmware upgrade exception, the TBOX starts running the upgraded ECU firmware version from the A partition, and re-executes the ECU firmware upgrade in the B partition, to ensure reliable flashing.

10. The TBOX-based vehicle malfunction diagnosis system according to claim 5, characterized by, The remote diagnosis platform adopts a micro-service distributed architecture, and supports large-scale vehicle concurrent diagnosis and data analysis.

Images