A message encapsulation method and analysis method based on Internet of Vehicles, a terminal and a system

Abstract

The application provides a message encapsulation method and analysis method based on Internet of Vehicles, a terminal and a system, and belongs to the technical field of Internet of Vehicles. A first artificial intelligence agent is installed on a vehicle information processing terminal. The method comprises the following steps: obtaining a service message; serializing the service message to generate serialized service data; the serialized service data is in binary format; performing abnormality analysis on the serialized service data by using the first artificial intelligence agent; if the serialized service data is normal, generating a frame message according to a start identifier, a public header field and the serialized service data; the public header field comprises a request identifier, a subcommand and a first abnormality confidence obtained through abnormality analysis; and sending the frame message to an Internet of Vehicles cloud terminal through an Internet of Vehicles communication link. The application reduces the complexity of protocol development and operation and maintenance cost.

Description

Technical Field

[0001] This invention relates to the field of vehicle networking technology, specifically to a message encapsulation method, parsing method, terminal, and system based on vehicle networking. Background Technology

[0002] As the core edge node of vehicle-to-cloud communication, the vehicle information processing terminal undertakes all-scenario business interactions such as vehicle status reporting, remote vehicle control, and emergency call (ECALL).

[0003] Currently, there are two main implementation schemes for vehicle-to-cloud communication protocols. The first is a custom binary bare protocol, where each service independently designs its message structure as needed, resulting in fragmented formats and high coupling. The second is a basic Protobuf serialization scheme, which is only used as a data packaging tool. It does not break down the core requirements of vehicle-to-cloud communication based on the fundamental deconstruction method, and it does not introduce edge AI agents with local decision-making and self-learning capabilities, as well as corresponding LoRA lightweight adaptation technology, into the in-vehicle information processing terminal. As a result, the vehicle cannot form a complete intelligent closed loop from data perception, analysis and decision-making, execution feedback to model self-iteration.

[0004] The aforementioned existing technologies still have significant drawbacks. First, all AI computing power is placed in the cloud, and the vehicle does not have independent intelligent processing capabilities locally. Each interaction requires uploading raw data to the cloud for analysis, resulting in high response latency and large network bandwidth consumption. Second, there is a risk of user privacy leakage. Summary of the Invention

[0005] In view of this, it is necessary to provide a message encapsulation method, parsing method, terminal and system based on vehicle networking to solve the technical problems of chaotic message format and difficult operation and maintenance in the existing vehicle-cloud communication protocol.

[0006] To address the aforementioned technical problems, in a first aspect, the present invention provides a message encapsulation method based on the Internet of Vehicles (IoV), applied to an in-vehicle information processing terminal, wherein the in-vehicle information processing terminal is equipped with a first artificial intelligence agent, comprising: Retrieve business messages; The business message is serialized to generate serialized business data; the serialized business data is in binary format. The first AI agent performs anomaly analysis on the serialized business data. If the serialized service data is not abnormal, a frame message is generated based on the start identifier, common header fields, and the serialized service data; the common header fields include the request identifier, subcommand, and the first anomaly confidence level obtained from anomaly analysis; The frame message is sent to the vehicle-to-everything (V2X) cloud terminal via the vehicle-to-everything (V2X) communication link.

[0007] In one possible implementation, the anomaly analysis of the serialized business data by the first artificial intelligence agent includes: The first business feature vector of the serialized business data is extracted through the first anomaly analysis model maintained by the first artificial intelligence agent. The first anomaly confidence level is calculated based on the first business feature vector and the first normal feature vector in the first preset feature library. Compare the first anomaly confidence level with the preset threshold. If the first anomaly confidence level is greater than or equal to the preset threshold, it is determined that the serialized service data is abnormal; If the first anomaly confidence level is less than the preset threshold, it is determined that the serialized service data does not have anomalies.

[0008] One possible implementation also includes: The first AI agent senses the vehicle network communication status and its own operating status, and determines the compression level based on the sensing results. If the serialized service data does not have any abnormalities, the serialized service data is compressed according to the compression level; The compression level is added to the common header field, and the frame message is generated using the compressed serialized business data.

[0009] One possible implementation also includes: If the serialized service data is abnormal, the generation of the frame message is refused, and a prompt message is generated and sent to the vehicle network cloud terminal.

[0010] Secondly, the present invention also provides a message parsing method based on the Internet of Vehicles (IoV), applied to an IoV cloud terminal, comprising: The system receives frame messages from an in-vehicle information processing terminal and parses the start identifier in the frame messages to complete frame synchronization. The frame messages are generated by the first artificial intelligence agent of the in-vehicle information processing terminal through anomaly analysis of serialized service data. If there are no anomalies in the serialized service data, the system generates the serialized service data based on the start identifier, common header fields, and the serialized service data. The serialized service data is generated by the in-vehicle information processing terminal through serialization of acquired service messages. The serialized service data is in binary format. The common header fields include a request identifier, a subcommand, and a first anomaly confidence level obtained from the anomaly analysis. Extract the common header fields from the frame message to obtain the request identifier, the subcommand, and the first anomaly confidence level; Based on the request identifier and the sub-command, the serialized service data in the frame message is routed to the corresponding service parser; The business parser is invoked to deserialize the serialized business data and restore the business message.

[0011] In one possible implementation, the vehicle-to-everything (V2X) cloud terminal is equipped with a second artificial intelligence agent, and the method further includes: The serialized service data in the frame message is decompressed according to the compression level in the common header field to obtain the decompressed serialized service data; The second artificial intelligence agent performs anomaly detection on the serialized business data to obtain a second anomaly confidence level. Determine whether both the first anomaly confidence level and the second anomaly confidence level are lower than a preset threshold; If the value is lower than the preset threshold, the business logic corresponding to the frame message will be executed. If the second anomaly confidence level is greater than or equal to the preset threshold and the first anomaly confidence level is less than the preset threshold, the frame message is recorded as an anomaly event and an alarm message is generated.

[0012] One possible implementation also includes: The system receives model parameter adjustment amounts uploaded by multiple vehicle information processing terminals. These model parameter adjustment amounts are generated by the first artificial intelligence agent of each vehicle information processing terminal after fine-tuning the first anomaly analysis model locally through low-rank matrix factorization. Based on the federated learning approach, global model parameters are generated by adjusting the model parameters accordingly. The global model parameters are distributed to each vehicle information processing terminal to update the model parameters of the first anomaly analysis model.

[0013] Thirdly, the present invention also provides an in-vehicle information processing terminal, comprising: Including memory and processor, among which, The memory is used to store programs; The processor, coupled to the memory, is used to execute the program stored in the memory to implement the steps in the above-described message encapsulation method based on the Internet of Vehicles.

[0014] Fourthly, the present invention also provides a vehicle-to-everything (V2X) cloud terminal, comprising: Including memory and processor, among which, The memory is used to store programs; The processor, coupled to the memory, is used to execute the program stored in the memory to implement the steps in the above-described message encapsulation method based on the Internet of Vehicles.

[0015] Fifthly, the present invention also provides a message processing system based on the Internet of Vehicles, including the vehicle information processing terminal described in the third aspect and the Internet of Vehicles cloud terminal described in the fourth aspect.

