Internet of vehicles data processing method and system

Abstract

The invention provides an Internet of Vehicles data processing method and system. The method comprises the following steps: determining a protocol type of a protocol message through a protocol parser and calling a matched parsing rule to parse the protocol message; judging whether a target processing logic rule exists or not through a semantic mapping engine according to the combined protocol information corresponding to the protocol message; if not, querying and reading a first mapping configuration file matched with the combined protocol information from a configuration file library, constructing a target processing logic rule based on configuration data of the first mapping configuration file, and processing the analyzed protocol message into target Internet of Vehicles data according to the target processing logic rule; if so, directly processing according to the target processing logic rule to obtain target Internet of Vehicles data; and generating an Internet of Vehicles unified data model object according to the target structure and the target Internet of Vehicles data through an object generator, and sending the Internet of Vehicles unified data model object to a service system. According to the method and the device, the thorough decoupling of the upper layer service and the bottom layer protocol is realized, the overall maintainability and expansibility are improved, and the data processing efficiency is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of Internet of Vehicles data processing, in particular to an Internet of Vehicles data processing method and system. BACKGROUND

[0002] With the rapid development of intelligent networked vehicles and the Internet of Vehicles industry, vehicle internal communication and vehicle cloud data interaction protocols present highly heterogeneous and fragmented characteristics, covering a complex system from bottom-layer vehicle bus to cloud telemetry, from international standards to manufacturer proprietary protocols.

[0003] Therefore, processing the above Internet of Vehicles data has the following problems: complicated development, embodied in that each time a new protocol is added, parsing code needs to be re-written, databases and business logic need to be modified. Data confusion, embodied in that the name, unit and precision of the same data in different protocols are inconsistent and cannot be directly used. Difficulty in fusion, embodied in that data from different protocols is difficult to correlate and analyze (such as combining engine data from CAN and location data from GPS). SUMMARY

[0004] The present application provides an Internet of Vehicles data processing method and system, which realizes complete decoupling of upper-layer business and bottom-layer protocols, significantly improves the maintainability, expandability and data fusion capability of the system, and improves the data processing efficiency.

[0005] In a first aspect, an Internet of Vehicles data processing method is provided, applied to a unified data model, the unified data model comprising: a target interface, a protocol parser, a semantic mapping engine and an object generator; the method comprising: receiving protocol packets from different vehicle terminals based on the target interface, determining the protocol type of the protocol packets through the protocol parser, and calling the parsing rule matched with the protocol type to parse the protocol packets, to obtain first key field data; the protocol packets comprising Internet of Vehicles data; determining whether there is a target processing logic rule of each original protocol and target structure in the combination protocol information corresponding to the Internet of Vehicles data through the semantic mapping engine according to the combination protocol information; if not, querying and reading a first mapping configuration file matched with the combination protocol information from a configuration file library, constructing the target processing logic rule based on the configuration data in the first mapping configuration file, and processing the first key field data into target Internet of Vehicles data matched with the target structure according to the target processing logic rule; if yes, directly processing the first key field data into target Internet of Vehicles data matched with the target structure according to the target processing logic rule; A vehicle Internet unified data model object is generated by an object generator according to the target structure and the target vehicle Internet data, and the unified data model object is sent to a business system.

[0006] In a possible implementation, the first mapping configuration file is determined by a method including the following steps. According to the combined protocol information corresponding to the vehicle Internet data, a storage address matching the combined protocol information is queried from a preconfigured file lookup manual, and a second mapping configuration file is obtained from the storage address; According to the attribute information and the operation behavior information of the second mapping configuration file, a target verification mode for the second mapping configuration file is determined. According to the target verification mode, the second mapping configuration file is verified, and a verification pass identifier is added to the second mapping configuration file that passes the verification, to obtain the first mapping configuration file.

[0007] In a possible implementation, the second mapping configuration file is dynamically loaded in the following manner to realize service uninterrupted updating and guarantee data consistency, specifically including the following steps. Loading timing control: combined with real-time query rate per second (QPS), central processing unit (CPU) usage rate, and queue backlog, configuration loading is triggered when system load is lower than a preset threshold; and batch loading of new configurations is supported according to device type, tenant ID, or protocol type, including taking effect on a preset proportion of non-core devices, and full-scale promotion after a preset time period without exception; Atomicity and version management: new configurations are loaded into an independent memory area, and after passing the verification, the pointer is atomically switched to point to the new version, and the old configuration is released asynchronously after there is no reference; and a unique version ID is generated each time the configuration is loaded, and if the new configuration leads to an increase in error rate, the system can be rolled back to the previous stable version; Loading scheduling optimization: configuration loading is processed by an independent thread pool, without blocking I / O threads; only modified mapping rule segments are reloaded, rather than full-scale configurations; configurations are preferentially read from a local disk / memory cache, and the latest version is asynchronously pulled in the background, to realize fast startup and eventual consistency; Observability and fuse bottom: the time consumption, success / failure times, trigger source, and affected protocol type of each loading are recorded, to generate observability indexes; if loading fails for three consecutive times, automatic updating is automatically suspended and an alarm is given, to prevent repeated impact of error configurations on the system; and when loading fails, the current effective configuration is continued to be used and error logs are recorded, to guarantee business continuity.

[0008] In a possible implementation, the target verification mode for the second mapping configuration file is determined according to the attribute information and the operation behavior information of the second mapping configuration file. determining, according to the operation behavior information of the second mapping configuration file, whether the second mapping configuration file meets a scene check condition, if yes, obtaining a first check mode matched with the scene check condition, and if not, not obtaining the first check mode; wherein the second mapping configuration file meeting the scene check condition comprises reading the second mapping configuration file for the first time or a time length from a last scene check being greater than a preset time length; determining, according to attribute information of the second mapping configuration file, a second check mode matched with the attribute information; determining that the first check mode and the second check mode are the target check mode, or determining that the second check mode is the target check mode.

[0009] In a possible implementation, the second mapping configuration file includes configuration data; when the second mapping configuration file is checked, the second mapping configuration file is parsed into structured data in a computer memory; The first check mode comprises checking, on the structured data in the second mapping configuration file, physical property correctness of Internet of Vehicles data, business logic feasibility of Internet of Vehicles data, and security of Internet of Vehicles data respectively. The second check mode comprises syntax and semantic check preposition and sandbox simulation running check; wherein the syntax and semantic check preposition comprises legality check of JSON / YAML format, whether a field mapping path exists, and loop dependency detection performed before loading; the sandbox simulation running check comprises trial running of a new configuration in an isolated environment using a historical message sample, and verifying whether an output model conforms to an expectation.

[0010] In a possible implementation, checking, on the structured data in the second mapping configuration file, security of Internet of Vehicles data comprises: In a registration center of a unified data model, security compliance metadata of a target index is defined, and the security compliance metadata includes a data classification label of the target index and a data processing component identification that must be associated; After a semantic mapping rule in the second mapping configuration file is loaded, policy metadata corresponding to the target index is obtained from the registration center, it is determined whether the data classification label of the target index belongs to a pre-defined controlled data classification; if yes, it is further checked whether the semantic mapping rule has correctly associated the data processing component that must be associated specified in the policy metadata; if not, it is determined that the check fails, and the semantic mapping rule is prevented from taking effect or a security alarm is issued; wherein the semantic mapping rule defines a mapping relationship from a data source to the target index, and includes reference information of the data processing component.

[0011] In a possible implementation, the constructing the target processing logic rule based on the configuration data in the first mapping configuration file and processing the first key field data into the target Internet of Vehicles data matching the target structure according to the target processing logic rule comprises: constructing a rule execution network in the memory, the rule execution network at least comprising: a rule hash table, a key of which is a composite key generated by splicing a protocol identifier of an original protocol and an original field name, and a value of which is a corresponding target mapping rule and a precompiled executable unit; and a condition judgment tree, used for organizing and managing a mapping rule containing a condition expression, a node of the tree being a condition judgment logic, and a leaf node being a corresponding mapping rule set; taking the first key field data as input original data, the semantic mapping engine performing matching retrieval in the rule hash table based on a composite key generated by the semantic mapping engine based on a protocol identifier and an original field name of the original data; if the matching succeeds, the semantic mapping engine performs a pre-defined programmable data transformation process to generate standard data of the target structure, the programmable data transformation process at least including numerical calculation based on a configuration expression; and if the matching fails, the semantic mapping engine traverses the condition judgment tree to find a matching condition rule, and executes a precompiled executable unit corresponding to the matching rule to generate standard data of the target structure.

