Internet of vehicles multi-protocol dynamic analysis method based on protocol description model

Abstract

The invention provides an Internet of Vehicles multi-protocol dynamic analysis method based on a protocol description model. The Internet of Vehicles multi-protocol dynamic analysis method comprises the following steps: constructing a multi-level PDM comprising a protocol metadata layer, a dynamic adaptation layer, a security verification layer and a resource scheduling layer; generating a dynamic analysis engine integrating protocol identification, parameter adjustment and result standardization functions based on PDM; after receiving multi-source data, calling an engine to analyze, distributing resources by combining a resource scheduling layer through PDM safety verification, and outputting standardized analysis data; when protocol updating is detected, PDM is updated through edge-cloud collaboration, and a new protocol can be adapted without reconstructing an engine. According to the invention, the analysis flexibility and precision are improved through the PDM dynamic adaptation to the Internet of Vehicles scene; double security check and Nash equilibrium resource scheduling guarantee security and real-time performance; edge-cloud collaborative updating gives consideration to efficiency and privacy, and is suitable for a multi-protocol dynamic analysis scene of the Internet of Vehicles.

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 speed and insufficient data throughput at low speed. 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] The protocol description model (PDM) is mostly used in existing technologies for metadata description of static protocols and is not adapted and designed in combination with the dynamic scenario characteristics of Internet of Vehicles, and lacks fusion with technologies such as edge computing and federated learning, which cannot achieve efficient updating and multi-terminal synchronization of protocol description rules and cannot meet the needs of Internet of Vehicles multi-protocol dynamic analysis. 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 guarantee 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 Internet of Vehicles multi-protocol dynamic analysis scenarios.

[0006] The technical solution of the embodiments of the present application is as follows: 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: 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 field structures, data types and coding rules of mainstream protocols of the Internet of Vehicles, the dynamic adaptation layer embeds vehicle moving state correlation factors and communication link quality parameters, and the security check layer integrates hash check rules and protocol field legality check rules. A dynamic analysis engine is generated based on the constructed PDM, the dynamic analysis engine integrating protocol identification, parameter adjustment and result standardization functions, protocol types of to-be-analyzed data are matched with metadata features of the PDM to complete protocol identification, and the size of an analysis window is dynamically optimized according to real-time speed, acceleration of a vehicle and network topology changes to realize parameter adjustment, and after data analysis and check are completed, the analysis result is subjected to format standardization processing and uniform format data is output. After receiving multi-source data uploaded by an Internet of Vehicles terminal, the generated dynamic analysis engine and corresponding protocol description rules of the PDM are called to perform preliminary analysis, and data integrity is checked by a preset hash algorithm of the security check layer of the PDM, after the check is passed, result standardization processing is performed and uniform format analysis data is output. When a new protocol is accessed or an existing protocol version is updated, first, the difference between update content and existing metadata is matched through a protocol feature fingerprint library of the PDM, then, protocol metadata layer difference information is updated through an extension interface of the PDM, and after the update is completed, the updated description rules are directly loaded to realize new protocol analysis without reconstructing the dynamic analysis engine.

[0007] In a second aspect, the embodiments of the present application further provide a multi-protocol dynamic analysis device for the Internet of Vehicles based on a protocol description model, the device comprising: 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 field structures, data types and coding rules of mainstream protocols of the Internet of Vehicles, the dynamic adaptation layer embeds vehicle moving state correlation factors and communication link quality parameters, and the security check layer integrates hash check rules and protocol field legality check rules. A generation module is configured to generate a dynamic analysis engine based on the constructed PDM, the dynamic analysis engine integrating protocol identification, parameter adjustment and result standardization functions, protocol types of to-be-analyzed data are matched with metadata features of the PDM to complete protocol identification, and the size of an analysis window is dynamically optimized according to real-time speed, acceleration of a vehicle and network topology changes to realize parameter adjustment, and after data analysis and check are completed, the analysis result is subjected to format standardization processing and uniform format data is output. The output module is configured to receive multi-source data uploaded by the Internet of Vehicles terminal, call a generated dynamic analysis engine and a protocol description rule corresponding to the PDM to perform preliminary analysis, check data integrity through a preset hash algorithm of a PDM security check layer, perform standardization processing on a result after the checking passes, and output parsed data in a uniform format. The updating module is configured to, when detecting that a new protocol is accessed or an existing protocol version is updated, match differences between the update content and existing metadata through a protocol feature fingerprint library of the PDM, update protocol metadata layer difference information through an extension interface of the PDM, and directly load the updated description rule after the updating to implement new protocol analysis without reconstructing the dynamic analysis engine.