[0016] The beneficial effects of this invention are as follows: First, the invention serializes the acquired business messages to generate binary serialized business data. Then, it combines a fixed start identifier, common header fields, and serialized business data to form a unified frame structure. This ensures that messages (i.e., frame messages) in all business scenarios follow the same standardized encapsulation paradigm. The parser only needs one general parser to complete frame synchronization and common header parsing. Then, it dynamically routes to the corresponding business processing logic based on the request identifier and sub-command. This avoids the fragmentation problem of developing separate parsers for each business, achieves complete decoupling between business and protocol, and thus improves the efficiency of new business launch and effectively reduces development and maintenance costs. Furthermore, by deploying a first AI agent on the vehicle side to perform anomaly analysis on serialized business data before encapsulating and generating frame messages, malicious packets can be independently identified and intercepted without relying on the cloud, avoiding invalid data from occupying the bandwidth of the vehicle-to-everything (V2X) communication link. At the same time, the first anomaly confidence score obtained from the anomaly analysis is embedded in the common header field and uploaded to the V2X cloud terminal along with the normal frame message, providing the V2X cloud terminal with detection basis on the vehicle side. This allows the V2X cloud terminal to compare and verify with its own deep detection results, forming a collaborative security closed loop between the vehicle and the cloud, thereby significantly improving the security of vehicle-to-cloud communication. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic flowchart of an embodiment of the message encapsulation method based on the Internet of Vehicles provided by the present invention; Figure 2 For the present invention Figure 1 A schematic diagram of an embodiment of S103; Figure 3 This is a schematic flowchart of another embodiment of the message encapsulation method based on the Internet of Vehicles provided by the present invention; Figure 4 This is a schematic flowchart of an embodiment of the message parsing method based on the Internet of Vehicles provided by the present invention; Figure 5 This is a schematic flowchart of another embodiment of the message parsing method based on the Internet of Vehicles provided by the present invention; Figure 6This is a schematic flowchart of another embodiment of the message parsing method based on the Internet of Vehicles provided by the present invention; Figure 7 This is a schematic diagram of an embodiment of the message processing system based on the Internet of Vehicles provided by the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0020] In the description of the embodiments of the present invention, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0021] The terms "first," "second," etc., used in the embodiments of this invention are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a technical feature defined with "first" or "second" may explicitly or implicitly include at least one of that feature.

[0022] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0023] Before demonstrating the embodiments, the following terms will be explained.

[0024] RAG (Retrieval-Augmented Generation) is a technical framework that combines information retrieval with generative models. It first retrieves relevant content from a knowledge base based on the input, and then generates a more accurate output based on the retrieval results. In this scheme, it is used for memory enhancement and anomaly detection.

[0025] SDV (Software Defined Vehicle) refers to a car development concept that uses software to define, upgrade, and configure vehicle functions. It emphasizes the decoupling of hardware platforms and software logic, and supports rapid iteration and online updates of functions.

[0026] LoRA (Low-Rank Adaptation) is a lightweight model fine-tuning technique that adapts to new tasks by injecting a low-rank decomposition matrix into the weight matrix of a pre-trained model. It achieves similar results to full-parameter fine-tuning by updating only a small number of parameters. This solution is suitable for quickly adapting to new services on automotive-grade MCUs.

[0027] This invention provides a message encapsulation method, parsing method, terminal, and system based on the Internet of Vehicles (IoV), which will be described below.

[0028] Figure 1 This is a schematic flowchart of an embodiment of the message encapsulation method based on the Internet of Vehicles (IoV) provided by the present invention. The IoV-based message encapsulation method is applied to an in-vehicle information processing terminal, which is equipped with a first artificial intelligence agent, such as... Figure 1 As shown, it includes: S101, Obtain business messages.

[0029] It should be noted that a vehicle-mounted TBox (Telematics Box, also known as a vehicle-mounted information processing terminal or vehicle-side device) is an edge computing device installed in a vehicle to enable data communication, status reporting, remote control, and emergency calls between the vehicle and the cloud. The vehicle-mounted TBox integrates a first AI Agent (Artificial Intelligence Agent, a lightweight intelligent entity capable of independently performing perception, decision-making, and execution on the vehicle side). The vehicle-mounted TBox receives business messages from different business modules through an internal bus or application layer interface. Business messages refer to the raw data structures defined by the application layer when the vehicle-to-everything (TBox) interacts with the cloud. Business messages include, but are not limited to, login authentication requests, remote vehicle control commands, vehicle status reporting data, emergency call (ECALL, Emergency Call, automatically triggered distress communication when a vehicle experiences an emergency) trigger signals, or log upload content.

[0030] S102. Serialize the business message to generate serialized business data; the serialized business data is in binary format.

[0031] It should be noted that after obtaining the original business message, the in-vehicle TBox calls the lightweight serialization module and uses Protobuf-lite (Protocol Buffers Lite, a lightweight version of Protobuf that removes reflection and descriptors, suitable for resource-constrained embedded environments) lightweight serialization technology to serialize the business message. Protobuf-lite lightweight serialization technology is used to convert structured key-value pair data into a compact binary byte stream, which is the serialized business data. The serialized business data does not contain any field names or type descriptions, only retaining the field numbers and actual values.

[0032] S103. Perform anomaly analysis on the serialized business data through the first artificial intelligence agent.

[0033] It should be noted that after generating serialized business data, this data is input into the first AI Agent deployed inside the in-vehicle T-Box. The first AI Agent is a lightweight intelligent computing entity whose core is a pre-trained deep learning model. This model can run in real-time on a resource-constrained automotive-grade MCU (Microcontroller Unit), performing anomaly analysis on the serialized business data and outputting the anomaly analysis results. These results include at least a quantified anomaly confidence score (first anomaly confidence score), which characterizes the probability of an anomaly in the serialized business data. This analysis process is entirely completed locally on the vehicle, without interaction with the vehicle-to-everything (V2X) cloud terminal (hereinafter referred to as the cloud).

[0034] S104. If the serialized service data does not have any anomalies, a frame message is generated based on the start identifier, the common header field, and the serialized service data; the common header field includes the request identifier, the subcommand, and the first anomaly confidence level obtained from the anomaly analysis.

[0035] It should be noted that when the anomaly analysis result is no anomaly, the in-vehicle T-Box performs frame encapsulation. First, a fixed-content start flag (start_flag) is generated. This start flag can be a specific byte sequence (such as "0x5A") as a frame synchronization anchor point, used by the receiving end to quickly locate the frame boundary. Second, a common header field (TBoxHeader) is constructed. This common header field at least includes a request identifier (request_id, used to identify the business category, such as login, vehicle control, reporting, etc.), a sub-command (custom_cmd, used to further distinguish specific operations under the same business category, such as opening the door or turning on the air conditioner in remote vehicle control), and the first anomaly confidence score calculated by the first AI Agent through anomaly analysis. The common header field may also optionally include metadata such as the vehicle identification number (VIN, Vehicle Identification Number, 17-bit unique vehicle identifier), session identifier (session_id), and protocol version number. The start flag, the common header field (encoded into binary in a predefined order), and the serialized business data are concatenated sequentially to form a complete frame message (TBoxMessage). The structure of this frame message follows the essential deconstruction method. The frame layer only retains three core elements: synchronization, metadata, and payload. All business messages are carried through the same frame structure.

[0036] S105. The frame message is sent to the vehicle network cloud terminal through the vehicle network communication link.

[0037] It should be noted that the encapsulated frame message is handed over to the vehicle's communication module. The communication module uses a pre-established vehicle-to-everything (V2X) communication link to send the frame message to the V2X cloud terminal. This V2X communication link is based on 4G / 5G mobile communication technology or satellite communication technology and is dedicated to bidirectional data transmission between the in-vehicle information processing terminal and the V2X cloud platform. During transmission, the communication module can dynamically adjust the modulation and coding scheme and retransmission strategy based on the current link signal strength, bandwidth usage, and transmission delay to ensure the real-time performance and reliability of the frame message. At this point, the vehicle has completed the unified encapsulation and transmission of the service message.

[0038] In summary, the message encapsulation method based on the Internet of Vehicles provided in this embodiment of the invention first serializes the acquired business messages to generate binary serialized business data, and then combines a fixed start identifier, common header fields, and serialized business data to form a unified frame structure. This ensures that messages (i.e., frame messages) in all business scenarios follow the same standardized encapsulation paradigm. The parser only needs one general parser to complete frame synchronization and common header parsing, and then dynamically routes to the corresponding business processing logic based on the request identifier and sub-command. This avoids the fragmentation problem of developing separate parsers for each business, achieves complete decoupling between business and protocol, and thus improves the efficiency of new business launch and effectively reduces development and maintenance costs. Furthermore, by deploying a first AI agent on the vehicle side to perform anomaly analysis on serialized business data before encapsulating and generating frame messages, malicious packets can be independently identified and intercepted without relying on the cloud, avoiding invalid data from occupying the bandwidth of the vehicle-to-everything (V2X) communication link. At the same time, the first anomaly confidence score obtained from the anomaly analysis is embedded in the common header field and uploaded to the V2X cloud terminal along with the normal frame message, providing the V2X cloud terminal with detection basis on the vehicle side. This allows the V2X cloud terminal to compare and verify with its own deep detection results, forming a collaborative security closed loop between the vehicle and the cloud, thereby significantly improving the security of vehicle-to-cloud communication.

