Method for processing vehicle status data and processing system for vehicle status data

Abstract

The application provides a vehicle state data processing method and a vehicle state data processing system. The method comprises the following steps: obtaining current state data of a vehicle; determining whether a vehicle state of the vehicle meets a preset state change condition according to the current state data and historical state data stored in a signal value cache area; if yes, encapsulating the current state data and sending the encapsulated data packet to the cloud; and updating the current state data to the signal value cache area. In this way, the current state data meeting the state change condition can be screened out and encapsulated and uploaded, so as to reduce the transmission of redundant data, thereby improving the data transmission efficiency and reducing the resource consumption of the vehicle terminal and the cloud.

Description

Technical Field

[0001] This application relates to the field of vehicle network communication technology, and in particular to a method and system for processing vehicle status data. Background Technology

[0002] In modern vehicle-to-everything (V2X) technology, onboard terminals need to collect and report large amounts of vehicle status data to the cloud in real time to enable functions such as remote monitoring, fault diagnosis, and big data analysis. With the increasing complexity of vehicle electronic and electrical architectures, vehicle status data involving thousands of signal channels, including those related to the engine, battery, and intelligent driving system, needs to be transmitted to the cloud at high frequency.

[0003] In existing technologies, vehicle-mounted terminals typically process vehicle status data through periodic reporting. This means that regardless of whether the vehicle's status has undergone any substantial change, the terminal sends all collected signals to the cloud at fixed intervals. This method generates a large number of repetitive and meaningless data packets when the signal is static or fluctuating smoothly. This not only continuously consumes limited in-vehicle wireless network bandwidth, leading to network congestion and increased latency, but also places significant storage and computational burdens on the cloud server. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a method and system for processing vehicle status data. By comparing the current status data of the vehicle with the historical status data stored in the signal value buffer and judging the vehicle status based on preset status change conditions, the current status data that meets the status change conditions can be filtered out, encapsulated and uploaded, thereby reducing the transmission of redundant data, thereby improving data transmission efficiency and reducing the resource consumption of the vehicle terminal and the cloud.

[0005] In a first aspect, the present invention provides a method for processing vehicle status data, applied to an in-vehicle terminal; the in-vehicle terminal pre-establishes a signal value buffer for each vehicle status data; the method includes: Obtain the vehicle's current status data.

[0006] Based on the current state data and the historical state data stored in the corresponding signal value buffer, determine whether the vehicle's state meets the preset state change conditions.

[0007] If so, encapsulate the current state data and send the encapsulated data packet to the cloud.

[0008] Update the current state data to the signal value buffer.

[0009] In an optional implementation, the step of obtaining the vehicle's current state data includes: Real-time monitoring of message data on the vehicle bus.

[0010] The raw data of vehicle status is extracted from the message data according to the preset signal list.

[0011] The raw data is parsed to obtain the vehicle's current status data.

[0012] In an optional implementation, the state change conditions include: The degree of state change is determined based on the difference between the current state data and the historical state data.

[0013] If the degree of state change exceeds the preset range, the vehicle state is determined to meet the state change conditions.

[0014] In an optional implementation, the method further includes: Real-time monitoring of the frequency of changes in vehicle status data.

[0015] When the frequency of change increases, the preset range of change is increased.

[0016] When the frequency of change decreases, the preset range of change is reduced.

[0017] In an optional implementation, the step of encapsulating the current state data includes: Obtain the signal identifier, the value of the current state data, and the corresponding timestamp corresponding to the current state data that meets the preset state change conditions.

[0018] According to the preset binary protocol format, the signal identifier, the value of the current state data and the timestamp are combined to obtain the data packet.

[0019] In an optional implementation, the method further includes the following steps before encapsulating the current state data: Continuously acquire current state data that meets the state change conditions within a preset time window.

[0020] Encapsulate the current state data, including: At least one current status data obtained within a preset time window is combined and encapsulated into the same data packet.

[0021] In an optional implementation, the method further includes: Get the current wireless network's transmission rate and network latency.

[0022] Determine network load status based on transmission rate and network latency.

[0023] When the network load is high, increase the duration of the preset time window.

[0024] When the network load is low, reduce the duration of the preset time window.

[0025] In an optional implementation, the method further includes: Prioritize tasks that identify current state data that meet the conditions for state change.

[0026] If the task priority is high, immediately encapsulate the current status data to obtain a data packet, and send the data packet to the cloud.

[0027] In an optional implementation, the method further includes: According to the preset cycle duration, the current status data of all vehicle status data is encapsulated into a full data packet and sent to the cloud.

[0028] Secondly, the present invention provides a vehicle status data processing system, including a vehicle-mounted terminal and a cloud connected in communication; the vehicle-mounted terminal is used to execute the vehicle status data processing method as described in any of the foregoing embodiments; a signal value buffer is pre-established in the vehicle-mounted terminal for each vehicle status data.

[0029] The cloud is used to receive data packets sent by the vehicle terminal; update the historical cloud status data corresponding to the vehicle status data according to the data packets, and generate a change record of the corresponding vehicle status data based on the updated historical cloud status data.

