Remote monitoring terminal data acquisition method and system for OBD (On-Board Diagnostic) interface

Abstract

The invention relates to the field of wireless communication, in particular to a remote monitoring terminal data acquisition method and system for an OBD diagnosis interface, and the method comprises the steps: obtaining vehicle operation data collected by the OBD diagnosis interface in real time when a vehicle-mounted terminal detects that a vehicle is powered on; before data uploading, vehicle operation data are analyzed in real time, high-priority data containing fault codes or key parameter anomalies are recognized, and the high-priority data and conventional monitoring data are distinguished and marked; respectively packaging the high-priority data, the conventional monitoring data and the vehicle positioning information to form data packets with different transmission priorities; establishing a communication connection with a remote server, and uploading the data packets by adopting a differentiated transmission strategy according to the priorities of the data packets, the data packets with high priorities being transmitted preferentially in real time; and the remote server receives and analyzes the data packet, carries out storage and alarm according to the data category and priority, and provides a vehicle state monitoring and remote diagnosis interface for the client.

Description

Technical Field

[0001] This application relates to the field of wireless communication technology, and in particular to a method and system for data acquisition of a remote monitoring terminal with an OBD diagnostic interface. Background Technology

[0002] Remote monitoring of the OBD diagnostic interface refers to a technology that uses an onboard terminal installed in the vehicle to connect to the vehicle's standard onboard diagnostic interface. This allows for real-time or periodic collection of data such as the vehicle's operating status and fault information, and the transmission of this data to a remote server via wireless communication. This enables remote and centralized monitoring and management of the vehicle's health, geographical location, and emissions levels. Existing solutions typically connect the onboard diagnostic terminal to the vehicle's OBD-II interface. The terminal periodically sends diagnostic requests (such as reading specific parameter identifiers like PID) to the vehicle's electronic control unit (ECU) based on a pre-set instruction list to obtain data such as engine speed, vehicle speed, coolant temperature, and fault codes. The acquired data is usually temporarily cached locally on the terminal. Data transmission generally employs two basic strategies: timed uploads, where cached data is packaged and sent to the remote server at fixed time intervals (e.g., every 30 seconds); and quantitative uploads, where data is sent only when it accumulates to a certain size, improving the efficiency of each transmission. The server receives the data and then stores, analyzes, and visualizes it.

[0003] Existing solutions typically treat all types of OBD data (such as data from normally functioning sensors and codes indicating serious faults) the same, processing them using the same fixed acquisition cycle and transmission rhythm. This leads to two contradictions: First, to ensure the transmission efficiency of general monitoring data and conserve network resources, the system often uses a low transmission frequency or large data packets. This makes it impossible to report critical fault information in a timely manner, resulting in significant transmission delays and failing to meet the real-time response requirements for emergencies such as vehicle safety and emissions exceeding standards. Second, if the existing rhythm is immediately interrupted to send a separate small data packet to report a sudden fault, it will significantly increase network signaling overhead and face a higher risk of transmission failure when network conditions are poor. Existing technologies struggle to achieve an adaptive and refined balance between "low-latency transmission of critical data" and "overall system transmission efficiency and reliability."

[0004] Secondly, the environments vehicles face in real-world use are far from ideal laboratory conditions, and existing solutions are prone to revealing their shortcomings in many real-world scenarios. For example, these solutions often assume that the vehicle's OBD interface responds to diagnostic requests stably and without loss, failing to adequately consider that frequent active diagnostic requests may interfere with the internal states of certain ECUs. This results in the returned data not being purely real-time operating values, thus affecting the authenticity of the data source. Simultaneously, many solutions assume stable terminal power supply and continuous network connectivity, failing to properly handle common abnormal operating conditions such as transient power drops in vehicles and frequent entry and exit from network blind spots. This can easily lead to data loss, terminal state machine malfunctions, or connection interruptions, affecting the continuity and consistency of monitoring. Furthermore, in the data transmission stage, fixed transmission strategies cannot adapt to dynamically changing network quality (such as moving from a strong 4G signal area to a weak signal basement), potentially causing performance degradation when communication is urgently needed. These factors collectively make it difficult to fully guarantee the stability, reliability, and final data credibility of existing systems when facing the complex and ever-changing real world. Summary of the Invention

[0005] In order to solve one or more problems in the prior art, the main objective of this application is to provide a method and system for data acquisition of a remote monitoring terminal with an OBD diagnostic interface.

[0006] To achieve the aforementioned objectives, this application proposes a method for data acquisition from a remote monitoring terminal of an OBD diagnostic interface, the method comprising: When the vehicle terminal detects that the vehicle is powered on, it acquires the vehicle operation data collected by the OBD diagnostic interface in real time. The vehicle operation data includes real-time parameters of the power system, emission-related freeze frame data, and fault codes. Before the data is uploaded, the vehicle operation data is analyzed in real time to identify high-priority data containing fault codes or abnormal key parameters, and these data are distinguished and marked from regular monitoring data. The high-priority data, along with regular monitoring data and vehicle location information, are packaged into data packets with different transmission priorities. Establish a communication connection with the remote server and upload data packets using a differentiated transmission strategy based on packet priority, wherein high-priority packets are transmitted preferentially and in real time. The remote server receives and parses data packets, stores and issues alarms based on data type and priority, and provides vehicle status monitoring and remote diagnostic interfaces to the client.

[0007] This application also provides a remote monitoring terminal data acquisition system for an OBD diagnostic interface, including: The acquisition module is used to acquire vehicle operating data collected by the OBD diagnostic interface in real time when the vehicle terminal detects that the vehicle is powered on. The vehicle operating data includes real-time parameters of the power system, emission-related freeze frame data, and fault codes. The identification module is used to perform real-time analysis of the vehicle operation data before data upload, identify high-priority data containing fault codes or abnormal key parameters, and distinguish and mark them from regular monitoring data. The packaging module is used to package the high-priority data and regular monitoring data, together with vehicle positioning information, into data packets with different transmission priorities. The upload module is used to establish a communication connection with the remote server and to upload data packets using a differentiated transmission strategy based on the priority of the data packets, wherein high-priority data packets are transmitted first and in real time. The remote module is used to receive and parse data packets through a remote server, store and alarm according to data category and priority, and provide vehicle status monitoring and remote diagnostic interfaces to the client.

[0008] This application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of any of the methods described above.

[0009] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of any of the methods described above.

[0010] The remote monitoring terminal data acquisition method and system for the OBD diagnostic interface in this application embodiment ensures real-time monitoring startup and data source integrity through automatic triggering of vehicle power-on and comprehensive data acquisition via the OBD interface. Subsequently, real-time analysis and priority marking on the vehicle terminal side enable rapid response at the data source. Based on this, the differentiated data and location information are packaged and associated with different transmission priorities, transforming the inherent urgency of the data into explicit network transmission instructions. Furthermore, the differentiated transmission strategy implemented by the network layer based on priority fundamentally resolves the contradiction between the delay of critical alarm information and network resource utilization, achieving near real-time reliable uploading of high-priority data. Finally, the intelligent parsing, alarm, and interaction interface provided by the server completes the value loop from raw data to executable insights, providing users with efficient management tools. Overall, this method rationally distributes the computational load between the vehicle and the cloud, replacing traditional indiscriminate transmission with intelligent data scheduling. This significantly improves emergency response speed and system reliability while optimizing communication resource utilization, achieving accurate, efficient, and reliable remote vehicle monitoring. Attached Figure Description