[0039] In some embodiments of the present invention, such as Figure 2 As shown, step S103 includes: S201. Extract the first business feature vector of the serialized business data through the first anomaly analysis model maintained by the first artificial intelligence agent.

[0040] It should be noted that the first AI Agent internally pre-trains and maintains a lightweight first anomaly analysis model. This first anomaly analysis model adopts a Convolutional Long Short-Term Memory (CNN-LSTM) fusion architecture, which can run efficiently on resource-constrained automotive-grade microcontrollers. CNN (Convolutional Neural Network) is a feedforward neural network with a deep structure that includes convolutional computation. LSTM (Long Short-Term Memory) is a special type of recurrent neural network. The generated serialized business data (binary byte stream) is fed into the first anomaly analysis model. The CNN in the first anomaly analysis model is responsible for extracting local spatial patterns in the byte sequence (such as specific byte combinations and short sequence anomaly features), while the LSTM in the first anomaly analysis model is responsible for capturing long-term temporal dependencies across bytes (such as the contextual relationships of command sequences). After multiple layers of computation, a fixed-dimensional floating-point vector, i.e., the first business feature vector, is output from the last fully connected layer of the first anomaly analysis model. The first business feature vector encapsulates the statistical characteristics of the original serialized business data in binary format across multiple dimensions. The first business feature vector refers to a set of numerical features used to characterize the communication patterns and behavioral attributes of the business data. The first business feature vector is typically a 128-dimensional floating-point array, where each dimension represents the statistical or structural characteristics of the data in a certain dimension (e.g., byte frequency, local sequence pattern, temporal dependencies, etc.).

[0041] S202. Calculate the first anomaly confidence level based on the first business feature vector and the first normal feature vector in the first preset feature library.

[0042] It should be noted that: The first AI Agent internally maintains a first preset feature library, which stores several first normal feature vectors extracted from historical normal communication scenarios (e.g., aggregated from the fleet through unsupervised learning or federated learning). The first AI Agent calculates the cosine similarity between the first business feature vector and each first normal feature vector in the first preset feature library, obtaining a set of similarity values. Simultaneously, it uses the Isolation Forest algorithm (an outlier detection algorithm based on random isolation) to score the first business feature vector, obtaining an Isolation Forest score. Then, the difference after cosine similarity conversion (e.g., 1 minus the maximum similarity) is weighted and fused with the Isolation Forest score, and normalized to the range of 0 to 100, finally obtaining a quantitative score, namely the first anomaly confidence score. The higher the first anomaly confidence score, the greater the degree to which the first business feature vector deviates from the normal pattern, and the higher the probability of an anomaly.

[0043] S203. Compare the first anomaly confidence level with the preset threshold.

[0044] It should be noted that a preset threshold is set (this threshold can be dynamically adjusted according to the safety policy; for example, 80 is commonly used as the dividing line in automotive-grade environments). The first AI Agent compares the calculated first anomaly confidence level with the preset threshold to obtain the comparison result.

[0045] S204. If the first anomaly confidence level is greater than or equal to the preset threshold, it is determined that the serialized service data is abnormal.

[0046] It should be noted that when the comparison result is that the first anomaly confidence level is greater than or equal to the preset threshold, the first AIAgent determines that the current serialized business data is abnormal data.

[0047] S205. If the first anomaly confidence level is less than the preset threshold, it is determined that the serialized service data does not have anomalies.

[0048] It should be noted that when the comparison result shows that the first anomaly confidence score is less than a preset threshold, the first AI Agent determines that the current serialized business data is normal data. The first AI Agent allows the current serialized business data to continue to the subsequent frame encapsulation steps and writes the calculated first anomaly confidence score into the corresponding position in the common header field of the frame message (e.g., the ai_abnormal_score field). In addition, the first AI Agent can periodically add the current first business feature vector as a normal sample to the local feature library, or upload the feature gradient to the cloud federated learning server to achieve online optimization of the model.

[0049] In this embodiment, a lightweight first anomaly analysis model maintained by a first artificial intelligence agent extracts the first business feature vector of serialized business data. This enables low-latency, small-volume feature extraction on an automotive-grade MCU, providing real-time and deployable anomaly detection on the vehicle side. Furthermore, by performing vector calculations between the first business feature vector and normal features in a first preset feature library to obtain a first anomaly confidence level, and comparing this first anomaly confidence level with a preset threshold, different processing strategies—blocking alarms or allowing access and writing to the common header—are executed based on the comparison results. This allows for real-time decision-making and tiered responses on the vehicle side, ensuring low-latency forwarding of normal services while accurately filtering malicious packets at the vehicle source. This achieves high-sensitivity identification of malicious packets, significantly reducing the false negative rate and effectively improving the overall security and efficiency of the vehicle-cloud communication link.

[0050] In some embodiments of the present invention, such as Figure 3 As shown, it also includes: S301. The first artificial intelligence agent senses the vehicle network communication status and its own operating status, and determines the compression level based on the sensing results.

[0051] It should be noted that the First AI Agent monitors the V2V communication status and the onboard TBox's own operating status in real time during the early stages of the message transmission process (after acquiring the business message and before serialization). The V2V communication status includes parameters such as signal strength, available bandwidth, transmission latency, and packet loss rate. The onboard TBox's own operating status includes parameters such as the priority of the currently pending business messages (e.g., emergency calls and remote vehicle control are high priority, status reporting and log uploads are low priority) and hardware load (e.g., microcontroller utilization, remaining memory, and task queue depth). The First AI Agent then integrates and analyzes the collected V2V communication status and its own operating status, determining a dynamic compression level based on preset decision logic or a strategy network fine-tuned through lightweight low-rank adaptation (LoRA). Compression levels are typically divided into 1 to 8 levels; higher levels represent higher compression ratios and smaller data volumes, but also relatively increased computational overhead and latency.

[0052] The first AI Agent can dynamically determine the compression level based on at least one of the parameters in the perception results (including the vehicle network communication status and its own operating status). For example, if the compression level is determined solely based on the priority of the service, high-priority services will use a low compression level to ensure low latency, while low-priority services will use a high compression level to save bandwidth. Alternatively, the compression level can be determined based on the vehicle network communication status and hardware load; a high compression level will be used when the network is congested and the MCU is idle, while a low compression level will be used when the network is unobstructed or the MCU is busy. Finally, the compression level can be determined based on available bandwidth and priority; a low compression level will be selected to ensure low latency when the available bandwidth of the communication link is sufficient and the service priority is high, while a high compression level will be selected to save bandwidth when the available bandwidth of the communication link is insufficient and the service priority is low.

[0053] S302. If the serialized service data is not abnormal, compress the serialized service data according to the compression level.

[0054] It should be noted that if the first AI Agent determines that the serialized service data does not contain any anomalies (i.e., the first anomaly confidence level is less than a preset threshold), then the first AI Agent allows the serialized service data to continue flowing. At this time, the first AI Agent performs corresponding compression operations on the serialized service data (binary byte stream) according to the determined compression level. The compression algorithm can use lightweight gzip, zlib, or a custom fast compression algorithm, and the compression strength is positively correlated with the compression level. The compressed data volume is significantly reduced, which helps to reduce the bandwidth consumption of the vehicle-to-everything (V2X) communication link.

[0055] S303. Add the compression level to the common header field, and generate the frame message using the compressed serialized service data.