[0030] This application provides a method and system for processing vehicle status data. By establishing a signal value buffer for vehicle status data in the vehicle terminal, and judging the vehicle status based on the comparison between the current status data and historical status data, combined with preset status change conditions, the current status data that meets the status change conditions can be filtered out for encapsulation and uploading. This reduces redundant data transmission and lowers the wireless communication load, thereby improving data transmission efficiency, reducing the power consumption of the vehicle terminal and the cloud storage and processing pressure, while ensuring the effectiveness and continuity of vehicle status change information.

[0031] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the application.

[0032] 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

[0033] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0034] Figure 1 A flowchart illustrating the vehicle status data processing method provided in this application embodiment; Figure 2 A flowchart illustrating the current state data acquisition method provided in this application embodiment; Figure 3 Flowchart of the state change condition judgment method provided in the embodiments of this application; Figure 4 A flowchart illustrating the method for encapsulating current state data provided in this application embodiment; Figure 5 This is a schematic diagram of a vehicle status data processing system provided in an embodiment of this application.

[0035] Icons: 1-Vehicle terminal; 2-Cloud. Detailed Implementation

[0036] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0037] To help those skilled in the art better understand this application, a brief introduction to its application scenarios and design concepts is provided.

[0038] Vehicle-mounted terminals typically employ a periodic full-data reporting method, packaging and uploading various vehicle status data collected during vehicle operation to the cloud at fixed time intervals. While simple to implement, this method suffers from redundancy because vehicles are in a steady-state or slowly changing state for most of their operating time. A large amount of vehicle status data, which changes little or not at all within adjacent time periods, is repeatedly uploaded. This redundant data transmission consumes significant wireless communication bandwidth, reducing communication resource utilization efficiency. Furthermore, frequent data packaging and transmission increase the power consumption of the vehicle-mounted terminal, further burdening cloud data storage and processing. In addition, while some existing technologies control data uploads by comparing current and historical data, they typically use fixed thresholds, making it difficult to adapt to the varying characteristics of different vehicle status data and achieving a balance between data accuracy and transmission efficiency.

[0039] Based on this, this application provides a method and system for processing vehicle status data. By establishing a signal value buffer for each vehicle status data in the vehicle terminal, and judging the vehicle status based on the relationship between the current status data and historical status data, combined with preset status change conditions, only the current status data that meets the status change conditions is encapsulated and uploaded. This effectively filters out data with actual change significance and reduces redundant data transmission. Simultaneously, by introducing a dynamic adjustment mechanism based on the degree and frequency of change, the status change conditions can adapt to the changing characteristics of different vehicle status data, further improving data compression while ensuring data validity. Furthermore, by setting a time window to aggregate and encapsulate data that meets the status change conditions, and dynamically adjusting the time window duration based on network load status, a balance between data transmission efficiency and real-time performance can be achieved under different network environments. Furthermore, by prioritizing the transmission of high-priority data and using a periodic full data synchronization mechanism, both the real-time performance of critical data and the consistency and integrity of system data are ensured. In summary, this application can significantly reduce data transmission volume, improve communication efficiency, and reduce resource consumption of the vehicle terminal and cloud while ensuring the validity of vehicle status information.

[0040] To facilitate understanding of this embodiment, the embodiments of this application will be described in detail below.

[0041] This application provides a method for processing vehicle status data, applied to an in-vehicle terminal. The in-vehicle terminal pre-establishes a signal value buffer for each piece of vehicle status data.

[0042] Here, the in-vehicle terminal is typically integrated into the vehicle's electronic and electrical architecture, serving as a gateway device for communication between the vehicle and the external cloud. In one implementation, the in-vehicle terminal is a Telematics Box (TBOX), possessing in-vehicle bus access capabilities, data processing capabilities, and wireless communication capabilities.

[0043] The vehicle-mounted terminal integrates a microprocessor or central processing unit, memory, and a communication module. The memory stores program instructions, signal configuration lists, and signal value buffers. The communication module supports wireless transmission protocols such as 4G, 5G, next-generation cellular networks, in-vehicle Wi-Fi, or dedicated short-range communication. The vehicle-mounted terminal connects to various electronic control units (ECUs) within the vehicle via a Controller Area Network (CAN) interface, a Local Internet (LIN) interface, or an in-vehicle Ethernet interface. The vehicle-mounted terminal not only has the function of real-time acquisition of raw vehicle bus messages but also possesses advanced processing capabilities for protocol parsing, data calculation, logical judgment, and data encapsulation of these raw messages.

[0044] The signal value buffer is a dedicated logical storage area allocated within the internal memory of the vehicle terminal. The vehicle terminal pre-establishes a one-to-one signal value buffer for each piece of vehicle status data that needs to be monitored or reported (i.e., each independent signal channel). The function of the signal value buffer is to persistently store the value of the signal when it most recently successfully triggered the reporting logic. This value is defined as historical status data and serves as a benchmark for subsequently determining whether the vehicle status has undergone a substantial change.