[0012] In a possible implementation, the precompiled executable unit comprises: an expression executor, a unit converter, an enumeration normalizer, a condition filter, and a hot update listener; and the executing the precompiled executable unit corresponding to the matching rule to generate standard data of the target structure comprises: performing dynamic calculation, conversion, or logical processing on the original field value by the expression executor to generate a value of a target VUDM field; providing standardized unit conversion capability by the unit converter to automatically convert a non-standard unit in the original data into a unified unit defined in the VUDM model; mapping enumeration values from different protocols into unified semantic enumeration values defined in the VUDM model by the enumeration normalizer, the enumeration values at least including: a state code, a text description, and a Boolean value; determining whether to map or filter a piece of data according to a user-defined condition expression by the condition filter, supporting complex multi-condition combinations; detecting changes in the semantic mapping configuration file by the hot update listener, and automatically reloading the mapping rule when detecting the changes, without restarting the system.

[0013] In a possible implementation, the unified data model further comprises a protocol fingerprint extraction module, a templated mapping module, and a mode switching control module; and the method further comprises: In response to the real-time load index of the protocol message processing of the server satisfying a mode switching condition or the triggering operation of a mode switching switch by a designated authority user, the mode switching control module is switched from a current mode to a high-performance degradation mode; In the high-performance degradation mode, the target Internet of Vehicles data matching the target structure in the protocol message is obtained by a protocol fingerprint extraction module, a templated mapping module, and an asynchronous bottom-up verification module. The real-time load index of the protocol message processing satisfying the mode switching condition includes: real-time monitoring of the throughput, CPU usage, memory occupancy, and queue backlog of the server for the protocol message; when at least one of the protocol message throughput, CPU usage, memory occupancy, and queue backlog per unit time satisfies the corresponding threshold condition, and the current business context does not belong to a non-critical data scenario, it is determined that the real-time load index of the protocol message processing satisfies the mode switching condition. The protocol fingerprint extraction module extracts the protocol fingerprint by pre-training a lightweight model from the message header and key fields; the key fields include: device ID, message type, timestamp; the templated mapping module fills in the missing data of the key fields using an offline trained time series prediction model, and matches the protocol fingerprint with a pre-defined unified model template to output a processing result through the unified model template; the asynchronous bottom-up verification module puts the processing result into a low-priority queue, which is verified and corrected by a background task afterwards to obtain the target Internet of Vehicles data.

[0014] In a second aspect, the embodiments of the present application provide a vehicle Internet of Things data processing system, comprising: a target interface, a protocol parser, a semantic mapping engine, and an object generator; wherein, The target interface is configured to receive protocol messages from different vehicle terminals. The protocol parser is configured to determine the protocol type of the protocol message and call the parsing rule matched with the protocol type to parse the protocol message to obtain first key field data. The semantic mapping engine is configured to determine whether there is a target processing logic rule of each original protocol and target structure in the combined protocol information corresponding to the vehicle Internet of Things data according to the combined protocol information; if not, a first mapping configuration file matching the combined protocol information is queried and read from a configuration file library, and the target processing logic rule is constructed based on the configuration data in the first mapping configuration file, and the first key field data is processed into target vehicle Internet of Things data matching the target structure according to the target processing logic rule; if so, the first key field data is directly processed into target vehicle Internet of Things data matching the target structure according to the target processing logic rule. The object generator is used to generate a unified data model object for the Internet of Vehicles based on the target structure and the target Internet of Vehicles data, and then send the unified data model object to the business system.

[0015] The vehicle network data processing method and system provided in this application embodiment constructs a standardized and scalable "Vehicle Network Unified Data Model" (VUDM) and combines it with a semantic mapping engine to achieve dynamic parsing and unified conversion of heterogeneous data from multiple sources such as CAN, UDS, MQTT, JT / T808, and vendor proprietary protocols. Through flexible configuration files supporting expression calculation, unit conversion, and enumeration standardization, the system can shield underlying protocol differences and output a data structure with unified semantics, allowing upper-layer business platforms to directly use the data without needing to be aware of protocol details. This method thoroughly solves problems such as strong coupling between protocols and services, fragmented data semantics, and difficulties in system expansion and maintenance, significantly improving the maintainability, scalability, and cross-protocol data fusion capabilities of vehicle network data processing, and also increasing data processing efficiency. Attached Figure Description

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

[0017] Figure 1 A flowchart illustrating a first method for processing vehicle network data provided in an embodiment of this application is shown; Figure 2 A flowchart illustrating a second method for processing vehicle network data provided in an embodiment of this application is shown; Figure 3 A flowchart illustrating a third method for processing vehicle network data provided in an embodiment of this application is shown; Figure 4 A flowchart illustrating the fourth method for processing vehicle network data provided in this application embodiment is shown; Figure 5 This paper shows a schematic diagram of the structure of a vehicle network data processing system provided in an embodiment of this application; Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

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

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

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

[0021] The following problems exist when processing the aforementioned vehicle network data: Development is cumbersome, as each new protocol requires rewriting parsing code, modifying the database, and changing business logic. Data is chaotic, as the same data has inconsistent names, units, and precision across different protocols, making it unusable directly. Integration is difficult, as data from different protocols is hard to correlate and analyze (e.g., combining CAN engine data and GPS location data). Based on this, this application provides a method and system for processing vehicle network data. This solution dynamically maps heterogeneous data from multiple protocols into a unified semantic model, achieving complete decoupling between upper-layer business and lower-layer protocols, significantly improving system maintainability, scalability, and data fusion capabilities, and increasing data processing efficiency.

[0022] like Figure 1 As shown in the figure, this application provides a method for processing vehicle network data, applied to a unified data model, which includes: a target interface, a protocol parser, a semantic mapping engine, and an object generator; the method includes: S101. Based on the target interface, receive protocol messages from different vehicle terminals, determine the protocol type of the protocol message through a protocol parser, and call the parsing rules matching the protocol type to parse the protocol message to obtain the first key field data; the protocol message includes vehicle network data.

[0023] S102. The semantic mapping engine determines whether there are target processing logic rules for each original protocol and target structure in the combined protocol information based on the combined protocol information corresponding to the vehicle network data.

[0024] S103. If it does not exist, query and read the first mapping configuration file that matches the combined protocol information from the configuration file library, construct the target processing logic rule based on the configuration data in the first mapping configuration file, and process the first key field data into target vehicle network data that matches the target structure according to the target processing logic rule; if it exists, directly process the first key field data into target vehicle network data that matches the target structure according to the target processing logic rule.

[0025] S104. Generate a unified data model object for the Internet of Vehicles (IoV) based on the target structure and the target IoV data using an object generator, and send the unified data model object to the business system.

[0026] This application utilizes the aforementioned method and system for processing vehicle network data. This solution achieves complete decoupling between upper-layer services and lower-layer protocols by dynamically mapping heterogeneous data from multiple protocols into a unified semantic model. This significantly improves the maintainability, scalability, and data fusion capabilities of the system, and also enhances data processing efficiency.

[0027] The exemplary embodiments described above will be explained below: S101. Based on the target interface, receive protocol messages from different vehicle terminals, determine the protocol type of the protocol message through a protocol parser, and call the parsing rules matching the protocol type to parse the protocol message to obtain the first key field data; the protocol message includes vehicle network data.

