Automobile data cross-border detection system based on multi-source data fusion

Abstract

The application discloses a car data cross-border detection system based on multi-source data fusion, and particularly relates to the technical field of data cross-border detection, and comprises the following steps: setting multiple data nodes, collecting real-time car multi-source heterogeneous data; receiving multi-source heterogeneous data, preprocessing the collected multi-source heterogeneous data, and generating cross-border transmission suspicion events; analyzing the cross-border transmission suspicion events through a machine learning model, and outputting cross-border transmission suspicion event detection results; quantitatively scoring and grading the detection results; generating a visualized traceability atlas according to the quantitative scoring and grading, and thus realizing car data cross-border detection. Through the data collection module, the data fusion processing module, the intelligent analysis and judgment module, the dynamic risk rating module and the visualized response module, the application solves the problems of narrow detection coverage, insufficient accuracy, poor flexibility, low supervision convenience and the like in the prior art.

Description

Technical Field

[0001] This invention relates to the field of cross-border data detection technology, and more specifically, to a cross-border vehicle data detection system based on multi-source data fusion. Background Technology

[0002] With the increasing intelligence and connectivity of automobiles, cross-border data transmission scenarios are becoming more frequent, covering various sensitive data such as vehicle location information, user data, and vehicle status. The security and compliance of this transmission have become core regulatory requirements. Current cross-border vehicle data detection technologies mainly revolve around single-node data collection and fixed-rule judgment. One type of technology relies on a single node, the vehicle terminal, to collect data and uses a pre-set blacklist of overseas IP addresses for matching and judgment. This only captures data transmission behavior directly sent from the vehicle terminal to overseas IP addresses, without considering data from multiple links such as communication networks and cloud platforms. Another type of solution deploys DPI devices at communication network nodes to capture data packets and judges violations based on whether the IP address's location matches the data type, but it does not perform correlation verification of data from vehicle terminals and cloud platforms.

[0003] However, the aforementioned existing technical solutions still have the following technical drawbacks in practical use: First, the data source is singular and incomplete: Solution 1 relies solely on vehicle terminal data, failing to capture data transmission behavior in the communication network and cloud platform, resulting in missing data across the entire link; Solution 2 only monitors from the network side, lacking the association between vehicle identification number (VIN) and data content, making it difficult to accurately bind transmission behavior to specific vehicles; Second, the data heterogeneity processing capability is weak: Existing systems do not perform unified preprocessing and format conversion for multi-source heterogeneous data, such as vehicle terminals, network traffic, and cloud logs, leading to problems such as format conflicts and missing fields among data records, affecting the accuracy of subsequent analysis; Third, the correlation and fusion mechanism is lacking: Existing technologies lack multi-source data correlation and fusion based on vehicle, time, and IP dimensions, failing to construct a complete transmission time-series link and making it difficult to identify complex cross-border transmission patterns across nodes and time periods; Fourth, the detection rules are static and have poor adaptability: Detection methods based on fixed rules cannot learn complex patterns in historical data, and their ability to identify new cross-border transmission behaviors, such as frequent IP switching and batch data transmission, is insufficient, resulting in high false alarm and false negative rates.

[0004] The aforementioned technical deficiencies result in existing cross-border vehicle data detection systems having problems such as narrow detection coverage, insufficient accuracy, poor flexibility, and low regulatory convenience. They cannot meet the precise regulatory needs in complex cross-border transmission scenarios, and there is an urgent need for a comprehensive detection solution that integrates multi-source data, intelligent analysis, dynamic rating, and visual traceability. Summary of the Invention

[0005] To overcome the aforementioned deficiencies of the prior art, the present invention provides a cross-border vehicle data detection system based on multi-source data fusion, which solves the problems mentioned in the background art through the following solutions.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a cross-border vehicle data detection system based on multi-source data fusion, comprising:

[0007] Data acquisition module: Sets up multiple data nodes to collect multi-source heterogeneous data of the vehicle in real time. The data nodes include vehicle terminals, communication networks and cloud platforms. The multi-source heterogeneous data includes vehicle identification, data content feature tags, transmission timestamps and IP addresses.

[0008] Data fusion and processing module: Receives multi-source heterogeneous data, preprocesses the collected multi-source heterogeneous data to form data records in a unified format, and correlates and merges the data records to generate suspected cross-border transmission events;