[0008] In a third aspect, an electronic device is provided, including 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 through the bus. The processor executes the machine-readable instructions to perform the protocol description model-based dynamic analysis method for multiple protocols of the Internet of Vehicles.

[0009] In a fourth aspect, a computer-readable storage medium is provided. The computer-readable storage medium stores a computer program. When the computer program is run by a processor, the protocol description model-based dynamic analysis method for multiple protocols of the Internet of Vehicles is executed.

[0010] The embodiments of the present application have the following beneficial effects: (1) The analysis flexibility is significantly improved. By constructing a multi-level PDM and generating a dynamic analysis engine, only the PDM metadata needs to be updated through an extension interface when a new protocol is added or an existing protocol is updated, without the need to reconstruct the engine. This solves the pain point of the traditional scheme of "reconstruction of a new protocol", and the adaptation efficiency is improved by more than 60%. (2) The dynamic adaptation capability is strengthened. The dynamic adaptation layer fuses vehicle moving state and communication link quality parameters, corrects the correlation factor through Kalman filtering, and dynamically adjusts the parameters according to the strategy, so that the analysis window can adapt to the change of the vehicle state. The analysis accuracy is improved by 30% when moving at high speed, and the data throughput is improved by 40% when moving at low speed. (3) The safety and reliability are improved. The security check layer realizes hash integrity check and field legality check, and the abnormal data recognition rate is improved to 99%. The resource scheduling layer optimizes resource allocation through the Nash equilibrium model, and the high-priority data analysis delay standard rate is improved to 99.5%. (4) The updating efficiency and privacy protection are considered. The edge-cloud collaborative updating mechanism combines federated learning and differential updating, and the new protocol synchronization efficiency is improved by 50%. At the same time, the risk of privacy leakage caused by direct uploading of sample data is avoided. Attached Figure Description

[0011] 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.

[0012] Figure 1 This is a flowchart illustrating steps S101-S104 provided in the embodiments of this application; Figure 2 This is a flowchart illustrating steps S201-S203 provided in the embodiments of this application; Figure 3 This is a flowchart illustrating steps S301-S302 provided in the embodiments of this application; Figure 4 This is a flowchart illustrating steps S401-S403 provided in the embodiments of this application; Figure 5 This is a flowchart illustrating steps S501-S504 provided in the embodiments of this application; Figure 6 This is a flowchart illustrating steps S601-S604 provided in the embodiments of this application; 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; Figure 8 This is a schematic diagram of the composition structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0013] 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.

[0014] In the following description, reference is made to "some embodiments", which describe a subset of all possible embodiments, but it is understood that "some embodiments" can be the same subset or a different subset of all possible embodiments, and can be combined with each other, without conflict.

[0015] In addition, the described embodiments are only some of the embodiments of the present application, not all the embodiments. The components of the embodiments of the present application described and shown in the drawings herein can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the claimed application, but only represents selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0016] In the following description, the term "first\second\third" is only to distinguish similar objects, not to represent the specific order of the objects. It is understood that "first\second\third" can be interchanged with specific order or sequence as allowed, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

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

[0018] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which the present application belongs. The terms used herein are for the purpose of describing the embodiments of the present application, not to limit the present application.

[0019] Referring to Figure 1 , Figure 1 is a flowchart of the method steps S101-S104 of the protocol description model based vehicle networking multi-protocol dynamic analysis method provided by the embodiments of the present application, which will be described in conjunction with Figure 1 steps S101-S104 shown in the drawings.