[0028] In this embodiment of the application, different vehicle terminals typically use different protocols to send messages, and the protocols used by the vehicle terminals to send different vehicle network data are also typically different. The above protocols include: 1. Vehicle bus protocols: CAN (Controller Area Network), LIN (Local Interconnect Network), FlexRay, Ethernet (including DoIP, Diagnostic over IP), etc., used for real-time communication and diagnosis between ECUs; 2. Diagnostic protocols: UDS (ISO 14229), KWP2000, OBD-II (SAE J1979), etc., used for vehicle fault diagnosis, parameter reading and flashing; 3. Telemetry and cloud platform protocols: MQTT, HTTP / JSON, CoAP, WebSocket, gRPC and other general IoT protocols, supporting vehicle status reporting, remote control and OTA upgrades; 4. Standard vehicle networking protocols: (1) JT / T808: Communication protocol for vehicle terminals of road transport vehicle satellite positioning system issued by designated institutions, widely used for the supervision of passenger and dangerous goods vehicles and freight vehicles; (2) JT / T 794, JT / T 1078: respectively specify the technical requirements of vehicle terminals and audio and video transmission protocols; (3) GB / T 32960: Technical Specification for Remote Service and Management System for Electric Vehicles, used for data reporting of new energy vehicles; (4) GT06 / GT06N: Commonly found in low-cost GPS positioning terminals, widely used in electric bicycles, motorcycles, and logistics tracking equipment. The protocol structure is simple but the market share is high; 5. OEM private protocol: ECU communication format and data encapsulation specifications customized by each car manufacturer, such as MQB platform CAN matrix of car manufacturer 1, TNGA platform diagnostic protocol of car manufacturer 2, DiLink data frame of car manufacturer 3, NAD service protocol of car manufacturer 4, etc.; 6. Private protocol of vehicle network terminal manufacturers: (1) Manufacturer 1: Its protocol is widely used in commercial vehicles, construction machinery, and shared mobility fields, and supports custom data packet structure and encrypted fields; (2) Manufacturer 2: The protocol supports TCP / UDP custom binary format and is often used for fleet management and asset tracking; (3) Other manufacturers also have their own private protocol systems, and the data structure, field definition, heartbeat mechanism, and alarm type are not uniform.

