A vehicle networking multi-protocol dynamic analysis method based on a protocol description model

Abstract

The application provides a vehicle networking multi-protocol dynamic analysis method based on a protocol description model, comprising: constructing a multi-level PDM containing a protocol metadata layer, a dynamic adaptation layer, a security check layer and a resource scheduling layer; generating a dynamic analysis engine integrating protocol identification, parameter adjustment and result standardization functions based on the PDM; after receiving multi-source data, calling the engine to analyze and pass the PDM security check, combining the resource scheduling layer to allocate resources, and outputting standardized analysis data; when detecting protocol updates, updating the PDM through edge-cloud collaboration, without the need to reconfigure the engine to adapt to new protocols. The application dynamically adapts the vehicle networking scene through the PDM, improves the analysis flexibility and accuracy; double security check and Nash equilibrium resource scheduling guarantee safety and real-time performance; edge-cloud collaborative updating takes into account efficiency and privacy, and is suitable for vehicle networking multi-protocol dynamic analysis scenes.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Internet of Vehicles communication, and in particular to an Internet of Vehicles multi-protocol dynamic analysis method based on a protocol description model. BACKGROUND

[0002] With the rapid development of Internet of Vehicles technology, multi-scene communication such as vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-pedestrian (V2P) is increasingly frequent, and the communication protocols involved in Internet of Vehicles are diversified, such as CAN, LIN, Ethernet / IP, 5G-V2X, and other coexisting protocols. Existing Internet of Vehicles multi-protocol analysis solutions mostly use a fixed analysis engine architecture, and special analysis modules need to be developed for different protocols. When a new protocol is added or the version of an existing protocol is updated, the analysis engine needs to be restructured or recompiled, resulting in poor analysis flexibility and low adaptation efficiency.

[0003] At the same time, in the Internet of Vehicles scenario, vehicles are in a dynamic moving state, the network topology structure changes frequently, and the communication link quality is affected by factors such as vehicle speed and obstruction, resulting in fluctuations. Existing analysis methods mostly use fixed analysis parameters (such as analysis window size) and cannot dynamically adjust according to the vehicle moving state and link quality, which easily leads to problems such as decreased analysis accuracy at high speeds and insufficient data throughput at low speeds. In addition, the security verification of existing solutions mostly only checks data integrity, lacks a verification mechanism for the legality of protocol fields, and when multiple protocols are concurrently analyzed, resource allocation is unreasonable, making it difficult to ensure real-time analysis of critical data such as emergency braking signals.

[0004] Protocol description models (PDMs) are mostly used in existing technologies for metadata description of static protocols and are not adapted and designed in combination with the dynamic scenario characteristics of Internet of Vehicles, and the integration with technologies such as edge computing and federated learning is insufficient, which makes it difficult to achieve efficient updating and multi-terminal synchronization of protocol description rules and meet the needs of dynamic analysis of Internet of Vehicles multi-protocols. SUMMARY

[0005] Therefore, the embodiments of the present application provide an Internet of Vehicles multi-protocol dynamic analysis method, device, electronic equipment, and storage medium based on a protocol description model, which can dynamically adapt to the Internet of Vehicles scenario through PDM, improve analysis flexibility and accuracy, and ensure safety and real-time performance through double security verification and Nash equilibrium resource scheduling. Edge-cloud collaborative updating takes into account efficiency and privacy, and is suitable for the Internet of Vehicles multi-protocol dynamic analysis scenario.

[0006] The technical scheme of the embodiments of the present application is as follows:

[0007] In a first aspect, the embodiments of the present application provide an Internet of Vehicles multi-protocol dynamic analysis method based on a protocol description model, including the following steps:

[0008] A multi-level protocol description model PDM is constructed, the PDM comprising a protocol metadata layer, a dynamic adaptation layer and a security check layer, wherein the protocol metadata layer predefines the field structure, data type and coding rule of a mainstream protocol of the Internet of Vehicles, the dynamic adaptation layer embeds a vehicle moving state correlation factor and a communication link quality parameter, and the security check layer integrates a hash check rule and a protocol field legality check rule;

[0009] A dynamic analysis engine is generated based on the constructed PDM, the dynamic analysis engine integrating a protocol identification, parameter adjustment and result standardization function, the protocol type of to-be-analyzed data being matched with the metadata features of the PDM to complete protocol identification, the size of an analysis window being dynamically optimized according to the real-time speed, acceleration and network topology change of a vehicle to realize parameter adjustment, the analysis result being standardized after data analysis and check are completed, and uniform format data being output;

[0010] After receiving multi-source data uploaded by an Internet of Vehicles terminal, the generated dynamic analysis engine and the corresponding protocol description rule of the PDM are called to perform preliminary analysis, and the data integrity is checked by a preset hash algorithm of the security check layer of the PDM, the result is standardized after the check is passed, and uniform format analysis data is output;

[0011] When a new protocol is accessed or an existing protocol version is updated, the difference between the update content and the existing metadata is matched through the protocol feature fingerprint library of the PDM, the protocol metadata layer difference information is updated through the extension interface of the PDM, and the updated description rule is directly loaded after the update is completed to realize new protocol analysis without reconstructing the dynamic analysis engine.

[0012] In a second aspect, the embodiments of the present application further provide a vehicle Internet multi-protocol dynamic analysis device based on a protocol description model, comprising:

[0013] A construction module is configured to construct a multi-level protocol description model PDM, the PDM comprising a protocol metadata layer, a dynamic adaptation layer and a security check layer, wherein the protocol metadata layer predefines the field structure, data type and coding rule of a mainstream protocol of the Internet of Vehicles, the dynamic adaptation layer embeds a vehicle moving state correlation factor and a communication link quality parameter, and the security check layer integrates a hash check rule and a protocol field legality check rule;

[0014] A generation module is configured to generate a dynamic analysis engine based on the constructed PDM, the dynamic analysis engine integrating a protocol identification, parameter adjustment and result standardization function, the protocol type of to-be-analyzed data being matched with the metadata features of the PDM to complete protocol identification, the size of an analysis window being dynamically optimized according to the real-time speed, acceleration and network topology change of a vehicle to realize parameter adjustment, the analysis result being standardized after data analysis and check are completed, and uniform format data being output.

[0015] The output module receives multi-source data uploaded by the vehicle network terminal, calls the generated dynamic parsing engine and the protocol description rules corresponding to PDM for preliminary parsing, and verifies the data integrity through the preset hash algorithm of the PDM security verification layer. After the verification is passed, the results are standardized and parsed data in a unified format is output.

[0016] The update module is used to detect the access of new protocols or the update of existing protocol versions. First, it matches the differences between the updated content and the existing metadata through the protocol feature fingerprint library of PDM. Then, it updates the protocol metadata layer difference information in a targeted manner through the extended interface of PDM. After the update is completed, it directly loads the updated description rules to achieve new protocol parsing without reconstructing the dynamic parsing engine.

[0017] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to execute the vehicle-to-everything (V2X) multi-protocol dynamic parsing method based on the protocol description model as described in any of the first aspects.

[0018] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is executed by a processor to perform the vehicle-to-everything (V2X) multi-protocol dynamic parsing method based on the protocol description model as described in any one of the first aspects.

[0019] The embodiments of this application have the following beneficial effects:

[0020] (1) Significantly improved parsing flexibility: By constructing a multi-level PDM and generating a dynamic parsing engine, when adding or updating protocols, it is only necessary to update the PDM metadata through the extension interface, without having to reconstruct the engine. This solves the pain point of "reconstruction is required when adding a protocol" in the traditional solution, and improves the adaptation efficiency by more than 60%.

[0021] (2) Enhanced dynamic adaptation capability: The dynamic adaptation layer integrates vehicle movement status and communication link quality parameters, corrects correlation factors through Kalman filtering, and combines parameter dynamic adjustment strategy to enable the parsing window to adapt to changes in vehicle status. The parsing accuracy is improved by 30% when moving at high speed and the data throughput is improved by 40% when moving at low speed.

[0022] (3) Enhanced security and reliability: The security verification layer provides dual protection through hash integrity verification and field validity verification, increasing the abnormal data identification rate to 99%; the resource scheduling layer optimizes resource allocation through the Nash equilibrium model, increasing the high-priority data parsing latency compliance rate to 99.5%;