[0009] Intelligent analysis and judgment module: It is communicatively connected to the data fusion and processing module, analyzes the suspected cross-border transmission events through a machine learning model, and outputs the detection results of the suspected cross-border transmission events, including the risk level and the chain of evidence;

[0010] Dynamic risk rating module: It communicates with the intelligent analysis and judgment module, receives the detection results, and performs quantitative scoring and level classification by comprehensively considering data content feature tags, IP address, risk level, and evidence chain;

[0011] Visualization Response Module: Communicates with the dynamic risk rating module and generates a visual traceability map based on quantitative scoring and level classification. The visual traceability map dynamically displays the entire cross-border data link of automobiles with the transmission timestamp as the horizontal axis and the data nodes as the vertical axis, and marks the illegal links in the entire link with red boxes.

[0012] The technical effects and advantages of this invention are as follows:

[0013] This invention achieves multi-source heterogeneous data collection across the entire cross-border transmission link of vehicle data by setting up three major data nodes: vehicle terminal, communication network and cloud platform. It overcomes the problems of incomplete data coverage and difficulty in binding to specific vehicles caused by relying on a single node in the prior art.

[0014] This invention uses the machine learning model XGBoost+SHAP to analyze suspected cross-border transmission events. It can learn complex patterns from historical data and identify new cross-border behaviors that are difficult to capture by traditional rules, such as frequent IP switching and batch data transmission, effectively reducing the false alarm rate and false negative rate.

[0015] This invention uses a dynamic risk rating module to quantify and classify the detection results, comprehensively considering multi-dimensional features such as data content, IP attributes, and evidence chains, and outputs interpretable risk levels and key evidence to provide accurate basis for regulatory decisions.

[0016] This invention constructs a closed-loop detection system covering the entire chain from data acquisition, fusion processing, intelligent analysis, dynamic rating to visual response. It realizes end-to-end monitoring and response to cross-border transmission of vehicle data, meets the comprehensive regulatory needs in complex cross-border scenarios, and has strong engineering feasibility and promotional application value. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the system module structure of the present invention.

[0018] Figure 2 This is a schematic diagram of the data fusion processing module of the present invention.

[0019] Figure 3 This is a schematic diagram of the intelligent analysis and judgment module of the present invention.

[0020] Figure 4 This is a schematic diagram of the dynamic risk rating module of the present invention.

[0021] Figure 5 This is a schematic diagram of the structure of the visual response module of the present invention. Detailed Implementation

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

[0023] Please see Figures 1-5 As shown, this embodiment of the invention provides a cross-border vehicle data detection system based on multi-source data fusion. Through a data acquisition module, a data fusion processing module, an intelligent analysis and judgment module, a dynamic risk rating module, and a visualization response module, it achieves cross-border detection of vehicle data. The system includes:

[0024] The data acquisition module is equipped with multiple data nodes to collect multi-source heterogeneous data from the vehicle in real time. The data nodes include an in-vehicle terminal, a communication network, and a cloud platform. The multi-source heterogeneous data includes vehicle identification, data content feature tags, transmission timestamps, and IP addresses.

[0025] This embodiment requires a detailed explanation of the specific process for setting up multiple data nodes, as follows:

[0026] A101: Deployment of Vehicle-Mounted Terminal Nodes

[0027] Hardware selection: Select a suitable data acquisition terminal based on the vehicle type, which includes fuel vehicles and new energy vehicles. Select an on-board OBD interface data acquisition device with an integrated CAN bus interface. This acquisition device should have a 4G / 5G communication module and a local storage unit.

[0028] Installation and connection: Connect the terminal to the vehicle via the OBD interface or the vehicle bus CAN, configure the communication protocol between the terminal and the vehicle ECU, and ensure that the vehicle identification VIN code and GPS positioning data information are read.

[0029] Network configuration: Configure the APN for the terminal and bind the fixed IP of the SIM card to ensure two-way communication between the terminal and the communication network or cloud platform.

[0030] A102: Deployment of Communication Network Nodes

[0031] Access point selection involves cooperating with telecommunications operators to deploy edge computing nodes in high-frequency activity areas such as highway networks and cross-border ports, and accessing vehicle communication data through the signaling monitoring gateway (SGW) of the operator's core network.

[0032] The data capture device deploys DPI detection equipment and captures communication data packets from vehicle terminals, the cloud, and cross-domain servers through port mirroring technology. It parses the IP header of the data packets, which includes: source IP address, destination IP address, and transport layer protocol field.