[0045] In terms of physical implementation, the signal value buffer can be configured in the random access memory (RAM) of the vehicle terminal to ensure high-speed read and write, or it can be backed up synchronously in non-volatile memory (such as Flash or EEPROM) to ensure that the vehicle terminal can still obtain the previous historical status data after power failure and restart, and avoid duplicate reporting.

[0046] The signal value buffer structure supports multiple data types, including but not limited to Boolean, integer, floating-point, and bit-mapped types. For each signal value buffer, the vehicle terminal assigns a unique signal identifier, ensuring that the current state data can accurately locate the corresponding historical state data during comparison. Through this distributed caching architecture, the vehicle terminal can process hundreds or thousands of concurrent signal change monitoring tasks in parallel, thereby achieving efficient management of large-scale vehicle state data under limited hardware resources.

[0047] Reference Figure 1 The vehicle status data processing method provided in this application includes: Step S101: Obtain the current status data of the vehicle.

[0048] Here, the onboard terminal collects various operating parameters of the vehicle in real time through the onboard network bus. The onboard network bus includes the Controller Area Network Bus (CAN bus), the Local Interconnect Network Bus (LIN bus), or the onboard Ethernet. The onboard terminal obtains the vehicle's current status data from the onboard network bus, which includes signals from the vehicle's powertrain system, chassis system, body system, and intelligent driving system.

[0049] Specifically, current status data includes, but is not limited to: vehicle speed, engine speed, remaining battery charge, battery voltage, battery current, motor speed, gear position, accelerator pedal travel, brake pedal position, steering wheel angle, and fault codes from various control units. When acquiring current status data, the vehicle terminal can periodically acquire it according to a preset sampling frequency, or asynchronously based on the triggering of a specific event. The vehicle terminal parses and performs protocol conversion on the collected raw messages to obtain numerical values ​​or status bits with physical meaning.

[0050] Step S102: Based on the current state data and the historical state data stored in the corresponding signal value buffer, determine whether the vehicle state meets the preset state change conditions.

[0051] Here, the signal value buffer is used to persistently store the value of the signal when it was last successfully triggered to report the logic, i.e., historical state data. After obtaining the current state data, the vehicle terminal compares the current state data with the corresponding historical state data in the signal value buffer, either numerically or logically, to determine whether the vehicle's state meets the preset state change conditions.

[0052] The preset state change conditions include multiple judgment dimensions to accommodate signals of different properties: First, for analog signals (such as vehicle speed, voltage, and other numerical data), the condition for state change is that the absolute value of the difference between the current state data and the historical state data exceeds a preset numerical threshold, or the rate of change of the current state data relative to the historical state data exceeds a preset change ratio.

[0053] Second, for switch or status signals (such as gear position, headlight switch, door status, etc.), the condition for a status change is that the current status data has undergone a state jump or bit flip relative to the historical status data.

[0054] Third, for composite signals, the state change condition can be a combination of the above-mentioned multiple judgment logics.

[0055] Through this comparison mechanism, the vehicle-mounted terminal can accurately filter out redundant data within a stable fluctuation range and only locate state nodes with substantial changes.

[0056] Step S103: If yes, encapsulate the current state data and send the encapsulated data packet to the cloud.

[0057] Here, when the vehicle terminal determines that the vehicle status meets the preset status change conditions, it indicates that the current status data has reporting value. The vehicle terminal then initiates a data packaging process, encapsulating the current status data according to a preset communication protocol format. The encapsulation process includes adding a signal identifier, data length, current status data value, and sampling timestamp to the current status data.

[0058] To improve transmission efficiency, the vehicle-mounted terminal can encapsulate data using binary or structured text formats. After encapsulation, the vehicle-mounted terminal establishes a secure connection with the cloud server via an in-vehicle communication module (such as 4G, 5G, or in-vehicle Wi-Fi wireless network) and sends the generated data packets to the cloud in real time. During transmission, the vehicle-mounted terminal supports a retransmission mechanism for disconnections and a priority scheduling mechanism to ensure that critical change data is accurately and promptly delivered to the cloud storage center for subsequent remote monitoring or big data analysis.

[0059] Step S104: Update the current state data to the signal value buffer.

[0060] Here, after determining that the state change conditions are met or the data reporting action is completed, the vehicle terminal writes the current state data into the corresponding signal value buffer to replace the original historical state data.

[0061] In practical applications, there are two triggering times for updating the signal value buffer: one is to update the signal value buffer immediately as long as the state change condition is met, regardless of whether the reporting is successful, in order to ensure the real-time nature of the judgment benchmark; the other is to update the signal value buffer only after confirming that the data packet has been successfully sent to the cloud and receiving feedback, in order to ensure the consistency between the vehicle terminal and the cloud data.

[0062] In an optional implementation, refer to Figure 2 Step S101 includes the following steps S201-S203.

[0063] Step S201: Monitor message data on the vehicle bus in real time.