[0023] (4) Balancing update efficiency and privacy protection: The edge-cloud collaborative update mechanism combines federated learning and differential update, improving the synchronization efficiency of the new protocol by 50% while avoiding the risk of privacy leakage caused by direct upload of sample data. Attached Figure Description

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

[0025] Figure 1 This is a flowchart illustrating steps S101-S104 provided in the embodiments of this application;

[0026] Figure 2 This is a flowchart illustrating steps S201-S203 provided in the embodiments of this application;

[0027] Figure 3 This is a flowchart illustrating steps S301-S302 provided in the embodiments of this application;

[0028] Figure 4 This is a flowchart illustrating steps S401-S403 provided in the embodiments of this application;

[0029] Figure 5 This is a flowchart illustrating steps S501-S504 provided in the embodiments of this application;

[0030] Figure 6 This is a flowchart illustrating steps S601-S604 provided in the embodiments of this application;

[0031] Figure 7 This is a schematic diagram of the structure of the vehicle-to-everything (V2X) multi-protocol dynamic parsing device based on the protocol description model provided in this application embodiment;

[0032] Figure 8 This is a schematic diagram of the composition structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0033] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0034] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0035] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0036] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0037] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0038] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application and is not intended to limit this application.

[0039] See Figure 1 , Figure 1This is a flowchart illustrating steps S101-S104 of the vehicle-to-everything (V2X) multi-protocol dynamic parsing method based on a protocol description model provided in this application embodiment. It will be combined with... Figure 1 Steps S101-S104 are explained below.

[0040] In step S101, a multi-level protocol description model (PDM) is constructed. The PDM includes a protocol metadata layer, a dynamic adaptation layer, and a security verification layer. The protocol metadata layer predefines the field structure, data type, and encoding rules of mainstream vehicle networking protocols. The dynamic adaptation layer embeds vehicle movement state correlation factors and communication link quality parameters. The security verification layer integrates hash verification rules and protocol field validity verification rules.

[0041] This step is the basic model building stage of the method. The core solution is to design a "three-level collaborative" PDM architecture to break through the static limitations of the traditional single metadata model.

[0042] The protocol metadata layer adopts a "full protocol coverage + structured definition" approach, predefining the field structure of mainstream protocols such as CAN and 5G-V2X (e.g., the 11-bit / 29-bit ID field and 0-8 byte data length field of the CAN protocol), data types (integer for vehicle speed, floating-point for fuel consumption), and encoding rules (ASCII encoding for text data, binary encoding for sensor values). At the same time, a feature vector library is built to store the differentiated features of each protocol, providing data support for subsequent identification.

[0043] The dynamic adaptation layer adopts a "dual-parameter fusion" scheme, embedding vehicle movement state correlation factors (speed, heading angle derived parameters) and communication link quality parameters (signal-to-noise ratio, packet loss rate), which solves the shortcomings of existing PDM that only focus on the protocol itself and do not adapt to the dynamic scenarios of vehicle networking.

[0044] The security verification layer adopts a "dual rule integration" scheme, integrating hash verification rules such as SHA-256 to ensure data integrity, and protocol field validity verification rules (such as the CAN protocol ID field range of 0-2047 and the data length field matching the actual load), thus making up for the security vulnerabilities of existing single verification methods. This step, through hierarchical design, enables PDM to have "protocol description accuracy", "dynamic adaptation capability", and "security assurance strength".

[0045] In step S102, a dynamic parsing engine is generated based on the constructed PDM. The dynamic parsing engine integrates protocol identification, parameter adjustment and result standardization functions. It matches the protocol type of the data to be parsed with the metadata features of the PDM to complete the protocol identification. It dynamically optimizes the parsing window size according to the real-time speed, acceleration and network topology changes of the vehicle to achieve parameter adjustment. After the data parsing and verification are completed, the parsing results are format-standardized and output data in a unified format.

[0046] The engine generation adopts a "model-driven compilation" approach, which reads the rules of each layer of PDM through the parsing device's compiler and automatically generates an integrated engine that includes protocol identification, parameter adjustment, and standardization, without the need for manual development of dedicated modules. Protocol identification adopts a "metadata feature matching" approach, which calls the feature vector library of the PDM metadata layer and calculates the matching degree between the data to be parsed and the features of each protocol (such as the similarity of field length, key field position, and encoding format) using a cosine similarity algorithm, which is more accurate than traditional single header identifier matching. Parameter adjustment adopts a "dynamic optimization" approach, which collects vehicle speed, acceleration, and network topology change frequency in real time, and combines the correlation factors of the PDM dynamic adaptation layer to adjust the parsing window size through a preset algorithm (such as reducing the window size at high speeds to improve anti-interference). Result standardization adopts a "unified format mapping" approach, which predefines JSON as the output format and maps the parsing results of different protocols (such as binary data of CAN and JSON data of 5G-V2X) to a unified structure, reducing the adaptation cost of subsequent data applications.

[0047] The above approach enables the engine to be "protocol independent," laying the foundation for subsequent multi-protocol parsing and rapid updates.

[0048] In step S103, after receiving multi-source data uploaded by the vehicle network terminal, the generated dynamic parsing engine and the protocol description rules corresponding to PDM are called to perform preliminary parsing. At the same time, the data integrity is verified by the preset hash algorithm of the PDM security verification layer. After the verification is passed, the result is standardized and parsed data in a unified format is output.

[0049] This step establishes a closed loop of "parsing-verification-standardization," balancing efficiency and security. Data reception employs a "multi-protocol compatibility" scheme, receiving multi-source data from terminals such as ECUs, navigation systems, and entertainment devices via the parsing device's communication module (supporting CAN bus, 5G, and Ethernet), eliminating the need for categorized receiving devices. Preliminary parsing utilizes an "engine + PDM collaboration" scheme. The dynamic parsing engine, based on the initial characteristics of the data to be parsed, invokes the corresponding protocol description rules in the PDM (such as field parsing order and data type conversion rules) to perform parsing, ensuring consistency between the parsing logic and protocol definitions. Security verification employs a "dual verification" scheme. First, a joint hash value (header + payload) of the data to be parsed is generated using the hash algorithm of the PDM security verification layer, compared with a pre-stored baseline value to verify integrity. Then, field validity rules are used for verification (such as ID field range and data length matching), dual verification improving the anomaly detection rate. Standardization and output employ a "real-time mapping output" scheme. After successful verification, the parsing result is immediately mapped to a unified JSON format and output to the vehicle network control center or local storage via the communication interface. This step solves the problems of "cumbersome multi-source data processing and insufficient security verification" in existing parsing methods.

[0050] In step S104, when a new protocol access or an existing protocol version update is detected, the differences between the updated content and the existing metadata are quickly matched using the protocol feature fingerprint database of PDM. Then, the protocol metadata layer difference information is updated in a targeted manner through the extended interface of PDM. After the update is completed, there is no need to reconstruct the dynamic parsing engine. The updated description rules can be loaded directly to realize the parsing of the new protocol.

[0051] The update detection adopts the "feature fingerprint matching" scheme. PDM pre-stores the feature fingerprints of each protocol (unique identifiers generated by core fields, encoding rules, etc.). When a new protocol or version update is detected, its feature fingerprint is extracted and compared with the existing fingerprint to quickly locate the differences (such as new fields or changes in encoding rules).

[0052] When updating differences, a standardized extension interface is designed through PDM (supporting the addition and deletion of metadata fields and modification of rules), only the differences are updated (e.g., adding a new protocol only adds its metadata, and version updates only modify the change rules), without having to modify the entire PDM.

[0053] For engine adaptation, a "rule hot loading" solution is adopted. The updated PDM rules are imported into the dynamic parsing engine through memory hot loading, without the need to restart or reconstruct the engine. The engine automatically recognizes the new rules and executes the parsing.

[0054] The above method reduces the adaptation time of the new protocol from several days to minutes, greatly improving adaptation efficiency.

[0055] In some embodiments, see Figure 2 , Figure 2 This is a flowchart illustrating steps S201-S203 provided in the embodiments of this application, as shown below. Figure 2 As shown, the specific process of constructing the dynamic adaptation layer includes steps S201-S203, which will be explained in conjunction with each step.