[0029] The aforementioned protocol message includes vehicle-to-everything (V2X) data. Specifically, the protocol parser compares "connection layer characteristics (e.g., network port or physical channel / interface)" and message structure characteristics (e.g., fixed header, length field, and checksum) with a built-in "protocol feature library" to determine the specific protocol type. Alternatively, the protocol parser can also use connection layer characteristics (e.g., device pre-registration information and session state) to assist in determining the protocol type. After determining the protocol type, the protocol parser outputs a unique protocol identifier. The protocol parser then queries a pre-maintained "protocol knowledge base" for parsing rules that match the protocol identifier and parses the protocol message based on these rules to obtain the first key field data. The "protocol knowledge base" pre-maintains parsing rules corresponding to different protocol identifiers; in the vehicle network data, the "first key field data" can be vehicle status and operation data, diagnostic and alarm data, terminal and device metadata, multimedia and extended data, and response data of control commands; the above-mentioned vehicle status and operation data can be location-related (such as original latitude and longitude values, altitude, original speed values, heading / heading angle), power system-related (such as "engine speed, original engine temperature, fuel level / electricity SOC (percentage or original voltage value), instantaneous fuel consumption, cumulative mileage), chassis and body-related, etc.

[0030] S102. The semantic mapping engine determines whether there are target processing logic rules for each original protocol and target structure in the combined protocol information based on the combined protocol information corresponding to the vehicle network data.

[0031] In this embodiment, each piece of vehicle network data has corresponding combined protocol information. Different combined protocol information is pre-configured to adapt to business needs. For example, the combined protocol information includes "A1+B1+C1+D1, A2+B3+C1+D4", where ABCD represents different protocols and 1234 represents different versions. Each business corresponds to one type of combined protocol information, and the vehicle network data under that business corresponds to that combined protocol information. The semantic mapping engine determines whether there are target processing logic rules for each original protocol and target structure in the pre-generated combined protocol information based on the combined protocol information corresponding to the vehicle network data. It should be noted that the target processing logic rules for each type of combined protocol information can be stored for a preset duration (e.g., 24 hours). They are regenerated based on user operations with specific permissions or after the preset duration is reached.

[0032] Here, the target structure is the structure of a unified data model (such as VUDM, Virtual Unified Device Model), which is a standardized and scalable data structure (as shown in Table 1) used to carry the parsing results from any protocol. It contains at least the following fields, and the above data is the target vehicle network data obtained by processing the data of the first key field based on the target processing logic rules.

[0033] Table 1

[0034] S103. If it does not exist, query and read the first mapping configuration file that matches the combined protocol information from the configuration file library, construct the target processing logic rule based on the configuration data in the first mapping configuration file, and process the first key field data into target vehicle network data that matches the target structure according to the target processing logic rule; if it exists, directly process the first key field data into target vehicle network data that matches the target structure according to the target processing logic rule.

[0035] In this embodiment of the application, if there is a target processing logic rule corresponding to the combined protocol information, the first key field data is directly processed into target vehicle network data matching the target structure according to the target processing logic rule; if it does not exist, the first mapping configuration file (i.e., the original configuration file) matching the combined protocol information is queried and read from the configuration file library, and the target processing logic rule is constructed based on the configuration data in the first mapping configuration file, and the first key field data is processed into target vehicle network data matching the target structure according to the target processing logic rule.

[0036] S104. Generate a unified data model object for the Internet of Vehicles (IoV) based on the target structure and the target IoV data using an object generator, and send the unified data model object to the business system.

[0037] The object generator generates a unified data model object for the Internet of Vehicles based on the target structure and corresponding data of the specified fields in Table 1 above, and sends the unified data model object to the business system.

[0038] Furthermore, such as Figure 2 As shown in the embodiments of this application, the method for processing vehicle network data determines the first mapping configuration file through the following method: S201. Based on the combined protocol information corresponding to the vehicle network data, query the storage address that matches the combined protocol information from the pre-configured file search manual, and obtain the second mapping configuration file from the storage address.

[0039] S202. Determine the target verification method for the second mapping configuration file based on the attribute information and operation behavior information of the second mapping configuration file.

[0040] S203. Verify the second mapping configuration file according to the target verification method, and add a verification pass flag to the second mapping configuration file that passes the verification to obtain the first mapping configuration file.

[0041] In conjunction with the above S201-S203, the first mapping configuration file used to construct the target processing logic rule in this embodiment of the application has been pre-verified and passed the verification. Specifically, each combination protocol information matches a different second mapping configuration file. Therefore, the storage address that matches the selected combination protocol information is first determined, and the second mapping configuration file is obtained from the storage address. Then, based on the attribute information and operation behavior information of the second mapping configuration file, the target verification method for the second mapping configuration file is determined, and the second mapping configuration file is verified according to the target verification method. A verification pass identifier is added to the second mapping configuration file that passes the verification to obtain the first mapping configuration file.

[0042] Specifically, determining the target verification method for the second mapping configuration file based on its attribute information and operation behavior information includes: determining whether the second mapping configuration file meets the scenario verification conditions based on the operation behavior information of the second mapping configuration file (e.g., whether it is the first operation or the time since the last scenario verification); if it meets the conditions, obtaining the first verification method matching the scenario verification conditions; if it does not meet the conditions, not obtaining the first verification method; wherein, the second mapping configuration file meeting the scenario verification conditions includes reading the second mapping configuration file for the first time or the time since the last scenario verification being greater than a preset time; then, determining the second verification method matching the attribute information based on the attribute information of the second mapping configuration file (e.g., vehicle network scenario attributes); the target verification method may include the first verification method and the second verification method, or the target verification method may only include the second verification method.

[0043] The second mapping configuration file includes configuration data; when validating the second mapping configuration file, the second mapping configuration file is parsed into structured data in computer memory; The first verification method includes: verifying the correctness of the physical characteristics of the vehicle network data, the feasibility of the vehicle network data business logic, and the security of the vehicle network data for the structured data in the second mapping configuration file.

[0044] Here, "verification of the correctness of the physical characteristics of vehicle network data" includes: verification of the reasonableness of the numerical range, that is, whether the converted data value is within the possible physical range; verification of unit consistency, that is, whether the units in the calculation formula can be converted and matched to avoid errors such as "dividing meters by seconds to get liters"; verification of the continuity of the rate of change, that is, whether the change of the data value conforms to physical inertia; and verification of sensor range matching, that is, whether the accuracy and range of the data after empty mapping are consistent with the known specifications of the vehicle-mounted sensors.

[0045] "Feasibility verification of vehicle network data business logic" includes: business rule conflict verification, including whether the data combination violates the preset business logic; correctness verification of derived indicator calculation, that is, checking whether the business indicators calculated by the expression are correct; and completeness of enumeration value mapping, that is, ensuring that all possible original enumeration values ​​are mapped to the standardized values ​​recognized by the business system without omission.

[0046] The second verification method includes: pre-verification of syntax and semantics and sandbox simulation verification. Pre-verification of syntax and semantics includes: performing JSON / YAML format validity checks, field mapping path existence checks, and circular dependency detection before loading. Sandbox simulation verification includes: using historical message samples to test the new configuration in an isolated environment to verify whether the output model meets expectations. Here, through the above pre-verification of syntax and semantics and sandbox testing, the initial loading success rate is improved.

[0047] 1. Pre-processing of syntax and semantics validation: Execute before loading: (1) JSON / YAML format validity check; (2) Does the field mapping path exist (e.g., is ${device.model} defined in the protocol)? (3) Circular dependency detection (A→B→A mapping dead loop).

[0048] 2. Sandbox simulation operation: Using historical message samples, we tested the new configuration in an isolated environment to verify whether the output model met the expected schema and intercepted 90%+ of configuration errors.

[0049] Furthermore, the vehicle network data processing method provided in this application embodiment includes verifying the vehicle network data security of the structured data in the second mapping configuration file, comprising: S1. In the unified data model registry center, define security compliance metadata for the target metrics. The security compliance metadata includes the data classification tags of the target metrics and the identifiers of the data processing components that must be associated with them. S2. After loading the semantic mapping rules in the second mapping configuration file, obtain the policy metadata corresponding to the target indicator from the registry center, and determine whether the data classification label of the target indicator belongs to the predefined controlled data category; if it does, further verify whether the configuration of the semantic mapping rule has been correctly associated with the data processing component that must be associated as specified in the policy metadata; if it is not correctly associated, determine that the verification has failed, and prevent the semantic mapping rule from taking effect or issue a security alarm; wherein, the semantic mapping rule defines the mapping relationship from the data source to the target indicator and contains reference information to the data processing component.

[0050] Specifically, during the system design phase, each indicator (such as vehicle_location) is pre-labeled with a security tag (e.g., category: highly sensitive geographic information) in the "data dictionary" (registration center), and the components that must be associated when processing this data are forcibly specified (e.g., mandatory associated components: geofence blurring processor, data transmission encryptor). When a set of mapping rules is written (e.g., "map the latitude and longitude fields of the JT808 protocol to the vehicle_location indicator"), the system will automatically check the "security profile" of vehicle_location in the registration center when loading, and find that it belongs to the "predefined controlled data category" (e.g., "personal privacy" or "important data"). The system then checks whether the configuration of this mapping rule explicitly references (or configures) the data processing components required in the security profile. For example, does the rule specify that "vehicle_location data must be processed by GeoFuzzProcessor (geofometry component) before output"? If the verification fails (for example, sensitive location data is mapped without any desensitization or encryption components), the system will automatically prevent this mapping rule from going live, fundamentally preventing insecure data from being produced. Security personnel will also be notified to intervene.

[0051] Furthermore, the vehicle network data processing method provided in this application embodiment dynamically loads the second mapping configuration file in the following manner to achieve uninterrupted service updates and ensure data consistency, specifically including: Loading timing control: Combining real-time query per second (QPS), CPU utilization, and queue backlog, configuration loading is triggered when the system load is below a preset threshold; and it supports loading new configurations in batches by device type, tenant ID, or protocol type, including applying the configuration to a preset proportion of non-core devices, and then fully promoting it after observing for a preset period of time without any abnormalities. Atomicity and version management: New configurations are loaded into an independent memory area. After verification, the pointer is atomically switched to point to the new version. Old configurations are released asynchronously after they are no longer referenced. Each load generates a unique version ID. If the new configuration causes the error rate to increase, it can be rolled back to the previous stable version. Loading and scheduling optimization: Configuration loading is handled by an independent thread pool, which does not block I / O threads; only modified mapping rule fragments are reloaded, instead of the full configuration; configuration is read from the local disk / memory cache first, and the latest version is asynchronously pulled from the remote server in the background to achieve fast startup and eventual consistency; Observability and circuit breaker fallback: Record the time taken for each loading, the number of successes / failures, the trigger source and the affected protocol type to generate observability metrics; if three consecutive loading failures occur, automatically pause automatic updates and issue an alarm to prevent incorrect configurations from repeatedly impacting the system; and when loading fails, continue to use the currently effective configuration and record error logs to ensure business continuity.

[0052] In this embodiment of the application, the above-mentioned dynamic loading of the "mapping configuration file" mechanism is adopted. In addition to enabling uninterrupted service updates, dynamic loading of the "mapping configuration file" can also introduce the following key mechanisms to ensure high success rate, low latency, and data consistency.

[0053] 1. Loading timing control: Avoiding interference during peak business periods: (1) Traffic-aware scheduling: Combining real-time query per second (QPS), central processing unit (CPU) utilization, queue backlog and other indicators, loading is triggered during business off-peak periods (such as at night (11 pm to 6 am the next day) and weekends) or when the system load is below the threshold, so as to reduce the impact on online requests.

[0054] (2) Gray window mechanism: Supports loading new configurations in batches according to device type, tenant ID or protocol type to avoid avalanche caused by full mutation.

[0055] Example: First apply the new mapping rule to 5% of non-core devices, observe for 10 minutes if there are no abnormalities, and then promote it to the whole device.

[0056] 2. Atomicity and Version Control: Preventing Intermediate State Pollution (1) Double buffer / shadow configuration mechanism: The new configuration is loaded into an independent memory area (such as config_v2). After the verification is passed, the pointer is atomically switched to point to the new version. The old configuration is released asynchronously after it is no longer referenced. This mechanism avoids reading the unfinished configuration during the loading process.

[0057] (2) Configure version number + rollback capability: Each load generates a unique version ID (such as GitCommitHash (i.e., version fingerprint) or timestamp). If the new configuration causes the error rate to increase, it can be rolled back to the previous stable version in seconds.

[0058] 3. Pre-verification and sandbox testing: Improve the initial load success rate. (1) Pre-processing of syntax and semantic verification: Before loading, perform the following checks: JSON / YAML format validity; existence of field mapping paths (e.g., whether ${device.model} is defined in the protocol); and detection of circular dependencies (A→B→A mapping dead loop).

[0059] (2) Sandbox simulation operation: Use historical packet samples to test the new configuration in the isolated environment, verify whether the output model meets the expected schema, and intercept 90%+ of configuration errors.

[0060] 4. Loading and scheduling optimization: Balancing efficiency and resource consumption: (1) Asynchronous non-blocking loading: Configuration loading is handled by an independent thread pool, which does not block I / O threads and avoids service lag caused by parsing large files.

[0061] (2) Incremental update support: If only some mapping rules are modified (such as adding a new device model), only the changed fragment is reloaded instead of the full reload, and the loading time is reduced from seconds to milliseconds.

[0062] (3) Local caching + remote synchronization: The configuration file is read from the local disk / memory cache first, while the latest version is asynchronously pulled from the remote disk (such as from Nacos / Apollo / etcd) in the background to achieve fast startup and eventual consistency.

[0063] 5. Observability and circuit breaker backup: (1) Loading success rate monitoring: Record the loading time, number of successes / failures, trigger source (manual / API / automatic) and affected protocol type for each loading; (2) Failure circuit breaker mechanism: If the loading fails 3 times in a row, the automatic update will be automatically suspended and an alarm will be issued to notify the operation and maintenance to intervene, so as to prevent the system from being repeatedly impacted by incorrect configuration.

[0064] (3) Degradation strategy: When loading fails, continue to use the currently effective configuration and record the error log to ensure business continuity.

[0065] In this application embodiment, the dynamic loading described above is not a simple hot update. The core principle of dynamic loading is: The goal of the aforementioned "dynamic loading" is not only "non-stop operation," but also "seamless, reliable, and traceable." Through four layers of protection—pre-verification, atomic switching, gray-scale scheduling, and circuit breaker rollback—it can support the dynamic mapping needs of millions of devices and thousands of protocols in complex production environments. The specific details of the "dynamic loading" in this application are shown in Table 2 below: Table 2

[0066] Furthermore, such as Figure 3 As shown in the embodiments of this application, the method for processing vehicle network data includes constructing the target processing logic rules based on the configuration data in the first mapping configuration file, and processing the first key field data into target vehicle network data matching the target structure according to the target processing logic rules, comprising: S301. Construct a rule execution network in memory, the rule execution network including at least: a rule hash table: its key is a composite key generated by concatenating the protocol identifier of the original protocol and the original field name, and its value is the corresponding target mapping rule and the pre-compiled executable unit; a condition judgment tree: used to organize and manage mapping rules containing condition expressions, the nodes of the tree are condition judgment logic, and the leaf nodes are the corresponding mapping rule sets.

[0067] S302. The first key field data is used as the input raw data, and the semantic mapping engine performs matching and retrieval in the rule hash table based on the composite key generated by its protocol identifier and the original field name.

[0068] S303. If the match is successful, the semantic mapping engine executes a predefined programmable data transformation process to generate standard data of the target structure. The programmable data transformation process includes at least numerical calculation based on the configuration expression. If the match fails, the condition judgment tree is traversed to find the matching condition rule, and the pre-compiled executable unit corresponding to the matching rule is executed to generate standard data of the target structure.

[0069] Specifically, the aforementioned pre-compiled executable unit includes: an expression executor, a unit converter, an enumeration normalizer, a conditional filter, and a hot update listener; the pre-compiled executable unit corresponding to the execution matching rule generates standard data for the target structure, including: The expression executor executes user-defined expressions to dynamically calculate, transform, or logically process the original field values, generating the values ​​of the target VUDM fields. The unit converter provides standardized unit conversion capabilities, automatically converting non-standard units in the raw data into uniform units defined in the VUDM model.

[0070] The enumeration normalizer maps enumeration values ​​from different protocols to unified semantic enumeration values ​​defined in the VUDM model; the enumeration values ​​include at least: status codes, text descriptions, and Boolean values; The conditional filter determines whether to map or filter a certain piece of data based on user-defined conditional expressions, and supports complex combinations of multiple conditions. The hot update listener monitors for changes to the semantic mapping configuration file and automatically reloads the mapping rules when a change is detected, without requiring a system restart.

[0071] In this embodiment, the semantic mapping engine is responsible for dynamically mapping the raw fields output by the protocol parser to VUDM objects. Its core modules include: (1) Mapping configuration loader: reads the mapping configuration file in JSON / YAML format and builds the mapping rule table; (2) Expression executor: Supports JavaScript / SpEL expressions to achieve dynamic calculation (e.g., (value-32)*5 / 9); (3) Unit converter: Built-in unit conversion rules (e.g., mph→km / h, °F→°C); (4) Enumeration Standardizer: Maps enumeration values ​​of different protocols to a unified standard value (e.g., 1 → "OPEN", "open" → "OPEN"). (5) Conditional filters: support conditional expressions (such as ifprotocol=="UDS"andfield=="dtc"); (6) Hot update listener: listens for changes in configuration files and automatically reloads mapping rules without restarting the service.

[0072] Furthermore, a key feature of this application embodiment is the introduction of big data and AI solutions to replace the "protocol parser + semantic mapping engine" to improve efficiency. Specifically, the vehicle network data processing method provided in this application embodiment includes a protocol fingerprint extraction module, a templated mapping module, and a mode switching control module in the unified data model; the method also includes: S3. The response server controls the mode switching control module to switch from the current mode to the high-performance degradation mode when the real-time load index of the protocol message processing meets the mode switching conditions or responds to the trigger operation of the mode switching switch by a user with specified permissions.

[0073] S4. In the high-performance degradation mode, target vehicle network data matching the target structure in the protocol message is obtained through the protocol fingerprint extraction module, the templated mapping module, and the asynchronous fallback verification module.

[0074] The determination that the real-time load indicators of the protocol message processing meet the mode switching conditions includes: real-time monitoring of the server's throughput, CPU utilization, memory usage, and queue backlog for protocol messages; when at least one of the protocol message throughput, CPU utilization, memory usage, and queue backlog is found to meet the corresponding threshold condition within a unit time, and the current business context does not belong to a non-critical data scenario (such as device heartbeat, telemetry data, log reporting), it is determined that the real-time load indicators of the protocol message processing meet the mode switching conditions. The protocol fingerprint extraction module uses a pre-trained lightweight model to extract the message header and key fields to generate a protocol fingerprint. The key fields include: device ID, message type, and timestamp. The templated mapping module uses an offline-trained time-series prediction model to fill in the missing data of the key fields and matches a predefined unified model template according to the protocol fingerprint, outputting the processing result through the unified model template. The asynchronous fallback verification module puts the processing result into a low-priority queue, which is then verified and corrected by a background task to obtain the target vehicle network data.

[0075] This application provides a conventional processing mode and a high-performance degradation mode for vehicle network data. The former ensures both efficiency and accuracy, while the latter, compared to the former, sacrifices some accuracy but still meets high concurrency requirements. These are explained in detail below: A. Standard processing mode (medium concurrency): Under moderate concurrent loads (e.g., 100,000 protocol packets per second), the system employs a complete "protocol parser + semantic mapping engine" chain for processing. This process includes: (1) Protocol decoding: Parse binary / text messages field by field according to standard or proprietary protocol specifications; (2) Semantic validation: Validate the legality of fields and business constraints (such as range, enumeration, and dependency relationships); (3) Contextual association: Semantic completion is performed by combining the device's historical state and the session context; (4) Model mapping: Convert the original message structure into a unified data model.

[0076] This mode ensures high accuracy (≥99.9%) and strong consistency, making it suitable for scenarios with stringent data quality requirements (such as billing, alarms, and auditing). The end-to-end processing latency is controlled within seconds, meeting the real-time requirements of most business systems.

[0077] B. High-performance degradation mode (high-concurrency burst scenarios): When a system faces extremely high concurrency pressure (such as 1 million+ messages per second) or millisecond-level response requirements (such as edge computing, real-time risk control, and IoT device flow control), the complete parsing chain may become a performance bottleneck. In such cases, introducing big data models and AI can enable a FastPath algorithm based on feature recognition and lightweight inference. Its core mechanism is as follows: 1. Specific conditions (triggering downgrade mode): (1) The system detects that the protocol message throughput per unit time exceeds the threshold (e.g., >500,000 TPS). (2) Or the CPU / memory / queue backlog indicators reach the preset level; (3) The current business context allows for a certain degree of fault tolerance (such as non-critical telemetry data, status heartbeat, and log reporting).

[0078] 2. Special method (FastPath implementation): (1) Protocol fingerprint extraction: Using a pre-trained lightweight model (such as decision tree, embedding vector matching) or rule engine, only the message header / key fields (such as device ID, message type, timestamp) are extracted to generate a "protocol fingerprint"; (2) Templated mapping: Based on fingerprint matching, a predefined "unified model template" is used to skip field-level validation and complex semantic reasoning; 3. AI-assisted completion (optional): Use offline trained time series prediction models (such as LSTM) to perform probability imputation on missing fields (only for non-critical fields); 4. Asynchronous fallback verification: The FastPath processing result is placed in a low-priority queue, and the background task performs post-processing verification and correction.

[0079] In this application embodiment, the above-mentioned high-performance degradation mode is applicable to the following scenarios: 1. High business tolerance: This scenario is mostly used for monitoring, statistics, and trend analysis data. A small amount of error will not affect the overall decision-making (such as "device online rate 98% vs 99.9%" is above the alarm threshold). 2. Higher priority for timeliness: Millisecond-level latency can avoid problems such as misjudgment of device disconnection and failure of real-time strategies; 3. Errors are controllable and traceable: (1) The accuracy rate remains at 95%~98% (verified by A / B testing). (2) All FastPath data is tagged with processing_mode=fast, which makes it easier for the upper layer to filter or use it with weights as needed; (3) The asynchronous verification mechanism can correct about 70% of the misjudgments, and the remaining errors are included in the system SLA tolerance range.

[0080] The advantages of the above high-performance degradation mode are summarized in Table 3: Table 3

[0081] The following is combined Figure 4 The present application provides a method for processing vehicle network data (i.e., a unified vehicle network data model (VUDM) and its semantic mapping method) through specific embodiments, including the following components and steps: 1. Construct a unified data model for vehicle-to-everything (VUDM): VUDM is a standardized, scalable data structure (as shown in Table 1) used to carry parsing results from any protocol. It contains at least the following fields: (one field; data used by different protocols, compatible with many protocols; the data is standardized and structured).

[0082] 2. Build a semantic mapping engine: The semantic mapping engine is responsible for dynamically mapping the raw fields output by the protocol parser to VUDM objects. Its core modules include: Mapping configuration loader: Reads mapping configuration files in JSON / YAML format and builds a mapping rule table; Expression executor: Supports JavaScript / SpEL expressions and enables dynamic calculation (e.g., (value-32)*5 / 9); Unit converter: Built-in unit conversion rules (e.g., mph→km / h, °F→°C); Enumeration Standardizer: Maps enumeration values ​​from different protocols to a unified standard value (e.g., 1 → "OPEN", "open" → "OPEN"). Conditional filters: support conditional expressions (such as ifprotocol=="UDS"andfield=="dtc"); Hot update listener: Monitors configuration file changes and automatically reloads mapping rules without requiring a service restart.

[0083] 3. Define the semantic mapping configuration file: The mapping configuration file uses YAML or JSON format, and each rule contains source field definitions and target VUDM field definitions: mappings: -source: protocol:"UDS_0x22"#Original Protocol ID field:"engine_temp_raw"# Original field name target: metric:"engine_temperature"#Standardized metric name unit: "°C"# Standardized unit expression: "value*0.1" # Expression: Original value 856 → 85.6°C quality: "good" # Default quality level -source: protocol: "MQTT_OBD" field:"speed_mph" target: metric: "vehicle_speed" unit: "km / h" expression:"value*1.60934"#mph→km / h -source: protocol: "CAN_0x301" field:"door_status" target: metric:"door_status" unit:"enum" expression:"value==1?'OPEN':'CLOSED'" 4. System workflow: Protocol parsers (such as PDM engines) output raw field objects: {protocol:"UDS_0x22",field:"engine_temp_raw",value:856} The semantic mapping engine matches mapping rules based on protocol + field; Perform expression calculations, unit conversions, and enumeration mappings; Generate standard VUDM objects: { "deviceId":"ECU_ENGINE_01", "timestamp":1747382400000, "metric":"engine_temperature", "value":85.6, "unit":"°C", "quality":"good", "sourceProtocol":"UDS_0x22" } Output to a message queue (Kafka / RabbitMQ) or directly push to the business system; Business systems consume VUDM data without needing to be aware of the underlying protocol details.

[0084] 5. Supports integration with Protocol Description Model (PDM): This application can be used in conjunction with the PDM (Protocol Description Model) method for dynamic parsing of multiple protocols in vehicle-to-everything (V2X) communication: The PDM engine is responsible for parsing the protocol and raw fields. This application is responsible for the semantic mapping of raw fields to VUDM; A dual-model architecture of "PDM+VUDM" is formed to achieve end-to-end conversion from raw byte stream to unified semantic model.

[0085] 6. Model Registry Center and Version Management: (1) Establish a VUDM indicator registry center for unified management: A dictionary of indicator names (e.g., engine_temperature, vehicle_speed); Unit systems (e.g., °C, km / h, rpm); Enumeration value criteria (e.g., door_status:OPEN / CLOSED); Data quality definition; (2) Supports VUDM model version management (such as v1.0, v2.0), and different versions can be bound to different devices.

[0086] The vehicle network data processing system provided in this application has the following significant advantages: 1. Complete decoupling of protocols and business logic: Adding a new protocol only requires adding mapping configuration, with zero modification to the business code; 2. Highly unified data semantics: The same physical quantity uses a unified index name, unit, and enumeration value, supporting cross-protocol aggregation analysis; 3. The upper-layer platform is completely unaware: the business system only needs to be developed for VUDM, shielding it from the complexity of the underlying protocol; 4. Supports dynamic semantic calculation: Unit conversion, scaling, and conditional mapping are implemented through the expression engine; 5. Hot update capability: Mapped configurations take effect within seconds, ensuring 24 / 7 business continuity; 6. Reduce development and maintenance costs: Business development efficiency increased by 50%+, and test case reuse rate increased by 80%+; 7. Supports AI and rule engines: Standardized semantic models facilitate machine learning feature engineering and business rule writing; 8. High scalability: Supports custom extensions through metadata fields, ensuring compatibility with future new metrics and protocols.

[0087] Based on the same inventive concept, this application also provides a vehicle network data processing system corresponding to the vehicle network data processing method. Since the principle of the system in this application is similar to the vehicle network data processing method described above in this application, the implementation of the system can refer to the implementation of the method, and the repeated parts will not be described again.

[0088] Reference Figure 5 As shown, this application provides a vehicle network data processing system, including: a target interface, a protocol parser, a semantic mapping engine, and an object generator; wherein, The target interface 501 is used to receive protocol messages from different vehicle terminals; Protocol parser 502 is used to determine the protocol type of the protocol message and call the parsing rules that match the protocol type to parse the protocol message and obtain the first key field data; The semantic mapping engine 503 is used to determine whether there are target processing logic rules for each original protocol and target structure in the combined protocol information based on the combined protocol information corresponding to the vehicle network data. If not, it queries and reads the first mapping configuration file that matches the combined protocol information from the configuration file library, constructs the target processing logic rules based on the configuration data in the first mapping configuration file, and processes the first key field data into target vehicle network data that matches the target structure according to the target processing logic rules. If it exists, it directly processes the first key field data into target vehicle network data that matches the target structure according to the target processing logic rules. Object generator 504 is used to generate a unified data model object for the Internet of Vehicles based on the target structure and the target Internet of Vehicles data, and send the unified data model object to the business system.

[0089] Furthermore, the vehicle network data processing system provided in this application embodiment determines the first mapping configuration file through the following method: Based on the combined protocol information corresponding to the vehicle network data, the storage address matching the combined protocol information is queried from the pre-configured file search manual, and the second mapping configuration file is obtained from the storage address; Based on the attribute information and operation behavior information of the second mapping configuration file, determine the target verification method for the second mapping configuration file; The second mapping configuration file is verified according to the target verification method, and a verification pass flag is added to the second mapping configuration file that passes the verification to obtain the first mapping configuration file.

[0090] Furthermore, the vehicle network data processing system provided in this application embodiment dynamically loads the second mapping configuration file in the following manner to achieve uninterrupted service updates and ensure data consistency, specifically including: Loading timing control: Combining real-time query per second (QPS), CPU utilization, and queue backlog, configuration loading is triggered when the system load is below a preset threshold; and it supports loading new configurations in batches by device type, tenant ID, or protocol type, including applying the configuration to a preset proportion of non-core devices, and then fully promoting it after observing for a preset period of time without any abnormalities. Atomicity and version management: New configurations are loaded into an independent memory area. After verification, the pointer is atomically switched to point to the new version. Old configurations are released asynchronously after they are no longer referenced. Each load generates a unique version ID. If the new configuration causes the error rate to increase, it can be rolled back to the previous stable version. Loading and scheduling optimization: Configuration loading is handled by an independent thread pool, which does not block I / O threads; only modified mapping rule fragments are reloaded, instead of the full configuration; configuration is read from the local disk / memory cache first, and the latest version is asynchronously pulled from the remote server in the background to achieve fast startup and eventual consistency; Observability and circuit breaker fallback: Record the time taken for each loading, the number of successes / failures, the trigger source and the affected protocol type to generate observability metrics; if three consecutive loading failures occur, automatically pause automatic updates and issue an alarm to prevent incorrect configurations from repeatedly impacting the system; and when loading fails, continue to use the currently effective configuration and record error logs to ensure business continuity.

[0091] Furthermore, in the vehicle network data processing system provided in this application embodiment, the step of determining the target verification method for the second mapping configuration file based on the attribute information and operation behavior information of the second mapping configuration file includes: Based on the operation behavior information of the second mapping configuration file, it is determined whether the second mapping configuration file meets the scene verification conditions. If it does, the first verification method matching the scene verification conditions is obtained. If it does not meet, the first verification method is not obtained. The second mapping configuration file meeting the scene verification conditions includes reading the second mapping configuration file for the first time or the time since the last scene verification being greater than a preset time. Based on the attribute information of the second mapping configuration file, determine the second verification method that matches the attribute information; The first verification method and the second verification method are determined as the target verification method; or, the second verification method is determined as the target verification method.

[0092] Furthermore, in the vehicle network data processing system provided in this application embodiment, the second mapping configuration file includes configuration data; when verifying the second mapping configuration file, the second mapping configuration file is parsed into structured data in computer memory; The first verification method includes: verifying the correctness of the physical characteristics of the vehicle network data, the feasibility of the vehicle network data business logic, and the security of the vehicle network data for the structured data in the second mapping configuration file; The second verification method includes: pre-processing of syntax and semantic verification and sandbox simulation verification. Pre-processing of syntax and semantic verification includes: performing JSON / YAML format validity checks, field mapping path existence checks, and circular dependency detection before loading. Sandbox simulation verification includes: using historical message samples to test the new configuration in an isolated environment to verify whether the output model meets expectations.

[0093] Furthermore, the vehicle network data processing system provided in this application embodiment includes verifying the vehicle network data security of the structured data in the second mapping configuration file, including: In the unified data model registry center, security compliance metadata is defined for the target metrics. The security compliance metadata includes the data classification tags of the target metrics and the identifiers of the data processing components that must be associated with them. After loading the semantic mapping rules in the second mapping configuration file, the system retrieves the policy metadata corresponding to the target metric from the registry center and determines whether the data category label of the target metric belongs to a predefined controlled data category. If it does, the system further verifies whether the configuration of the semantic mapping rule has correctly associated with the data processing component that must be associated as specified in the policy metadata. If it is not correctly associated, the system determines that the verification has failed and prevents the semantic mapping rule from taking effect or issues a security alert. The semantic mapping rule defines the mapping relationship from the data source to the target metric and includes reference information to the data processing component.

[0094] Furthermore, the vehicle network data processing system provided in this application embodiment, wherein the step of constructing the target processing logic rule based on the configuration data in the first mapping configuration file, and processing the first key field data into target vehicle network data matching the target structure according to the target processing logic rule, includes: A rule execution network is constructed in memory, which includes at least: a rule hash table: the key of which is a composite key generated by concatenating the protocol identifier of the original protocol and the original field name, and the value of which is the corresponding target mapping rule and the pre-compiled executable unit; a condition judgment tree: used to organize and manage mapping rules containing conditional expressions, the nodes of the tree are condition judgment logic, and the leaf nodes are the corresponding mapping rule sets; The first key field data is used as the raw data input, and the semantic mapping engine performs matching and retrieval in the rule hash table based on the composite key generated by its protocol identifier and the original field name. If a match is successful, the semantic mapping engine executes a predefined programmable data transformation process to generate standard data for the target structure. The programmable data transformation process includes at least numerical calculations based on configuration expressions. If a match fails, the engine traverses the conditional judgment tree to find matching conditional rules, executes the pre-compiled executable unit corresponding to the matching rule, and generates standard data for the target structure.

[0095] Furthermore, in the vehicle network data processing system provided in this application embodiment, the pre-compiled executable unit includes: an expression executor, a unit converter, an enumeration normalizer, a conditional filter, and a hot update listener; the pre-compiled executable unit corresponding to the execution matching rule generates standard data of the target structure, including: The expression executor executes user-defined expressions to dynamically calculate, transform, or logically process the original field values, generating the values ​​of the target VUDM fields. The unit converter provides standardized unit conversion capabilities, automatically converting non-standard units in the raw data into uniform units defined in the VUDM model; The enumeration normalizer maps enumeration values ​​from different protocols to unified semantic enumeration values ​​defined in the VUDM model; the enumeration values ​​include at least: status codes, text descriptions, and Boolean values; The conditional filter determines whether to map or filter a certain piece of data based on user-defined conditional expressions, and supports complex combinations of multiple conditions. The hot update listener monitors for changes to the semantic mapping configuration file and automatically reloads the mapping rules when a change is detected, without requiring a system restart.

[0096] Furthermore, the vehicle network data processing system provided in this application embodiment further includes a protocol fingerprint extraction module, a templated mapping module, and a mode switching control module in the unified data model; the method further includes: The control mode switching control module is used to switch from the current mode to the high-performance degradation mode in response to the server's real-time load index for processing the protocol messages meeting the mode switching conditions or in response to the trigger operation of the mode switching switch by a user with specified permissions. The protocol fingerprint extraction module, the templated mapping module, and the asynchronous fallback verification module obtain target vehicle network data that matches the target structure in the protocol message under the high-performance degradation mode; The determination that the real-time load indicators of the protocol message processing meet the mode switching conditions includes: real-time monitoring of the server's throughput, CPU utilization, memory usage, and queue backlog for protocol messages; when at least one of the protocol message throughput, CPU utilization, memory usage, and queue backlog is detected to meet the corresponding threshold conditions within a unit time, and the current business context does not belong to a non-critical data scenario, it is determined that the real-time load indicators of the protocol message processing meet the mode switching conditions. The protocol fingerprint extraction module uses a pre-trained lightweight model to extract the message header and key fields to generate a protocol fingerprint. The key fields include: device ID, message type, and timestamp. The templated mapping module uses an offline-trained time-series prediction model to fill in the missing data of the key fields and matches a predefined unified model template according to the protocol fingerprint, outputting the processing result through the unified model template. The asynchronous fallback verification module puts the processing result into a low-priority queue, which is then verified and corrected by a background task to obtain the target vehicle network data.

[0097] The semantic mapping engine includes a mapping configuration loader, an expression executor, a unit converter, an enumeration normalizer, a conditional filter, and a hot update listener, and executes the corresponding core content based on these execution units.

[0098] like Figure 6 As shown in the embodiment of this application, an electronic device 600 includes a processor 601, a memory 602, and a bus. The memory 602 stores machine-readable instructions executable by the processor 601. When the electronic device is running, the processor 601 communicates with the memory 602 via the bus, and the processor 601 executes the machine-readable instructions to perform the steps of the above-described vehicle network data processing method.

[0099] Specifically, the aforementioned memory 602 and processor 601 can be general-purpose memory and processor, without any specific limitations. When the processor 601 runs the computer program stored in the memory 602, it can execute the aforementioned method for processing vehicle network data.

[0100] Corresponding to the above-described method for processing vehicle network data, this application embodiment also provides a computer-readable storage medium storing a computer program, which, when run by a processor, executes the steps of the above-described method for processing vehicle network data.

[0101] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system described above can be referred to the corresponding process in the method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed system and method can be implemented in other ways. The system embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection can be an indirect coupling or communication connection through some communication interfaces, devices, or modules, and can be electrical, mechanical, or other forms.

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

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

[0104] 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, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0105] 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 processing vehicle network data, characterized in that, Applied to a unified data model, the unified data model includes: a target interface, a protocol parser, a semantic mapping engine, and an object generator; the method includes: Based on the target interface, protocol messages from different vehicle terminals are received. The protocol parser determines the protocol type of the protocol message and calls the parsing rules that match the protocol type to parse the protocol message and obtain the first key field data. The protocol message includes vehicle network data. The semantic mapping engine determines whether there are target processing logic rules for each original protocol and target structure in the combined protocol information based on the combined protocol information corresponding to the vehicle network data. If it does not exist, then query and read the first mapping configuration file that matches the combined protocol information from the configuration file library, construct the target processing logic rule based on the configuration data in the first mapping configuration file, and process the first key field data into target vehicle network data that matches the target structure according to the target processing logic rule; if it exists, then directly process the first key field data into target vehicle network data that matches the target structure according to the target processing logic rule. The object generator generates a unified data model object for the Internet of Vehicles based on the target structure and the target Internet of Vehicles data, and then sends the unified data model object to the business system.