[0056] It should be noted that after compression is complete, the first AI Agent writes the compression level to the corresponding position in the common header field (e.g., the `ai_compress_level` field). Then, the start identifier, the common header field containing the compression level and the first anomaly confidence level, and the compressed serialized business data are sequentially concatenated to generate the final frame message. By carrying the compression level in the common header, the cloud can determine the compression strength used in the frame message during parsing, thus correctly decompressing and recovering the original serialized business data.

[0057] In this embodiment, the first AI Agent dynamically determines the compression level based on real-time perception of the vehicle-to-everything (V2X) communication status and its own operating status. This allows the compression strategy to adaptively match current network conditions and service requirements, prioritizing low latency when bandwidth is ample and saving bandwidth when bandwidth is limited, achieving a dynamic balance between transmission efficiency and real-time performance. Furthermore, by compressing serialized service data only after anomaly analysis confirms the absence of anomalies, and embedding the compression level into the common header and sending it along with the frame message, invalid compression calculations for abnormal packets can be avoided, reducing wasted computing power on the vehicle side. Simultaneously, it ensures that the cloud can correctly decompress and restore the data, improving the utilization efficiency of the vehicle-to-cloud communication link without sacrificing the accuracy of anomaly detection and system compatibility.

[0058] In some embodiments of the present invention, it further includes: If the serialized service data is abnormal, the generation of the frame message is refused, and a prompt message is generated and sent to the vehicle network cloud terminal.

[0059] It should be noted that when the first AI Agent determines through anomaly analysis that the first anomaly confidence level of the serialized service data is greater than or equal to a preset threshold, the first AI Agent immediately determines that the current serialized service data is abnormal. The first AI Agent performs the following operations: First, it discards the service data and refuses to send the abnormal serialized service data into the subsequent frame encapsulation process; that is, it does not generate frame messages, nor does it perform any compression or transmission operations, thereby blocking the abnormal message from being transmitted outward at the source. Second, the first AI Agent generates a prompt message, which includes at least an anomaly type identifier, the first anomaly confidence level, the vehicle identification number (VIN), and a timestamp. The prompt message can be encapsulated using the same frame structure as the normal message, or it can use a simplified alarm format. However, to ensure that the cloud can identify and process it in a timely manner, it is preferable to use a pre-agreed simple protocol (e.g., carrying only a fixed alarm code and anomaly confidence level). The first AI Agent reports the prompt message to the vehicle network cloud terminal through the vehicle network communication link, informing the cloud that the vehicle information processing terminal has detected and blocked the abnormal message. Upon receiving the alert, the cloud can perform security audits, source tracing, or model updates, update the trust status of the corresponding vehicle, or trigger further manual review or model update processes. Furthermore, the first AIAgent can record this anomaly to its local log for subsequent negative sample accumulation in self-learning or federated learning.

[0060] In this embodiment, by immediately refusing to generate frame messages and blocking transmission when anomalies are detected in serialized service data at the vehicle end, malicious or abnormal packets can be prevented from occupying vehicle-to-everything (V2X) communication link resources at the source, avoiding their propagation to the cloud and causing potential security threats or ineffective processing. Furthermore, by generating alert messages containing key information such as the first anomaly confidence level and proactively reporting them to the V2X cloud terminal, the cloud can promptly detect security events at the vehicle end, achieving a closed-loop threat response and audit system linked to the vehicle, thereby enhancing the proactive defense capabilities and traceability of the entire V2X system.

[0061] Figure 4 This is a schematic flowchart of an embodiment of the message parsing method based on the Internet of Vehicles (IoV) provided by the present invention. The IoV-based message parsing method is applied to an IoV cloud terminal, such as... Figure 4 As shown, the message parsing method based on the Internet of Vehicles includes: S401. Receive a frame message from the vehicle information processing terminal, parse the start identifier in the frame message to complete frame synchronization; the frame message is generated by the first artificial intelligence agent of the vehicle information processing terminal performing anomaly analysis on the serialized service data, and when there is no anomaly in the serialized service data, it is generated based on the start identifier, the common header field and the serialized service data. The serialized service data is generated by the vehicle information processing terminal serializing the acquired service message. The serialized service data is in binary format, and the common header field includes a request identifier, a sub-command and a first anomaly confidence level obtained from the anomaly analysis.

[0062] It should be noted that the vehicle-to-everything (V2X) cloud terminal continuously monitors the V2X communication link (based on 4G / 5G or satellite communication technology) to receive frame messages from the in-vehicle information processing terminal. Upon receiving a frame message from the in-vehicle information processing terminal, it first reads the fixed byte sequence of the frame start portion (i.e., the start flag, start_flag, for example, the preset "0x5A"). The parser locates the frame boundary by searching for this start flag, achieving frame synchronization. If multiple consecutive frames fail to synchronize, the current frame message is discarded and the synchronization header is searched again. The received frame messages are generated by the first AI Agent of the in-vehicle information processing terminal after performing anomaly analysis on the serialized service data and determining that no anomalies exist, based on the start flag, common header fields, and serialized service data. For a detailed description of the specific frame messages, please refer to the above embodiment; further details are omitted here.

[0063] S402. Extract the common header field from the frame message to obtain the request identifier, the subcommand, and the first anomaly confidence level.