[0033] Protocol adaptation: Configure DPI devices to recognize the vehicle-specific DoIP protocol to ensure that the vehicle identification number (VIN) can be extracted from non-standard data packets.

[0034] A103: Cloud Platform Node Deployment

[0035] The server architecture uses the Elastic ECS computing service from a cloud service provider to build cloud nodes, configures distributed storage and time-series databases, and deploys an API gateway as the data access point.

[0036] Interface development involves developing two types of interfaces: one is the vehicle terminal access interface, and the other is the communication network node data synchronization interface.

[0037] Identity authentication involves configuring device interfaces for connected vehicle terminals and communication network nodes, and verifying identities through two-way TLS to prevent unauthorized nodes from accessing the network.

[0038] This embodiment requires specific explanation of the real-time acquisition process of multi-source heterogeneous vehicle data as follows:

[0039] A104: Standardized Collection of Multi-Source Heterogeneous Data in Automobiles

[0040] Vehicle Identification A 17-digit alphanumeric VIN code is uniformly used. If the vehicle terminal cannot read the VIN directly, it will be read indirectly through the binding relationship between the terminal device number and the vehicle.

[0041] Data content feature tags Define feature label enumeration values, which include vehicle location information, vehicle status information, and user data. The labels are matched by each node based on the data content.

[0042] Transmission timestamp The time format is uniformly UTC, accurate to milliseconds, and generated by the local clock of the acquisition node;

[0043] IP address It can distinguish between source IP addresses and destination IP addresses, and supports storing IP address data in both IPv4 and IPv6 formats.

[0044] A105: Configuration of Acquisition Frequency and Trigger Conditions

[0045] The vehicle-mounted terminal node has a default data collection frequency of 100ms / time. When GPS locates the area within 10km of the border, it triggers a high-frequency data collection of 50ms / time to determine that the vehicle is traveling on a cross-border road.

[0046] Communication network nodes collect data according to the communication session cycle. Each time a UDP session is established, session metadata is collected once. The session metadata includes: source IP address, destination IP address, and collection timestamp. Sessions with destination IP addresses in overseas network segments are tracked and recorded.

[0047] The cloud platform node receives data uploaded by the vehicle terminal in real time, and scans the API gateway every 5 minutes to extract multi-source heterogeneous vehicle data that has not been captured by the terminal node or network node.

[0048] The data fusion and processing module receives multi-source heterogeneous data, preprocesses the collected multi-source heterogeneous data to form data records in a unified format, and correlates and merges the data records to generate suspected cross-border transmission events.

[0049] This embodiment requires specific explanation of the preprocessing of the collected multi-source heterogeneous data:

[0050] B101: Multi-source heterogeneous data reception and verification

[0051] Multi-source heterogeneous data access: A unified receiving port is designed to support concurrent processing of multi-source heterogeneous data in vehicles, taking into account different transmission methods of vehicle terminals, communication networks, and cloud platforms;

[0052] Format validation: Perform core field validation on the received heterogeneous multi-source vehicle data to determine the vehicle identifier. Data content feature tags Transmission timestamp IP address If any core field data is missing, it is marked as invalid data and stored in the exception data pool.

[0053] B102: Handling Missing Data

[0054] If the core field is missing, such as the vehicle identifier If the VIN is missing, it can be determined by checking the source IP address and transmission timestamp. Perform reverse matching, which is the mapping relationship between the vehicle terminal IP and VIN. If the matching fails, the data is marked as needing to be completed. If the data is not completed within 24 hours, the data will be removed.

[0055] If non-core fields are missing, such as data content feature tags If a missing data is found, it will be automatically filled in by parsing the data content, such as extracting location information from GPS latitude and longitude data; if the destination IP address is missing due to some vehicle terminal data not being reported, the source IP address of the same VIN with a similar transmission timestamp will be supplemented from the communication network node data.

[0056] B103: Outlier Identification and Correction

[0057] If a timestamp is abnormal, check whether the transmission timestamp falls within an unreasonable range. The unreasonable range includes timestamps that are earlier than the system deployment time or later than the current time by more than 30 minutes. For abnormal transmission timestamps, they need to be corrected by synchronizing the node clock of the data acquisition module. If the timestamp is still abnormal after correction, it is marked as an invalid transmission timestamp.