[0056] In step S201, the vehicle's speed and heading angle data for a preset number of consecutive timestamps, as well as the communication link signal-to-noise ratio and packet loss rate data for the corresponding timestamps, are collected.

[0057] This step is the basic data collection stage for the dynamic adaptation layer. The core of the solution is "multi-dimensional synchronous collection" to solve the adaptation deviation problem caused by the existing single vehicle status collection.

[0058] The specific implementation process is as follows:

[0059] The data collection employs a dual-dimensional approach: "vehicle status + link quality." Vehicle status is measured using speed (reflecting movement speed) and heading angle (reflecting direction of travel), while link quality is measured using signal-to-noise ratio (SNR) (reflecting signal quality) and packet loss rate (reflecting transmission stability). These two types of data directly impact the effectiveness of the parsing parameter adaptation. The data collection method uses a "time-synchronization" approach, collecting data at 100ms intervals for a predetermined number of timestamps (e.g., 10). This ensures that each timestamp corresponds to both vehicle status and link quality data simultaneously, avoiding correlation distortion caused by time-series misalignment. The data source utilizes a "multi-sensor fusion" approach, with vehicle status data from the vehicle's OBD interface and link quality data from the communication module's built-in monitoring unit, ensuring data authenticity and real-time performance. This step provides a "time-consistent and comprehensive" data source for subsequent correlation factor calculations.

[0060] In step S202, the collected vehicle data is processed by the Kalman filter algorithm to predict the vehicle's position information at the next moment and calculate the position prediction deviation value. At the same time, the position prediction deviation value is adaptively corrected by combining the communication link data to obtain the corrected correlation factor.

[0061] Vehicle state prediction employs a Kalman filter scheme, which features anti-interference and high-precision prediction. Inputting collected speed and heading angle data, it predicts the next moment's position using a state equation, corrects the predicted value using an observation equation, and outputs a position prediction deviation (reflecting the degree of vehicle state fluctuation). Deviation correction uses a link quality weighting scheme, determining the correction weight based on the communication link's signal-to-noise ratio and packet loss rate (e.g., weight increases to 0.8 when packet loss rate > 5%, and decreases to 0.3 when packet loss rate < 1%). The position prediction deviation is multiplied by the weight to obtain the corrected correlation factor, allowing the correlation factor to simultaneously reflect the combined impact of vehicle state and link quality. The calculation frequency uses a real-time iteration scheme, performing a calculation after each round of new data collection (10 timestamps) to ensure dynamic matching of the correlation factor with the scene. This step solves the problems of "one-sidedness and lag" in the adaptation of existing single vehicle state parameters.

[0062] In step S203, the calculated position prediction deviation value is used as the vehicle movement state correlation factor and embedded into the dynamic adaptation layer of PDM as the basis for adjusting the parsing parameters.

[0063] This application's embodiments employ "structured storage," setting a dedicated correlation factor field in the PDM dynamic adaptation layer to store the corrected correlation factors and their corresponding timestamps, facilitating rapid retrieval by the engine. For the correlation mechanism, predefined mapping rules between correlation factors and parsing parameters are used (e.g., a small window corresponds to a correlation factor > a preset threshold, and a large window corresponds to a correlation factor > a threshold), enabling the dynamic parsing engine to directly determine the adjustment strategy by reading the factors. During updates, newly calculated correlation factors directly overwrite old values, ensuring that the engine always uses the latest adaptation criteria for the current scenario.

[0064] The above approach achieves seamless integration of the "data-factor-model-engine" chain, providing direct support for dynamic parameter adjustment.

[0065] In some embodiments, see Figure 3 , Figure 3 This is a flowchart illustrating steps S301-S302 provided in the embodiments of this application, as shown below. Figure 3 As shown, the specific process of parameter adjustment includes steps S301-S302, which will be explained in conjunction with each step.

[0066] In step S301, the vehicle's driving speed and the frequency of network topology changes in the vehicle network are acquired in real time.

[0067] Vehicle speed acquisition employs an "OBD real-time reading" scheme. This involves communicating with the vehicle's OBD interface via a parsing device, reading vehicle speed data at 50ms intervals with an accuracy of 0.1km / h, ensuring real-time speed perception. A communication module monitors the connection / disconnection counts of nodes (vehicles, roadside units) in the vehicle network, statistically analyzing the number of changes per unit time (1 second), i.e., the topology change frequency, reflecting the stability of the network structure. Data preprocessing uses a "noise reduction filtering" scheme, applying mean filtering to the collected speed and frequency data to remove instantaneous fluctuations (such as sudden speed changes or temporary disconnections), ensuring the stability of the status data. This approach avoids the limitations of existing methods that rely solely on vehicle speed, covering the two core influencing factors: "vehicle motion" and "network structure."

[0068] In step S302, if the vehicle speed is detected to be greater than the preset speed or the network topology change frequency is greater than the preset frequency, the parsing window size is automatically reduced to a first preset ratio of the original size, and a parallel parsing thread is started at the same time; if the vehicle is detected to be stationary or in a low-speed platooning state, the parsing window is expanded to a second preset ratio of the original size to improve data throughput.

[0069] Scene determination adopts a "threshold trigger" scheme, with preset speed (e.g., 60km / h) and preset frequency (e.g., 3 times / second) as the determination thresholds. When either "high speed" or "topological change" is met, it is determined to be a dynamic scene; when vehicles are stationary (speed ≤ 0km / h) or in low-speed platooning (speed ≤ 30km / h and stable spacing between vehicles in the platoon), it is determined to be a static scene. Dynamic scene adjustment adopts a "small window + parallel parsing" scheme, reducing the parsing window to 60% of its original size (first preset ratio) to reduce the amount of data parsed per session and improve anti-interference, while starting 2-4 parallel threads to process data to compensate for the throughput loss caused by window reduction. Static scene adjustment adopts a "large window" scheme, expanding the parsing window to 1.5 times its original size (second preset ratio) to increase the amount of data parsed per session, thereby increasing throughput by more than 40%. Parameter configuration adopts a "customizable" scheme, with preset speed, frequency, and ratio that can be modified through the PDM extension interface according to the application scenario (urban roads, highways) to improve adaptability.

[0070] The above method resolves the contradiction of "low accuracy at high speed and poor efficiency at low speed" in the existing fixed window.

[0071] In some embodiments, see Figure 4 , Figure 4 This is a flowchart illustrating steps S401-S403 provided in the embodiments of this application, as shown below. Figure 4 As shown, the security verification process includes steps S401-S403, which will be explained in conjunction with each step.

[0072] In step S401, the header field and payload data of the data to be parsed are extracted, and a joint hash value is generated based on a preset hash algorithm.

[0073] Data extraction employs a "full field coverage" approach, extracting header fields (such as protocol identifiers and length fields) and payload data (such as sensor values ​​and control commands) from the data frame to be parsed. This avoids the header tampering omission problem caused by traditional methods that only extract the payload. The hash algorithm chosen adopts a "security and efficiency balance" approach, selecting the SHA-256 algorithm. This algorithm has 128-bit collision resistance, offering higher security than MD5, while its computational efficiency meets the real-time requirements of vehicle-to-everything (V2X) networks (single-frame data computation time ≤1ms). The joint hash generation uses a "concatenation followed by encryption" approach, concatenating the header fields and payload data in a fixed order (header first, payload last), and then generating a 256-bit joint hash value using the SHA-256 algorithm. This ensures that tampering with any part of the data will result in a change in the hash value. This step provides the "full field coverage" encryption basis for subsequent integrity verification.

[0074] In step S402, the pre-stored corresponding protocol baseline hash value is retrieved from the PDM security verification layer, the generated joint hash value is compared with the baseline hash value, and the deviation rate is calculated.

[0075] The baseline hash value retrieval adopts a "protocol association" scheme. The PDM security verification layer stores baseline hash values ​​according to protocol type (e.g., one set of baseline values ​​corresponds to the CAN protocol, and another set corresponds to 5G-V2X). After the parsing engine determines the protocol type, it quickly retrieves the corresponding baseline value through the protocol identifier, avoiding the time-consuming full-data search. The comparison method adopts a "bit-by-bit comparison" scheme, comparing the generated joint hash value with the baseline value bit by bit and counting the number of different bits. The deviation rate calculation adopts a "proportional quantization" scheme: deviation rate = number of different bits / total number of bits × 100%. This quantitative indicator reflects the degree of data integrity and is more suitable for the slight fluctuation scenarios of vehicle network data transmission (such as individual bit flips caused by signal interference) than the traditional rigid verification of "complete consistency is required to pass". This step realizes "precise positioning + flexible judgment" of integrity verification.