[0011] Figure 1 This is a flowchart illustrating a remote monitoring terminal data acquisition method for an OBD diagnostic interface according to an embodiment of this application. Figure 2 This is a flowchart illustrating a remote monitoring terminal data acquisition method for an OBD diagnostic interface according to an embodiment of this application. Figure 3 This is a schematic block diagram of the structure of a remote monitoring terminal data acquisition system for an OBD diagnostic interface according to an embodiment of this application; Figure 4 This is a schematic block diagram of the structure of a computer device according to an embodiment of this application.

[0012] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0014] Reference Figure 1 This application provides a method for remote monitoring terminal data acquisition of an OBD diagnostic interface, the method comprising: S1. When the vehicle terminal detects that the vehicle is powered on, it acquires the vehicle operation data collected by the OBD diagnostic interface in real time. The vehicle operation data includes real-time parameters of the power system, emission-related freeze frame data, and fault codes. S2. Before uploading the data, perform real-time analysis on the vehicle operation data, identify high-priority data containing fault codes or abnormal key parameters, and distinguish and mark them from regular monitoring data. S3. Pack the high-priority data and regular monitoring data together with vehicle positioning information into data packets with different transmission priorities. S4. Establish a communication connection with the remote server and upload data packets using a differentiated transmission strategy based on the priority of the data packets, wherein high-priority data packets are transmitted preferentially and in real time. S5: The remote server receives and parses data packets, stores and alarms according to data type and priority, and provides vehicle status monitoring and remote diagnostic interfaces to the client.

[0015] As described in steps S1-S3 above, in step 1, the on-board terminal detects whether the vehicle is "powered on" by monitoring voltage changes in the vehicle's power system or specific wake-up signals, such as CAN bus activity. Once the vehicle is confirmed to be powered on, the terminal immediately sends data request commands to the vehicle's electronic control unit (ECU) via the OBD diagnostic interface, according to standard diagnostic protocols (such as ISO 15765 and SAE J1979). These commands target different data identifiers (such as PID and DID) to obtain three types of core data: real-time powertrain parameters, such as engine speed, vehicle speed, intake airflow, and throttle position, reflecting the vehicle's instantaneous operating status; emission-related frozen frame data, referring to snapshots of several key parameters automatically saved by the ECU at the moment of the fault occurrence when an emission-related fault is triggered; and fault codes, i.e., diagnostic fault codes (DTCs), used to indicate faults detected in various vehicle subsystems, such as the engine, transmission, and emission system. This achieves seamless synchronization between the monitoring system and the vehicle's status, ensuring that monitoring begins immediately upon vehicle startup without manual intervention, thus improving the system's automation level. The collected data comprehensively covers the core elements of vehicle operating health status, providing a complete data foundation for subsequent fault diagnosis, emissions monitoring, and performance analysis. Step 2 is completed within the onboard terminal, belonging to the edge computing process. The terminal's built-in processor or dedicated logic unit performs real-time analysis and judgment on the raw data acquired in Step 1: Fault code analysis: Directly analyzes diagnostic fault codes read from the ECU; their presence indicates an abnormality in the vehicle. Key parameter anomaly analysis: Compares the acquired real-time parameter values ​​with preset normal threshold ranges or dynamically calculated reference models. If the parameter values ​​continuously or significantly deviate from the normal range, such as engine temperature exceeding safety limits, it is judged as abnormal. Based on the analysis results, the data is divided into two categories and marked: High-priority data: Contains any fault codes and real-time data judged as "key parameter anomalies." Regular monitoring data: Other monitoring data that has not triggered a fault and whose parameter values ​​are within the normal range. At the data source (vehicle end), preliminary data value identification is completed, distinguishing information requiring urgent attention (faults, serious anomalies) from routine monitoring information. This enables the system to respond quickly to important events, avoiding processing delays caused by treating all data equally. Step 3 involves network transmission, requiring data encapsulation into data packets. In this step, the vehicle terminal organizes the marked high-priority data and routine monitoring data, combined with vehicle location information obtained from the GPS module, into different data packets. The key point is: "separate packaging": high-priority data and routine data are usually placed in different data packet structures, or although they may be mixed, different "priority identifiers" are explicitly set in the protocol header. Location information integration: Each data packet contains vehicle location information at the time of collection, such as latitude and longitude, and a timestamp, achieving data binding with spatiotemporal information. This forms a data unit suitable for network transmission and with built-in priority attributes.The packaging process transforms the logical priority of data into identifiable identifiers within the transmission protocol, providing a direct basis for differentiated transmission scheduling at the network layer. Integrated location information ensures that all reported data possesses geographic context, significantly enhancing its application value in fleet management, route analysis, and accident tracing.

[0016] As described in steps S4-S5 above, in step 4, the vehicle-mounted terminal establishes a TCP / IP or IoT protocol-based connection with the remote server through its wireless communication module (such as a 4G / 5G module). When sending data packets, the terminal or network device adopts different transmission strategies based on the priority identifier of the data packet: Scheduling strategy: High-priority data packets are placed at the head of the transmission queue or sent through a separate, high-priority logical channel. Resource allocation strategy: When network resources are scarce, the transmission of regular data packets can be suspended or delayed to prioritize the bandwidth of high-priority data packets. Retransmission and acknowledgment mechanism: A more aggressive retransmission mechanism and a shorter acknowledgment timeout are adopted for high-priority data packets to ensure their reliable delivery. This resolves the contradiction between "critical information transmission delay" and "network resource utilization efficiency" in the background technology. High-priority data, such as fault alarms, can be uploaded quickly "jump the queue," achieving near real-time remote alarms; while regular data is transmitted using idle bandwidth, optimizing overall network utilization. This significantly improves the system's remote perception speed and reliability of vehicle emergency states. Step 5: The remote server acts as a data aggregation and processing center. Its workflow includes: Receiving and parsing: unpacking data and routing it according to its category and priority identifier. Storage and alarming: all data is persistently stored in the database. Simultaneously, the server's embedded rule engine checks the data, especially high-priority data. Once a preset alarm condition is matched, such as a specific fault code, an alarm is immediately triggered to the relevant client or administrator via SMS, email, or in-platform messages. The server provides clients, such as computer browsers and mobile apps, with functional interfaces for data querying, historical playback, and remote diagnostics, such as sending diagnostic commands to vehicles, through APIs, WebSockets, or Web services. This completes the closed loop from data collection to final value presentation. Intelligent processing on the server side, such as automatic alarms, transforms raw data into actionable intelligence. The rich interfaces provided to clients enable fleet managers, maintenance personnel, or regulatory agencies to conveniently and intuitively access monitoring information and perform remote interaction, truly realizing remote, centralized, and intelligent vehicle management. In this embodiment, a hierarchical, closed-loop feedback intelligent remote monitoring data flow pipeline is constructed. The overall architecture of "real-time analysis at the terminal side + priority-driven transmission" aims to fundamentally resolve the core contradiction between "low data value density" and "limited transmission resources" in traditional solutions. Traditional solutions upload all data indiscriminately to the cloud for analysis, consuming significant bandwidth and causing delays in critical information. This embodiment moves some computational tasks to the resource-constrained but closer-to-data-source vehicle terminal (edge ​​side), performing preliminary data value extraction (i.e., priority marking) locally, thus enabling targeted transmission and cloud processing.This design embodies the concept of "edge-cloud" collaboration, ensuring real-time system responsiveness while also considering the feasibility and economy of the overall solution (saving bandwidth and cloud computing resources). It paves the way for subsequent, more refined optimizations tailored to complex scenarios.