2. The method for processing vehicle network data according to claim 1, characterized in that, The first mapping configuration file is determined by the following methods: Based on the combined protocol information corresponding to the vehicle network data, the storage address matching the combined protocol information is queried from the pre-configured file search manual, and the second mapping configuration file is obtained from the storage address; Based on the attribute information and operation behavior information of the second mapping configuration file, determine the target verification method for the second mapping configuration file; The second mapping configuration file is verified according to the target verification method, and a verification pass flag is added to the second mapping configuration file that passes the verification to obtain the first mapping configuration file.

3. The method for processing vehicle network data according to claim 2, characterized in that, The second mapping configuration file is dynamically loaded in the following manner to ensure uninterrupted service updates and data consistency, specifically including: Loading timing control: Combining real-time query per second (QPS), CPU utilization, and queue backlog, configuration loading is triggered when the system load is below a preset threshold; and it supports loading new configurations in batches by device type, tenant ID, or protocol type, including applying the configuration to a preset proportion of non-core devices, and then fully promoting it after observing for a preset period of time without any abnormalities. Atomicity and version management: New configurations are loaded into an independent memory area. After verification, the pointer is atomically switched to point to the new version. Old configurations are released asynchronously after they are no longer referenced. Each load generates a unique version ID. If the new configuration causes the error rate to increase, it can be rolled back to the previous stable version. Loading and scheduling optimization: Configuration loading is handled by an independent thread pool, which does not block I / O threads; only modified mapping rule fragments are reloaded, instead of the full configuration; configuration is read from the local disk / memory cache first, and the latest version is asynchronously pulled from the remote server in the background to achieve fast startup and eventual consistency; Observability and circuit breaker fallback: Record the time taken for each loading, the number of successes / failures, the trigger source and the affected protocol type to generate observability metrics; if three consecutive loading failures occur, automatically pause automatic updates and issue an alarm to prevent incorrect configurations from repeatedly impacting the system; and when loading fails, continue to use the currently effective configuration and record error logs to ensure business continuity.