[0058] If an IP address is found to be abnormal, its format will be checked. IP addresses with incorrect formats need to be extracted again by parsing the original data packet. If extraction fails, the IP address will be marked as invalid.

[0059] If data content feature tags conflict, and the same data is simultaneously tagged as both location information and IP address, the tags will be corrected through secondary parsing of the data content.

[0060] B104: Data records that form a uniform format

[0061] The data processed by B102 and B103 are converted to a unified field format to eliminate data heterogeneity.

[0062] Further explanation is needed regarding the format conversion. For vehicle terminal data, the same VIN is associated with the communication network node data, and the transmission timestamp is mapped to the target IP address at a speed of ±100ms. For communication network node data, the source IP address is matched with the terminal VIN, and the timestamp in the session data is used as the transmission timestamp. For cloud platform data, the access time of the API gateway is used as the transmission timestamp, the source IP address is the client IP, and the target IP address is the cloud server IP.

[0063] This embodiment requires specific explanation of the association and fusion of data records:

[0064] B105: Data Record Association Dimensions

[0065] Vehicles are associated using VINs, and data records with the same VIN are grouped into the same vehicle data set for tracking the full data transmission of a vehicle.

[0066] The time dimension is associated with transmission timestamps. For the same VIN, records with consecutive timestamps are associated as time-series links to identify the continuity of data transmission. For example, after the vehicle terminal sends location information, the communication network detects the transmission of data packets with the same VIN.

[0067] The IP dimension associates records based on their IP addresses, linking records with the same source IP address or the same destination IP address to identify cross-vehicle data transmissions from the same IP address.

[0068] B106: Related and Integrated Execution

[0069] Construct an association index table and use a graph database to store data relationships. Nodes are standardized data records and edges are association types, such as the same VIN, consecutive timestamps, and the same target IP address.

[0070] Multi-source cross-validation involves cross-validating the location information recorded by the vehicle terminal with the target IP recorded by the communication network node. If the same VIN exists in both types of records at similar timestamps, the association weight is strengthened.

[0071] B107: Suspected Cross-Border Transfer Incident Developed

[0072] Based on the data record association dimension, suspected cross-border transmission events are identified and generated according to preset rules for triggering suspected events. These preset rules include:

[0073] Rule 1: The target IP address belongs to an overseas IP range, and the data content feature tags include location information, user data, and vehicle status;

[0074] Rule 2: For the same VIN transmission timestamp, the target IP address of 3 or more consecutive records switches between domestic and foreign borders, such as first a domestic IP address, then a foreign IP address, and then a domestic IP address;

[0075] Rule 3: If an overseas target IP address receives location information data from ≥5 different VINs within 1 hour, it is considered a batch cross-border transmission of vehicle data.

[0076] A suspected event is triggered if any one of the above three types of rules is met. Each suspected event contains the following core information:

[0077] The VIN involved is the associated vehicle identifier; overseas IP information includes the target IP address and its country or region of origin; a set of content feature tags, which includes the content feature tags of all vehicle data involved; the event time range, including the earliest and latest transmission timestamps; and the triggering rule number, such as rule 1, rule 2, and rule 3.

[0078] Suspected incidents are recorded in a MySQL relational database and linked to the links in the graph data for subsequent tracing. The data is pushed to the intelligent analysis and judgment module in real time via REST API, along with the associated data, to provide analysis for the machine learning model.

[0079] The intelligent analysis and judgment module is communicatively connected to the data fusion and processing module. It analyzes the suspected cross-border transmission events through a machine learning model and outputs the detection results of the suspected cross-border transmission events, including the risk level and the chain of evidence.

[0080] This embodiment requires a detailed explanation of the machine learning model:

[0081] C101: Receive suspected cross-border data transfer incidents and perform model training. The model training includes training set construction and risk label definition. The training set source is...

[0082] Training set construction: Collect historical cross-border transfer event data, including confirmed violations (positive samples) and compliance (negative samples). The sample size should contain at least 100,000 labeled samples, with positive samples accounting for 30% and negative samples accounting for 70%.

[0083] Positive examples: Cases of illegal cross-border transmission of vehicle data as identified by regulatory agencies, such as sending sensitive location information to unregistered servers overseas, must include the event-related VIN, IP address, content feature tags, and transmission timestamp;

[0084] Negative samples: Verified compliant cross-border data transfer cases, such as automakers transferring anonymized vehicle data to overseas R&D centers and completing the filing process, as well as normal data transfer records without cross-border activities;