[0017] As described above, the automatic triggering of vehicle power-on and comprehensive data acquisition via the OBD interface ensures real-time monitoring startup and data source integrity. Subsequently, real-time analysis and priority marking on the vehicle terminal enable rapid response at the data source. Based on this, the differentiated data and location information are packaged and associated with different transmission priorities, transforming the inherent urgency of the data into explicit network transmission instructions. Furthermore, the differentiated transmission strategy implemented at the network layer based on priority fundamentally resolves the contradiction between critical alarm information delays and network resource utilization, achieving near real-time reliable uploading of high-priority data. Finally, intelligent parsing, alarm functions, and interactive interfaces on the server side complete the value loop from raw data to actionable insights, providing users with efficient management tools. Overall, this method rationally distributes the computational load between the vehicle and the cloud, replacing traditional indiscriminate transmission with intelligent data scheduling. This significantly improves emergency response speed and system reliability while optimizing communication resource utilization, achieving accurate, efficient, and reliable remote vehicle monitoring.

[0018] Reference Figure 2 In one embodiment, the step of performing real-time analysis of the vehicle operating data to identify high-priority data containing fault codes or abnormal key parameters includes: S21. Analyze the fault codes and their associated status information obtained from the OBD diagnostic interface; S22. The status information is indicated as the currently active fault code, and the real-time parameter anomaly corresponding to the fault code is identified as the highest priority data. S23. Indicate the status information as a fault code that is not currently active, and identify it as pending confirmation data that is lower than the highest priority.

[0019] As described above, step 1 parses the fault codes and their associated status information. In standard OBD protocols, such as ISO 15031-5 or SAE J2012, a complete Diagnostic Trouble Code (DTC) information not only includes a code identifying the fault type (e.g., P0300) but also a set of status bytes. The onboard terminal acquires this status information simultaneously when reading the fault codes. Each bit in the status byte has a specific meaning. For example, the "Test Failed This Operation Cycle" bit indicates whether the diagnostic test for this fault failed in the current driving cycle (from power-on to power-off). Setting this bit usually means the fault is currently active. The "Confirmed DTC" bit indicates that the fault code has been confirmed by the ECU and stored in non-volatile memory; it may be a historical or intermittent fault. Bits such as "Test Not Completed Since Last Clear" provide the status of the diagnostic test. By parsing these predefined bits, the terminal can accurately determine the real-time status of each fault code. This step transforms the original fault code list into rich status information with precise time and activity attributes. It utilizes the most authoritative diagnostic status judgment provided by the vehicle's ECU itself, providing an accurate and objective basis for subsequent intelligent decision-making, avoiding misjudgments that may occur due to the terminal's own guessing or the use of fixed rules. Step 2 identifies the highest priority data. This step performs logical judgment based on the parsing results of the status bytes. Only those fault codes whose status information explicitly indicates "currently active," such as those with the "Test Failed" bit set to 1, are identified as "highest priority data." At the same time, the system will check the real-time parameters related to these currently active fault codes, such as engine speed and load parameters related to the misfire fault code P0300. If these parameters also show abnormalities, such as drastic fluctuations, they will also be included in the highest priority category. This achieves precise identification of the vehicle's ongoing and urgent fault problems. Assigning the highest priority to "currently active" faults and their related environmental data ensures that system resources and communication bandwidth can be prioritized for handling the most urgent situations, enabling remote monitoring platforms or maintenance personnel to know and respond to the vehicle's real and current faults as soon as possible, greatly improving the timeliness of safety warnings and fault handling. Step 3 identifies the data to be confirmed. For fault codes whose status information indicates "not currently active," such as "Confirmed DTC" but the current test has not failed, this may be a historically stored, fixed, or intermittent fault. This step categorizes them as "lower priority data to be confirmed." Fault information is managed in a refined hierarchical manner. While these "data to be confirmed" do not require an urgent response like current faults, they are valuable for establishing vehicle health records, analyzing fault trends, and planning preventative maintenance.By assigning lower transmission priority, the system can upload data only when network bandwidth is sufficient, or cache and aggregate it locally, thus preventing non-urgent information from crowding out emergency communication channels, optimizing overall transmission efficiency, and ensuring data integrity. In this embodiment, the native state of the protocol is used to achieve factual differentiation of fault priorities, rather than subjective division. Recognizing the crude drawbacks of traditional solutions that merely list fault codes, this solution utilizes the crucial dimension of "status information," which is inherent in the OBD diagnostic protocol but often overlooked. By analyzing the ECU's own authoritative judgment on the timeliness and activity of the fault, this solution can distinguish between current faults representing the "present tense" and historical faults representing the "past tense." The fundamental reason for this is to solve the alarm overload and resource mismatch problems caused by "treating all fault codes equally" in the background technology. It ensures that the monitoring system can prioritize "where the vehicle is currently broken," rather than being distracted by a large amount of historical data.

[0020] In one embodiment, the step of packaging the high-priority data, regular monitoring data, and vehicle location information into data packets with different transmission priorities includes: Set up a data buffer to be sent for regular monitoring data and configure a packing trigger strategy; the packing trigger strategy is: when the amount of data in the buffer reaches the capacity threshold, or when a time threshold has elapsed since the last regular data packet was sent, the packing operation of the data in the buffer is triggered. When high-priority data is generated, a wait window shorter than the time threshold is initiated; If the packaging operation of the regular monitoring data is triggered within the waiting window, the high-priority data is injected into the regular data being packaged, forming a mixed data packet marked as high priority. If the packing operation is not triggered by the end of the waiting window, a separate highest priority data packet will be generated for the high-priority data.