4. The method for processing vehicle network data according to claim 2, characterized in that, The step of determining the target verification method for the second mapping configuration file based on the attribute information and operation behavior information of the second mapping configuration file includes: Based on the operation behavior information of the second mapping configuration file, it is determined whether the second mapping configuration file meets the scene verification conditions. If it does, the first verification method matching the scene verification conditions is obtained. If it does not meet, the first verification method is not obtained. The second mapping configuration file meeting the scene verification conditions includes reading the second mapping configuration file for the first time or the time since the last scene verification being greater than a preset time. Based on the attribute information of the second mapping configuration file, determine the second verification method that matches the attribute information; The first verification method and the second verification method are determined as the target verification method; or, the second verification method is determined as the target verification method.

5. The method for processing vehicle network data according to claim 4, characterized in that, The second mapping configuration file includes configuration data; when validating the second mapping configuration file, the second mapping configuration file is parsed into structured data in computer memory; The first verification method includes: verifying the correctness of the physical characteristics of the vehicle network data, the feasibility of the vehicle network data business logic, and the security of the vehicle network data for the structured data in the second mapping configuration file; The second verification method includes: pre-processing of syntax and semantic verification and sandbox simulation verification. Pre-processing of syntax and semantic verification includes: performing JSON / YAML format validity checks, field mapping path existence checks, and circular dependency detection before loading. Sandbox simulation verification includes: using historical message samples to test the new configuration in an isolated environment to verify whether the output model meets expectations.