[0020] In step S101, a multi-level protocol description model (PDM) is constructed, the PDM comprising a protocol metadata layer, a dynamic adaptation layer and a security verification layer, wherein the protocol metadata layer predefines the field structure, data type and coding rules of the mainstream protocol of vehicle networking, the dynamic adaptation layer embeds the vehicle moving state correlation factor and the communication link quality parameter, and the security verification layer integrates the hash verification rule and the protocol field legality verification rule.

[0021] This step is the basic model construction link of the method. The core scheme is to design a "three-level collaborative" PDM architecture, breaking through the static limitations of traditional single metadata model.

[0022] The protocol metadata layer adopts the "full protocol coverage + structured definition" scheme, predefines the field structure (such as the 11-bit / 29-bit ID field and 0-8-byte data length field of the CAN protocol), data type (integer corresponding to vehicle speed, floating point corresponding to fuel consumption) and coding rules (ASCII encoding corresponding to text data, binary encoding corresponding to sensor values) of mainstream protocols such as CAN and 5G-V2X, and constructs a feature vector library to store the differentiated features of each protocol, providing data support for subsequent identification.

[0023] The dynamic adaptation layer adopts the "double parameter fusion" scheme, embeds vehicle moving state correlation factors (speed, heading angle derived parameters) and communication link quality parameters (signal-to-noise ratio, packet loss rate), and solves the defects of existing PDMs that only focus on the protocol itself and do not adapt to the dynamic scenarios of vehicle networking.

[0024] The security verification layer adopts the "double rule integration" scheme, which integrates hash verification rules such as SHA-256 to ensure data integrity, and protocol field legality verification rules (such as the CAN protocol ID field range 0-2047 and data length field matching the actual payload), to make up for the security vulnerabilities of existing single verification. This step makes the PDM have "protocol description precision", "dynamic adaptation capability" and "security guarantee strength" through hierarchical design.

[0025] In step S102, a dynamic analysis engine is generated based on the constructed PDM. The dynamic analysis engine integrates protocol identification, parameter adjustment and result standardization functions, matches the protocol type of the data to be analyzed through the metadata features of the PDM to complete protocol identification, dynamically optimizes the analysis window size according to the real-time speed, acceleration and network topology changes of the vehicle to realize parameter adjustment, and processes the analysis results after data analysis and verification are completed. Format standardization and output unified format data.

[0026] The engine generates a "model-driven compilation" scheme, reads the PDM rules at each level by parsing the device compiler, automatically generates an integrated engine including protocol identification, parameter adjustment, and standardization, without manual development of special modules; the protocol identification adopts a "metadata feature matching" scheme, calls the feature vector library of the PDM metadata layer, calculates the matching degree (such as the similarity of field length, key field position, and coding format) of the data to be parsed and each protocol feature through the cosine similarity algorithm, which is more accurate than the traditional single header identification matching; the parameter adjustment adopts a "dynamic optimization" scheme, real-time collects vehicle speed, acceleration, and network topology change frequency, combines the correlation factors of the PDM dynamic adaptation layer, and adjusts the parsing window size (such as reducing the window size to improve anti-interference at high speed) through a preset algorithm; the result standardization adopts a "unified format mapping" scheme, predefines JSON as the output format, maps the parsing results (such as CAN binary data and 5G-V2X JSON data) of different protocols into a unified structure, and reduces the adaptation cost of subsequent data application.

[0027] The above-mentioned manner enables the engine to be "protocol-independent", laying a foundation for subsequent multi-protocol parsing and rapid updating.

[0028] In step S103, after receiving the multi-source data uploaded by the Internet of Vehicles terminal, the generated dynamic parsing engine and the corresponding protocol description rules of the PDM are called for preliminary parsing, and the data integrity is checked through the preset hash algorithm of the PDM security verification layer. After passing the check, the result standardization processing is performed and the unified format parsing data is output.