[0064] It should be noted that after frame synchronization is completed, the general frame parser inside the vehicle-to-everything (V2X) cloud terminal (V2X cloud platform, hereinafter referred to as the cloud) extracts the common header fields from the frame message according to a predefined common header field encoding order (e.g., first reading the frame start identifier followed by a fixed-length common header). The common header fields are typically encoded in binary (e.g., TLV format or fixed offset). The general frame parser decodes the request identifier (used to identify the business category, such as login, vehicle control, reporting, etc.), sub-commands (used to distinguish specific operations within the same business category, such as opening the door or turning on the air conditioning in remote vehicle control), and the first anomaly confidence score (an anomaly score of 0-100 given by the vehicle's first AI Agent) according to the protocol specifications. In addition, the common header may optionally include other metadata such as the vehicle identification number (VIN), session identifier (session_id), protocol version number, and compression level.

[0065] S403. Based on the request identifier and the sub-command, route the serialized service data in the frame message to the corresponding service parser.

[0066] It's important to note that the cloud maintains an internal routing table that maps request identifiers and subcommands to specific business parser instances (e.g., login, remote vehicle control, status reporting, etc.). The general frame parser handles frame-level parsing and routing, while the business parser handles deserialization. The general frame parser uses the obtained request identifier and subcommand to look up the routing table to determine the business parser, then passes the remaining serialized business data (the body, which is uncompressed or potentially compressed binary data) from the frame message to that business parser. If the request identifier or subcommand does not match any registered business parser, the frame is discarded and an exception is logged.

[0067] S404. Call the business parser to deserialize the serialized business data and restore the business message.

[0068] It should be noted that after completing routing, the general frame parser passes the serialized business data (i.e., the binary byte stream of the remaining body portion of the frame message) as input parameters to the corresponding business parser. Upon receiving the serialized business data, the business parser, based on the predefined protocol buffer message structure (Protobuf schema) for that business scenario, calls the deserialization interface of the lightweight protocol buffer (Protobuf-lite) to perform a deserialization operation, converting the serialized business data into the original business message object (e.g., login request structure, remote vehicle control command structure, status data structure). If deserialization is successful, the recovered business message can be processed by the cloud (e.g., performing remote vehicle control, storing status data, triggering emergency call procedures, etc.). If deserialization fails (e.g., incorrect data format, Protobuf schema mismatch, or version inconsistency), the business parser returns an error code to the general frame parser, which records the exception log and can return an error response to the in-vehicle information processing terminal via the vehicle network communication link.

[0069] In this embodiment, frame synchronization is achieved by parsing the start identifier in the frame message, and the request identifier, subcommand, and first anomaly confidence level in the common header fields are extracted. This enables seamless integration with the unified frame structure of the vehicle end, allowing the cloud to process messages for all business scenarios with a single general parser. This eliminates the need to develop separate frame parsing logic for each business, significantly reducing the complexity and maintenance cost of the parsing module. Furthermore, by dynamically routing serialized business data to the corresponding business parser based on the request identifier and subcommand, and then calling the business parser to deserialize and restore the business message, complete decoupling of the business processing logic from the communication protocol layer is achieved. Adding new business scenarios only requires adding a business parser without modifying the frame parsing process, thereby greatly improving the scalability of cloud functionality.

[0070] In some embodiments of the present invention, the vehicle-to-everything (V2X) cloud terminal is equipped with a second artificial intelligence agent, such as... Figure 5 As shown, the method further includes: S501. Decompress the serialized service data in the frame message according to the compression level in the common header field to obtain decompressed serialized service data.

[0071] It should be noted that the general frame parser reads the compression level (ai_compress_level, ranging from 1 to 8, with 0 indicating no compression) from the common header field. If the compression level is greater than 0, it indicates that the vehicle-side has compressed the serialized service data before transmission to save bandwidth. The cloud-based general frame parser calls the corresponding decompression algorithm (such as gzip, zlib, or a custom lightweight decompression) based on this compression level to decompress the serialized service data (i.e., the binary byte stream carried by the body field) in the frame message, thereby restoring the original, uncompressed serialized service data. If the compression level is 0 or does not exist, no decompression is required, and the original serialized service data is used directly. The decompressed data will be used for subsequent anomaly detection and service processing.

[0072] S502. The serialized business data is subjected to anomaly detection by the second artificial intelligence agent to obtain a second anomaly confidence level.

[0073] It should be noted that the second AI Agent integrates a second anomaly analysis model (including a CNN-LSTM model and a LoRA low-rank adaptation module) that is derived from the first anomaly analysis model of the first AI Agent on the vehicle side. However, due to the richer computing resources and training data in the cloud, the model parameters of the second anomaly analysis model are usually optimized with a larger dataset, resulting in stronger generalization capabilities. The general frame parser transmits the decompressed serialized business data (i.e., the original binary byte stream) to the second AI Agent deployed in the cloud. The general frame parser transmits the serialized business data to be detected (if decompression is performed in S501, the data is the decompressed result; if decompression is not performed, the data is the original serialized business data) to the second AI Agent deployed in the cloud. The second AI Agent first extracts the second business feature vector of the serialized business data to be detected using its internal second anomaly analysis model, and then compares this second business feature vector with the second normal feature vector in the second preset feature library maintained in the cloud. The second normal feature vector in the second preset feature library covers the patterns of the entire fleet under various normal communication scenarios. During the comparison process, the second AI Agent uses cosine similarity to calculate the similarity between the second business feature vector and the second normal feature vector in the second preset feature library, while also using the Isolation Forest algorithm to assess its outlier potential. Finally, the results from the two dimensions are weighted and fused, normalized to a quantitative score of 0-100, which is the second anomaly confidence score. The second anomaly confidence score represents the confidence level of the cloud-based second anomaly analysis model in independently judging whether the serialized business data to be detected is abnormal. The higher the score, the more likely the serialized business data to be detected is anomaly.

[0074] S503. Determine whether both the first abnormal confidence level and the second abnormal confidence level are lower than a preset threshold.

[0075] It should be noted that the general frame parser obtains the first anomaly confidence score (ai_abnormal_score) from the vehicle side carried in the common header field and the second anomaly confidence score from the cloud side calculated in step S502. The general frame parser determines whether both are lower than a preset threshold (e.g., 80) based on the first and second anomaly confidence scores. Since the anomaly analysis models of the vehicle side and the cloud side are from the same source and their training data overlap, the confidence scores of normal messages should be basically consistent.

[0076] S504. If the value is lower than the preset threshold, execute the business logic corresponding to the frame message.

[0077] It should be noted that if both the first and second anomaly confidence scores are below the preset threshold, the message frame is determined to be safe and without anomalies. The cloud continues to execute subsequent business logic, that is, it deserializes the decompressed serialized business data according to the routed business parser, restores the business message, and then the business module performs the corresponding processing (such as executing remote vehicle control commands, storing status data, triggering emergency call procedures, etc.).

[0078] S505. If the second anomaly confidence level is greater than or equal to the preset threshold and the first anomaly confidence level is less than the preset threshold, record the frame message as an anomaly event and generate an alarm message.

[0079] It should be noted that if the cloud determines the message to be abnormal but the vehicle determines it to be normal (i.e., the first anomaly confidence level is less than a preset threshold and the second anomaly confidence level is greater than or equal to the preset threshold), then the message frame is considered to have a security risk. In this case, the cloud will not execute business logic (it can be postponed for non-critical business operations, but will be directly rejected for critical business operations such as vehicle control), and will record the complete content of the message frame (including the original binary payload, both ends' confidence levels, vehicle VIN, timestamp, etc.) in the security audit log. Simultaneously, a high-priority alarm message will be generated and sent to the security management center or operations personnel. The alarm message will include the specific inconsistencies and possible attack types.

[0080] In this embodiment, by using a second AI Agent in the cloud to independently detect anomalies in serialized business data and obtain a second anomaly confidence level, cross-validation of the vehicle-side first-level detection results can be achieved. This avoids security vulnerabilities caused by false negatives or missed positives from a single model, forming a dual-verification defense line between the vehicle and cloud ends. Furthermore, by comparing the first and second anomaly confidence levels and executing business logic or recording alarms based on the comparison results, while ensuring low-latency response for normal business operations, suspicious events with inconsistent conclusions between the two ends can be accurately captured. This significantly improves the proactive defense capability and traceability of the vehicle-cloud communication system, thus ensuring the security of vehicle-cloud communication.

[0081] In some embodiments of the present invention, such as Figure 6 As shown, it also includes: S601. Receive model parameter adjustment amounts uploaded by multiple vehicle information processing terminals. The model parameter adjustment amounts are generated by the first artificial intelligence agent of each vehicle information processing terminal after fine-tuning the first anomaly analysis model locally through low-rank matrix factorization.

[0082] It should be noted that the vehicle-to-everything (V2X) cloud terminal continuously receives model parameter adjustments reported by multiple in-vehicle TBOXes from the fleet. These model parameter adjustments are not the original communication messages or user privacy data, but rather incremental updates generated by each in-vehicle TBOX locally based on its collected actual operating data (normal message characteristics and abnormal sample characteristics) to fine-tune its first anomaly analysis model. The fine-tuning process employs Low-Rank Matrix Decomposition (LRD), a parameter-efficient fine-tuning technique, to decompose the large-scale weight update matrix into the product of two low-rank matrices. This allows for near-full-scale fine-tuning with only a small number of parameters. Specifically, the first AI agent freezes most of the original weight parameters of the first anomaly analysis model, inserts and trains only the Low-Rank Adaptation (LoRA) matrix, calculates the local changes in model parameters through backpropagation, and then uploads these changes as model parameter adjustments to the cloud. Throughout this process, no original messages or feature vectors need to be uploaded, thus protecting user privacy and the confidentiality of vehicle communication content at the source.

[0083] S602. Based on the federated learning method, adjust the model parameters according to the model parameters to generate global model parameters.

[0084] It should be noted that after receiving model parameter adjustments uploaded from multiple vehicles, the vehicle-to-everything (V2X) cloud terminal initiates the federated learning aggregation module. The V2X cloud terminal does not directly access the local data of each vehicle; instead, it uses a federated averaging algorithm (a distributed machine learning aggregation strategy that synthesizes a global model by weighted averaging of model updates uploaded by each participant) to aggregate the collected model parameter adjustments. Specifically, the V2X cloud terminal calculates weight coefficients based on the local training sample size or participation confidence level of each vehicle, and then performs a weighted average of the model parameter adjustments uploaded by each vehicle to generate the aggregated model parameter updates. The V2X cloud terminal then adds this model parameter update to the current global first anomaly analysis model parameters to obtain a new version of the global model parameters. This aggregation process can be iterated multiple times as needed, supporting asynchronous or synchronous aggregation strategies. In this way, the V2X cloud terminal can aggregate diverse anomaly patterns from different vehicles and driving environments without collecting any raw data, building a first anomaly analysis model with stronger generalization capabilities.

[0085] S603. The global model parameters are sent to each vehicle information processing terminal to update the model parameters of the first anomaly analysis model.

[0086] It should be noted that after generating the global model parameters, the vehicle-to-everything (V2X) cloud terminal securely broadcasts or unicasts these parameters to each participating vehicle-mounted TBOX via the V2X communication link. Upon receiving the global model parameters, the first AI Agent of each vehicle-mounted TBOX merges and updates them with the parameters of its existing local first anomaly analysis model. The update method can be either directly replacing the local model parameters or using momentum updates to weightedly merge the global and local parameters (e.g., retaining some local features to prevent catastrophic forgetting). After the update, the first AI Agent of each vehicle-mounted TBOX continues to execute subsequent serialized business data anomaly analysis tasks with the new model parameters. The entire upload, aggregation, and distribution process can be executed cyclically according to a preset period (e.g., daily, weekly) or triggered after a certain number of new samples are accumulated on the vehicle side, enabling continuous online evolution of the model.

[0087] In this embodiment, by using low-rank matrix factorization to fine-tune the first anomaly analysis model locally on the vehicle side and only uploading the model parameter adjustments, the model parameter adjustments can be compressed to a very small proportion of the original model, significantly reducing the communication bandwidth consumption between the vehicle and the cloud. Simultaneously, since the original business data is always retained locally on the vehicle side, the risk of user privacy leakage is fundamentally eliminated, perfectly adapting to the security and resource constraints of large-scale vehicle-to-everything (V2X) deployment scenarios. Furthermore, by aggregating the model parameter adjustments from each vehicle side using a federated learning mechanism in the cloud to generate global model parameters and then distributing updates, the first anomaly analysis model can be collaboratively optimized using distributed data sources without centrally collecting sensitive data. This allows the first anomaly analysis model of the vehicle-mounted TBOX to continuously absorb diverse anomaly features from different vehicles under different environments, thereby significantly improving the generalization ability and overall robustness of anomaly detection on both the vehicle and cloud sides.

[0088] In all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent is obtained first. Furthermore, the collection, use, and processing of this data comply with relevant laws, regulations, and standards. Additionally, when embodiments of this application require access to sensitive personal information, separate permission or consent from the user is obtained through pop-ups or redirects to confirmation pages. Only after obtaining the user's separate permission or consent is the necessary user-related data required for the proper functioning of these embodiments acquired.

[0089] To better implement the vehicle-to-everything (V2X) based message encapsulation method in this invention, this invention also provides an in-vehicle information processing terminal, including a memory and a processor, based on the V2X-based message encapsulation method. The memory is used to store programs; The processor, coupled to the memory, is used to execute the program stored in the memory to implement the steps in the above-described message encapsulation method based on the Internet of Vehicles.

[0090] To better implement the vehicle-to-everything (V2X) based message encapsulation method in this invention, this invention also provides a V2X cloud terminal, including a memory and a processor, based on the V2X message encapsulation method. The memory is used to store programs; The processor, coupled to the memory, is used to execute the program stored in the memory to implement the steps in the above-described message encapsulation method based on the Internet of Vehicles.

[0091] To better implement the message encapsulation method based on the Internet of Vehicles (IoV) in this invention embodiment, based on the IoV-based message encapsulation method, correspondingly, as follows: Figure 7 As shown, this embodiment of the invention also provides a message processing system based on the Internet of Vehicles, including an in-vehicle information processing terminal 701 and an Internet of Vehicles cloud terminal 702.

[0092] Figure 7 This invention demonstrates the core interaction process between the vehicle-side (vehicle information processing terminal 701) and the cloud (vehicle network cloud terminal 702) in the solution. When the first AI agent on the vehicle-side performs anomaly analysis on the business load body (i.e., the serialized business data of this invention), if the calculated first anomaly confidence level is greater than or equal to a preset threshold, the message is determined to be abnormal. At this time, the vehicle-side does not send a normal frame message, but generates an alarm (i.e., alarm information) and reports it to the cloud. When the first anomaly confidence level is less than the preset threshold, the vehicle-side determines that the message is normal. The vehicle-side assembles the business load body together with the start identifier and common header fields (including the first anomaly confidence level, request identifier, sub-commands, etc.) into a frame message and sends it to the cloud through the vehicle network communication link. After receiving the frame message and completing parsing, routing, and business processing, the cloud can return a business response message to the vehicle-side (this step is optional and not required for every message interaction). The vehicle-side collects running data locally and fine-tunes its anomaly analysis model through low-rank matrix factorization to generate model parameter adjustment amounts. The vehicle-side only uploads the model parameter adjustments, not the original message or feature vector, to protect privacy. The cloud collects the model parameter adjustments uploaded by multiple vehicle-side devices, aggregates them using a federated learning approach, generates global model parameters, and then distributes them to each vehicle-side device to update its local anomaly analysis model.

[0093] The above process describes the real-time message processing and model collaborative optimization between the vehicle and the cloud. The underlying protocol architecture supporting this process will be explained below. This invention reconstructs the vehicle-cloud communication protocol stack layer by layer based on the essential deconstruction method, returning to the essence of the five-layer architecture: The physical layer uses 4G / 5G or satellite communication technology to realize the physical link connection between the vehicle and the cloud; the frame layer adopts a structure of "fixed outer frame TBoxMessage + unified common header TBoxHeader + Protobuf-lite serialized business body" to achieve unified encapsulation of messages across all business scenarios; the presentation layer uses Protobuf-lite lightweight serialization technology and combines AI decision-making to achieve dynamic data compression, balancing serialization efficiency and bandwidth usage; the session layer uses session_id to implement session management and combines AI heartbeat Agent to ensure session stability; the application layer uses pure business Protobuf message definitions, completely decoupled from the frame layer, ensuring independent evolution of business logic. This layered design significantly improves the maintainability and scalability of the protocol stack, with clear responsibilities and boundaries for each layer, supporting rapid adaptation across vehicle models and manufacturers. As a crucial link between the upper and lower layers, the frame layer not only shields the differences in underlying communication but also provides a unified access view for the upper layers. The AI-driven dynamic compression and heartbeat mechanism can reduce the average bandwidth usage by more than 30% while ensuring real-time performance. The entire stack adopts Protobuf-lite unified serialization, which improves the efficiency of edge-cloud collaborative development by 40% and reserves standardized interfaces for subsequent V2X multi-mode integration.

[0094] Next, the unified message frame structure of this invention will be described in detail to solve the problems of format chaos and fragmented parsing. Specifically, based on the Protobuf v3 protocol standard, an absolutely standardized outer frame TBoxMessage structure is defined. This structure contains only three indivisible core elements, ensuring the simplicity and standardization of the frame structure, as shown below: protobuf message TBoxMessage { string start_flag = 1; / / Fixed start flag, serving as the unique anchor point for frame synchronization. TBoxHeader header = 2; / / Unified common header, applicable to all business scenarios bytes body = 3; / / Business serialization payload, achieving complete decoupling from the frame layer. }".

[0095] Among them, TBoxHeader is a unified public header used across all business scenarios. It extracts public metadata from all business interaction processes and adds an AI Agent control field to realize intelligent collaboration between vehicle-side AI and vehicle-cloud communication, as shown below: protobuf message TBoxHeader { RequestId request_id = 1; ResponseCode response_id = 2; string vin = 3; EncryptionType encryption = 4; string session_id = 5; string proto_version = 6; CmdVersion cmd_version = 7; uint32 custom_cmd = 8; Timestamp timestamp = 9; / / AI Agent Extended Fields (Core Innovation) uint32 ai_agent_flag = 10; / / Agent running status: Idle / Optimizing / Detecting / Abnormal uint32 ai_compress_level = 11; / / Dynamic AI compression level (levels 1-8) uint32 ai_abnormal_score = 12; / / Abnormal confidence level (0~100) string ai_model_version = 13; / / Vehicle-side LoRA model version }".

[0096] The design fully follows the core principles of the essential deconstruction method. The frame structure retains only three core essential elements: "frame synchronization, public metadata, and business load" and does not contain any business-intrusive fields, thus achieving the standardization goal of "one frame structure adapting to all business scenarios".

[0097] Building upon this foundation, the present invention further achieves complete decoupling between business logic and protocols to address the issue of poor scalability. Specifically, messages for all business scenarios (login authentication, remote vehicle control, status reporting, ECALL emergency calls, log uploads, etc.) have independently defined Protobuf message structures, without referencing or depending on the definitions of the outer frame TBoxMessage and the common header TBoxHeader. During message transmission, business messages undergo Protobuf-lite lightweight serialization processing (removing the reflection mechanism and descriptor module, reducing data size by 60% compared to traditional Protobuf), generating bytes type data which is then directly filled into the body field of TBoxMessage. During message reception, the parser first parses the outer frame and common header, and then, based on the request_id and custom_cmd fields in TBoxHeader, dynamically routes the serialized data in the body field to the parser corresponding to the business scenario, achieving accurate parsing of business data.

[0098] The design value of the essential deconstruction method lies in the fact that changes in business logic only require modification of the corresponding business's Protobuf message structure, while the outer frame TBoxMessage structure, the common header TBoxHeader, and the parsing link remain unchanged. This truly enables the independent evolution of business logic and communication protocols, meeting the rapid iteration requirements of Software Defined Vehicles (SDV).

[0099] Beyond protocol-level decoupling, this invention also introduces a first AI Agent on the vehicle side to achieve an intelligent closed loop, addressing the issues of static adaptation and lack of real-time intelligence. Specifically, a lightweight AI agent (OpenClaw) is deployed on the in-vehicle TBOX. This first AI Agent integrates a first anomaly analysis module built upon technologies such as LoRA low-rank adaptation, CNN-LSTM feature extraction, federated learning, and incremental memory RAG. This achieves a complete intelligent closed loop of "perception → thinking → decision-making → execution → memory → self-learning," replacing the traditional static configuration mode and enabling intelligent dynamic adaptation on the vehicle side.

[0100] (1) Agent hardware adaptation (meeting automotive-grade deployment requirements) The first anomaly analysis module deployed by the first AI Agent adopts a lightweight CNN-LSTM fusion architecture, where CNN is responsible for extracting local features of the message and LSTM is responsible for extracting temporal features. It employs a lightweight technique combining 8-bit quantization, structured pruning, and LoRA low-rank adaptation to compress the model size to ≤800KB (INT8 precision) and control the inference latency to ≤80μs. This allows direct deployment on STM32F4 / F7 series automotive-grade MCUs (RAM≥128KB), meeting the hardware constraints of automotive-grade low power consumption and low computing power. The deployment method combines event triggering and sleep scheduling, entering a low-power mode when there is no service, which can reduce the overall power consumption of the TBOX by more than 40%.

[0101] (2) Agent's three core capabilities (solving dynamic adaptation problems based on the essential deconstruction method) Dynamic compression optimization (achieving a balance between bandwidth and latency): The AI ​​Agent perceives network status, service priorities, and MCU load in real time, and makes online decisions on the Protobuf-lite compression level. High-priority services use a low compression level (latency <50ms), while low-priority services use a high compression level (bandwidth savings of over 35%), and the policy weights are dynamically adjusted through LoRA to adapt to different scenarios.

[0102] Real-time anomaly detection (building a closed-loop security protection system): The AI ​​Agent extracts the 128-dimensional feature vector of the message, compares it with the local normal feature library, and calculates the anomaly confidence score using cosine similarity and the Isolation Forest algorithm; when the confidence score is greater than 80, the message is blocked and reported. The feature library is updated incrementally daily through federated learning, and only feature gradients are transmitted to protect privacy.

[0103] Intelligent power consumption scheduling (meets automotive-grade low power requirements): The AI ​​Agent monitors the MCU status, battery voltage, and task queue in real time, and dynamically adjusts the message sending cycle and MCU wake-up timing; it extends the heartbeat cycle and merges non-urgent messages during idle periods, reducing the number of MCU wake-up times by more than 50% and reducing the overall power consumption of the TBOX by more than 35%.

[0104] (3) Vehicle-Cloud Dual-Terminal AI Collaborative Verification (Improving the Security Protection Closed Loop) A dual-end AI collaborative verification model is adopted: the vehicle-side AI Agent is responsible for first-level real-time anomaly interception, while the cloud-based CNN-LSTM+LoRA model is deployed for second-level deep verification. A common header carries the vehicle-side detection results, and the cloud compares the conclusions of the two ends. If they are inconsistent, a deep audit is triggered, forming a complete security closed loop. The anomaly detection accuracy can reach over 99.8%.

[0105] The high accuracy of anomaly detection mentioned above relies on continuously updated models, while rapid adaptation to new business scenarios places higher demands on the iterative efficiency of these models. To address this, this invention further designs an AI online incremental learning mechanism to solve the problem of difficult adaptation to new business scenarios. Specifically, an AI online incremental learning mechanism is designed to meet the adaptation needs of new business scenarios, eliminating the need to retrain and deploy the model. The specific process is as follows: After the new business goes live, the Agent automatically collects 500-1000 samples and preprocesses them; the model is quickly fine-tuned through LoRA low-rank adaptation (training time < 5 minutes, computing power consumption < 1%); the local feature library is updated, taking effect online without requiring a firmware restart; and global features are synchronized through federated learning to achieve collaborative optimization of the entire fleet's models.

[0106] The core methods and mechanisms of this invention have been described above. The specific system structure is given below. The message processing system based on the Internet of Vehicles (IoV) proposed in this invention consists of two parts: an in-vehicle TBOX (edge ​​node) and an IoV cloud terminal (platform node). The two parts achieve bidirectional data interaction through a 4G / 5G communication link. The specific structure and connection relationship are as follows: The vehicle-mounted TBOX mainly consists of five functional modules, which are electrically connected and interact with each other via the MCU bus. 1) Packaging module: responsible for business message serialization and frame assembly; 2) AI Agent module: integrates lightweight model, LoRA adaptation, RAG memory and federated learning client to realize message optimization, anomaly detection and power consumption scheduling; 3) Communication module: uses a 4G / 5G modem to handle data transmission; 4) Storage module: uses Flash to store model parameters, feature library and configuration information; 5) Power management module: responsible for MCU sleep / wake-up and power consumption adjustment.