[0021] As described above, in step 1, the vehicle-mounted terminal allocates a dedicated area in memory as a data buffer to be sent, used to sequentially store continuously generated routine monitoring data. To control the data transmission behavior of this buffer, the system is configured with a dual-condition triggering strategy: Capacity threshold triggering: When the amount of routine data accumulated in the buffer reaches a preset number of bytes, such as 1KB, packet transmission is immediately triggered. Time threshold triggering: Starting from the last successful transmission of a routine data packet, if the capacity threshold is not met after a preset time, such as 30 seconds, packet transmission is forcibly triggered. This strategy establishes an automatic balance mechanism between data timeliness and network transmission efficiency. The capacity threshold prioritizes ensuring that each transmitted data packet has a large effective payload, improving network bandwidth utilization and reducing protocol overhead caused by frequent transmission of small packets. The time threshold provides a "bottom-line" timeliness guarantee for data transmission, ensuring that even if the data generation rate is slow, routine monitoring information can be reported periodically, avoiding indefinite data retention in the buffer, thereby maintaining the basic update frequency of the remote monitoring view. Step 2: When the system generates high-priority data, such as the currently active fault, it does not immediately create a separate data packet for it. Instead, it starts a timer whose duration (waiting window) is preset to be much shorter than the time threshold for regular data, for example, 200 milliseconds vs. 30 seconds. This introduces a short, controlled delay decision period. The core purpose of this design is to create a "hitchhiking" opportunity for high-priority data. It allows the system to observe whether a regular data packet is about to be sent within a very short time, thus creating conditions for possible subsequent "packet merging." This short window itself has minimal impact on the urgency of the high-priority data. Step 3: During the waiting window countdown, the system continuously monitors the packetization trigger status of the regular data buffer. Once regular data triggers a packetization operation due to reaching the capacity or time threshold, the system immediately injects the current high-priority data into the regular data packet to be sent. This newly formed packet contains both regular and high-priority data and is explicitly marked "high priority" in its protocol header. This allows high-priority data to "ride" on a pre-planned regular data packet, avoiding the need to generate and send a separate, potentially small, data packet. This significantly reduces the number of small packets on the network, lowering overall signaling overhead and interaction frequency. Despite being a mixed packet, the network layer can still identify its importance and prioritize its transmission through priority marking. This mechanism achieves a leap in transmission efficiency with almost no impact on the real-time performance of high-priority data. Step 4: If the waiting window countdown ends and the regular data packetization trigger has not yet occurred, meaning there is neither sufficient data accumulation nor the scheduled transmission time, the system immediately terminates the wait, generates an independent data packet with the highest priority identifier for this high-priority data, and schedules its transmission. This acts as a "safety valve" to ensure the system's real-time commitment.It ensures that high-priority data is never unreasonably delayed by waiting for a slow-moving "ride". By setting a waiting window much smaller than the usual threshold, the triggering conditions for independent packets are very lenient, thus strictly guaranteeing the low latency limit for emergency information transmission. This prevents the side effects that optimization mechanisms (waiting for a ride) might have in specific scenarios (where very little regular data is generated). In this embodiment, a classic dilemma in remote monitoring is solved: how to ensure the real-time nature of critical alarms while avoiding excessive consumption of network resources and increased costs due to frequent sending of alarm packets. Through a coherent control logic of "buffering-triggering-waiting-injection / independent", a dynamic and adaptive packet assembly pipeline is established. It allows regular data to be transmitted stably according to the rhythm of "accumulating enough to send" or "sending at the appointed time", maintaining the monitoring baseline; at the same time, a "wait-and-see" intelligent strategy is designed for sudden high-priority data - prioritizing finding "rides" (injecting mixed packets), and only immediately "calling a dedicated vehicle" (independent packets) when no rides are available. The fundamental reason for this approach is the recognition of the coexistence of "normal" and "emergency" characteristics in vehicle monitoring data streams, and the design of a cooperative rather than mutually exclusive transmission scheme to address these two characteristics. This not only optimizes wireless channel resources but also reduces the connection processing pressure on the server side, enabling the entire system to operate in complex real-world network environments.

[0022] In one embodiment, before the step of initiating a waiting window shorter than the time threshold when high-priority data is generated, the step includes: Real-time monitoring of the transmission quality of wireless communication networks; When the transmission quality is detected to be lower than the preset weak network threshold, an enhanced waiting window is initiated, wherein the preset duration of the enhanced waiting window is greater than the preset duration of the waiting window that is less than the time threshold. Within the enhanced waiting window, continuously monitor whether the packaging operation of the regular monitoring data is triggered; If the packetization operation is detected to be triggered, all currently generated high-priority data will be immediately injected into the regular data being packetized, forming a mixed data packet marked as the highest priority, and the enhanced waiting window will end. If the enhanced waiting window times out, then regardless of whether the regular data packaging operation is triggered, an independent highest priority data packet is immediately generated for all currently generated high priority data. When the transmission quality is detected to be no lower than the weak network threshold, the waiting window that is less than the time threshold is started.

[0023] As mentioned above, the wireless communication module of the vehicle terminal in Step 1, such as a 4G / 5G module, has the ability to report the underlying link status in real time. This step evaluates transmission quality by reading parameters provided by the module or by actively probing. Evaluation indicators typically include: signal strength: such as Received Signal Strength Indicator (RSSI); network latency and jitter: measured by sending lightweight probe packets (such as Ping) to the server to measure round-trip latency and its fluctuations; data packet loss rate: calculated based on the success / failure statistics of historical data packet transmission. One or more of the above indicators are combined into a "transmission quality" evaluation value and compared with a preset weak network threshold. This allows the system to transition from a "blind transmission" state to an environment-aware state. By quantifying the network condition in real time, the system can identify whether it is currently in a "weak network" environment with poor signal, instability, or high latency, providing an objective and quantitative decision-making basis for subsequent dynamic adjustment of the core transmission strategy. Step 2: When the comprehensively evaluated transmission quality value is lower than the preset weak network threshold, the system determines that it is currently in a degraded communication environment with scarce network resources and high transmission costs (prone to failure, high latency). In response, the system abandons the standard "short wait window" strategy and instead uses a "strengthened wait window" with a longer preset duration. This is a strategy switch for weak network environments. The extended wait time is not intended to increase latency, but rather to strategically increase the probability of high-priority data "hitching a ride." In weak networks, sending a small data packet independently has a low success rate and high cost. By extending the wait time, the system has a better chance of attaching high-priority data to a larger, upcoming regular data packet, thus transforming "multiple small packet transmissions" into "one large packet transmission," which typically has a higher transmission success rate and overall efficiency in weak networks. Step 3: Within the strengthened wait window, the system continuously monitors the packetization triggering of regular data packets. Once triggered, the system no longer injects only the current single high-priority data, but immediately "batch injects" all currently generated but unsent high-priority data, forming a "hybrid data packet" containing regular data and multiple high-priority data, and marking it as the highest priority. This achieves data aggregation and traffic shaping in weak network environments. It solves the problem of multiple high-priority data packets potentially being generated consecutively in weak networks by compressing them into a single transmission opportunity through the "batch injection" mechanism. This minimizes the total number of independent packet transmissions under poor channel conditions, significantly reducing failures, retransmissions, and the resulting additional latency and power consumption caused by frequent transmission attempts, thus improving the utilization efficiency of valuable network resources. Step 4, if the waiting window timeout is strengthened, means that regular data packets still haven't met the transmission conditions (insufficient data volume and not yet timed) within the extended waiting period. At this point, the system no longer continues to wait idly; regardless of the regular data, it immediately generates an independent highest-priority data packet for all backlogged high-priority data and sends it. This is the real-time guarantee mechanism in the weak network strategy. An acceptable upper limit for high-priority data transmission latency in weak network environments is set.Although the waiting time is extended for efficiency, it is never indefinite. This ensures that even under the worst network and data generation conditions, emergency information can still be attempted to be sent within a controllable time, preventing the system from falling into a vicious cycle of "waiting-no vehicle-waiting again". Step 5: When the monitored transmission quality is not lower than, equal to or better than, the weak network threshold, the system determines that the network condition is good and the overhead and risk of transmitting small packets are acceptable. At this time, the system does not activate the enhanced waiting strategy, but directly jumps to and executes the defined standard process, that is, starts the "waiting window less than the time threshold". This achieves adaptive recovery of the strategy. When the network conditions are good, the system automatically switches back to the optimization mode with the lowest latency as the primary goal. This ensures that under most normal operating conditions, the system can exert the defined high-efficiency and low-latency characteristics of "short waiting, priority hitchhiking or independent transmission", achieving the best balance between resource optimization and real-time performance. In this embodiment, the specific and common adverse operating condition of "weak network" is addressed. By dynamically switching the waiting window duration and injection strategy, the system proactively shifts its focus from pursuing "extremely low latency" to pursuing "higher transmission success rate and efficiency" in weak network conditions. This represents an intelligent trade-off between short-term, controllable strategic delays and overall communication reliability and resource conservation. The fundamental reason for this is to ensure that the entire monitoring system maintains robust and reliable data reporting capabilities even in the real world with fluctuating network conditions. This prevents the system from getting bogged down in communication issues due to inappropriate strategies when the network is at its worst and users most need to know the vehicle's status, such as when a fault occurs in a remote area.