[0064] Here, the onboard terminal connects to the vehicle's internal communication network via a built-in controller area network (Controller Area Network) interface, Ethernet interface, or local internet interface. The onboard terminal remains active during vehicle operation, listening to and monitoring all message data on the onboard bus in real time. The message data on the onboard bus is sent cyclically by various electronic control units within the vehicle according to a preset communication protocol or triggered by events.

[0065] The vehicle terminal's communication controller performs logical conversion on the physical voltage levels on the vehicle bus, restoring continuous electrical signals into data frame format message data. To ensure real-time data transmission, the vehicle terminal has a high-frequency message monitoring capability, capable of capturing millisecond-level bus data changes. This real-time monitoring process provides the raw data stream foundation for subsequent signal filtering and analysis, ensuring that the vehicle terminal can acquire the real-time communication status of the entire vehicle system without omission.

[0066] Step S202: Extract the raw data of vehicle status data from the message data according to the preset signal list.

[0067] Here, the vehicle terminal pre-stores a list of preset signals, which defines the attribute information of the vehicle status data that needs to be monitored and reported. The attribute information in the preset signal list specifically includes: message identifier, the start bit of the signal in the message, the bit length occupied by the signal, and the bus channel to which it belongs.

[0068] After receiving massive amounts of message data, the vehicle terminal matches the identifier of each message with a preset signal list. When the identifier matches the definition in the preset signal list, the vehicle terminal extracts the corresponding binary segment from the data field of that message based on the offset and length information specified in the preset signal list. The extracted binary segment is the raw vehicle status data. Through this filtering mechanism based on the preset signal list, the vehicle terminal can accurately extract valid raw data related to key components such as the power battery, motor, and vehicle control from the complex bus traffic, while eliminating irrelevant interference information.

[0069] Step S203: parse the raw data to obtain the current status data of the vehicle.

[0070] Here, after the vehicle terminal obtains the raw vehicle status data, it calls the preset protocol conversion logic to parse the raw data. The parsing process involves performing sign bit determination, big-endian or little-endian byte order conversion, resolution multiplication, and offset addition on the raw data.

[0071] Through the above parsing operations, the vehicle terminal transforms the originally meaningless binary raw data into current state data with actual physical meaning. For example, the vehicle terminal parses a hexadecimal raw data into a numerical value representing a specific vehicle speed, a floating-point number representing battery voltage, or a Boolean value representing a switch state.

[0072] In an optional implementation, refer to Figure 3 The conditions for state change include the following steps S301-S302.

[0073] Step S301: Determine the degree of state change based on the difference between the current state data and the historical state data.

[0074] Here, after acquiring the vehicle's current status data, the vehicle terminal immediately reads the corresponding historical status data from the signal value buffer in its internal memory. The vehicle terminal then subtracts the value of the current status data from the value of the historical status data to calculate the difference between the current status data and the historical status data.

[0075] The vehicle terminal takes the absolute value of the calculated difference and defines this absolute value as the degree of state change. The degree of state change reflects the fluctuation of the vehicle signal between two consecutive reporting cycles. For example, if the historical vehicle speed status data stored in the signal value buffer is 60.0 km / h, and the currently monitored vehicle speed status data is 60.8 km / h, then the degree of state change calculated by the vehicle terminal is 0.8 km / h.

[0076] Step S302: If the degree of state change exceeds the preset change range, determine that the vehicle state meets the state change conditions.

[0077] Here, the onboard terminal compares the calculated degree of state change with a pre-set range of change. The pre-set range of change represents the threshold value at which the vehicle state data is allowed to fluctuate normally, i.e., the pre-set change threshold.

[0078] In one implementation, the vehicle terminal presets different ranges of variation values ​​for different types of signals.

[0079] For the total voltage signal of the power battery, the preset variation range can be set between 0.5V and 1.0V; for the speed signal of the drive motor, the preset variation range can be set between 50rpm and 100rpm; for the vehicle speed signal, the preset variation range can be set between 0.5km / h and 1.0km / h.

[0080] When the degree of state change exceeds a preset range, the vehicle terminal determines that the signal has undergone a substantial state drift or abrupt change, thereby confirming that the vehicle state meets the state change conditions and triggering subsequent data encapsulation and reporting processes. Conversely, if the degree of state change is within the preset range, the vehicle terminal determines that the fluctuation is normal signal noise or a weak disturbance and has no reporting value, thus effectively filtering out redundant silent data.

[0081] The process of determining the preset variation range can be statically set based on the vehicle's factory calibration parameters, or dynamically calibrated based on the original fluctuation characteristics of the signal. Specifically, the vehicle terminal acquires the standard fluctuation range value (i.e., noise range) of the vehicle status data, and multiplies this standard fluctuation range value by a preset multiple (e.g., 1.2 to 1.5 times) as the initial preset variation range.

[0082] By setting a range with a redundancy coefficient, the vehicle terminal can minimize the frequency of reporting messages and reduce the communication pressure on the vehicle wireless network while ensuring that critical data is not lost.

[0083] In an optional implementation, the method further includes the following steps S401-S403.