[0085] Risk label definition: for training set samples Risk level labeling includes:

[0086] High Risk A: Clearly violates regulations on cross-border data transmission, such as transmitting real-time location data from an unregistered overseas IP address without any data anonymization.

[0087] Medium Risk B: There are suspected violations, such as transmitting sensitive data overseas, but the company to which the source IP address belongs is registered, and the vehicle data transmission exceeds the scope of the registration.

[0088] Low-risk C: Compliant and low-risk behaviors include: first, transmitting non-sensitive data to registered overseas target IP addresses; second, performing anonymization processing on cross-border data transmission.

[0089] C102: Machine Learning Model Building

[0090] For all training sets Normalization is performed to generate a standardized training set. The standardized training set X is input into the machine learning model, which is constructed by combining a main model and an auxiliary model:

[0091] The main model uses the XGBoost gradient boosting tree model to output the risk level. Its advantages are strong ability to handle nonlinear features and good interpretability;

[0092] Further explanation is needed regarding the XGBoost gradient boosting tree model. XGBoost outputs the risk level through the ensemble of multiple decision trees. The decision function of a single tree is: in Indicates the first Parameters of the tree The standardized training set number is... The first tree leaf nodes This indicates the weight of the leaf node. Indicates an indicator function, This represents the value of a data point in the standardized training set;

[0093] Risk level after integration The formula for predicting the score is: in Represents the total number of ensemble trees, Indicates the first Trees to Rank The output;

[0094] Finally, the probabilities of each level are obtained by normalization using the softmax function: in Indicates a single risk level, or a predicted level. The category with the highest probability of a single risk level:

[0095] The auxiliary model adopts The value calculation model is responsible for quantifying the contribution of each feature to the risk level and supporting the generation of the evidence chain;

[0096] Further explanation is needed regarding the auxiliary model. The value calculation model transforms the correlation between risk levels into a risk score. in The feature weights learned by the XGBoost model are represented. This indicates the bias term, the mapping relationship between risk level and score:

[0097] The formula for calculating contribution is: in Indicates the standardized training set, This indicates the marginal contribution of the risk score;

[0098] C103: Model Training Process

[0099] Input the vector of the standardized training set Output risk level Training parameters: learning rate 0.1, tree depth 5, number of iterations 100, objective function is softmax multi-class logarithmic; optimization: parameters are adjusted through 5-fold cross-validation, with the F1-score of the validation set as the optimization objective, and the optimization objective is ≥0.9;

[0100] C104: Detection Results Generation

[0101] The risk level output directly uses the model prediction results. It also includes a confidence level, which is the model's prediction probability for that level;

[0102] Evidence chain generation, based on Contribution Ranking by contribution The training set elements, with the associated car data for each training set element as evidence: if Contribution Belongs to ranking If the training set elements are a given set, then the evidence chain includes the source IP address and the target IP address.

[0103] The dynamic risk rating module communicates with the intelligent analysis and judgment module, receives the detection results, and performs quantitative scoring and level classification by comprehensively considering data content feature tags, IP address, risk level, and evidence chain.

[0104] The dynamic risk rating module needs to further integrate multi-dimensional vehicle data, including data content feature tags, IP address risk attributes, evidence chains, and risk levels, based on the intelligent analysis and judgment module. This will enable a deeper shift from model-based risk prediction to quantitative dynamic rating, ensuring that the rating results are more aligned with actual regulatory scenarios.

[0105] D101: Input data reception:

[0106] Receive the output of the intelligent analysis and judgment module: risk level and evidence chain of suspected cross-border transmission events; standardized data records of the associated data fusion processing module: matching associated data (including data content feature tags, source IP / destination IP address, transmission timestamp, VIN, etc.) through event risk level.

[0107] D102: Output includes:

[0108] Basic event information: Event ID, VIN, transmission timestamp range, IP address and region; Quantitative scoring: Score for each risk level (e.g., A=55 points, B=70 points, etc.) and weight; Dynamic risk level: For example, if the risk level is medium, it may be low due to cross-border time adjustments; Key evidence chain: Select the top 3 training set elements with the greatest impact.

[0109] The visualization response module communicates with the dynamic risk rating module and generates a visualization traceability map based on the quantitative score and level classification. The visualization traceability map dynamically displays the entire cross-border link of automobile data with the transmission timestamp as the horizontal axis and the data node as the vertical axis, and marks the illegal links in the entire link with red boxes.