[0024] In one embodiment, when the vehicle terminal detects that the vehicle is powered on, the specific steps include: Continuously monitor the wireless authentication signal associated with the vehicle's ignition key; When the wireless authentication signal is detected and verified to have the authority to unlock the vehicle, it is determined that the vehicle is powered on, and the wireless data transmission module and data acquisition are then activated. When the vehicle is turned off, and a vehicle lock authentication signal is detected or no valid wireless authentication signal is received for a preset period of time, the vehicle is determined to be powered off, and the wireless data transmission module is immediately shut down.

[0025] As mentioned above, modern vehicles are generally equipped with keyless entry and start systems. This system relies on wireless communication between the smart key and the body control, such as low-frequency / radio frequency or Bluetooth. In step 1, the onboard terminal continuously scans and decodes signals on the communication channel by integrating a corresponding wireless receiving module or reusing the vehicle's communication bus interface. Its target is the authentication frames or broadcast signals periodically emitted by the legitimate key, containing specific identifiers. These signals are the basis for the vehicle itself to detect the presence of the key, achieve passive unlocking, or one-button start. This achieves non-intrusive, low-power perception of the vehicle's usage status by the terminal. It does not require additional physical sensors or modifications to the vehicle's wiring, but cleverly utilizes the vehicle's existing, mature wireless authentication system as a "status indicator." This allows the terminal to continuously acquire key precursory information for determining whether the vehicle is about to be used without interfering with vehicle functions. In step 2, simply detecting a wireless signal is insufficient to determine that the "vehicle is powered on," as there may be key signals from other vehicles nearby. Therefore, the terminal either communicates with the vehicle gateway / body control module or has its own verification capabilities to verify the validity of the captured signals. The verification process includes checking whether the encrypted identity in the verification signal matches the vehicle and whether the command authority carried by the signal is sufficient to trigger vehicle unlocking, rather than just vehicle locator. Only when the signal passes verification does the system determine that the driver is carrying a legitimate key and intends to use the vehicle, and that the vehicle is about to or has already entered a "power-on" preparation state. This ensures that the monitoring system is only activated when the owner or authorized driver is actually preparing to operate the vehicle. This fundamentally eliminates false triggering, such as when a passerby walks past the vehicle with a key, and also improves system security, preventing unauthorized devices from maliciously waking the terminal through simulated signals. Step 3: Module startup and data acquisition begin. Once the power-on determination is completed, the control logic of the vehicle terminal immediately sends a power-on command to the wireless data transmission module, such as the 4G / 5G communication chip, and the data acquisition module (OBD interface controller). These two core modules then complete a series of startup procedures, including initialization, network registration, and establishing a diagnostic session with the vehicle ECU, and begin executing data acquisition and processing tasks. This achieves seamless synchronous self-starting of the monitoring system and vehicle operation. From the user's perspective, monitoring begins as soon as the vehicle starts, requiring no manual intervention from the terminal switch. This significantly enhances the user experience and the system's automation and intelligence, ensuring that data from the initial stages of vehicle operation (often a period prone to malfunctions or critical for emissions monitoring) is not overlooked. Step 4, determining the timing of "power off" after the vehicle is turned off, is equally crucial. This step defines two complementary decision-making logics: Active locking signal: Listening for a clear lock command authentication signal from the key, indicating the user's clear intention to leave the vehicle. Signal loss timeout: If no valid key authentication signal is received for a preset duration, such as 5 minutes, this is used to handle special cases such as the user not actively locking the vehicle but having turned off the engine and left, or the key battery being depleted.Once any condition is met, the vehicle is determined to be in a "power-off" parking state. A shutdown command is then sent to the wireless data transmission module and data acquisition module, causing them to enter a low-power or completely power-off state. This addresses a fundamental but crucial engineering problem in remote monitoring terminal deployment: how to achieve intelligent, reliable, and seamless synchronization between the terminal's operating cycle and the vehicle's usage cycle in unattended situations. Traditional solutions often rely on detecting the power supply voltage of the OBD interface, but this is prone to misjudgment when the vehicle is "off but not powered off," such as when it is in ACC mode or encounters transient power interference, and it cannot predict in advance when the vehicle is about to start.

[0026] In one embodiment, the step of packaging the high-priority data and regular monitoring data, along with vehicle location information, into data packets with different transmission priorities further includes: Continuously monitor the power supply voltage of the vehicle terminal; When a transient drop in the power supply voltage is detected, and the voltage value is lower than the first threshold but higher than the second threshold that would cause the system to reset, the current critical transmission context is immediately stored in the non-volatile memory. The critical transmission context includes at least: the valid data area information of the data buffer to be sent, the status of the currently active waiting window, and the high-priority data content that has been marked for injection. Once the power supply voltage stabilizes, the critical transmission context is read from the non-volatile memory, and the field state of the data packaging and transmission process is restored accordingly.

[0027] As described above, in step 1, during continuous monitoring of the supply voltage, the power management unit of the vehicle terminal or the analog-to-digital converter (ADC) pin of the microcontroller continuously samples and measures the supply voltage provided by the vehicle through the OBD interface, typically 12V or 24V. This monitoring process operates at a frequency of milliseconds or higher, tracking the instantaneous voltage value and its changing trend in real time. This forms the sensing basis of the entire protection mechanism. It enables the system to "sense" the stability of the vehicle's power network in real time, rather than passively bearing the consequences of voltage changes. Through continuous digital monitoring, the system has the ability to identify abnormal voltage events, such as instantaneous drops and glitches, providing the possibility for implementing pre-protection measures. Step 2 performs two-level judgments on the monitored voltage value: First threshold: representing the lower limit of the normal operating voltage. Below this value, it indicates that the power supply is unstable, but the system hardware, such as the MCU and memory, can still temporarily maintain operation. Second threshold: representing the voltage critical point at which the system will inevitably reset. Above this value, the system can still maintain its logical state; below this value, the chip will reset or crash due to undervoltage. When the voltage drops to between two thresholds, the system identifies it as a "transient drop," a dangerous but not yet fatal state. At this point, the system immediately copies the ongoing, volatile, critical transmission context to non-volatile memory. This context is central to maintaining the continuity of the defined complex packetization logic and includes: buffer valid data area information: indicating which data in the data buffer is stored and ready to be sent, preventing data overwriting or loss; the status of the currently active waiting window: such as the remaining countdown time, preventing the window timer from becoming invalid due to reset; and high-priority data content marked for injection: preventing the loss of identified but not yet injected or sent high-priority data. This achieves "capturing the scene during the drop." Before the system may experience an uncontrollable reset due to further voltage drops, it performs a snapshot backup of the software logic's "state" with extremely high priority and speed. This fundamentally solves the problem of state machine chaos and data loss caused by power disturbances, transforming unreliable hardware-level events into logical events that can be recovered by software. Step 3: Once the power supply voltage is detected to have recovered and stabilized within the normal range (e.g., confirmed through multiple consecutive sampling), the system initialization process, after completing basic hardware checks, will actively query the non-volatile memory for a valid backup of the "critical transmission context." If present, it will be fully read and, based on this information, the read / write pointers and valid data of the data buffer to be sent will be restored. The timer for the waiting window will be restored and resumed from the last saved remaining time. High-priority data to be processed will be restored, allowing it to re-enter the process of waiting for injection or packaging. This achieves "seamless resumption from the backup point." After reading the context from the non-volatile memory, the system can accurately restore the data processing state just before the voltage drop.For the entire data transmission pipeline, this voltage disturbance was like a brief "time pause." After it resumed, all logic continued, and the order, integrity, and priority of data packets remained intact. This ensured the continuity and consistency of the monitoring data stream, and the internal hardware anomaly was virtually imperceptible to both users and the server.