[0084] Step S401: Monitor the frequency of changes in vehicle status data in real time.

[0085] Here, the vehicle-mounted terminal uses built-in counters and timers to perform real-time frequency statistics on the changes in the status data of each monitored vehicle. Within a preset sampling period, the vehicle-mounted terminal records the number of times the vehicle status data meets the status change conditions, or calculates the time interval between two consecutive instances of meeting the status change conditions.

[0086] Specifically, the vehicle terminal uses a sliding window algorithm to count the frequency of vehicle status data reporting over the past minute. If the vehicle status data fluctuates frequently and exceeds the current preset range of change multiple times within a short period, the vehicle terminal determines that the signal is in a high-frequency oscillation state. Monitoring the frequency of change provides the system with a real-time indicator reflecting the activity level of the signal, enabling the vehicle terminal to identify whether the signal is in a relatively stable cruising state or in a dynamic operating condition with violent fluctuations (such as rapid acceleration or frequent braking).

[0087] Step S402: When the frequency of change increases, increase the preset range of change.

[0088] Here, when the vehicle terminal determines that the frequency of changes in vehicle status data has increased and exceeds a preset frequency upper limit threshold, it will automatically trigger the logic to increase the preset change range. The purpose of increasing the preset change range is to filter out minor, non-critical numerical fluctuations in a high-frequency fluctuating environment, thereby preventing the vehicle terminal from generating excessive communication load due to frequent data packet encapsulation.

[0089] In specific implementations, the method for increasing the preset variation range includes a proportional growth method. The vehicle terminal multiplies the current preset variation range by a step factor greater than 1 (e.g., 1.2 or 1.5) to obtain a new preset variation range. For example, if the current preset vehicle speed variation range is 0.5 km / h, when the vehicle speed signal changes too rapidly due to road bumps or frequent pedal input by the driver, the vehicle terminal dynamically increases the preset vehicle speed variation range to 0.75 km / h. Through this adaptive expansion of the range, the vehicle terminal can effectively compress the reporting frequency under extreme conditions, ensuring that the bandwidth of the vehicle wireless network is not saturated by a sudden surge of redundant packets.

[0090] Step S403: When the frequency of change decreases, reduce the preset range of change.

[0091] Here, when the vehicle terminal determines that the frequency of changes in vehicle status data has decreased and fallen below a preset lower frequency threshold, it will automatically trigger a reduction logic for the preset change range. When the signal tends to stabilize, reducing the preset change range can improve the vehicle terminal's sensitivity to signal changes, ensuring that any small substantial state deviations during stable operation can be captured by the cloud in a timely manner.

[0092] In specific implementations, the method for reducing the preset variation range includes a step-reduction method. The vehicle terminal subtracts a preset step value from the current preset variation range, or multiplies the current preset variation range by an attenuation coefficient less than 1 (e.g., 0.8), until it returns to the preset initial reference value. For example, when the vehicle enters constant speed cruise mode and the frequency of vehicle speed signal changes significantly decreases, the vehicle terminal adjusts the preset vehicle speed variation range, which was originally increased to 0.75 km / h, back to 0.5 km / h. Through this dynamic reduction mechanism, the vehicle terminal can maintain high-precision monitoring in static environments and maintain efficient bandwidth utilization in dynamic environments, thereby achieving a dynamic optimal balance between the accuracy of vehicle status data reporting and transmission costs.

[0093] In an optional implementation, refer to Figure 4 The step of encapsulating the current state data in step S103 includes the following steps S501-S502.

[0094] Step S501: Obtain the signal identifier, the value of the current state data, and the corresponding timestamp corresponding to the current state data that meets the preset state change conditions.

[0095] Here, when the vehicle terminal determines through logical comparison that the vehicle's current state data meets the preset state change conditions, the vehicle terminal extracts the complete attribute information associated with the current state data from memory. The vehicle terminal first obtains the signal identifier corresponding to the signal in the preset signal list. The signal identifier is a unique number or code used to identify which vehicle parameter the data specifically represents (such as the vehicle speed signal identifier or the battery voltage signal identifier) ​​during cloud parsing.

[0096] Simultaneously, the vehicle-mounted terminal acquires the physical values ​​of the current state data. Furthermore, the vehicle-mounted terminal uses a built-in high-precision clock chip or system timer to obtain the precise moment the current state data was collected and converts it into a timestamp corresponding to the current state data. The timestamp records the absolute time or relative offset time of the signal generation, ensuring that the cloud can accurately reconstruct the trajectory of the vehicle's state changes according to the timeline after receiving the data packet.

[0097] Step S502: According to the preset binary protocol format, the signal identifier, the value of the current state data and the timestamp are combined to obtain a data packet.

[0098] Here, the vehicle-mounted terminal calls a preset encoding algorithm to assemble the signal identifier, the current status data value, and the timestamp according to a preset binary protocol format. The preset binary protocol format defines the message structure of the data packet, which typically consists of a start bit, a protocol version number, a data carrier area, and a check bit.