[0029] This step realizes the "parsing-verification-standardization" closed loop, taking into account efficiency and security. The data receiving adopts a "multi-protocol compatible" scheme, which receives multi-source data of ECU, navigation, entertainment, etc. through the communication module (supporting CAN bus, 5G, Ethernet) of the parsing device, without the need for classified receiving equipment; the preliminary parsing adopts a "engine+PDM cooperative" scheme, the dynamic parsing engine calls the description rules (such as field parsing order, data type conversion rules) of the corresponding protocol in the PDM according to the initial characteristics of the data to be parsed to perform parsing, ensuring that the parsing logic is consistent with the protocol definition; the security verification adopts a "double verification" scheme, first generates the joint hash value (header+payload) of the data to be parsed through the hash algorithm of the PDM security verification layer, and compares it with the pre-stored reference value to verify the integrity, and then verifies the field legality rule (such as ID field range, data length matching), which improves the abnormal recognition rate; the standardization and output adopt a "real-time mapping output" scheme, which immediately maps the parsing result into a unified JSON format after passing the check, and outputs it to the Internet of Vehicles control center or local storage through the communication interface. This step solves the problems of "complicated multi-source data processing and insufficient security verification" in the existing parsing.

[0030] In step S104, when a new protocol access or an existing protocol version update is detected, the difference between the update content and the existing metadata is first matched by the protocol feature fingerprint library of the PDM, and then the protocol metadata layer difference information is updated through the extension interface of the PDM. After the update is completed, the dynamic analysis engine does not need to be reconstructed, and the updated description rule can be directly loaded to realize the new protocol analysis.

[0031] The update detection adopts a "feature fingerprint matching" scheme. The PDM pre-stores the feature fingerprints (unique identifiers generated by core fields, coding rules, etc.) of each protocol. When a new protocol or version update is detected, the feature fingerprints are extracted and compared with the existing fingerprints to quickly locate the difference content (such as newly added fields, coding rule changes).

[0032] When the difference is updated, the PDM is designed with a standardized extension interface (supporting metadata field addition and deletion, rule modification), and only the difference part is updated (such as adding the metadata of a new protocol, and modifying the changed rules for version update), without changing the entire PDM.

[0033] The engine adaptation adopts a "rule hot loading" scheme. The updated PDM rules are imported into the dynamic analysis engine through memory hot loading, without restarting or reconstructing the engine. The engine automatically identifies the new rules and performs analysis.

[0034] The above-mentioned manner shortens the new protocol adaptation time from several days to minutes, greatly improving the adaptation efficiency.

[0035] In some embodiments, referring to Figure 2 , Figure 2 is a flowchart of steps S201-S203 provided by the embodiments of the present application, as shown in Figure 2 The specific process of constructing the dynamic adaptation layer includes steps S201-S203, which will be described in conjunction with each step.

[0036] In step S201, the speed and heading angle data of a vehicle for a continuous preset number of time stamps are collected, as well as the communication link signal-to-noise ratio and packet loss rate data corresponding to the time stamps.

[0037] This step is the basic data collection link of the dynamic adaptation layer. The core of the scheme is "multi-dimensional synchronous collection", which solves the adaptation deviation problem caused by the existing single vehicle state collection.

[0038] The specific implementation process is as follows: The collected object adopts a "vehicle state + link quality" two-dimensional scheme, the vehicle state selects speed (reflecting the speed of movement), heading angle (reflecting the direction of travel), the link quality selects signal-to-noise ratio (reflecting signal quality), and packet loss rate (reflecting transmission stability), and the two types of data directly affect the fitting effect of the analysis parameters; the collection method adopts a "time sequence synchronization" scheme, with 100 ms as the time interval, collecting data of a continuous preset number (such as 10) timestamps, ensuring that each timestamp corresponds to vehicle state and link quality data at the same time, and avoiding the distortion of association caused by time sequence misplacement; the data source adopts a "multi-sensor fusion" scheme, the vehicle state data comes from the vehicle-mounted OBD interface, and the link quality data comes from the built-in monitoring unit of the communication module, ensuring the authenticity and real-time of the data. This step provides a "time sequence consistent, comprehensive dimensional" data source for the subsequent correlation factor calculation.