6. The method for processing vehicle network data according to claim 3, characterized in that, in, Verification of vehicle-to-everything (V2X) data security is performed on the structured data in the second mapping configuration file, including: In the unified data model registry center, security compliance metadata is defined for the target metrics. The security compliance metadata includes the data classification tags of the target metrics and the identifiers of the data processing components that must be associated with them. After loading the semantic mapping rules in the second mapping configuration file, the system retrieves the policy metadata corresponding to the target metric from the registry center and determines whether the data category label of the target metric belongs to a predefined controlled data category. If it does, the system further verifies whether the configuration of the semantic mapping rule has correctly associated with the data processing component that must be associated as specified in the policy metadata. If it is not correctly associated, the system determines that the verification has failed and prevents the semantic mapping rule from taking effect or issues a security alert. The semantic mapping rule defines the mapping relationship from the data source to the target metric and includes reference information to the data processing component.

7. The method for processing vehicle network data according to claim 1, characterized in that, The step of constructing the target processing logic rules based on the configuration data in the first mapping configuration file, and processing the first key field data into target vehicle network data matching the target structure according to the target processing logic rules, includes: A rule execution network is constructed in memory, which includes at least: a rule hash table: the key of which is a composite key generated by concatenating the protocol identifier of the original protocol and the original field name, and the value of which is the corresponding target mapping rule and the pre-compiled executable unit; a condition judgment tree: used to organize and manage mapping rules containing conditional expressions, the nodes of the tree are condition judgment logic, and the leaf nodes are the corresponding mapping rule sets; The first key field data is used as the raw data input, and the semantic mapping engine performs matching and retrieval in the rule hash table based on the composite key generated by its protocol identifier and the original field name. If a match is successful, the semantic mapping engine executes a predefined programmable data transformation process to generate standard data for the target structure. The programmable data transformation process includes at least numerical calculations based on configuration expressions. If a match fails, the engine traverses the conditional judgment tree to find matching conditional rules, executes the pre-compiled executable unit corresponding to the matching rule, and generates standard data for the target structure.