[0099] Within the data carrier area, the vehicle terminal places a signal identifier at the beginning, followed immediately by the value of the current status data. To compress the data volume, the vehicle terminal performs bitwise operations on the current status data value according to the bit length defined in the preset signal list, converting it into a compact binary code stream. Next, the vehicle terminal serializes the timestamp and fills it into the specified offset position within the data carrier area.

[0100] During the combination process, if multiple signals satisfy preset state change conditions, the vehicle terminal can sequentially arrange the identifiers and values ​​of these signals within the same data packet's carrier area and calculate a redundancy check code (such as a CRC check code) for the entire data packet. Through this binary protocol encapsulation method, the messages generated by the vehicle terminal have extremely high data density compared to structured text formats (such as JSON), significantly reducing data packet traffic consumption during transmission in the vehicle wireless network, ultimately resulting in a compact data packet to be sent to the cloud.

[0101] In an optional implementation, before encapsulating the current state data in step S103, the method further includes: Continuously acquire current state data that meets the state change conditions within a preset time window.

[0102] Here, the vehicle terminal has a preset time window, which serves as a timing buffer period to aggregate all valid change data generated within that time period.

[0103] After the preset time window opens, the vehicle terminal continuously monitors and acquires current state data that meets preset state change conditions. For example, within a preset time window with a period of 500ms, if the vehicle speed signal, battery voltage signal, and motor temperature signal successively trigger the preset state change conditions, the vehicle terminal will temporarily store the current state data of these signals in the transmission buffer instead of triggering network requests one by one. Through this delay-waiting mechanism based on the preset time window, the vehicle terminal can effectively transform scattered triggering events into batch processing tasks, thereby avoiding the additional power consumption and signaling overhead caused by the high-frequency switching of the vehicle communication module.

[0104] Step S103 encapsulates the current state data, including: At least one current status data obtained within a preset time window is combined and encapsulated into the same data packet.

[0105] Here, when the preset time window reaches its preset duration, the vehicle terminal triggers the combined encapsulation logic. The vehicle terminal retrieves all current state data accumulated within the preset time window that meet the preset state change conditions from the transmission buffer.

[0106] The vehicle-mounted terminal arranges and combines at least one current status data acquired within a preset time window according to a preset binary protocol format. During the combination process, the vehicle-mounted terminal matches a corresponding signal identifier and timestamp for each current status data. Subsequently, the vehicle-mounted terminal encapsulates these combined data sequences into the data carrier area of ​​the same data packet.

[0107] This multi-signal encapsulation method allows a single data packet to carry multiple dimensions of vehicle dynamic change information simultaneously. Because multiple current status data points share the same packet header information, protocol version number, and checksum, the effective payload ratio of the data packet is significantly improved. By reducing the total number of data packets, the vehicle terminal reduces the concurrent connection pressure on the vehicle wireless network, ensuring that the reporting of large-scale vehicle status data can be completed more efficiently with limited bandwidth resources, ultimately generating a comprehensive data packet containing multiple change information.

[0108] In an optional implementation, the method further includes the following steps S601-S604.

[0109] Step S601: Obtain the current wireless network's transmission rate and network latency.

[0110] Here, the vehicle-mounted terminal obtains the network quality parameters of the current wireless network in real time through its built-in wireless communication module. The wireless communication module, through interaction with the base station, periodically measures and reports back the current uplink transmission rate and end-to-end network latency.

[0111] Transmission rate represents the amount of data that the vehicle terminal can send to the cloud per unit of time, while network latency reflects the round-trip time from when the data packet is sent from the vehicle terminal to when it is received by the cloud and a confirmation message is sent back.

[0112] Step S602: Determine the network load status based on the transmission rate and network latency.

[0113] Here, after acquiring the transmission rate and network latency, the vehicle-mounted terminal inputs these parameters into a preset network evaluation model to determine the network load status. The network evaluation model has multiple preset performance ranges. When the transmission rate is lower than a preset rate threshold and the network latency is higher than a preset latency threshold, the vehicle-mounted terminal determines that the current wireless network environment is extremely poor and the risk of data congestion is high, thus determining the network load status as high load.

[0114] Conversely, when the transmission rate is high and the network latency is extremely low and stable, the vehicle terminal determines that the network environment is excellent and bandwidth resources are sufficient, thus classifying the network load as low. Through this real-time performance evaluation, the vehicle terminal can dynamically identify whether the vehicle is in special scenarios with unstable signals, such as tunnels, underground parking garages, or congested base stations, thereby providing a basis for smooth control of data reporting frequency.

[0115] Step S603: When the network load is high, increase the duration of the preset time window.

[0116] Here, the vehicle-mounted terminal adaptively adjusts the duration of the preset time window based on the determined network load status, so as to achieve a dynamic balance between data reporting accuracy and communication success rate.