[0076] In step S403, if the deviation rate is less than or equal to the preset deviation rate, the verification is deemed successful and subsequent result standardization processing is performed; if the deviation rate is greater than the preset deviation rate, the data retransmission mechanism is triggered and a data anomaly log is recorded.

[0077] The result determination adopts a "threshold-based" scheme, with a preset deviation rate (e.g., 0.01%) as the judgment threshold. When the deviation rate is ≤ the threshold, it is judged as "data complete" and allowed to proceed to the next process; when the deviation rate is > the threshold, it is judged as "data abnormal" and refused to proceed to the next process. The abnormality handling adopts a "retransmission + log" scheme, triggering a data retransmission mechanism (sending a retransmission request to the data sending terminal through the communication module, with ≤3 retransmissions), and recording an abnormality log. The log content includes timestamp, protocol type, deviation rate, and data frame content, providing a basis for fault tracing. The fallback mechanism adopts a "timeout discard" scheme. If the abnormality persists after 3 retransmissions, the data frame is discarded and an alarm message is sent to the control center to avoid the accumulation of abnormal data affecting parsing efficiency. This step forms a security closed loop of "verification-processing-tracing".

[0078] In some embodiments, see Figure 5 , Figure 5 This is a flowchart illustrating steps S501-S504 provided in the embodiments of this application, as shown below. Figure 5 As shown, the new protocol update process includes steps S501-S504, which will be explained in conjunction with each step.

[0079] In step S501, the edge node collects sample data of the new protocol, performs deduplication and noise reduction preprocessing on the sample data, extracts the core features of the protocol, and labels the feature confidence level.

[0080] Sample collection employs an "edge node localization" approach, where edge nodes (such as roadside units and vehicle gateways) are located close to the data source, enabling the collection of sufficient new protocol sample data (≥1000 frames), avoiding the latency and loss associated with remote cloud collection. Preprocessing utilizes a "duplicate removal + noise reduction" approach. Duplicate frames are removed by comparing their hash values, while noise reduction uses mean filtering to remove abnormally fluctuating frames (such as distorted frames caused by signal interference). This preprocessing improves sample effectiveness to over 95%. Core feature extraction employs a "structured extraction" approach, extracting core features such as protocol header identifiers, field quantity, field length, encoding rules, and the meaning of key fields. Confidence labeling uses a "statistical quantification" approach, statistically analyzing the frequency of each feature in the samples. Features with a frequency ≥99% are labeled with a confidence level of 1.0, those with a frequency between 90% and 99% are labeled with 0.9, and so on, providing a reliable basis for subsequent update verification. This step provides "high-precision, verifiable" feature data for new protocol updates.

[0081] In step S502, the edge node encrypts the extracted core features using a lightweight encryption algorithm and then uploads them to the cloud-based PDM management platform.

[0082] The encryption algorithm adopts an "efficiency-first + security-sufficient" approach, using the lightweight AES-128 encryption algorithm. The key is pre-negotiated between the edge node and the cloud platform, with encryption time ≤0.5ms, meeting real-time transmission requirements while resisting common eavesdropping and tampering attacks. The transmission method employs a "resumable interruption" scheme. Edge nodes upload encrypted core features to the cloud via 5G or Ethernet. If transmission is interrupted, only the incomplete portion is uploaded upon reconnection, avoiding full retransmission. Authentication uses a "node key verification" scheme. Edge nodes carry a unique identifier and key when uploading data; the cloud platform only receives the data after successful verification, preventing malicious nodes from forging feature data. This step addresses the "privacy leakage and transmission interruption" issues in the new protocol's feature transmission.

[0083] In step S503, the cloud-based PDM management platform calls the federated learning model to update the protocol metadata layer of the PDM based on the uploaded core features and feature confidence levels, and performs cross-node consistency verification on features with confidence levels lower than a preset threshold.

[0084] Model training employs a federated learning approach. The cloud platform calls the federated learning model to aggregate encrypted features uploaded from multiple edge nodes (without aggregating raw sample data). The model is then used to train and generate metadata rules for the new protocol, avoiding privacy leaks caused by uploading raw data. Metadata updates utilize a feature mapping approach, mapping the newly generated protocol rules to the field structure and encoding rules of the PDM metadata layer, updating only the differing parts. Low-confidence verification employs a cross-node consistency approach, with a pre-set confidence threshold (e.g., 0.8). For features with confidence levels below the threshold (e.g., fields appearing only 85% of the time), verification requests are sent to other edge nodes. The frequency of this feature is counted across nodes; if the frequency is ≥90% across ≥3 nodes, the feature is retained; otherwise, it is discarded, ensuring the accuracy of the updated content. This step achieves "precise updates under privacy protection."

[0085] In step S504, the cloud distributes the updated PDM to each parsing device via differential update to complete the synchronization of the new protocol description rules.

[0086] The update method employs a "differential update" scheme. The cloud platform compares the PDM before and after the update, extracting only the changed metadata fragments (such as metadata for newly added protocols and modified rules), reducing data transmission volume by more than 90% compared to a full update, and shortening update time from minutes to seconds. The distribution method uses a "broadcast + confirmation" scheme. The cloud broadcasts the differential update packet to all parsing devices via 5G. Each device sends a confirmation message upon receiving the packet; unconfirmed devices retransmit individually. Synchronization verification uses a "rule verification" scheme. After loading the updated PDM, the parsing device calls test data (a preset sample of the new protocol) to perform a parsing test. If the parsing success rate is ≥98%, synchronization is successful; otherwise, a retransmission is requested from the cloud. This step achieves "efficient and consistent" synchronization of the new protocol rules.

[0087] Furthermore, the process of building a PDM also includes the following sub-steps:

[0088] A resource scheduling layer is added to the PDM. The resource scheduling layer is pre-configured with a Nash equilibrium model and data security level ranking rules, wherein the data security level ranking is emergency braking signal > navigation data > entertainment data.

[0089] This step involves building the PDM extension layer. The core of the solution is "adding a new layer + dual-rule configuration," addressing the resource allocation issue in concurrent parsing of multiple protocols. The layer addition adopts a "modular integration" approach, adding a resource scheduling layer to the existing three layers of PDM. This modular design allows for independent upgrades or modifications without affecting other layer functionalities. The Nash equilibrium model configuration uses a "scenario adaptation" approach. The model inputs are the resource requirements (channel bandwidth, computing resources) and data priorities of each protocol, and the output is the optimal resource allocation ratio. Game theory algorithms ensure the overall optimal solution during multi-protocol resource competition, preventing a single protocol from monopolizing excessive resources. The security level ranking adopts a "demand-oriented" approach, ranking the security importance of vehicle network data based on: emergency braking signals directly correlate with driving safety (highest level), navigation data affects driving paths (medium level), and entertainment data does not affect safety (lowest level). Predefined ranking rules are stored in the scheduling layer. This step provides "algorithm support + rule basis" for subsequent resource scheduling.

[0090] During parsing, the method further includes a resource scheduling sub-step:

[0091] When receiving multi-source data and detecting concurrent parsing of multi-protocol data, the Nash equilibrium model of the resource scheduling layer is invoked to allocate channel occupancy rights according to the preset data security level sorting rules. If the parsing delay of high-priority data exceeds the preset delay, the dynamic resource reallocation mechanism is triggered to preempt some channel resources of low-priority data to ensure that the parsing delay of high-priority data meets the requirements.