[0107] The vehicle-to-everything (V2X) cloud terminal mainly consists of five functional modules, which work together through a cloud server bus. 1) Receiving module: has high-concurrency message receiving capability; 2) Cloud AI verification module: deploys a homogeneous model and is responsible for secondary deep verification; 3) Parsing and routing module: responsible for frame parsing and business distribution; 4) Federated learning server: responsible for model aggregation and gradient distribution; 5) Business module: handles business logic such as remote vehicle control and data reporting.

[0108] Furthermore, the complete structure definition of a frame message is as follows: protobuf / / Top-level message packaging / / Full news about T-BOX message TBoxMessage { string start_flag = 1; / / Starting byte TBoxHeader header = 2; bytes body = 3; / / Serialized data body / / Enterprise Standard Body: After filling the message with the protobuf business message defined below, serialize the message body and pass it in. } / / General message header message TBoxHeader { RequestId request_id = 1; / / Request identifier ResponseCode response_id = 2; / / Response flag string vin = 3; / / 17-byte VIN code EncryptionType encryption = 4; / / Data body encryption method string session_id = 5; / / Session ID (16 bytes) string proto_version = 6; / / Protocol version CmdVersion cmd_version = 7; / / Command version uint32 custom_cmd = 8; / / Subcommand uint32 ai_agent_flag = 10; / / Agent running status indicator: Idle / Optimizing / Detecting / Abnormal uint32 ai_compress_level = 11; / / Dynamic AI compression level (levels 1-8) uint32 ai_abnormal_score = 12; / / Abnormal confidence level (0~100) string ai_model_version = 13; / / Vehicle-side LoRA model version number Timestamp timestamp = 9; }".