[0117] In high-load scenarios, to avoid further exacerbating network congestion by frequently sending small data packets, the vehicle-mounted terminal automatically increases the duration of the preset time window. Increasing the preset time window means that the vehicle-mounted terminal will extend the time it caches changed data locally, thereby aggregating more current status data into a single data packet for batch transmission. For example, the vehicle-mounted terminal increases the preset time window from 500ms to 2s. By reducing the frequency of data packet transmission, the vehicle-mounted terminal reduces the pressure on unstable network channels and improves the success rate of single data reporting.

[0118] Step S604: When the network load is low, reduce the duration of the preset time window.

[0119] Here, in low-load scenarios, due to ample network resources, the vehicle terminal automatically reduces the duration of the preset time window to improve the real-time performance of data reporting. For example, the vehicle terminal may reduce the preset time window to 100ms or even lower. Reducing the duration of the preset time window shortens the dwell time of changing data on the vehicle terminal, enabling the cloud to synchronize vehicle status changes almost in real time. Through this closed-loop adjustment mechanism based on network load status, the vehicle terminal ensures that it can process vehicle status data with the optimal transmission strategy under any network environment.

[0120] In an optional implementation, the method further includes the following steps S701-S702.

[0121] Step S701: Identify the task priority of the current state data that meets the state change conditions.

[0122] Here, after determining that the current state data meets the preset state change conditions, the vehicle terminal will identify the task priority of the current state data in real time according to the priority configuration information in the preset signal list. The preset signal list predefines different priority levels for each type of vehicle state data, usually divided into high priority and normal priority.

[0123] Task priorities are assigned based on the degree to which signals affect vehicle safety and the real-time performance of monitoring. For example, critical safety signals such as vehicle collision warnings, high-temperature battery warnings, serious braking system malfunctions, or airbag deployment status are defined as high priority. Auxiliary signals such as ambient temperature, air conditioning settings, or general driving statistics are defined as ordinary priority.

[0124] Step S702: If the task priority is high, immediately encapsulate the current status data to obtain a data packet and send the data packet to the cloud.

[0125] Here, if the task priority is determined to be high priority, the vehicle terminal will skip the preset time window timing waiting logic and will not queue up with other ordinary signals.

[0126] The vehicle-mounted terminal immediately extracts the current status data, signal identifier, and timestamp of the high-priority signal, and quickly encapsulates it independently according to a preset binary protocol format to generate an emergency data packet. Subsequently, the vehicle-mounted terminal's wireless communication module will preempt the transmission queue and prioritize sending the emergency data packet to the cloud via the wireless network.

[0127] This high-priority, immediate reporting logic ensures that abnormal states involving vehicle safety and core faults reach the cloud monitoring platform within milliseconds. Even during periods of high network load or at the beginning of a preset time window, high-priority signals can be reported with zero latency through a queue-jumping mechanism. This minimizes the cloud's response time to dangerous vehicle conditions, guaranteeing vehicle operational safety and extreme real-time monitoring.

[0128] In an optional implementation, the method further includes: According to the preset cycle duration, the current status data of all vehicle status data is encapsulated into a full data packet and sent to the cloud.

[0129] Here, to ensure eventual consistency between the historical cloud state data stored in the cloud and the signal value cache on the vehicle terminal, the vehicle terminal, in addition to executing trigger-based incremental reporting logic, also has a periodic full reconciliation mechanism. The vehicle terminal has a preset period duration (e.g., every 30 seconds or 60 seconds).

[0130] When the timing period reaches a preset threshold, the vehicle terminal traverses all signal channels in the preset signal list and obtains the latest current status data for each vehicle status data point. Instead of comparing status change conditions, the vehicle terminal packages and encapsulates the identifiers, physical values, and unified timestamps of all signals according to a full-data packet format, generating a full data packet. The vehicle terminal then sends this full data packet to the cloud via the wireless network. This periodic full reporting effectively corrects data deviations in the cloud caused by wireless network packet loss or local judgment errors, providing the cloud with a complete and highly reliable snapshot of the vehicle status.

[0131] Based on the above embodiments, this application provides a vehicle status data processing system, referring to... Figure 5 The vehicle status data processing system provided in this application includes a vehicle-mounted terminal 1 and a cloud 2 connected in communication; the vehicle-mounted terminal 1 is used to execute the vehicle status data processing method as described in any of the foregoing embodiments; a signal value buffer is pre-established in the vehicle-mounted terminal 1 for each vehicle status data.

[0132] Cloud 2 is used to receive data packets sent by vehicle terminal 1; update the historical cloud status data corresponding to the vehicle status data according to the data packets, and generate a change record of the corresponding vehicle status data based on the updated historical cloud status data.

[0133] Here, the vehicle terminal 1 pre-establishes a signal value buffer for each vehicle status data, which is used to perform efficient change monitoring locally. The vehicle terminal 1 pushes the filtered valid change data and periodic full reconciliation data to the cloud 2 through a secure encrypted channel by real-time acquisition of bus messages, parsing signals, determining the degree of change, performing dynamic time window caching, and high-priority queue sending.