[0028] In one embodiment, after the step of acquiring vehicle operating data collected by the OBD diagnostic interface in real time, the method further includes: Based on the vehicle operation data, determine whether there is a data reliability risk in the vehicle operation data due to the mixing of collection methods. The reliability risk refers to the inconsistency of data sources caused by the mixing of vehicle operation data obtained through active diagnostic requests and data obtained by listening to broadcast frames. If the aforementioned risk is determined to exist, the following controlled data collection process will be executed: Based on predefined classification rules, the vehicle operation data to be collected is divided into basic parameters and extended parameters; The aforementioned basic parameters are collected by listening to and parsing standard data frames periodically broadcast on the vehicle network bus. For the extended parameters, perform merged active collection: combine the requests for multiple extended parameters into a single diagnostic session and send them, and perform logical consistency verification between the obtained response data and the basic parameters collected at the same time; Based on the verification results, the credibility level of the corresponding response data is marked.

[0029] As described above, step 1 is a self-reflection and diagnostic mechanism of the system. Its core lies in identifying a specific systemic problem: the risk of data source inconsistency. The system analyzes the logs of data acquisition requests and the vehicle's response characteristics to determine if a mixed acquisition mode exists. That is, whether some data, such as engine speed, is passively obtained by listening to standard data frames periodically broadcast by the vehicle's ECU, while other data, such as certain freeze frames or test values, is obtained by sending active diagnostic requests to the ECU. The system analyzes the correlation between these two types of data in terms of timestamps and numerical jump logic to determine if there are any inexplicable data contradictions or jumps caused by the ECU's responses under different operating modes (normal operation mode vs. diagnostic service mode). This achieves proactive monitoring and early warning of potential defects in the data acquisition process itself. It enables the system to realize that its own behavior, such as sending diagnostic requests, may be the root cause of data quality problems, rather than simply being a passive receiver. This marks the system's transformation from a simple "data collector" to an "intelligent data quality manager," providing decision-making triggers for implementing targeted, high-fidelity acquisition strategies. Step 2: When a risk is identified, the system intelligently categorizes all vehicle operation data to be collected into two types based on a predefined, configurable classification rule, such as a parameter-source mapping table: Basic parameters: These are typically the most fundamental and core parameters of vehicle operation that are actively broadcast by the ECU, such as vehicle speed, engine speed, and coolant temperature. Extended parameters: These refer to parameters that are not included in standard broadcast messages or require specific conditions to obtain and must be read through active diagnostic requests, such as manufacturer-specific data, detailed content of historical freeze frames, and specific test results. This step involves refined analysis and resource planning of the data acquisition task. Through clear classification, the system can allocate appropriate and minimally disruptive acquisition methods to data of different natures. This avoids applying a "one-size-fits-all" approach with highly intrusive active requests to all data, laying the foundation for building a hierarchical, low-interference acquisition system. Step 3: For data items classified as "basic parameters," the system adopts a completely passive listening method. In other words, the terminal does not send any request commands to the vehicle network. Instead, it acts like a network analyzer, continuously monitoring vehicle buses such as CAN, and capturing, parsing, and extracting standard data frames that periodically appear on the bus and conform to specific identifiers (IDs). This data is actively sent by the ECU during normal operation and represents the vehicle's most accurate real-time operating status. This achieves zero-interference, high-fidelity acquisition of core operating data. Because no requests are sent, the possibility of triggering ECU mode switching is avoided, thus ensuring the purity and high authenticity of this data source. This provides the entire monitoring system with a stable and reliable "ground truth" data stream, serving as the benchmark for all advanced analysis and verification.Step 4: For "extended parameters" that must be actively requested, the system performs optimized active data acquisition, including two key sub-actions: Request Merging: The system does not establish a separate diagnostic session and send a separate request for each extended parameter. Instead, it combines multiple extended parameters that need to be acquired into a single diagnostic session and one, or at least several, composite read commands. For example, it uses the "ReadDataByIdentifier" service to read multiple data identifiers at once. This significantly reduces the number of diagnostic session establishments / disconnections and the total number of request commands. Logical Consistency Verification: After obtaining the response values ​​of the extended parameters, the system does not directly accept them. Instead, it performs a correlational logical analysis with the basic parameter values ​​obtained through passive monitoring during the same period (within the same time window). For example, it compares the "catalytic converter temperature" read from the active request with the "engine load" and "air-fuel ratio" obtained through passive monitoring to check whether their numerical relationship conforms to the basic logic of engine thermodynamics. If an impossible or extremely low-probability contradiction occurs, such as reading an extremely high catalytic converter temperature at idle, it indicates that the data obtained from this active request may be unreliable. In cases where active intervention is necessary, this achieves minimization of interference and maximization of reliability. The merge request significantly reduces the frequency of "harassment" to the ECU, decreasing the probability of abnormal data generated by frequent mode switching. Logical consistency verification constructs a robust data reliability firewall. It uses reliable basic data as a benchmark to examine and filter data obtained through proactive requests, effectively identifying and isolating "distorted values" or "snapshot values" that may arise from diagnostic interactions. Step 5, based on the results of the logical consistency verification, assigns a reliability level label to each extended parameter data obtained through proactive requests. For example, it can be categorized as "high reliability" (completely consistent with the basic data logic), "to be confirmed" (minor but explainable discrepancies exist), and "low reliability / suspicious" (serious logical contradictions exist). This makes data quality information explicit and structured. Data with reliability level labels provides crucial metadata for all backend processing flows. For example, in priority identification, a "low reliability" fault code may be downgraded; in data storage and analysis, data of different reliability levels can be treated differently. This allows the entire system to "know" the reliability of the data, thereby making smarter and more robust decisions.

[0030] In one feasible embodiment, the method further includes: When multiple special processing conditions are triggered simultaneously or exist, a preset priority shaving rule is executed to coordinate the execution process. The special processing conditions include: data transmission quality is lower than the weak network threshold, the power supply voltage of the vehicle terminal experiences a transient drop, and the frequency of high-priority data generation exceeds a preset threshold. When a transient drop in the supply voltage is detected, the critical transmission context is saved, and new data acquisition and active network transmission are paused. After the power supply voltage stabilizes, if the network transmission quality is lower than the weak network threshold, the enhanced waiting window and packetization strategy corresponding to the weak network threshold will be used first to process the high-priority data accumulated during and after the voltage drop. When the network transmission quality recovers to a level no lower than the weak network threshold and there is no risk of voltage drop, the standard data packaging and transmission strategy will be reset.