[0110] E101: Parameter Configuration for Visual Source Tracing Map

[0111] Coordinate axis configuration: Transmission timestamp horizontal axis, starting from the earliest transmission timestamp of the suspected cross-border incident and ending with the latest transmission timestamp, automatically adapting to the time span, such as transmissions within 10 minutes are scaled in minutes, and transmissions within 1 hour are scaled in 10-minute intervals; marking key time points, such as the time when vehicle data is sent from the vehicle terminal, the time when it is forwarded to the cloud, and the time when it is received overseas;

[0112] The data nodes are arranged vertically from top to bottom according to the vehicle terminal, communication network, and cloud platform. Each node corresponds to a fixed coordinate value, and the node name is marked on the left side of the vertical axis. The node style is represented by a rectangular icon, and the colors distinguish the node types, with vehicle terminals being blue, communication networks being green, and cloud platforms being purple.

[0113] E102: Dynamic Display of the Entire Cross-Border Automotive Data Link

[0114] Link connection: The direction of vehicle data flow is indicated by arrowed lines. For example, a solid arrow is used from the vehicle terminal to the communication network. The line color corresponds to the risk level, with blue for low risk, orange for medium risk, and red for high risk. The line thickness corresponds to the quantitative score, with thicker lines for higher scores.

[0115] Cross-border data labeling: Violations are marked with a red dashed box with a thickness of 2px and a blinking animation; the type of violation is displayed inside the box, such as unregistered IP address or sensitive data transmission.

[0116] Legend configuration: Add a legend to the right side of the graph, labeling node type, risk level color, and violation mark. The legend can be hidden by clicking and the element corresponding to the X can be displayed.

[0117] E103: Violations highlighted in red and emphasized in display

[0118] Coordinate matching: Based on the detection results calculated by the machine learning model, determine the corresponding node and transmission timestamp range of the suspected cross-border event, and generate the rectangular coordinates of the red box;

[0119] Red border drawing: Draw a red dashed border at the corresponding coordinates, with the border covering the violation node icon and the corresponding time.

[0120] Add a "violation of cross-border regulations" label to the link lines within the segment;

[0121] If there are multiple violations, such as vehicle-mounted terminals collecting sensitive data or cloud-based unregistered data transmission, then multiple red boxes will be marked, and the flashing frequency will be adjusted according to the risk level: high risk A twice per second, medium risk B once per second, and low risk C once every 5 seconds.

[0122] Evidence Chain Linkage: Clicking the red box will bring up a pop-up window showing the evidence chain details of illegal cross-border transmission, such as sensitive tags containing location information, user data, IP address registration status, and quantitative scores.

[0123] Secondly: The accompanying drawings of the embodiments disclosed in this invention only involve the structures involved in the embodiments disclosed in this invention. Other structures can refer to the general design. In the absence of conflict, the same embodiment and different embodiments of this invention can be combined with each other.

[0124] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A cross-border vehicle data detection system based on multi-source data fusion, characterized in that, include: Data acquisition module: Sets up multiple data nodes to collect multi-source heterogeneous data of the vehicle in real time. The data nodes include vehicle terminals, communication networks and cloud platforms. The multi-source heterogeneous data includes vehicle identification, data content feature tags, transmission timestamps and IP addresses. Data fusion and processing module: Receives multi-source heterogeneous data, preprocesses the collected multi-source heterogeneous data to form data records in a unified format, and correlates and merges the data records to generate suspected cross-border transmission events; Intelligent analysis and judgment module: Communicatively connected to the data fusion and processing module, it analyzes the suspected cross-border transmission events through a machine learning model and outputs the detection results of the suspected cross-border transmission events. The detection results include risk level and evidence chain. The evidence chain is based on SHAP contribution, and the top 3 training set elements in terms of contribution are selected. The vehicle data associated with each training set element is used as evidence. The vehicle data includes vehicle identification number (VIN), data content feature tag, transmission timestamp, and IP address. Dynamic risk rating module: It communicates with the intelligent analysis and judgment module, receives the detection results, and performs quantitative scoring and level classification by comprehensively considering data content feature tags, IP address, risk level, and evidence chain; Visualization Response Module: Communicates with the dynamic risk rating module and generates a visual traceability map based on quantitative scoring and level classification. The visual traceability map dynamically displays the entire cross-border data link of automobiles with the transmission timestamp as the horizontal axis and the data nodes as the vertical axis, and marks the illegal links in the entire link with red boxes.