[0134] Cloud 2 consists of a data receiving server, a database, and a business logic engine. Cloud 2 is used to receive various data packets (including encapsulated variable data packets and full data packets) sent by vehicle terminal 1. After receiving the data packets, Cloud 2 first performs protocol decoding to extract the signal identifier and its corresponding value.

[0135] Cloud 2 updates the historical cloud status data corresponding to the vehicle status data based on the content of the data packet. By overwriting the old values ​​in the database with the received changes, Cloud 2 can always maintain a digital mirror that is highly synchronized with the actual operating status of the vehicle. Based on the updated historical cloud status data, Cloud 2 further generates change records of the corresponding vehicle status data, forming a complete vehicle operation trajectory log. These change records provide an accurate data foundation for subsequent vehicle health scoring, remote fault warning, and driving behavior analysis, thereby realizing full lifecycle monitoring of vehicle status.

[0136] The vehicle status data processing system provided in this application embodiment achieves intelligent end-to-end management of vehicle data from collection and judgment to transmission by pre-setting a signal value buffer in the vehicle terminal and establishing a collaborative mechanism with the cloud. This system utilizes the local computing power of the vehicle terminal to transform traditional periodic full-scale reporting into trigger-based reporting based on status change conditions. Combined with dynamic time window load adjustment and a high-priority signal immediate transmission strategy, it ensures that the cloud can accurately and in real-time reproduce key vehicle status change records while significantly reducing redundant data transmission within normal fluctuation ranges. This effectively solves the technical pain points of wireless network bandwidth congestion and cloud storage resource waste in large-scale vehicle-to-everything (V2X) applications, significantly improving the reliability of vehicle-cloud data interaction and system operating efficiency.

[0137] The computer program product provided in this application includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

[0138] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and apparatus described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0139] Furthermore, in the description of the embodiments of this application, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0140] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0141] In the description of this application, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0142] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the scope of the technology disclosed in this application, or make equivalent substitutions for some of the technical features. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the protection scope of this application.

Claims

1. A method for processing vehicle status data, characterized in that, Applications in vehicle-mounted terminals; The vehicle-mounted terminal pre-establishes a signal value buffer for each vehicle status data; the method includes: Obtain the vehicle's current status data; Based on the current state data and the corresponding historical state data stored in the signal value buffer, it is determined whether the vehicle state meets the preset state change conditions. If so, the current state data is encapsulated, and the encapsulated data packet is sent to the cloud; Update the current state data to the signal value buffer.

2. The method for processing vehicle status data according to claim 1, characterized in that, The step of obtaining the current status data of the vehicle includes: Real-time monitoring of message data on the vehicle bus; The original data of the vehicle status data is extracted from the message data according to the preset signal list; The original data is parsed to obtain the current status data of the vehicle.

3. The method for processing vehicle status data according to claim 1, characterized in that, The conditions for the state change include: The degree of state change is determined based on the difference between the current state data and the historical state data; If the degree of state change exceeds a preset range, the vehicle state is determined to meet the state change condition.

4. The method for processing vehicle status data according to claim 3, characterized in that, The method further includes: Real-time monitoring of the frequency of changes in the vehicle status data; When the frequency of change increases, the preset range of change is increased; When the frequency of change decreases, the preset range of change is reduced.

5. The method for processing vehicle status data according to claim 1, characterized in that, The step of encapsulating the current state data includes: Obtain the signal identifier, the value of the current state data, and the corresponding timestamp of the current state data that satisfy the preset state change conditions; The data packet is obtained by combining the signal identifier, the value of the current state data, and the timestamp according to a preset binary protocol format.

6. The method for processing vehicle status data according to claim 1, characterized in that, Before encapsulating the current state data, the method further includes: Continuously acquire current state data that meets the state change conditions within a preset time window; The encapsulation of the current state data includes: At least one current state data obtained within the preset time window is combined and encapsulated into the same data packet.

7. The method for processing vehicle status data according to claim 6, characterized in that, The method further includes: Obtain the current wireless network's transmission rate and network latency; Determine the network load status based on the transmission rate and network latency; When the network load is high, increase the duration of the preset time window; When the network load is low, the duration of the preset time window is reduced.

8. The method for processing vehicle status data according to claim 6, characterized in that, The method further includes: Identify the task priority of the current state data that satisfies the state change conditions; If the task priority is high, the current status data is immediately encapsulated to obtain the data packet, and the data packet is sent to the cloud.

9. The method for processing vehicle status data according to claim 1, characterized in that, The method further includes: According to a preset period, the current status data of all vehicle status data is encapsulated into a full data packet, and the full data packet is sent to the cloud.

10. A system for processing vehicle status data, characterized in that, The system includes a vehicle-mounted terminal and a cloud connection; the vehicle-mounted terminal is used to execute the vehicle status data processing method as described in any one of claims 1-9; the vehicle-mounted terminal pre-establishes a signal value buffer for each vehicle status data. The cloud is used to receive data packets sent by the vehicle-mounted terminal; The historical cloud status data corresponding to the vehicle status data is updated according to the data packet, and a change record of the corresponding vehicle status data is generated based on the updated historical cloud status data.

Images