[0109] Based on the above system and protocol design, this invention has achieved a series of significant beneficial effects. This invention, through a three-layer standardized paradigm of "fixed outer frame TBoxMessage + unified common header TBoxHeader + Protobuf-lite body," retains only the core communication elements, achieving unified encapsulation for all services and solving the problems of format chaos and fragmented parsing. The frame messages of this invention are independently defined and completely decoupled from the frame structure. Through dynamic routing and parsing of the common header, it achieves independent evolution of services and protocols, adapting to the rapid iteration requirements of SDV. This invention integrates AI Agent, LoRA adaptation, CNN-LSTM, and other technologies into the vehicle-mounted TBOX, realizing lightweight automotive-grade deployment of the anomaly analysis model, constructing a complete intelligent closed loop, and possessing three major capabilities: dynamic compression, anomaly detection, and power consumption scheduling. This invention constructs a mechanism of vehicle-side first-level detection plus cloud-side second-level verification. Auditing is triggered by comparing conclusions from both ends, achieving an anomaly detection accuracy of ≥99.8%, significantly improving the security of vehicle-cloud communication. When new services emerge, this invention utilizes LoRA for rapid model fine-tuning and online feature library updates, eliminating the need for retraining and re-deployment. Combined with federated learning, it achieves full fleet optimization, significantly reducing adaptation costs. Based on the fundamental deconstruction method, this invention's unified TBoxMessage frame structure eliminates redundant and intrusive fields, retaining only core communication elements. It standardizes message encapsulation and simplifies the parsing logic to "a single universal parser plus dynamic service routing," reducing development and maintenance costs by over 60% and achieving 100% protocol compatibility. This significantly improves the consistency and maintainability of vehicle-to-cloud communication. Service changes only require modification of the corresponding Protobuf message, while the frame structure and parsing link remain unchanged, achieving complete decoupling between services and protocols. It supports rapid SDV iteration and canary releases, shortening the new service launch cycle from 30 days to 7 days, thus addressing the pain point of insufficient scalability in traditional protocols. This invention features a lightweight CNN-LSTM+LoRA model with a size ≤800KB and inference latency ≤80μs, perfectly adapting to automotive-grade MCUs and improving vehicle-side intelligence and automotive-grade compatibility. Dynamic compression balances bandwidth and latency, achieving a real-time anomaly detection accuracy of ≥99.8%. Power scheduling reduces the overall power consumption of the TBOX by more than 35%, meeting automotive-grade requirements. This invention uses federated learning to incrementally update the feature library, transmitting only feature gradients to protect privacy. RAG memory combined with LoRA fine-tuning allows for new service adaptation without model retraining, online activation, and collaborative optimization across the entire fleet, achieving dual protection of privacy and model self-optimization, significantly improving adaptation efficiency.