[0031] In another embodiment, urban delivery vehicles, official vehicles with frequent starts and stops, short-distance driving, and long-term idling, and refrigerated transport vehicles, such as those parked for refrigeration, may never enter a "complete driving cycle" defined by an OBD system, such as never reaching the specified speed, water temperature, or running time. Existing solutions continuously collect and report data, but for emission-related monitoring, such as OBD mode $06 and fault code confirmation, data obtained under incomplete driving cycles is invalid or in an intermediate state. For example, some fault code states may always show "Pending," and sensor monitoring results may show "Not Supported" or "Not Met." Uploading and analyzing this data in the same way as data under normal cycles would pollute the database, leading to false alarms and misjudgments of vehicle health on the server side, or generating a large amount of meaningless "pending confirmation" data streams, wasting storage and computing resources. In this embodiment, the method also includes driving cycle perception, and the steps include: The vehicle is monitored and its current driving cycle stage is determined in real time. The driving cycle stage includes at least the cold start stage, the operation monitoring stage, and the power-off detection stage. Based on the current driving cycle stage and predefined diagnostic validity rules, the vehicle operation data collection strategy is dynamically adjusted, wherein: During the cold start phase and the initial stage of the operation monitoring phase, requests for diagnostic services related to the completion status of emission monitoring or those requiring specific operating conditions to be completed are temporarily suspended. When the vehicle operating parameters are detected to meet the conditions for entering the effective monitoring window, the collection of preset vehicle operating data related to emissions and fault confirmation is triggered. During the post-power-down detection phase, a diagnostic service request specific to the post-power-down detection state is sent. Associate the collected vehicle operation data with the corresponding driving cycle stage identifier and data validity status identifier.

[0032] As mentioned above, the driving cycle is the basic time unit for the vehicle's OBD system to perform emissions monitoring and fault confirmation. It begins when the ignition switch is turned on and ends when the ignition switch is turned off, and must meet specific operating conditions, such as reaching normal operating temperature and completing a series of driving modes. In step 1, the on-board terminal infers the current stage of the cycle in real time by comprehensively analyzing the sequence of key parameters obtained from the OBD interface, such as engine coolant temperature, engine running time, vehicle speed history, and catalyst temperature. For example, the "cold start stage" is usually defined as the period from startup until the coolant temperature first reaches a certain threshold, such as 70°C; the "effective monitoring stage" may require the vehicle to have been running for a period of time and the vehicle speed / load to meet specific conditions. Step 2 pre-sets a set of diagnostic validity rules bound to the driving cycle stage. These rules define which diagnostic requests are valid, meaningful, or should be avoided at which stage. Based on the judgment results of step 1, this step dynamically selects and schedules the timing and type of sending diagnostic service requests, specifically including: cold start and initial postponement: many OBD diagnostic tests, especially emissions-related monitoring in mode $06, require the vehicle to reach a stable operating state to draw valid conclusions. During this phase, actively requesting this data may result in the ECU returning "test incomplete," "not supported," or meaningless values, indicating an invalid request. Delaying these requests avoids wasting network and computing resources and reduces unnecessary interference with the ECU. Effective window-triggered acquisition: When monitored parameters indicate the vehicle has entered an effective monitoring window, such as adequate coolant temperature or continuous vehicle operation for a certain period, the system proactively triggers a set of pre-set, high-value diagnostic data acquisition. This ensures that critical data for emissions compliance verification and final fault confirmation (Pending to Confirmed) is acquired within the golden time window, with the highest data quality and confidence. Specific requests after power-off: Diagnostic tests for some vehicle systems, such as the fuel evaporation system, need to be performed within a specific time after the engine is turned off. During this phase, the system sends specific diagnostic service requests to obtain the results of these tests that can only be completed after the vehicle is stopped, filling the gaps in monitoring during operation. This achieves precise allocation of diagnostic resources and maximizes data value. By synchronizing the acquisition behavior with the vehicle's actual diagnostic capabilities, the system abandons blind, periodic polling and instead performs event-driven, condition-triggered intelligent acquisition. This greatly improves the effectiveness and usability of the acquired data, directly enhancing the accuracy of subsequent analysis and monitoring. Step 3: For each collected data item (whether passively monitored or actively requested), the system will attach two metadata tags when performing storage or packaging operations: Driving Cycle Stage Identifier: Records the stage at which the data was generated, such as: cold start, effective monitoring, after power-down.Data validity status identifier: This is a judgment result automatically generated based on the "diagnostic validity rules" and the actual acquisition context. It is used to mark whether the data was obtained under a condition that can theoretically produce a valid result. For example, the validity identifier of a fault code obtained within the valid monitoring window is "high".

[0033] Reference Figure 3 This application also provides a remote monitoring terminal data acquisition system for an OBD diagnostic interface, comprising: Module 1 is used to acquire vehicle operating data collected by the OBD diagnostic interface in real time when the vehicle terminal detects that the vehicle is powered on. The vehicle operating data includes real-time parameters of the power system, emission-related freeze frame data and fault codes. The identification module 2 is used to perform real-time analysis on the vehicle operation data before data upload, identify high-priority data containing fault codes or abnormal key parameters, and distinguish and mark them from regular monitoring data. Packaging processing module 3 is used to package the high-priority data and regular monitoring data together with vehicle positioning information into data packets with different transmission priorities. Upload module 4 is used to establish a communication connection with the remote server and to upload data packets using a differentiated transmission strategy based on the priority of the data packets, wherein high-priority data packets are transmitted first and in real time. Remote module 5 is used to receive and parse data packets through a remote server, store and alarm according to data category and priority, and provide vehicle status monitoring and remote diagnostic interface to the client.

[0034] As described above, it can be understood that each component of the remote monitoring terminal data acquisition system for the OBD diagnostic interface proposed in this application can realize the function of any one of the remote monitoring terminal data acquisition methods for the OBD diagnostic interface as described above, and the specific structure will not be described in detail.

[0035] Reference Figure 4 This application also provides a computer device, which may be a server, and its internal structure may be as follows: Figure 4As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores monitoring data and other data. The network interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a remote monitoring terminal data acquisition method for an OBD diagnostic interface.

[0036] The aforementioned processor executes the remote monitoring terminal data acquisition method of the OBD diagnostic interface, comprising: when the vehicle terminal detects that the vehicle is powered on, acquiring vehicle operation data collected by the OBD diagnostic interface in real time, the vehicle operation data including real-time power system parameters, emission-related freeze frame data, and fault codes; before uploading the data, performing real-time analysis on the vehicle operation data, identifying high-priority data containing fault codes or abnormal key parameters, and distinguishing and marking them from regular monitoring data; packaging the high-priority data and regular monitoring data, together with vehicle positioning information, into data packets with different transmission priorities; establishing a communication connection with a remote server, and uploading the data packets according to their priority using a differentiated transmission strategy, wherein the high-priority data packets are transmitted preferentially and in real time; receiving and parsing the data packets through the remote server, storing and alarming according to data category and priority, and providing a vehicle status monitoring and remote diagnostic interface to the client.