[0092] This step is the resource scheduling execution phase. The core of the solution is "pre-allocation + dynamic adjustment" to ensure the real-time performance of high-priority data. Concurrency detection uses a "data identification statistics" scheme, where the parsing device counts the number of data frames from different protocols received simultaneously in real time. When ≥2 types of protocol data exist simultaneously, it is determined to be a concurrent parsing scenario. Initial allocation uses a "model + rule collaboration" scheme, calling the Nash equilibrium model of the resource scheduling layer and combining it with security level sorting rules to allocate channel occupancy rights to each protocol (e.g., 40% bandwidth for emergency braking signals, 20% for navigation, 10% for entertainment, with the remaining 30% dynamically reserved). Dynamic reallocation uses a "latency triggering" scheme, monitoring the parsing latency of high-priority data in real time. If it exceeds a preset latency (e.g., 50ms), a reallocation mechanism is triggered, preempting some resources from the channel resources of low-priority data (e.g., preempting 10% bandwidth from entertainment data) until the high-priority data latency meets the standard. The recovery mechanism uses a "latency fallback release" scheme; when the high-priority data latency falls back below a preset value, the preempted resources are released and returned to the low-priority data. This step resolves the issue of excessive latency for high-priority data caused by existing "equal allocation" or "first-come, first-served" methods.

[0093] In some embodiments, see Figure 6 ,Figure 6 This is a flowchart illustrating steps S601-S604 provided in the embodiments of this application, as follows: Figure 6 As shown, the specific process of completing protocol identification includes steps S601-S604, which will be explained in conjunction with each step.

[0094] In step S601, the header protocol identifier field of the data frame to be parsed is read, and a first-level preliminary matching is performed based on this field.

[0095] The header field reading adopts a "fixed-position extraction" scheme, predefining the position and length of the header identifiers for each protocol (e.g., bytes 1-3 of the CAN protocol header are the identifiers, and bytes 1-4 of the 5G-V2X header are the identifiers). The parsing engine directly locates this position to extract the identifier field, avoiding full-frame retrieval. The initial matching uses an "identifier library comparison" scheme. The PDM metadata layer pre-stores the header identifier library for each protocol (e.g., CAN identifiers are 0x01-0x0F, and 5G-V2X identifiers are 0x7E-0x8F). The extracted identifiers are quickly compared with the identifiers in the library, filtering out 1-3 matching candidate protocols and eliminating most non-matching protocols. Matching time control uses a "hash index" scheme. A hash index is built into the identifier library, ensuring a matching time of ≤0.1ms, saving time for subsequent fine-grained matching. This step achieves "rapid filtering and narrowing down the scope" for protocol identification.

[0096] In step S602, the feature vector library of the PDM metadata layer is called to calculate the similarity between the data to be parsed and the protocol features in the feature vector library.

[0097] The feature vector library retrieval adopts a "candidate protocol association" scheme. Based on the candidate protocols selected in step S2a, only the feature vectors of the corresponding protocols are called (e.g., if the candidates are CAN and 5G-V2X, only the vectors of these two are called), avoiding the time-consuming process of calling the entire library. The feature dimensions adopt a "full protocol attribute coverage" scheme. Each protocol's feature vector includes 10+ dimensions such as the number of fields, the length of each field, the position of key fields, encoding rules, and checksum algorithms, ensuring the uniqueness of the features. Similarity calculation uses a "cosine similarity algorithm," which calculates the similarity between the feature vector of the data to be parsed and the standard vector of the candidate protocols. The similarity range is 0-1, with a value closer to 1 indicating a higher matching degree. This step, through multi-dimensional verification, solves the problem of single-identity matching being easily tampered with and deceived.

[0098] In step S603, if the similarity is greater than or equal to the preset similarity, the protocol type is determined based on the matching result.

[0099] The threshold setting adopts a "scenario adaptation" scheme, with a preset similarity (e.g., 0.95) as the judgment threshold. For high-precision scenarios (such as autonomous driving data parsing), this can be increased to 0.98, while for ordinary scenarios it can be reduced to 0.92. The threshold can be modified through the PDM extension interface. The type determination adopts a "highest similarity locking" scheme. If the similarity of multiple candidate protocols is ≥ the threshold, the protocol with the highest similarity is selected as the final type; if only one candidate protocol meets the threshold, it is directly determined as that type. The result storage adopts a "protocol type identifier binding" scheme, binding the determined protocol type identifier (e.g., 0x01 for CAN) to the data frame for easy subsequent parsing and calling of the corresponding rules. This step achieves "precise locking" of protocol identification.

[0100] In step S604, if the similarity is less than the preset similarity, the fuzzy matching mode is activated, and a manual intervention verification prompt message is generated.

[0101] Fuzzy matching employs a "feature weight matching" scheme. For the candidate protocol with the highest similarity, the weights of each feature are adjusted (e.g., the header identifier weight is increased to 0.5, and other features are weighted at 0.5), and the weighted similarity is recalculated. If the similarity is ≥0.9, it is temporarily identified as the protocol and marked as a "fuzzy matching result." Manual intervention prompts use a "multi-level alarm" scheme. The communication module of the parsing device sends a prompt message to the maintenance terminal, including data frame features, candidate protocols, and similarity values, while also recording it in the local log. If no manual confirmation is received within 10 minutes, a level-two alarm is sent. Result processing uses a "temporary parsing + marking" scheme. The fuzzy matching result is temporarily stored and marked "pending confirmation." It is officially output after manual confirmation; otherwise, the recognition process is re-executed. This step solves the recognition challenges of extreme scenarios such as unknown protocol fragments and mutated protocols.

[0102] The embodiments of this application will now be described in further detail with reference to specific examples.

[0103] In this embodiment, the parsing device adopts an embedded processor architecture, integrating a memory, a communication module, and a data processing module. The memory is used to store the PDM and dynamic parsing engine, the communication module supports multi-protocol data reception for vehicle networking, and the data processing module is used to perform parsing and algorithm calculations.

[0104] A method for dynamic parsing of multiple protocols in vehicle-to-everything (V2X) networks based on Protocol Description Model (PDM) is described below:

[0105] S1: Constructing a multi-level protocol description model (PDM):

[0106] Protocol metadata layer: Predefines the field structure (such as ID field and data length field of CAN protocol), data type (integer, floating point) and encoding rules (such as ASCII encoding, binary encoding) of mainstream vehicle networking protocols such as CAN, 5G-V2X, and Ethernet / IP, and builds a feature vector library for each protocol. The feature vectors include field length, key field position, etc.

[0107] Dynamic Adaptation Layer: First, S11 is executed to collect the vehicle's speed and heading angle data for 10 consecutive timestamps (100ms time interval), as well as the corresponding communication link signal-to-noise ratio and packet loss rate data for those timestamps; then, S12 is executed to process the vehicle data using a Kalman filter algorithm to predict the position information at the next moment and calculate the position prediction deviation value. The deviation value is adaptively corrected by combining the link signal-to-noise ratio and packet loss rate (e.g., increasing the correction coefficient when the packet loss rate increases), resulting in the corrected correlation factor; finally, S13 is executed to embed the correlation factor into the dynamic adaptation layer.

[0108] Security verification layer: integrates SHA-256 hash verification rules and protocol field validity verification rules (such as CAN protocol ID field range verification and data length field matching verification);

[0109] Resource scheduling layer (S10): Pre-configured Nash equilibrium model and data security level ranking rules (emergency braking signal > navigation data > entertainment data), stored in PDM.

[0110] S2: Based on PDM to generate dynamic parsing engine:

[0111] The dynamic parsing engine is generated by the parsing device's compiler and integrates protocol identification, parameter adjustment, and result standardization functions.

[0112] Protocol identification (sub-steps S2a-S2d): S2a reads the protocol identifier field in the header of the data frame to be parsed, such as 0x7E for the 5G-V2X protocol and 0x01 for the CAN protocol, and performs preliminary matching based on this field; S2b calls the metadata layer feature vector library to calculate the cosine similarity between the field length and key field position of the data to be parsed and the features in the library; S2c if the similarity is ≥95% (preset similarity), the protocol type is determined; S2d if the similarity is <95%, fuzzy matching is initiated (rule adaptation is performed based on the top 3 protocols with the highest field similarity), and a manual intervention prompt is sent through the communication module.

[0113] Parameter adjustment (sub-steps S21-S22): S21: The vehicle speed and network topology change frequency are obtained in real time through the communication module; S22: If the vehicle speed is >60km / h (preset speed) or the topology change frequency is >3 times / second (preset frequency), the parsing window is reduced to 60% of the original size (first preset ratio), and two parallel parsing threads are started; if the vehicle is stationary or in low-speed formation (speed ≤30km / h), the parsing window is expanded to 1.5 times the original size (second preset ratio).

[0114] S3: Multi-source data parsing and processing:

[0115] After receiving multi-source data uploaded by the vehicle terminal (such as ECU, navigation device, entertainment terminal), the communication module calls the dynamic parsing engine and the corresponding PDM rules to perform preliminary parsing;

[0116] Security Verification (S31-S33): S31 extracts the header fields and payload data, and generates a joint hash value using the SHA-256 algorithm; S32 retrieves the baseline hash value pre-stored in the security verification layer for comparison and calculates the deviation rate; S33 if the deviation rate is ≤0.01% (preset deviation rate), the verification is deemed successful; otherwise, a data retransmission mechanism is triggered, and an exception log (including timestamp, protocol type, and deviation rate) is recorded.

[0117] Resource scheduling (S30): If concurrent parsing of multiple protocol data is detected (such as simultaneous access of braking signal and entertainment data), the Nash equilibrium model of the resource scheduling layer is invoked to allocate channel occupancy rights according to the security level; if the braking signal parsing delay is detected to exceed 50ms (preset delay), 20% of the channel resources of entertainment data are preempted to ensure that the braking signal delay is ≤50ms.

[0118] Finally, the parsing results are standardized (converted to JSON format) and output to the vehicle network control center via the communication module.

[0119] S4: New Protocol Update:

[0120] When a new protocol (such as a new V2I ​​protocol) is detected, the edge nodes (roadside units) collect sample data of the new protocol. After performing S41 deduplication (removing duplicate frames) and noise reduction (filtering data with a signal-to-noise ratio <20dB) preprocessing, the core features of the protocol (such as header identifier 0x8F and data length 16 bytes) are extracted and the feature confidence level (e.g., 0.92) is marked. In S42, the core features are encrypted using the AES lightweight encryption algorithm and then uploaded to the cloud PDM management platform. In S43, the cloud calls the federated learning model to train the model and update the PDM metadata layer based on the features uploaded by multiple edge nodes. Features with a confidence level <0.8 (preset threshold) are verified for consistency by more than 3 edge nodes. In S44, the cloud distributes the updated PDM to each parsing device through differential update (only distributing changed metadata fragments). The parsing device loads the updated description rules and can realize the parsing of the new protocol without rebuilding the engine.

[0121] In summary, the embodiments of this application have the following beneficial effects:

[0122] (1) Significantly improved parsing flexibility: By constructing a multi-level PDM and generating a dynamic parsing engine, when adding or updating protocols, it is only necessary to update the PDM metadata through the extension interface, without having to reconstruct the engine. This solves the pain point of "reconstruction is required when adding a protocol" in the traditional solution, and improves the adaptation efficiency by more than 60%.

[0123] (2) Enhanced dynamic adaptation capability: The dynamic adaptation layer integrates vehicle movement status and communication link quality parameters, corrects correlation factors through Kalman filtering, and combines parameter dynamic adjustment strategy to enable the parsing window to adapt to changes in vehicle status. The parsing accuracy is improved by 30% when moving at high speed and the data throughput is improved by 40% when moving at low speed.

[0124] (3) Enhanced security and reliability: The security verification layer provides dual protection through hash integrity verification and field validity verification, increasing the abnormal data identification rate to 99%; the resource scheduling layer optimizes resource allocation through the Nash equilibrium model, increasing the high-priority data parsing latency compliance rate to 99.5%;

[0125] (4) Balancing update efficiency and privacy protection: The edge-cloud collaborative update mechanism combines federated learning and differential update, improving the synchronization efficiency of the new protocol by 50% while avoiding the risk of privacy leakage caused by direct upload of sample data.

[0126] Based on the same inventive concept, this application also provides a device for dynamic parsing of multiple protocols in the Internet of Vehicles based on a protocol description model, which corresponds to the method for dynamic parsing of multiple protocols in the Internet of Vehicles based on a protocol description model in the first embodiment. Since the principle of the device in this application is similar to the above-mentioned method for dynamic parsing of multiple protocols in the Internet of Vehicles based on a protocol description model, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0127] like Figure 7 As shown, Figure 7 This is a schematic diagram of the structure of the vehicle-to-everything (V2X) multi-protocol dynamic parsing device 700 based on a protocol description model provided in this application embodiment. The V2X multi-protocol dynamic parsing device 700 based on a protocol description model includes:

[0128] Module 701 is used to construct a multi-level protocol description model (PDM). The PDM includes a protocol metadata layer, a dynamic adaptation layer, and a security verification layer. The protocol metadata layer predefines the field structure, data type, and encoding rules of mainstream vehicle networking protocols. The dynamic adaptation layer embeds vehicle movement state correlation factors and communication link quality parameters. The security verification layer integrates hash verification rules and protocol field validity verification rules.

[0129] The generation module 702 is used to generate a dynamic parsing engine based on the constructed PDM. The dynamic parsing engine integrates protocol identification, parameter adjustment and result standardization functions. It matches the protocol type of the data to be parsed with the metadata features of the PDM to complete the protocol identification. It dynamically optimizes the parsing window size according to the real-time speed, acceleration and network topology changes of the vehicle to achieve parameter adjustment. After the data parsing and verification are completed, the parsing results are processed for format standardization and output data in a unified format.

[0130] The output module 703 is used to receive multi-source data uploaded by the vehicle network terminal, call the generated dynamic parsing engine and the protocol description rules corresponding to PDM for preliminary parsing, and at the same time verify the data integrity through the preset hash algorithm of the PDM security verification layer. After the verification is passed, the result is standardized and the parsed data in a unified format is output.

[0131] The update module 704 is used to detect the access of new protocols or the update of existing protocol versions. First, it matches the differences between the updated content and the existing metadata through the protocol feature fingerprint library of PDM. Then, it updates the protocol metadata layer difference information in a targeted manner through the extended interface of PDM. After the update is completed, it directly loads the updated description rules to achieve new protocol parsing without reconstructing the dynamic parsing engine.

[0132] Those skilled in the art should understand that Figure 7 The implementation functions of each unit in the vehicle-to-everything (V2X) multi-protocol dynamic parsing device 700 based on the protocol description model shown can be understood by referring to the relevant description of the aforementioned V2X multi-protocol dynamic parsing method based on the protocol description model. Figure 7 The functions of each unit in the vehicle-to-everything (V2X) multi-protocol dynamic parsing device 700 based on the protocol description model shown can be implemented by a program running on a processor or by specific logic circuits.

[0133] In one possible implementation, the specific process of constructing the dynamic adaptation layer includes the following sub-steps:

[0134] Collect vehicle speed and heading angle data for a preset number of consecutive timestamps, as well as communication link signal-to-noise ratio and packet loss rate data for the corresponding timestamps;

[0135] The collected vehicle data is processed by the Kalman filter algorithm to predict the vehicle's position information at the next moment and calculate the position prediction deviation. At the same time, the position prediction deviation is adaptively corrected by combining communication link data to obtain the corrected correlation factor.

[0136] The calculated position prediction deviation value is used as a vehicle movement state correlation factor and embedded into the dynamic adaptation layer of PDM as a basis for adjusting the parsing parameters.

[0137] In one possible implementation, the specific process of parameter adjustment includes the following sub-steps:

[0138] Real-time acquisition of vehicle speed and the frequency of network topology changes in the vehicle network;

[0139] If a vehicle's speed is detected to be greater than a preset speed or the network topology change frequency is greater than a preset frequency, the parsing window size will be automatically reduced to a first preset ratio of the original size, and a parallel parsing thread will be started. If a vehicle is detected to be stationary or traveling in a low-speed platoon, the parsing window will be expanded to a second preset ratio of the original size to improve data throughput.

[0140] In one possible implementation, the security verification process includes the following sub-steps:

[0141] Extract the header fields and payload data of the data to be parsed, and generate a joint hash value based on a preset hash algorithm;

[0142] Retrieve the pre-stored corresponding protocol baseline hash value from the PDM security verification layer, compare the generated joint hash value with the baseline hash value, and calculate the deviation rate;

[0143] If the deviation rate is less than or equal to the preset deviation rate, the verification is deemed successful and subsequent result standardization processing is performed; if the deviation rate is greater than the preset deviation rate, the data retransmission mechanism is triggered and a data anomaly log is recorded.

[0144] In one possible implementation, the new protocol update process includes the following sub-steps:

[0145] Edge nodes collect sample data of the new protocol. After deduplication and noise reduction preprocessing of the sample data, the core features of the protocol are extracted and the feature confidence is labeled.

[0146] The edge nodes encrypt the extracted core features using a lightweight encryption algorithm and then upload them to the cloud-based PDM management platform.

[0147] The cloud-based PDM management platform calls the federated learning model to update the protocol metadata layer of the PDM based on the uploaded core features and feature confidence levels, and performs cross-node consistency verification on features with confidence levels below a preset threshold.

[0148] The cloud will distribute the updated PDM to each parsing device via differential update to complete the synchronization of the new protocol description rules.

[0149] In one possible implementation, the process of constructing a PDM further includes:

[0150] A resource scheduling layer is added to the PDM. The resource scheduling layer is pre-configured with a Nash equilibrium model and data security level ranking rules, wherein the data security level ranking is emergency braking signal > navigation data > entertainment data.

[0151] During parsing, the method further includes a resource scheduling sub-step:

[0152] When receiving multi-source data and detecting concurrent parsing of multi-protocol data, the Nash equilibrium model of the resource scheduling layer is invoked to allocate channel occupancy rights according to the preset data security level sorting rules. If the parsing delay of high-priority data exceeds the preset delay, the dynamic resource reallocation mechanism is triggered to preempt some channel resources of low-priority data to ensure that the parsing delay of high-priority data meets the requirements.

[0153] In one possible implementation, the specific process of completing protocol identification includes the following sub-steps:

[0154] Read the protocol identifier field in the header of the data frame to be parsed, and perform a first-level preliminary match based on this field;

[0155] The feature vector library of the PDM metadata layer is called to calculate the similarity between the data to be parsed and the protocol features in the feature vector library;

[0156] If the similarity is greater than or equal to the preset similarity, the protocol type is determined based on the matching results;

[0157] If the similarity is less than the preset similarity, then fuzzy matching mode will be activated, and a manual verification prompt message will be generated.

[0158] The aforementioned vehicle-to-everything (V2X) multi-protocol dynamic parsing device based on the protocol description model has the following beneficial effects:

[0159] (1) Significantly improved parsing flexibility: By constructing a multi-level PDM and generating a dynamic parsing engine, when adding or updating protocols, it is only necessary to update the PDM metadata through the extension interface, without having to reconstruct the engine. This solves the pain point of "reconstruction is required when adding a protocol" in the traditional solution, and improves the adaptation efficiency by more than 60%.

[0160] (2) Enhanced dynamic adaptation capability: The dynamic adaptation layer integrates vehicle movement status and communication link quality parameters, corrects correlation factors through Kalman filtering, and combines parameter dynamic adjustment strategy to enable the parsing window to adapt to changes in vehicle status. The parsing accuracy is improved by 30% when moving at high speed and the data throughput is improved by 40% when moving at low speed.

[0161] (3) Enhanced security and reliability: The security verification layer provides dual protection through hash integrity verification and field validity verification, increasing the abnormal data identification rate to 99%; the resource scheduling layer optimizes resource allocation through the Nash equilibrium model, increasing the high-priority data parsing latency compliance rate to 99.5%;

[0162] (4) Balancing update efficiency and privacy protection: The edge-cloud collaborative update mechanism combines federated learning and differential update, improving the synchronization efficiency of the new protocol by 50% while avoiding the risk of privacy leakage caused by direct upload of sample data.

[0163] like Figure 8 As shown, Figure 8 This is a schematic diagram of the composition structure of the electronic device 800 provided in the embodiments of this application. The electronic device 800 includes:

[0164] The device includes a processor 801, a storage medium 802, and a bus 803. The storage medium 802 stores machine-readable instructions that can be executed by the processor 801. When the electronic device 800 is running, the processor 801 communicates with the storage medium 802 via the bus 803. The processor 801 executes the machine-readable instructions to perform the steps of the vehicle-to-everything (V2X) multi-protocol dynamic parsing method based on the protocol description model described in this application embodiment.

[0165] In practical applications, the various components in the electronic device 800 are coupled together via bus 803. It can be understood that bus 803 is used to achieve communication between these components. In addition to a data bus, bus 803 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 8 The general labeled all buses as Bus 803.

[0166] The above-mentioned electronic devices have the following beneficial effects:

[0167] (1) Significantly improved parsing flexibility: By constructing a multi-level PDM and generating a dynamic parsing engine, when adding or updating protocols, it is only necessary to update the PDM metadata through the extension interface, without having to reconstruct the engine. This solves the pain point of "reconstruction is required when adding a protocol" in the traditional solution, and improves the adaptation efficiency by more than 60%.

[0168] (2) Enhanced dynamic adaptation capability: The dynamic adaptation layer integrates vehicle movement status and communication link quality parameters, corrects correlation factors through Kalman filtering, and combines parameter dynamic adjustment strategy to enable the parsing window to adapt to changes in vehicle status. The parsing accuracy is improved by 30% when moving at high speed and the data throughput is improved by 40% when moving at low speed.

[0169] (3) Enhanced security and reliability: The security verification layer provides dual protection through hash integrity verification and field validity verification, increasing the abnormal data identification rate to 99%; the resource scheduling layer optimizes resource allocation through the Nash equilibrium model, increasing the high-priority data parsing latency compliance rate to 99.5%;

[0170] (4) Balancing update efficiency and privacy protection: The edge-cloud collaborative update mechanism combines federated learning and differential update, improving the synchronization efficiency of the new protocol by 50% while avoiding the risk of privacy leakage caused by direct upload of sample data.

[0171] This application also provides a computer-readable storage medium storing executable instructions. When the executable instructions are executed by at least one processor 801, the method for dynamic parsing of multiple protocols in vehicle networking based on the protocol description model described in this application is implemented.

[0172] In some embodiments, the storage medium may be a magnetic random access memory (FRAM), a read-only memory (ROM), or a programmable read-only memory (PROM). Erasable Programmable Read-Only Memory (EPROM) Electrically Erasable Programmable Read-Only Memory (EEPROM) Read-only memory, flash memory, magnetic surface storage, optical disc, or CD-ROM ROM, Compact Disc Read It can be a memory such as a memory only; or it can be a device that includes one or any combination of the above-mentioned memories.

[0173] In some embodiments, executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0174] As an example, executable instructions may, but do not necessarily, correspond to files in the file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple collaborating files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0175] As an example, executable instructions can be deployed to execute on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.

[0176] The aforementioned computer-readable storage media have the following beneficial effects:

[0177] (1) Significantly improved parsing flexibility: By constructing a multi-level PDM and generating a dynamic parsing engine, when adding or updating protocols, it is only necessary to update the PDM metadata through the extension interface, without having to reconstruct the engine. This solves the pain point of "reconstruction is required when adding a protocol" in the traditional solution, and improves the adaptation efficiency by more than 60%.

[0178] (2) Enhanced dynamic adaptation capability: The dynamic adaptation layer integrates vehicle movement status and communication link quality parameters, corrects correlation factors through Kalman filtering, and combines parameter dynamic adjustment strategy to enable the parsing window to adapt to changes in vehicle status. The parsing accuracy is improved by 30% when moving at high speed and the data throughput is improved by 40% when moving at low speed.

[0179] (3) Enhanced security and reliability: The security verification layer provides dual protection through hash integrity verification and field validity verification, increasing the abnormal data identification rate to 99%; the resource scheduling layer optimizes resource allocation through the Nash equilibrium model, increasing the high-priority data parsing latency compliance rate to 99.5%;

[0180] (4) Balancing update efficiency and privacy protection: The edge-cloud collaborative update mechanism combines federated learning and differential update, improving the synchronization efficiency of the new protocol by 50% while avoiding the risk of privacy leakage caused by direct upload of sample data.

[0181] In the several embodiments provided in this application, it should be understood that the disclosed methods and electronic devices can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components may be combined, or integrated into another system, or some features may be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed may be through some interfaces, and the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0182] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0183] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0184] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, 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, a platform server, or a 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, ROM, RAM, magnetic disks, or optical disks.