[0039] In step S202, the collected vehicle data is processed by a Kalman filter algorithm, the position information of the vehicle at the next time is predicted, and the position prediction deviation value is calculated, and the position prediction deviation value is adaptively corrected in combination with the communication link data to obtain the corrected correlation factor.

[0040] The vehicle state prediction adopts a "Kalman filter" scheme, which has the characteristics of "anti-interference and high-precision prediction", inputs the collected speed and heading angle data, predicts the position at the next time through the state equation, corrects the predicted value through the observation equation, and outputs the position prediction deviation value (reflecting the degree of fluctuation of the vehicle state); the deviation correction adopts a "link quality weighting" scheme, determines the correction weight according to the signal-to-noise ratio and packet loss rate of the communication link (such as increasing the weight to 0.8 when the packet loss rate is >5%, and reducing the weight to 0.3 when the packet loss rate is <1%), multiplies the position prediction deviation value by the weight to obtain the corrected correlation factor, so that the correlation factor reflects the comprehensive influence of the vehicle state and the link quality; the calculation frequency adopts a "real-time iteration" scheme, which performs calculation once for every new data (10 timestamps) collected, ensuring that the correlation factor dynamically matches the scene. This step solves the problem of "one-sidedness and hysteresis" of the existing single vehicle state parameter fitting.

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

[0042] 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.

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

[0044] 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.

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

[0046] 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."

[0047] 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.

[0048] 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.

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

[0050] 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.

[0051] 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.

[0052] 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.

[0053] 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.

[0054] 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.

[0055] 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.

[0056] 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".

[0057] 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.

[0058] 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.

[0059] 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.

[0060] 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.

[0061] 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.

[0062] 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.

[0063] 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."

[0064] 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.

[0065] 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.

[0066] Furthermore, the process of building a PDM also includes the following sub-steps: 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.

[0067] 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.

[0068] 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.

[0069] 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.

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

[0071] 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.

[0072] 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.

[0073] 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.

[0074] 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.

[0075] 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.

[0076] 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.

[0077] 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.

[0078] 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.

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

[0080] 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.

[0081] A method for dynamic parsing of multiple protocols in vehicle-to-everything (V2X) networks based on Protocol Description Model (PDM) is described below: S1: Constructing a multi-level protocol description model (PDM): 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. 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. 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); 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.

[0082] S2: A dynamic parsing engine based on PDM generation. The dynamic parsing engine is generated by the parsing device's compiler and integrates protocol identification, parameter adjustment, and result standardization functions. 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. 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).

[0083] S3: Multi-source data parsing and processing: 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; 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. 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. Finally, the parsing results are standardized (converted to JSON format) and output to the vehicle network control center via the communication module.

[0084] S4: New Protocol Update: 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.

[0085] In summary, the embodiments of this application have the following beneficial effects: (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%. (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. (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%; (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.

[0086] 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.

[0087] 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: 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. 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. 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. 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.

[0088] 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.

[0089] In one possible implementation, the specific process of constructing the 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.

[0090] In one possible implementation, 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 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.

[0091] In one possible implementation, 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.

[0092] In one possible implementation, 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.

[0093] In one possible implementation, the process of constructing a PDM further 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.

[0094] In one possible implementation, 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.

[0095] The aforementioned vehicle-to-everything (V2X) multi-protocol dynamic parsing device based on the protocol description model has the following beneficial effects: (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%. (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. (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%; (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.

[0096] 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: 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.

[0097] 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.

[0098] The above-mentioned electronic devices have the following beneficial effects: (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%. (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. (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%; (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.

[0099] 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.

[0100] 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.

[0101] 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.

[0102] 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).

[0103] 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.

[0104] The aforementioned computer-readable storage media have the following beneficial effects: (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%. (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. (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%; (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.

[0105] 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.

[0106] 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.

[0107] 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.

[0108] 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.

[0109] 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 processed for format standardization 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 specifically 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.

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 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.

5. The method according to claim 1, characterized in that, 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.

6. 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.

7. 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.

8. 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 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.

9. 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 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which is executed by a processor as described in any one of claims 1 to 7, for the dynamic parsing of multiple protocols in vehicle networking.

Images