[0037] One embodiment of this application also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements a remote monitoring terminal data acquisition method for an OBD diagnostic interface, comprising the following steps: when the vehicle terminal detects that the vehicle is powered on, it acquires vehicle operating data collected by the OBD diagnostic interface in real time. The vehicle operating data includes real-time parameters of the power system, emission-related freeze frame data, and fault codes. Before uploading the data, it performs real-time analysis on the vehicle operating data, identifies high-priority data containing fault codes or abnormal key parameters, and distinguishes and marks them from regular monitoring data. It packages the high-priority data and regular monitoring data, together with vehicle positioning information, into data packets with different transmission priorities. It establishes a communication connection with a remote server and uploads the data packets using a differentiated transmission strategy according to their priority, wherein the high-priority data packets are transmitted preferentially and in real time. The remote server receives and parses the data packets, stores and alarms them according to data category and priority, and provides a vehicle status monitoring and remote diagnostic interface to the client.

[0038] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in this application and in the embodiments can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual-speed SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0039] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, apparatus, article, or method that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, apparatus, article, or method. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, apparatus, article, or method that includes that element.

[0040] The above description is only a preferred embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural changes made based on the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for acquiring data from a remote monitoring terminal of an OBD diagnostic interface, characterized in that, The method includes: When the vehicle terminal detects that the vehicle is powered on, it acquires the vehicle operation data collected by the OBD diagnostic interface in real time. The vehicle operation data includes real-time parameters of the power system, emission-related freeze frame data, and fault codes. Before the data is uploaded, the vehicle operation data is analyzed in real time to identify high-priority data containing fault codes or abnormal key parameters, and these data are distinguished and marked from regular monitoring data. The high-priority data, along with regular monitoring data and vehicle location information, are packaged into data packets with different transmission priorities. Establish a communication connection with the remote server and upload data packets using a differentiated transmission strategy based on packet priority, wherein high-priority packets are transmitted preferentially and in real time. The system receives and parses data packets via a remote server, stores and issues alarms based on data type and priority, and provides vehicle status monitoring and remote diagnostic interfaces to clients.

2. The remote monitoring terminal data acquisition method for the OBD diagnostic interface according to claim 1, characterized in that, The step of performing real-time analysis of the vehicle operating data to identify high-priority data containing fault codes or abnormal key parameters includes: Analyze the fault codes and their associated status information obtained from the OBD diagnostic interface; The status information indicating the currently active fault code, and the corresponding real-time parameter anomaly, are identified as the highest priority data. The status information indicates a fault code that is not currently active, and identifies it as pending data with a lower priority than the highest priority.

3. The remote monitoring terminal data acquisition method for the OBD diagnostic interface according to claim 1, characterized in that, The step of packaging the high-priority data, regular monitoring data, and vehicle location information into data packets with different transmission priorities includes: Set up a data buffer to be sent for regular monitoring data and configure a packing trigger strategy; the packing trigger strategy is: when the amount of data in the buffer reaches the capacity threshold, or when a time threshold has elapsed since the last regular data packet was sent, the packing operation of the data in the buffer is triggered. When high-priority data is generated, a wait window shorter than the time threshold is initiated; If the packaging operation of the regular monitoring data is triggered within the waiting window, the high-priority data is injected into the regular data being packaged, forming a mixed data packet marked as high priority. If the packing operation is not triggered by the end of the waiting window, a separate highest priority data packet will be generated for the high-priority data.

4. The remote monitoring terminal data acquisition method for the OBD diagnostic interface according to claim 3, characterized in that, Before the step of initiating a wait window shorter than a time threshold when high-priority data is generated, the steps include: Real-time monitoring of the transmission quality of wireless communication networks; When the transmission quality is detected to be lower than the preset weak network threshold, an enhanced waiting window is initiated, wherein the preset duration of the enhanced waiting window is greater than the preset duration of the waiting window that is less than the time threshold. Within the enhanced waiting window, continuously monitor whether the packaging operation of the regular monitoring data is triggered; If the packetization operation is detected to be triggered, all currently generated high-priority data will be immediately injected into the regular data being packetized, forming a mixed data packet marked as the highest priority, and the enhanced waiting window will end. If the enhanced waiting window times out, then regardless of whether the regular data packaging operation is triggered, an independent highest priority data packet is immediately generated for all currently generated high priority data. When the transmission quality is detected to be no lower than the weak network threshold, the waiting window that is less than the time threshold is started.

5. The remote monitoring terminal data acquisition method for the OBD diagnostic interface according to claim 3, characterized in that, When the vehicle terminal detects that the vehicle is powered on, the specific steps include: Continuously monitor the wireless authentication signal associated with the vehicle's ignition key; When the wireless authentication signal is detected and verified to have the authority to unlock the vehicle, it is determined that the vehicle is powered on, and the wireless data transmission module and data acquisition are then activated. When the vehicle is turned off, and a vehicle lock authentication signal is detected or no valid wireless authentication signal is received for a preset period of time, the vehicle is determined to be powered off, and the wireless data transmission module is immediately shut down.

6. The remote monitoring terminal data acquisition method for the OBD diagnostic interface according to claim 3, characterized in that, The step of packaging the high-priority data and regular monitoring data, along with vehicle location information, into data packets with different transmission priorities further includes: Continuously monitor the power supply voltage of the vehicle terminal; When a transient drop in the power supply voltage is detected, and the voltage value is lower than the first threshold but higher than the second threshold that would cause the system to reset, the current critical transmission context is immediately stored in the non-volatile memory. The critical transmission context includes at least: the valid data area information of the data buffer to be sent, the status of the currently active waiting window, and the high-priority data content that has been marked for injection. Once the power supply voltage stabilizes, the critical transmission context is read from the non-volatile memory, and the field state of the data packaging and transmission process is restored accordingly.

7. The remote monitoring terminal data acquisition method for the OBD diagnostic interface according to claim 1, characterized in that, After the step of acquiring the vehicle operation data collected by the OBD diagnostic interface in real time, the method further includes: Based on the vehicle operation data, determine whether there is a data credibility risk in the vehicle operation data due to the mixing of collection methods. The credibility risk refers to the inconsistency of the data source caused by the mixing of vehicle operation data that needs to be obtained through active diagnostic requests and data obtained by listening to broadcast frames. If the aforementioned risk is determined to exist, the following controlled data collection process will be executed: Based on predefined classification rules, the vehicle operation data to be collected is divided into basic parameters and extended parameters; The aforementioned basic parameters are collected by listening to and parsing standard data frames periodically broadcast on the vehicle network bus. For the extended parameters, perform merged active collection: combine the requests for multiple extended parameters into a single diagnostic session and send them, and perform logical consistency verification between the obtained response data and the basic parameters collected at the same time; Based on the verification results, the credibility level of the corresponding response data is marked.

8. A remote monitoring terminal data acquisition system for an OBD diagnostic interface, characterized in that, include: The acquisition module is used to acquire vehicle operating data collected by the OBD diagnostic interface in real time when the vehicle terminal detects that the vehicle is powered on. The vehicle operating data includes real-time parameters of the power system, emission-related freeze frame data, and fault codes. The identification module is used to perform real-time analysis of the vehicle operation data before data upload, identify high-priority data containing fault codes or abnormal key parameters, and distinguish and mark them from regular monitoring data. The packaging module is used to package the high-priority data and regular monitoring data, together with vehicle positioning information, into data packets with different transmission priorities. The upload module is used to establish a communication connection with the remote server and to upload data packets using a differentiated transmission strategy based on the priority of the data packets, wherein high-priority data packets are transmitted first and in real time. The remote module is used to receive and parse data packets through a remote server, store and alarm according to data category and priority, and provide vehicle status monitoring and remote diagnostic interfaces to the client.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images