8. The method for processing vehicle network data according to claim 7, characterized in that, The pre-compiled executable unit includes: an expression executor, a unit converter, an enumeration normalizer, a conditional filter, and a hot update listener; the pre-compiled executable unit corresponding to the execution matching rule generates standard data for the target structure, including: The expression executor executes user-defined expressions to dynamically calculate, transform, or logically process the original field values, generating the values ​​of the target VUDM fields. The unit converter provides standardized unit conversion capabilities, automatically converting non-standard units in the raw data into uniform units defined in the VUDM model; The enumeration normalizer maps enumeration values ​​from different protocols to unified semantic enumeration values ​​defined in the VUDM model; the enumeration values ​​include at least: status codes, text descriptions, and Boolean values; The conditional filter determines whether to map or filter a certain piece of data based on user-defined conditional expressions, and supports complex combinations of multiple conditions. The hot update listener monitors for changes to the semantic mapping configuration file and automatically reloads the mapping rules when a change is detected.

9. The method for processing vehicle network data according to claim 1, characterized in that, The unified data model further includes a protocol fingerprint extraction module, a templated mapping module, and a mode switching control module; the method further includes: When the real-time load metric of the protocol message processing by the response server meets the mode switching condition or when a user with specified permissions triggers the mode switching switch, the control module switches from the current mode to the high-performance degradation mode. In the high-performance degradation mode, target vehicle network data matching the target structure in the protocol message is obtained through the protocol fingerprint extraction module, the templated mapping module, and the asynchronous fallback verification module. The determination that the real-time load indicators of the protocol message processing meet the mode switching conditions includes: real-time monitoring of the server's throughput, CPU utilization, memory usage, and queue backlog for protocol messages; when at least one of the protocol message throughput, CPU utilization, memory usage, and queue backlog is detected to meet the corresponding threshold conditions within a unit time, and the current business context does not belong to a non-critical data scenario, it is determined that the real-time load indicators of the protocol message processing meet the mode switching conditions. The protocol fingerprint extraction module uses a pre-trained lightweight model to extract the message header and key fields to generate a protocol fingerprint. The key fields include: device ID, message type, and timestamp. The templated mapping module uses an offline-trained time-series prediction model to fill in the missing data of the key fields and matches a predefined unified model template according to the protocol fingerprint, outputting the processing result through the unified model template. The asynchronous fallback verification module puts the processing result into a low-priority queue, which is then verified and corrected by a background task to obtain the target vehicle network data.

10. A vehicle networking data processing system, characterized in that, include: The target interface, protocol parser, semantic mapping engine, and object generator; among them, The target interface is used to receive protocol messages from different vehicle terminals; The protocol parser is used to determine the protocol type of the protocol message and to parse the protocol message by calling the parsing rules that match the protocol type to obtain the first key field data; the protocol message includes vehicle network data; The semantic mapping engine is used to determine whether there are target processing logic rules for each original protocol and target structure in the combined protocol information based on the combined protocol information corresponding to the vehicle network data. If not, it queries and reads the first mapping configuration file that matches the combined protocol information from the configuration file library, constructs the target processing logic rules based on the configuration data in the first mapping configuration file, and processes the first key field data into target vehicle network data that matches the target structure according to the target processing logic rules. If it exists, it directly processes the first key field data into target vehicle network data that matches the target structure according to the target processing logic rules. The object generator is used to generate a unified data model object for the Internet of Vehicles based on the target structure and the target Internet of Vehicles data, and then send the unified data model object to the business system.

Images