[0185] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for dynamic parsing of multiple protocols in vehicle networking based on a protocol description model, applied to parsing devices, characterized in that, Includes the following steps: A multi-level protocol description model (PDM) is constructed, which includes a protocol metadata layer, a dynamic adaptation layer, and a security verification layer. The protocol metadata layer predefines the field structure, data type, and encoding rules of mainstream vehicle networking protocols. The dynamic adaptation layer embeds vehicle movement state correlation factors and communication link quality parameters. The security verification layer integrates hash verification rules and protocol field validity verification rules. Based on the constructed PDM dynamic parsing engine, the dynamic parsing engine integrates protocol identification, parameter adjustment and result standardization functions. It matches the protocol type of the data to be parsed with the metadata features of the PDM to complete the protocol identification. It dynamically optimizes the parsing window size according to the real-time speed, acceleration and network topology changes of the vehicle to achieve parameter adjustment. After the data parsing and verification are completed, the parsing results are format-standardized and output data in a unified format. After receiving multi-source data uploaded by the vehicle network terminal, the generated dynamic parsing engine and the corresponding protocol description rules of PDM are called for preliminary parsing. At the same time, the data integrity is verified by the preset hash algorithm of the PDM security verification layer. After the verification is passed, the result is standardized and parsed data in a unified format is output. When a new protocol is detected or an existing protocol version is updated, the differences between the updated content and the existing metadata are first matched using the protocol feature fingerprint database of PDM. Then, the differences in the protocol metadata layer are updated in a targeted manner through the extended interface of PDM. After the update is completed, the updated description rules are loaded directly to achieve new protocol parsing without reconstructing the dynamic parsing engine. The security verification process includes the following sub-steps: Extract the header fields and payload data of the data to be parsed, and generate a joint hash value based on a preset hash algorithm; Retrieve the pre-stored corresponding protocol baseline hash value from the PDM security verification layer, compare the generated joint hash value with the baseline hash value, and calculate the deviation rate; If the deviation rate is less than or equal to the preset deviation rate, the verification is deemed successful and subsequent result standardization processing is performed; if the deviation rate is greater than the preset deviation rate, the data retransmission mechanism is triggered and a data anomaly log is recorded. The new protocol update process includes the following sub-steps: Edge nodes collect sample data of the new protocol. After deduplication and noise reduction preprocessing of the sample data, the core features of the protocol are extracted and the feature confidence is labeled. The edge nodes encrypt the extracted core features using a lightweight encryption algorithm and then upload them to the cloud-based PDM management platform. The cloud-based PDM management platform calls the federated learning model to update the protocol metadata layer of the PDM based on the uploaded core features and feature confidence levels, and performs cross-node consistency verification on features with confidence levels below a preset threshold. The cloud will distribute the updated PDM to each parsing device via differential update to complete the synchronization of the new protocol description rules.

2. The method according to claim 1, characterized in that, The specific process of building a dynamic adaptation layer includes the following sub-steps: Collect vehicle speed and heading angle data for a preset number of consecutive timestamps, as well as communication link signal-to-noise ratio and packet loss rate data for the corresponding timestamps; The collected vehicle data is processed by the Kalman filter algorithm to predict the vehicle's position information at the next moment and calculate the position prediction deviation. At the same time, the position prediction deviation is adaptively corrected by combining communication link data to obtain the corrected correlation factor. The calculated position prediction deviation value is used as a vehicle movement state correlation factor and embedded into the dynamic adaptation layer of PDM as a basis for adjusting the parsing parameters.

3. The method according to claim 1, characterized in that, The specific process of parameter adjustment includes the following sub-steps: Real-time acquisition of vehicle speed and the frequency of network topology changes in the vehicle network; If the vehicle speed is detected to be greater than the preset speed or the network topology change frequency is greater than the preset frequency, the parsing window size will be automatically reduced to the first preset ratio of the original size, and a parallel parsing thread will be started at the same time. If vehicles are detected to be stationary or traveling in low-speed platooning, the parsing window is expanded to a second preset scale of the original size to improve data throughput.

4. The method according to claim 1, characterized in that, The process of building a PDM also includes: A resource scheduling layer is added to the PDM. The resource scheduling layer is pre-configured with a Nash equilibrium model and data security level ranking rules, wherein the data security level ranking is emergency braking signal > navigation data > entertainment data. During parsing, the method further includes a resource scheduling sub-step: When receiving multi-source data and detecting concurrent parsing of multi-protocol data, the Nash equilibrium model of the resource scheduling layer is invoked to allocate channel occupancy rights according to the preset data security level sorting rules. If the parsing delay of high-priority data exceeds the preset delay, the dynamic resource reallocation mechanism is triggered to preempt some channel resources of low-priority data to ensure that the parsing delay of high-priority data meets the requirements.

5. The method according to claim 1, characterized in that, The specific process of completing protocol identification includes the following sub-steps: Read the protocol identifier field in the header of the data frame to be parsed, and perform a first-level preliminary match based on this field; The feature vector library of the PDM metadata layer is called to calculate the similarity between the data to be parsed and the protocol features in the feature vector library; If the similarity is greater than or equal to the preset similarity, the protocol type is determined based on the matching results; If the similarity is less than the preset similarity, then fuzzy matching mode will be activated, and a manual verification prompt message will be generated.

6. A vehicle-to-everything (V2X) multi-protocol dynamic parsing device based on a protocol description model, characterized in that, The device includes: The construction module is used to build a multi-level protocol description model (PDM). The PDM includes a protocol metadata layer, a dynamic adaptation layer, and a security verification layer. The protocol metadata layer predefines the field structure, data type, and encoding rules of mainstream vehicle networking protocols. The dynamic adaptation layer embeds vehicle movement state correlation factors and communication link quality parameters. The security verification layer integrates hash verification rules and protocol field validity verification rules. The generation module is used to generate a dynamic parsing engine based on the constructed PDM. The dynamic parsing engine integrates protocol identification, parameter adjustment and result standardization functions. It matches the protocol type of the data to be parsed with the metadata features of the PDM to complete the protocol identification. It dynamically optimizes the parsing window size according to the real-time speed, acceleration and network topology changes of the vehicle to achieve parameter adjustment. After the data parsing and verification are completed, the parsing results are processed for format standardization and output data in a unified format. The output module receives multi-source data uploaded by the vehicle network terminal, calls the generated dynamic parsing engine and the protocol description rules corresponding to PDM for preliminary parsing, and verifies the data integrity through the preset hash algorithm of the PDM security verification layer. After the verification is passed, the results are standardized and parsed data in a unified format is output. The update module is used to detect the access of new protocols or the update of existing protocol versions. First, it matches the differences between the updated content and the existing metadata through the protocol feature fingerprint library of PDM. Then, it updates the difference information of the protocol metadata layer in a targeted manner through the extended interface of PDM. After the update is completed, it directly loads the updated description rules to achieve new protocol parsing without reconstructing the dynamic parsing engine. The security verification process includes the following sub-steps: Extract the header fields and payload data of the data to be parsed, and generate a joint hash value based on a preset hash algorithm; Retrieve the pre-stored corresponding protocol baseline hash value from the PDM security verification layer, compare the generated joint hash value with the baseline hash value, and calculate the deviation rate; If the deviation rate is less than or equal to the preset deviation rate, the verification is deemed successful and subsequent result standardization processing is performed; if the deviation rate is greater than the preset deviation rate, the data retransmission mechanism is triggered and a data anomaly log is recorded. The new protocol update process includes the following sub-steps: Edge nodes collect sample data of the new protocol. After deduplication and noise reduction preprocessing of the sample data, the core features of the protocol are extracted and the feature confidence is labeled. The edge nodes encrypt the extracted core features using a lightweight encryption algorithm and then upload them to the cloud-based PDM management platform. The cloud-based PDM management platform calls the federated learning model to update the protocol metadata layer of the PDM based on the uploaded core features and feature confidence levels, and performs cross-node consistency verification on features with confidence levels below a preset threshold. The cloud will distribute the updated PDM to each parsing device via differential update to complete the synchronization of the new protocol description rules.

7. An electronic device, characterized in that, include: The device includes a processor, a storage medium, and a bus. The storage medium stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the vehicle-to-everything (V2X) multi-protocol dynamic parsing method based on a protocol description model as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which is executed by a processor to perform the vehicle-to-everything (V2X) multi-protocol dynamic parsing method based on a protocol description model as described in any one of claims 1 to 5.

Images