[0110] The message encapsulation system based on the Internet of Vehicles provided in the above embodiments can realize the technical solutions described in the above message encapsulation method embodiments based on the Internet of Vehicles. The specific implementation principles of each module or unit can be found in the corresponding content in the above message encapsulation method embodiments based on the Internet of Vehicles, and will not be repeated here.

[0111] The above provides a detailed description of the message encapsulation method, parsing method, terminal, and system based on the Internet of Vehicles provided by this invention. Specific examples have been used to illustrate the principles and implementation methods of this invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.

Claims

1. A message encapsulation method based on vehicle-to-everything (V2X) communication, characterized in that, Applied to an in-vehicle information processing terminal, the in-vehicle information processing terminal is equipped with a first artificial intelligence agent, including: Retrieve business messages; The business message is serialized to generate serialized business data; the serialized business data is in binary format. The first AI agent performs anomaly analysis on the serialized business data. If the serialized service data is not abnormal, a frame message is generated based on the start identifier, common header fields, and the serialized service data; the common header fields include the request identifier, subcommand, and the first anomaly confidence level obtained from anomaly analysis; The frame message is sent to the vehicle-to-everything (V2X) cloud terminal via the vehicle-to-everything (V2X) communication link.

2. The method according to claim 1, characterized in that, The step of performing anomaly analysis on the serialized business data through the first artificial intelligence agent includes: The first business feature vector of the serialized business data is extracted through the first anomaly analysis model maintained by the first artificial intelligence agent. The first anomaly confidence level is calculated based on the first business feature vector and the first normal feature vector in the first preset feature library. Compare the first anomaly confidence level with the preset threshold. If the first anomaly confidence level is greater than or equal to the preset threshold, it is determined that the serialized service data is abnormal; If the first anomaly confidence level is less than the preset threshold, it is determined that the serialized service data does not have anomalies.

3. The method according to claim 1, characterized in that, Also includes: The first AI agent senses the vehicle network communication status and its own operating status, and determines the compression level based on the sensing results. If the serialized service data does not have any abnormalities, the serialized service data is compressed according to the compression level; The compression level is added to the common header field, and the frame message is generated using the compressed serialized business data.

4. The method according to claim 1, characterized in that, Also includes: If the serialized service data is abnormal, the generation of the frame message is refused, and a prompt message is generated and sent to the vehicle network cloud terminal.

5. A message parsing method based on vehicle-to-everything (V2X) communication, characterized in that, Applications to vehicle-to-everything (V2X) cloud terminals include: The system receives frame messages from an in-vehicle information processing terminal and parses the start identifier in the frame messages to complete frame synchronization. The frame messages are generated by the first artificial intelligence agent of the in-vehicle information processing terminal through anomaly analysis of serialized service data. If there are no anomalies in the serialized service data, the system generates the serialized service data based on the start identifier, common header fields, and the serialized service data. The serialized service data is generated by the in-vehicle information processing terminal through serialization of acquired service messages. The serialized service data is in binary format. The common header fields include a request identifier, a subcommand, and a first anomaly confidence level obtained from the anomaly analysis. Extract the common header fields from the frame message to obtain the request identifier, the subcommand, and the first anomaly confidence level; Based on the request identifier and the sub-command, the serialized service data in the frame message is routed to the corresponding service parser; The business parser is invoked to deserialize the serialized business data and restore the business message.

6. The method according to claim 5, characterized in that, The vehicle-to-everything (V2X) cloud terminal is equipped with a second artificial intelligence agent, and the method further includes: The serialized service data in the frame message is decompressed according to the compression level in the common header field to obtain the decompressed serialized service data; The second artificial intelligence agent performs anomaly detection on the serialized business data to obtain a second anomaly confidence level. Determine whether both the first anomaly confidence level and the second anomaly confidence level are lower than a preset threshold; If the value is lower than the preset threshold, the business logic corresponding to the frame message will be executed. If the second anomaly confidence level is greater than or equal to the preset threshold and the first anomaly confidence level is less than the preset threshold, the frame message is recorded as an anomaly event and an alarm message is generated.

7. The method according to claim 5, characterized in that, Also includes: The system receives model parameter adjustment amounts uploaded by multiple vehicle information processing terminals. These model parameter adjustment amounts are generated by the first artificial intelligence agent of each vehicle information processing terminal after fine-tuning the first anomaly analysis model locally through low-rank matrix factorization. Based on the federated learning approach, global model parameters are generated by adjusting the model parameters accordingly. The global model parameters are distributed to each vehicle information processing terminal to update the model parameters of the first anomaly analysis model.

8. A vehicle-mounted information processing terminal, characterized in that, include: Including memory and processor, among which, The memory is used to store programs; The processor, coupled to the memory, is used to execute the program stored in the memory to implement the steps in the message encapsulation method based on the Internet of Vehicles as described in any one of claims 1 to 4.

9. A vehicle-to-everything (V2X) cloud terminal, characterized in that, include: Including memory and processor, among which, The memory is used to store programs; The processor, coupled to the memory, is used to execute the program stored in the memory to implement the steps in the message encapsulation method based on the Internet of Vehicles as described in any one of claims 5 to 7.

10. A message processing system based on the Internet of Vehicles, characterized in that, It includes the vehicle information processing terminal as described in claim 8 and the vehicle network cloud terminal as described in claim 9.

Images