2. The cross-border vehicle data detection system based on multi-source data fusion according to claim 1, characterized in that, The data acquisition module node deployment includes: For vehicle terminal node deployment, select an on-board OBD interface data acquisition device with integrated CAN bus interface, connect to the vehicle through OBD interface or on-board CAN bus, configure APN and bind SIM card fixed IP; Communication network node deployment: deploy edge computing nodes in areas with high vehicle activity, access vehicle communication data through SGW, deploy DPI detection equipment to capture communication data packets and parse IP headers, and configure the equipment to identify the vehicle-specific DoIP protocol. The cloud platform nodes are deployed using Elastic ECS computing services, configured with distributed storage and time-series databases, and developed with vehicle terminal access interfaces and communication network node data synchronization interfaces. The identity of access devices is verified through bidirectional TLS.

3. The cross-border vehicle data detection system based on multi-source data fusion according to claim 1, characterized in that, The preprocessing of the collected multi-source heterogeneous data includes: Data reception and verification: A unified receiving port is designed to support concurrent processing. The integrity of core fields is verified, and data with missing core fields is marked as invalid data and stored in the abnormal data pool. For missing values, missing core fields are filled by reverse matching of IP address and timestamp; if this fails, the missing value is removed after 24 hours. Missing non-core fields are filled by parsing the data content or by using network node data. Outlier correction includes correcting timestamps that are outside the reasonable range, re-extracting IP addresses with incorrect formats, and identifying feature tags that cause secondary parsing conflicts. Format conversion is performed, and the mapping is associated with VIN and timestamp to unify the transmission timestamp, source IP address, and destination IP address fields of data across all nodes.

4. The cross-border vehicle data detection system based on multi-source data fusion according to claim 1, characterized in that, The process of associating and fusing data records includes: The association is based on the vehicle dimension using VIN, grouping data records with the same VIN into the same vehicle data set; based on the time dimension using transmission timestamp, associating records with consecutive timestamps as time-series links; based on the IP dimension using IP address, associating records with the same source IP address or the same destination IP address; an association index table is constructed, data association relationships are stored using a graph database, and association weights are verified through multi-source cross-validation.

5. The cross-border vehicle data detection system based on multi-source data fusion according to claim 1, characterized in that, The events that generate suspected cross-border transfers include: Rule 1: The target IP address belongs to an overseas IP range, and the data content feature tags include location information, user data, and vehicle status; Rule 2: For the same VIN transmission timestamp, the target IP address of 3 or more consecutive records is switched between domestic and international borders; Rule 3: If an overseas target IP address receives location information data from ≥5 different VINs within 1 hour, a suspected event is triggered if any of the above rules are met. Each suspected event includes the VINs involved, overseas IP information, a set of content feature tags, the event time range, and the triggering rule number.

6. The cross-border vehicle data detection system based on multi-source data fusion according to claim 1, characterized in that, The machine learning model includes: The main model uses the XGBoost gradient boosting tree model to output the risk level and normalizes it using the softmax function to obtain the predicted probability of each level; the auxiliary model uses the SHAP value calculation model to quantify the contribution of each feature to the risk level and support the generation of evidence chain. The model training uses historical cross-border transmission event data to construct a training set, including positive and negative samples, and labels the risk levels as high risk (A), medium risk (B), and low risk (C).

7. The cross-border vehicle data detection system based on multi-source data fusion according to claim 1, characterized in that, The dynamic risk rating module includes: It receives risk level and evidence chain from the intelligent analysis and judgment module, as well as standardized data records from the data fusion and processing module, and outputs rating results including basic event information, quantitative scores and weights for each level, dynamic risk level, and the top 3 key evidence chains.

8. The cross-border vehicle data detection system based on multi-source data fusion according to claim 1, characterized in that, The visual source tracing map generated by the visual response module includes: The coordinate axis configuration uses the transmission timestamp as the horizontal axis and the data node as the vertical axis. Nodes are represented by rectangular icons and their types are distinguished by color. The entire cross-border data link for automobiles is represented by arrowed lines, with the line color and thickness corresponding to the risk level and quantitative score. Violations are marked with a red dashed box, 2px thick, and a blinking animation. Clicking the red box will bring up a pop-up window detailing the evidence chain.

Images