A vehicle-edge-cloud collaborative vehicle information security compliance management and control method and system

Abstract

The application provides a vehicle-edge-cloud collaborative vehicle information security compliance management and control method and system, which comprises the following steps: capturing message data and uploading the message data to the cloud for execution of slicing, extracting feature vectors in the slices, determining a time sequence anomaly score based on the feature vectors and calculating a risk correction coefficient gamma, then constructing a current critical fuzzy interval corresponding to the current working condition and matching the current critical fuzzy interval with national standard rules, and jointly determining the compliance condition based on the risk level of the national standard rule matching result and the time sequence anomaly score; determining whether to issue an OTA upgrade package to the vehicle end and update the vehicle baseline model of the cloud according to the threat level determined according to the abnormal type code; the real-time feature bitmap of the message and the compliance baseline bitmap are compared byte by byte by exclusive OR, then the AI auxiliary model is used for evaluation and determination of the abnormal offline message sequence, and the offline compliance is determined and the rectification instruction is generated by matching the local rules. The application can adapt to two scenes of new vehicle research and development pre-inspection and mass production vehicle whole life cycle compliance monitoring.

Description

Technical Field

[0001] This invention relates to the field of intelligent connected vehicle information security technology, specifically to a vehicle-edge-cloud collaborative method and system for vehicle information security compliance management. Background Technology

[0002] As the automotive industry continues its rapid transformation towards intelligent and connected vehicles, in-vehicle CAN bus, high-speed CAN FD bus, and in-vehicle Ethernet have become the core transmission carriers for data interaction between vehicle electronic control units. The mandatory national standard GB44495, "Technical Requirements for Information Security of Automobiles," explicitly requires all mass-produced and marketed intelligent connected vehicles to complete standardized compliance verification in several core areas, including in-vehicle bus communication behavior, access permissions for external interfaces, logic for calling in-vehicle diagnostic services, remote upgrade management of in-vehicle software, and protection of sensitive privacy data of vehicle users. Specific testing items in the GB44495 standard include, but are not limited to: in-vehicle bus communication behavior specifications, access permissions for external interfaces, logic for calling in-vehicle diagnostic services, remote upgrade management of in-vehicle software, and protection of sensitive privacy data of vehicle users.

[0003] Currently, automakers face two major pain points in the area of ​​vehicle information security compliance.

[0004] First, pre-construction inspections during the new vehicle development phase are costly and time-consuming. In the overall vehicle development process, vehicle information security compliance testing is typically scheduled during the finalization phase after vehicle development is complete, with automakers transporting vehicles to third-party testing institutions for formal testing. The closed network environment within automakers' R&D laboratories and production plants represents a typical physically isolated environment without external network access. Traditional cloud-based centralized network testing solutions heavily rely on stable and reliable external network communication links. Once in such an environment without external network access, data transmission links are directly interrupted, paralyzing all network-based testing functions. Automakers cannot conduct pre-construction compliance self-testing during the development phase; they can only determine compliance status after formal inspection. If problems are found, vehicles must be returned to the factory for rectification and re-inspection, severely extending the project cycle and resulting in high logistics and on-site engineer costs.

[0005] Secondly, there is a lack of full lifecycle compliance monitoring methods after mass-produced vehicles are delivered. Existing vehicle information security testing technologies mainly focus on the pre-market type approval testing phase. After vehicles are delivered to users, their software systems are upgraded via OTA (Over-The-Air), and the electronic control units may experience performance degradation or parameter drift due to long-term operation. The vehicle's compliance status is not permanently fixed once the type approval is achieved. Currently, the industry lacks continuous monitoring technologies for the full lifecycle compliance status of sold vehicles. OEMs face increasingly severe recall risks and regulatory compliance pressures.

[0006] In addition, existing technical solutions still have technical bottlenecks in the following aspects: traditional batch processing mode lacks the ability to slice and parse continuous data streams in real time, resulting in high response latency and lagging computing power scheduling; there is a resource competition conflict between the detection process and the driving business process; when the lightweight front-end parsing is in the fuzzy area of ​​the rule threshold, it is easy to produce fluctuating judgment results or even misjudgment; compliance baseline parameters are written once at the factory stage and do not have the ability to be dynamically updated. Summary of the Invention

[0007] In view of this, the problem to be solved by the present invention is to provide a vehicle-edge-cloud collaborative vehicle information security compliance management method and system, which can be adapted to two major scenarios: pre-inspection of new vehicle R&D and compliance monitoring of mass-produced vehicles throughout their entire life cycle, and meets national standards.

[0008] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: A vehicle-edge-cloud collaborative vehicle information security compliance management method and system includes: vehicle-side sampling, which involves capturing message data required for compliance testing based on national standards, performing three-level hierarchical desensitization processing, and uploading the data to the cloud via an encrypted channel; cloud-based time-series anomaly screening, which involves receiving and decrypting the message data uploaded from the vehicle, performing sliding window slicing on the message data based on the message data's timestamp, extracting features of the message data within the slice to form a feature vector, and using an AI time-series model to calculate a time-series anomaly score based on the feature vector. Based on the time-series anomaly score exceeding a threshold, a risk correction coefficient γ is calculated, representing the degree to which the message data within the corresponding slice deviates from the normal pattern, with a value range of 0.0 to 1.0; and cloud-based risk anomaly analysis, which involves determining the vehicle's current operating condition based on the feature vector corresponding to the slice to obtain several detection feature thresholds and corresponding feature weights corresponding to the current operating condition, calculating the mean μ and standard deviation σ based on the weighted score of each detection feature threshold, and combining the risk correction coefficient γ corresponding to the slice to construct the current critical ambiguity interval [μ + nσ + γ·σ, μ+(n+1)σ], where n is a value greater than 0, and is matched with national standard rules. Based on the result of the national standard rule matching and the time series anomaly score, dual-path compliance judgment is performed to output the judgment results of high confidence anomaly, critical ambiguity, and normal compliance. The slices judged as critical ambiguity are sent back to the cloud for secondary analysis of the time series anomaly screening step and sent to the edge for review and judgment. The cloud assesses the threat level and receives the anomaly type code that triggers anomalies during the national standard rule matching process. The threat analysis model performs threat level assessment and attack based on the pre-built attack tree database and anomaly type code. Type classification and analysis of affected electronic control units; Cloud-based upgrade: Based on the threat level that meets preset conditions, the attack type, and the affected electronic control units, an automatic upgrade strategy is orchestrated to send an OTA upgrade package containing the automatic upgrade strategy to the vehicle. The vehicle baseline model during normal operation is updated based on the upgrade results of the vehicle. Edge anomaly detection: Offline isolation operation is performed on the vehicle under offline conditions, and offline message data is collected. The real-time feature bitmap of the offline message data is compared byte by byte with the compliance baseline bitmap in the compliance baseline snapshot file of the corresponding vehicle model. The offline message sequence before and after the timestamp of the abnormal CAN ID and abnormal Ethernet port is extracted. The AI-assisted model performs binary classification assistance verification based on the offline message sequence. The offline message sequence determined by the AI-assisted model is matched with the local rules of the edge to make compliance judgment and generate rectification instructions.

[0009] A vehicle-edge-cloud collaborative vehicle information security compliance management system includes: a vehicle-side embedded SDK module, which embeds a vehicle-side rule engine IP core, a promiscuous monitoring and targeted capture program for receiving, parsing, and selectively capturing message data, a three-level hierarchical desensitization program, and a national standard SM2 / SM3 / SM4 encrypted transmission program; the vehicle-side hardware platform is configured with a heterogeneous computing array including a real-time microcontroller core, a dedicated neural network accelerator core, and an application processor core, with physical isolation between the cores achieved through hardware firewalls and memory protection units; a cloud-side SaaS platform module, which deploys a timing anomaly screening IP unit, a national standard rule engine IP unit, a threat level analysis IP unit, and an OTA upgrade management IP unit; it also deploys a deviation monitoring unit based on a vehicle-specific vehicle baseline model to determine the deviation of real-time monitoring message data, a predictive detection command generation and issuance unit, a cloud-side rule and vehicle-side AI model collaborative iterative update unit, a full lifecycle archive chain storage and management unit, and a disconnection status version synchronization unit for data synchronization after offline recovery at the vehicle or edge; and an edge industrial control detection module, which deploys a multi-factor network detection and offline isolation program, a security chip verification program, and a CAN bus... Program for building and dynamically updating ID and Ethernet port baseline snapshot files, program for bitmap comparison and AI-assisted model verification, program for local rule engine judgment and rectification instruction generation, and program for fragment synchronization.

[0010] The beneficial effects of this invention are: The cloud-based time-series anomaly pre-screening step uses a lightweight AI time-series model to quantitatively assess anomaly deviations in the anonymized time-series data uploaded from the vehicle and performs segmented analysis based on dynamic window slicing, generating a risk correction coefficient γ for each slice. The cloud-based risk anomaly analysis step dynamically adjusts the bandwidth of the critical fuzzy judgment interval based on the received risk correction coefficient γ, and then performs hard matching according to national standard rules to determine the risk level of the current anomaly. The cloud-based threat level assessment uses the anomaly type encoding triggered during the hard matching process according to national standard rules to assess the threat level of the anomaly event and trace the attack path. The cloud-based upgrade distribution step initiates upgrade strategy orchestration and distributes it to the vehicle based on the threat assessment results. The output of the previous step serves as the input for the next step, performing concatenated judgments on the data. The risk correction coefficient γ runs through the entire concatenated judgment process, forming a complete closed loop from data to decision. The cloud-based time-series anomaly pre-screening step reduces the problems of high detection response latency and lagging computing power scheduling by utilizing real-time slice parsing capabilities of continuous message data streams.

[0011] By deploying an embedded SDK module on the vehicle side, the vehicle-side AI model within the SDK module is iteratively updated based on cloud rules (message data parsing rules that conform to national standards recorded in the cloud), which improves the accuracy of the judgment results when the message features are in the critical ambiguity area of ​​the rule threshold in the lightweight vehicle-side parsing.

[0012] By setting up a vehicle baseline model corresponding to each vehicle in the cloud and updating it based on the vehicle's compliance message data in the most recent period, a full vehicle compliance status file can be built for each vehicle, enabling follow-up detection and adjustment of the compliance of individual vehicles and extending the time for vehicles to operate efficiently. Attached Figure Description

[0013] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a diagram of the overall architecture of the vehicle-edge-cloud three-layer collaborative system of the present invention; Figure 2 A schematic diagram illustrating the internal module structure and data flow of the vehicle-side embedded SDK; Figure 3 An analysis diagram of the interconnected architecture of the four major IPs of the cloud-based SaaS platform; Figure 4 Workflow diagram for the timing anomaly pre-screening unit; Figure 5 Here is a flowchart of the rule-AI dual-verification judgment logic; Figure 6 This is a flowchart of the offline detection and network recovery synchronization process at the edge. Figure 7 A schematic diagram of a hardware heterogeneous computing power affinity scheduling architecture; Figure 8 This is a schematic diagram of a chain-like evidence storage structure for compliance records throughout the entire lifecycle. Detailed Implementation

[0014] The technical solutions in the embodiments of the present invention will be clearly and completely described below. 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.

[0015] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0016] This invention provides a vehicle information security compliance management system based on vehicle-edge-cloud collaboration, such as... Figure 1-8The system includes a vehicle-side embedded SDK module, which embeds a vehicle-side rule engine IP core, a promiscuous monitoring and targeted capture program for receiving, parsing, and selectively capturing packet data, a three-level hierarchical desensitization program, and a national cryptographic SM2 / SM3 / SM4 encrypted transmission program; the vehicle-side hardware platform is configured with a heterogeneous computing array including a real-time microcontroller core, a dedicated neural network accelerator core, and an application processor core, with physical isolation between the cores achieved through hardware firewalls and memory protection units; a cloud-based SaaS platform module, which deploys a timing anomaly screening IP unit, a national standard rule engine IP unit, a threat level analysis IP unit, and an OTA upgrade control IP unit; it also deploys a deviation monitoring unit based on a vehicle-specific vehicle baseline model to determine the deviation of real-time monitoring packet data, a predictive detection command generation and issuance unit, a cloud-based rule and vehicle-side AI model collaborative iterative update unit, a full lifecycle archive chain storage management unit, and a disconnected state version synchronization unit for data synchronization after offline recovery at the vehicle or edge; and an edge industrial control detection module, which deploys a multi-factor network detection and offline isolation program, a security chip verification program, and a CAN bus. Program for building and dynamically updating ID and Ethernet port baseline snapshot files, program for bitmap comparison and AI-assisted model verification, program for local rule engine judgment and rectification instruction generation, and program for fragment synchronization.

[0017] A vehicle information security compliance diagnostic method based on the above system, such as Figure 1 and 2 As shown, step 1, "Promiscuous Listening and Targeted Capture of Vehicle-Side SDK," discloses the specific implementation method of how the vehicle-side embedded SDK module accesses the vehicle network in promiscuous listening mode and targets and captures the message data required for compliance testing in accordance with the GB 44495 standard (national standard).

[0018] The vehicle-mounted embedded SDK module (hereinafter referred to as the SDK) connects to the vehicle's communication network via a mirror port on the vehicle's Ethernet switch. This port is allocated by the vehicle gateway and mirrors all data frames passing through the core switch. Simultaneously, the SDK connects to the CAN / CAN FD bus via a CAN transceiver, receiving bus messages in listening mode. Upon SDK startup, it calls the network card driver interface to change the network card's operating mode to promiscuous listening mode. In this mode, the network card receives all data frames passing through the mirror port without filtering the destination MAC address and without actively sending any probe messages to the bus. The CAN transceiver hardware circuitry disconnects the message transmission line, retaining only the signal reception loop, and connects to the vehicle bus in a bypass parallel connection.

[0019] The SDK internally maintains a circular data buffer to temporarily store message data read from the network card receive buffer and the CAN transceiver. The SDK's embedded rule engine IP core performs targeted filtering of message data entering the buffer according to the detection items specified in the GB 44495 standard. The filtering logic is as follows: only message types directly related to GB 44495 compliance testing are captured, including CAN / CAN FD bus communication messages, vehicle Ethernet communication messages, ECU diagnostic service request and response messages, external interface data interaction messages, and software upgrade-related command messages. Message data unrelated to compliance testing, such as vehicle driving control commands and raw sensor data, are discarded and do not proceed to subsequent processing.

[0020] The filtered message data undergoes frame header identification and protocol parsing according to protocol type (implemented by the vehicle-side AI model). Basic field information such as source address, destination address, protocol type, and port number of each protocol layer is extracted, and a receiving timestamp is added to each message. The parsed message data is temporarily stored in the SDK's output buffer, awaiting subsequent de-identification processing.

[0021] like Figure 2 As shown, Step 2: Three-level hierarchical desensitization processing and national cryptographic secure transmission. This step discloses the specific implementation method of the SDK performing desensitization processing on the captured data according to the GB44495 standard and using national cryptographic algorithms for encrypted transmission.

[0022] Step 2.1 The three-level hierarchical desensitization processing method includes: the SDK performs three-level hierarchical desensitization processing on the message data in the output buffer, and the list of desensitized fields is determined according to the mandatory desensitized fields specified in GB 44495 standard.

[0023] Level 1 highly sensitive information includes the vehicle's VIN code and high-precision GPS latitude and longitude data. For the VIN code, the first three digits of the Manufacturer Identification Number (WMI) and the last six digits of the serial number are retained, while the middle Vehicle Feature Code (VDS) portion is uniformly replaced with an asterisk mask. For the high-precision GPS latitude and longitude data, values ​​with an original precision of more than six decimal places are uniformly truncated to two decimal places.

[0024] Level 2 operational status sensitive parameters include core operational data from the power domain, chassis domain, and battery management system. This type of data uses equal-length virtual placeholders to replace the original values. These placeholders are filled with all-FF hexadecimal bytes of the same length, and a CRC16 cyclic redundancy check is appended after the replacement. The CRC16 calculation covers the continuous original data block from the start offset address to the end offset address of the data field in the message, excluding the message frame header, the CRC check field itself, and other non-sensitive fields.

[0025] The Level 3 basic communication fields include pure communication protocol identification fields such as CAN ID, message DLC, timestamp, Ethernet source MAC address, and destination MAC address, which directly retain the original values.

[0026] After the data packet is de-identified, a 2-byte de-identification flag field is appended to the header of the packet data. The first byte indicates the de-identification level (0x01 for level 1, 0x02 for level 2, and 0x03 for level 3), and the second byte is a reserved extension field.

[0027] Step 2.2 Establishing an Encrypted Channel Based on Chinese Cryptographic Algorithms: The vehicle-mounted device establishes an encrypted communication channel with the cloud-based SaaS platform via a long TCP connection. The entire process of establishing the encrypted channel and transmitting data adopts Chinese cryptographic algorithms. The specific implementation method is as follows: Two-way authentication uses the Chinese cryptographic SM2 elliptic curve digital signature algorithm, employing the SM2 elliptic curve parameters specified in the GB / T 32918 standard. Both the vehicle-mounted device and the cloud have pre-configured public key certificates for each other. The vehicle-mounted device generates a random number R, combines R with its own unique device identifier to form an authentication request, signs it with its own private key, and sends it. The cloud verifies the signature, signs the random number R and the negotiated session parameters using its own private key, and generates an authentication response to return. The vehicle-mounted device verifies the response signature, completing the two-way identity verification. The session key negotiated during the authentication process is used for subsequent SM4 encryption.

[0028] Data encryption encapsulation employs the CTR (Counter) mode of the SM4 symmetric encryption algorithm, a national standard. The initialization vector (IV) for SM4-CTR mode is randomly generated at the vehicle end and transmitted along with the ciphertext. The CTR mode is chosen because it supports parallel encryption and decryption to improve processing efficiency in high-throughput scenarios and avoids the error propagation problem of CBC mode. SM4-CTR encryption is then performed on the de-identified data payload.

[0029] Integrity verification employs the national cryptographic standard SM3 Hash Message Authentication Code (HMAC). The SM3-HMAC key is independently derived from the SM4 session key, generated from the master session key using a key derivation function. The encapsulation format is: Protocol header (including version number, data length, key identifier) ​​|| SM3-HMAC (ciphertext) || Ciphertext. Throughout this patent, all aspects involving data integrity verification uniformly utilize the SM3 algorithm.

[0030] The offline key management method is as follows: For offline operation, the vehicle uses a factory-preset, locally fixed key with an expiration date for encryption. A monotonic counter within the security chip records the cumulative offline operation time. When the cumulative time exceeds a preset threshold, the security chip sets a key expiration status flag, and the system reminds the driver through the in-vehicle human-machine interface to move the vehicle to an area with network coverage as soon as possible. After the key expires, the SDK automatically switches to offline emergency mode: data upload is suspended, and the collected, de-identified data is locally encrypted with SM4 and stored in the vehicle's storage partition. After the network is restored and key rotation is completed, the data accumulated during the offline period is uploaded first. After the network is restored, the security chip, after completing SM2 two-way authentication, forcibly executes the key rotation process: a new SM4 session key is issued from the cloud, the vehicle verifies the key, uses the new key to encrypt subsequent communications, writes the SM3 digest of the new key to the secure storage area, and resets the offline timer.

[0031] like Figure 3 As shown, Step 3: Cloud-based analysis and result distribution of four core IPs. This step is the core of the method of this invention, and the execution entity is the cloud-based SaaS platform. This step discloses how the cloud uses four core IPs—time-series anomaly pre-screening IP (time-series anomaly screening IP unit), GB 44495 rule engine IP (national standard rule engine IP unit), TARA threat analysis IP (threat level analysis IP unit), and OTA upgrade management IP (OTA upgrade management IP unit)—to work together in a coordinated manner to complete a closed-loop method from data reception to the distribution of analysis results.

[0032] Step 3.1: The concatenation logic and data flow of the four IPs: After receiving the de-identified encrypted data packet uploaded by the SDK, the cloud calls the signature verification and decryption unit to perform SM4 decryption and SM2 signature verification, restoring the de-identified message data. The data is rearranged according to the timestamp order, forming a time-series message data stream. The decrypted message data is simultaneously distributed to the four IPs, and each IP executes sequentially according to the preset linkage relationship. The output of the previous IP unit serves as the input or parameter adjustment basis for the next IP unit.

[0033] like Figure 4 As shown, in step 3.2, the first IP—cloud-based time-series anomaly screening (time-series anomaly screening IP unit)—receives and decrypts the message data uploaded by the vehicle terminal. Based on the timestamp of the message data, it performs a sliding window slicing on the message data, extracts the features of the message data within the slice to form a feature vector, and the AI ​​time-series model calculates the time-series anomaly score based on the feature vector. Based on the time-series anomaly score exceeding the threshold, it calculates the risk correction coefficient γ, which represents the degree to which the message data within the corresponding slice deviates from the normal mode and has a value range of 0.0 to 1.0.

[0034] The slicing method employs a fixed-duration adaptive sliding window to slice the time-series message data stream. The default window duration is 200ms, adaptively adjusted based on the average message density over the most recent 60 seconds. When the average message density falls below a preset lower limit, the window expands to 400ms; when it exceeds a preset upper limit, the window shrinks to 100ms. Message data within each time window constitutes a slice. Without waiting for the entire time-series message data stream to be collected, each slice is immediately sent to the subsequent processing flow after generation. There are no overlapping intervals between adjacent slices, and each message data is assigned to a unique slice based on its timestamp.

[0035] The method for extracting the feature vector of each slice is as follows: four types of feature data are extracted for each slice. The first type is the short-term communication behavior characteristics of the message data, including the frequency distribution of each CAN ID within the slice, the proportion of each type of message, and the distribution statistics of the source node MAC address and IP address. The second type is the transmission frequency characteristics of the message data, including the total number of message frames within the slice and the year-on-year change rate of the number of frames corresponding to each CAN ID relative to the previous slice period. The third type is the periodic fluctuation characteristics of the message data, including the variance of the arrival time interval of periodic messages, the maximum periodic offset, and the number of consecutive offset frames. The fourth type is auxiliary features used for AI model (AI time-series model) inference, including the normalized numerical vector of the first 16 bytes of the message data field and the statistical histogram of the message arrival time interval. The extracted features are encapsulated in a structured format to form a feature vector.

[0036] The method for calculating the time-series anomaly score is as follows: A lightweight, unsupervised anomaly detection model (AI time-series model) runs internally within the time-series anomaly pre-screening unit. Preferably, this model is an isolated forest model or an autoencoder model with fewer than 300KB of parameters. During the system calibration phase, this AI time-series model is trained using feature vectors from massive amounts of message data that have undergone triple data verification and closed-loop confirmation to learn the distribution of normal communication behavior. The AI ​​time-series model file is permanently stored after being signed with an SM3 hash, and its integrity is verified during loading. Within each slice period, the feature vectors are input into the lightweight AI time-series model, and the model outputs a time-series anomaly score, representing the degree to which the current communication pattern deviates from the normal behavior distribution.

[0037] The risk correction coefficient γ is calculated as follows: γ = min(anomaly score / upper limit of anomaly threshold, 1.0), with a value ranging from 0.0 to 1.0. A higher γ value indicates a more severe deviation of the current data segment from the normal pattern. Slices with a risk correction coefficient γ exceeding the corresponding threshold are marked, and the marked slices, feature vectors, and risk correction coefficient γ are then passed to the cloud-based risk anomaly analysis step (national standard rule engine IP unit).

[0038] like Figure 5As shown, step 3.3, the second IP—cloud-based risk anomaly analysis (threat level analysis IP unit), receives the marked slices, feature vectors, and risk correction coefficients γ transmitted by the time-series anomaly screening IP unit. Based on the feature vectors corresponding to the slices, it determines the current operating condition of the vehicle to obtain several detection feature thresholds and corresponding feature weights corresponding to the current operating condition. Based on the weighted scores of each detection feature threshold, it calculates the mean μ and standard deviation σ. Combined with the risk correction coefficients γ corresponding to the slices, it constructs the current critical ambiguity interval [μ+nσ+γ·σ, μ+(n+1)σ], where n is a value greater than 0, and matches it with the national standard rules. Based on the risk level and time-series anomaly score of the national standard rule matching results, it performs dual-path compliance judgment to output the judgment results of high-confidence anomaly, critical ambiguity, and normal compliance. The slices judged as critical ambiguity are sent back to the cloud-based time-series anomaly screening step for secondary analysis and sent to the edge for review and judgment.

[0039] The current critical fuzzy interval is constructed as follows: the original critical fuzzy interval is [μ+2σ, μ+3σ], where μ and σ are the mean and standard deviation of the weighted scores of several compliant data (detection feature thresholds) under this operating condition, respectively. Based on the rule engine, the original critical fuzzy interval is dynamically adjusted according to γ ​​to adjust the sensitivity of the national standard rule matching judgment. After adjustment, the lower bound of the current critical fuzzy interval is μ+2σ+γ·σ. When γ=0, the current critical fuzzy interval remains unchanged; when γ=1.0, the lower bound of the current critical fuzzy interval is raised to μ+3σ, i.e., the current critical fuzzy interval is canceled. When the γ value is below 0.2, γ=0, and the current critical fuzzy interval is restored to the default bandwidth [μ+2σ, μ+3σ] to avoid oversensitivity under stable operating conditions, which could lead to an increase in false alarms.

[0040] The dynamic adjustment method for the original critical ambiguity interval is as follows: a pre-set operating condition-threshold mapping table is generated during the vehicle calibration stage. To ensure the reliability of the calibration data, message data after triple data verification is used as the calibration data: First, all CAN messages collected by the calibration vehicle under all operating conditions are compared frame by frame and signal by signal with the vehicle communication matrix DBC file to obtain all CAN messages that pass all comparisons; Second, the calibration vehicle is sent to a qualified third-party testing institution for full-item formal testing according to the GB 44495 standard, and the calibration data is only adopted when the test report concludes that all items have passed; Third, full-operating condition data is independently collected using at least three calibration vehicles of the same batch and configuration, and statistical significance tests are performed on the three sets of data to remove full-operating condition message data with significant individual biases. Only calibration data that has passed the above triple verification can be used to construct the operating condition-threshold mapping table.

[0041] The real-time vehicle operating condition identification method is as follows: The feature vector of the slice is input into a pre-trained lightweight decision tree model. The decision tree model outputs the current operating condition classification label of the vehicle, which includes at least four operating condition categories: idling, acceleration, cruising, and diagnostics. Then, based on the operating condition classification label, the corresponding benchmark detection feature threshold contained in the operating condition is called from the operating condition-threshold mapping table as the judgment basis.

[0042] Since national standard rule matching typically employs a multi-dimensional weighted scoring method, when constructing the original critical fuzzy interval, the rule records corresponding to the operating condition are pre-loaded into a hash table structure in memory in binary format. Each rule record corresponds to a set of feature thresholds and corresponding weight coefficients. The weight coefficients are pre-set according to the priority of each detection item in the GB 44495 standard, and their mean μ and standard deviation σ are calculated based on the weighted scores of each detection feature threshold, thereby constructing the original critical fuzzy interval for that operating condition.

[0043] The dual-path compliance determination method is as follows: When the national standard rule matching output is a high-confidence anomaly, it is directly confirmed; when the national standard rule matching output is critically ambiguous, if the time series anomaly score output by the AI ​​inference thread (AI time series model) exceeds a preset threshold, the determination is upgraded to a high-confidence anomaly; otherwise, the critical ambiguity is maintained and a fallback route is executed. The slices determined to be critically ambiguous are sent back to the cloud time series anomaly screening step for secondary analysis and sent to the edge for review and determination; when the national standard rule matching output is normal compliance but the time series anomaly score exceeds the potential threat alarm threshold, a potential unknown anomaly mark is generated. If the national standard rule matching output is normal compliance and the time series anomaly score does not exceed the threshold, it is confirmed as normal compliance. The compliance determination result, the anomaly type code triggered during the national standard rule matching process, and the associated message data (slices) are passed to the cloud threat level assessment step (threat level analysis IP unit).

[0044] The specific process of the fallback routing is as follows: When the national standard rule matching output is critically ambiguous and the time series anomaly score does not exceed the upgrade threshold, a fallback path is selected based on the current network status. In the online state, the data (slice) is sent back to the cloud's time series anomaly screening IP unit for secondary in-depth analysis, and the cloud calls a larger-scale AI time series teacher model to re-evaluate the time series anomaly score. In the offline state, the data (slice) is sent to the edge via the local link, and the edge loads the locally stored local rule matching and AI-assisted model to perform local review and judgment. The review conclusion generated by the fallback routing serves as the final judgment result for that slice.

[0045] Step 3.4 Third IP - Cloud-based threat level assessment (threat level analysis IP unit). The threat level analysis IP unit receives the anomaly type codes and associated slices that trigger anomalies during the national standard rule matching process. The internal threat analysis model performs threat level assessment, attack type classification, and analysis of affected electronic control units based on the pre-built attack tree database and anomaly type codes.

[0046] The threat level assessment method is as follows: the threat level analysis IP unit has a pre-built threat analysis model and attack tree database. For each abnormal event triggered by an abnormal packet, the attack tree database is searched for matching attack paths based on the abnormality type code to determine the attacker's possible intrusion method; based on the source and destination addresses of the abnormal packets, the list of affected electronic control units is analyzed; and the threat level is comprehensively assessed by combining the frequency, duration, and packet characteristics of the abnormality.

[0047] Threat levels are categorized into four levels: Low (general violation, no security impact), Medium (potential security risks exist), High (may lead to vehicle malfunction limitations or data breaches), and Severe (directly affects driving safety or may lead to remote vehicle control). TARA analysis results are transmitted to the OTA upgrade management IP.

[0048] Step 3.5 Fourth IP - Cloud-based upgrade delivery (OTA upgrade management IP unit): The OTA upgrade management IP unit receives the threat level transmitted by the threat level analysis IP unit, and automatically arranges the upgrade strategy based on the threat level that meets the preset conditions, the attack type (when the threat level is high or severe and the attack type can be fixed by software upgrade), and the affected electronic control units, to send an OTA upgrade package containing the automatically arranged upgrade strategy to the vehicle. Based on the upgrade results at the vehicle end, the vehicle baseline model when the vehicle is operating normally is updated.

[0049] After receiving the OTA upgrade package, the vehicle-side signature verification program performs signature verification and integrity checks. If the verification passes, the upgrade program is written to the spare partition in the A / B dual-partition storage architecture. After the write operation is complete, a full-file SM3 hash check is performed on the spare partition. If the hash check is inconsistent, data corruption is determined to have occurred during the write process, and the upgrade is abandoned. When the cumulative number of consecutive write failures reaches a preset threshold, a potential hardware storage failure is detected, triggering a hardware failure alarm. The spare partition is marked as a suspected failure, and the after-sales team is notified to perform hardware repair.

[0050] If the write verification passes, the vehicle-side will initiate a temporary safety protection program to take over the CAN bus monitoring function before restarting. After restarting, the vehicle-side will load the new version of the system program from the backup partition. After the upgrade is completed, the vehicle-side will initiate a multi-cycle driving monitoring program. The criteria for determining upgrade failure include four categories of indicators: brake system-related fault codes, steering system-related fault codes, vehicle communication bus abnormal alarms, and electronic control unit self-test abnormal codes. If any of these indicators is detected, the upgrade is immediately determined to have failed, and the partition's non-destructive automatic rollback program is initiated. After the rollback is completed, the version number of the vehicle-side system before the upgrade, the upgrade failure timestamp, and the specific fault code that triggered the rollback are extracted from the original running partition and reported to the cloud. After receiving the report, the cloud will archive the rollback event in the full vehicle compliance status file for that vehicle and simultaneously roll back the corresponding rule base version (invalid deviation filtering rule version) and vehicle baseline model version to ensure version consistency.

[0051] The OTA upgrade result is sent back to the timing anomaly pre-screening IP unit. After the upgrade is completed, the cloud marks the successful upgrade timestamp as the version boundary of the vehicle baseline model. Data before this timestamp will no longer be used for vehicle baseline model updates. Newly collected message data thereafter will continue to update the vehicle baseline model on a regular schedule according to the normal process.

[0052] For attacks with a high or severe threat level that require immediate blocking, the OTA upgrade management IP unit generates real-time blocking instructions while orchestrating upgrade strategies, and sends them to the SDK via a secure channel. Upon receiving the real-time blocking instructions, the SDK executes real-time control actions: temporarily restricting the routing of messages with illegal CAN IDs by sending a CAN frame routing control request to the gateway; or blocking communication traffic from suspicious IP addresses or MAC addresses through Ethernet switch ACL rules. Control requests are sent through a dedicated secure channel between the vehicle and the gateway, using a pre-set symmetric key for encryption and message authentication. After successful verification, the gateway adds a temporary filtering rule to its internal routing table and starts a timer and heartbeat counter. The vehicle sends a renewal request message every preset heartbeat period. If the gateway does not receive a renewal request within the timeout period, it automatically removes the rule and reports an anomaly. Active cancellation instructions sent from the cloud have higher priority than renewal requests.

[0053] Step 3.6 Distribution of Results After Connecting the Four IPs: After the analysis of the four IPs is completed, the cloud encapsulates the analysis results into a structured analysis report and distributes it to the edge computing industrial control printing device at the vehicle manufacturer's end via an encrypted channel. Upon receiving the analysis report, the edge computing industrial control printing device decrypts and parses the report content, drives the locally connected printing device or display terminal, and outputs a compliance testing report and rectification suggestions.

[0054] Step 3.7 Handling Network Disconnection: When the network link between the edge and the cloud is interrupted, the edge switches to offline isolated detection mode and independently performs offline detection according to the method in Step 6. The analysis results during offline processing are temporarily stored in the local storage of the edge. After the network is restored, they are uploaded to the cloud through a sharding synchronization mechanism, and the four major IPs of the cloud perform retrospective analysis on the offline data.

[0055] Step 3.8 Disconnection Status Synchronization Mechanism: When communication between any two parties in the vehicle-edge-cloud tripartite is interrupted, synchronization is restored using an alignment mechanism of model version number and rule base version number within each party. After network recovery, each end first reports the version number of its local data record. The cloud uses the party with the highest version number as the benchmark and sends incremental synchronization data to the party with the lagging version number to ensure that the data of the three parties is ultimately consistent with the judgment result.

[0056] like Figure 8 As shown, Step 4: Cloud-based full lifecycle compliance monitoring and proactive early warning. This step discloses the specific methods for how the cloud-based SaaS platform can achieve full lifecycle compliance status monitoring, proactive risk early warning, and in-process control for all vehicles. This includes cloud-based full lifecycle compliance monitoring: Each vehicle connected to the cloud has a corresponding vehicle baseline model with a data distribution profile composed of several indicator quantiles during normal vehicle operation. This model is used to continuously monitor the deviation of real-time message data uploaded by the vehicle from the baseline, and periodically updates the parameters within the vehicle baseline model based on the vehicle's most recent compliance message data. When the cloud detects that a certain indicator of the vehicle exhibits stable unidirectional drift over multiple consecutive windows but has not yet exceeded the compliance threshold based on the vehicle baseline model, it generates a predictive detection command containing the target CAN ID requiring enhanced monitoring and the detection parameters requiring temporary adjustment, and sends it to the vehicle. Real-time message data that passes the vehicle baseline model detection is stored using SM4 encryption to form an archive record. Each archive record contains a preceding archive hash pointer pointing to the SM3 hash value of the previous archive record. Several chained archive records constitute the full vehicle compliance status archive for that vehicle. Archive deletion and archive overwrite operations are recorded in the audit log, and the audit log uses chained evidence storage.

[0057] Step 4.1 Vehicle-Specific Baseline Construction and Deviation Monitoring: The cloud-based SaaS platform constructs a dedicated, normally functioning vehicle baseline model for each connected vehicle. This vehicle baseline model consists of a data distribution profile composed of multiple quantiles, including statistical indicators such as the fluctuation range of each quantile of bus load rate, the normal range of each quantile of CAN ID message cycle jitter, and the baseline of historical occurrence frequency of various abnormal events.

[0058] The deviation monitoring method is as follows: The cloud continuously compares the real-time received message data stream with the corresponding vehicle baseline model to calculate the deviation between the real-time message data and the baseline. The deviation calculation formula is: Deviation = |Current index collection value - Baseline mean| / Baseline standard deviation.

[0059] The risk level classification criteria are as follows: deviations between 1 and 2 standard deviations are classified as requiring attention; deviations between 2 and 3 standard deviations are classified as increased risk; and deviations exceeding 3 standard deviations are classified as high risk. Furthermore, the trend of deviation changes is analyzed: a continuous increase in deviation over multiple sampling periods is considered a deteriorating trend, while a continuous decrease is considered a converging trend.

[0060] Baseline aging reset rule (regular vehicle baseline model update): The vehicle baseline model is configured with a regular reset mechanism. At preset time intervals, the system automatically marks the vehicle baseline model as pending update and recalculates the baseline parameters using compliant data from the most recent period. After the baseline is reset, the deviation monitoring threshold is restored to its default value.

[0061] Step 4.2 Proactive Risk Prediction and Early Warning: The cloud periodically analyzes the subtle deviation trends between recent vehicle message data and the dedicated baseline. When a certain indicator is detected to exhibit stable unidirectional drift across multiple consecutive monitoring windows but has not yet exceeded the compliance threshold, the cloud proactively generates a predictive detection instruction. This instruction includes the target CAN ID or message type requiring enhanced monitoring, the feature dimension requiring temporary improvement in detection sensitivity, and the AI ​​anomaly judgment threshold parameters requiring temporary adjustment. This instruction is sent to the vehicle-side SDK via a secure channel. Upon receiving the instruction, the SDK dynamically adjusts the acquisition parameters and detection sensitivity in memory for the current detection cycle, enhancing monitoring for subsequent driving cycles.

[0062] Step 4.3 Specific methods for in-process control: For attack behaviors that are confirmed by the cloud as high-confidence anomalies (output of the national standard rule engine IP unit) and have a high or severe threat level (output of the threat level analysis IP unit), the cloud sends a real-time blocking command to the vehicle. The specific methods for in-process control have been described in step 3.5 and will not be repeated here.

[0063] Step 4.4 Full Lifecycle Archive Chain Storage: The cloud-based SaaS platform establishes an independent full-scale vehicle compliance status archive for each connected vehicle. The chain storage method for the full-scale vehicle compliance status archive is as follows: Real-time message data that has passed the vehicle baseline model detection is stored using SM4 encryption to form an archive record. The header of the archive record includes a previous archive hash pointer field, the value of which is the SM3 hash value of the previous archive record for the same vehicle. When writing a new archive record, the system automatically calculates an SM3 hash containing the hash value of the previous archive record and the content of the current archive record, which is used as the pre-generated previous hash value for the next archive record. Access permissions for archive data are managed hierarchically according to roles. Archive deletion and archive overwrite operations are also recorded in the audit log, which itself also uses chain storage.

[0064] Step 5: Rule-AI Model Collaborative Iterative Update. This step discloses how the cloud-based SaaS platform achieves continuous iterative upgrades of vehicle-side detection capabilities through deviation data accumulation, automatic rule updates, AI model knowledge distillation, and independent triggering mechanisms. This includes iterative updates of the vehicle-side AI model used for parsing message data based on cloud-based rules: the cloud performs secondary verification of the parsing and tagging information of the message data uploaded by the vehicle, and includes inconsistent message data into the deviation dataset after invalid deviation filtering. The invalid deviation filtering includes identifying and filtering message data that has been manually debugged. When the number of similar deviation events in the deviation dataset reaches a threshold, the distillation of the vehicle-side AI model is triggered. Distillation update; the distillation update includes using the abnormal score output of the cloud-based AI teacher model as soft labels and the abnormal score output of the vehicle-side student model as predicted values, and using the mean squared error as the distillation loss function to generate an updated vehicle-side AI model; the vehicle-side AI model is also configured with an independent triggering mechanism, which triggers the distillation update of the vehicle-side AI model when the number of newly added unknown abnormal samples in the deviation dataset that are not covered by the existing rules of the vehicle-side AI model reaches a threshold; when the vehicle fails to upgrade based on the OTA upgrade package and rolls back the vehicle-side AI model version, the cloud synchronously rolls back the invalid deviation filtering rules and vehicle baseline model of the corresponding version of the vehicle.

[0065] Specifically, the cloud performs secondary verification on the parsing and tagging information of the message data uploaded by the vehicle. Inconsistent records are included in the deviation dataset after being filtered for invalid deviations. In addition to removing message data with link errors, abnormal formats, and abnormal clocks, the invalid deviation filtering adds rules for identifying and filtering debugging messages: if the source address of the message belongs to the preset diagnostic tool address whitelist, or if the message data field contains a diagnostic session identifier, it is determined to be a human debugging message and is directly discarded and not included in the deviation dataset.

[0066] When the cumulative number of valid deviation events corresponding to the same parsing rule number reaches a preset threshold, the cloud automatically starts the parsing rule automatic update program to update the rule threshold parameters or weight coefficients in the vehicle-side AI model.

[0067] The distillation update method for the vehicle-side AI model is as follows: The abnormal score outputs of the cloud-based AI teacher model for samples in the bias dataset are used as soft labels, and the abnormal score outputs of the vehicle-side student model for the same batch of samples are used as predicted values. Mean squared error is used as the distillation loss function, and the student model parameters are updated through backpropagation. After training convergence, the updated student model file, after being signed with an SM3 hash, is sent to the vehicle along with the rule update package to update the vehicle-side AI model.

[0068] The AI ​​model is also equipped with an independent triggering mechanism: when the number of newly added unknown abnormal samples in the bias dataset that are not covered by any existing parsing rules reaches a preset threshold, the cloud will trigger the AI ​​teacher model retraining and distillation update separately, even if the distillation update action is not triggered.

[0069] like Figure 6 As shown, Step 6: Edge-end Offline Detection and Network Recovery Synchronization. This step discloses the offline detection method for the edge end in a physically isolated environment, as well as the data synchronization mechanism after the edge end network is restored. This includes performing offline isolation operations on the vehicle end under offline conditions and collecting offline message data. The real-time feature bitmap of the offline message data is XORed byte-by-byte with the compliance baseline bitmap in the corresponding vehicle model's compliance baseline snapshot file. Abnormal CAN IDs and abnormal Ethernet ports are extracted, along with their timestamp-related offline message sequences. An AI-assisted model performs binary classification verification based on the offline message sequences. The AI-assisted model determines abnormal offline message sequences and matches them with the edge end's local rules to perform compliance judgment and generate rectification instructions.

[0070] Step 6.1 Multi-factor network detection and offline isolation: After the edge device is powered on and completes its hardware self-test, the network monitoring daemon thread is started. It executes three operations in a preset, fixed sequence: ARP request sending probe, network key-click detection probe, and link timeout statistics. If no valid response is received within the set timeout threshold, it is determined to be in an offline state, and offline isolation operations are performed in a fixed sequence: First, disable the software-level wireless communication interface; second, clear the external network entries in the routing table; third, implement firewall rule blocking, adding DROP default policy rules to the INPUT chain, OUTPUT chain, and FORWARD chain respectively, while retaining the internal network communication whitelist rules with the vehicle; fourth, configure the internal network firewall whitelist.

[0071] The device integrates a security chip to store the root key and hash values ​​of critical configurations. During power-on self-test, the security chip automatically performs SM3 hash verification on the compliance baseline snapshot file, rule engine configuration file (local rule matching file), and AI-assisted model stored in local flash memory. If any file verification is inconsistent, the device will refuse to enter offline detection mode.

[0072] Step 6.2 Compliance Baseline Snapshot File Construction and Bitmap Comparison: During the R&D and calibration phase of the benchmark compliant vehicle, the edge device simultaneously accesses the vehicle communication network via the CAN transceiver interface and Ethernet interface for continuous bypass monitoring, collecting all communication messages. The full CAN ID list and Ethernet legitimate communication port list are extracted and verified item by item against the vehicle communication matrix DBC database file. Verified legitimate CAN IDs generate bitmaps according to the following mapping rules: For 11-bit standard CAN IDs, the corresponding bits are set to 1 according to the rule that the byte index equals the integer quotient of the ID value divided by 8, and the bit offset equals the remainder of the ID value modulo 8; for 29-bit extended CAN IDs, the ID space is divided into 16 independent segments by the high 4 bits, and each segment maintains an independent bitmap. For vehicle Ethernet legitimate communication ports, an Ethernet port bitmap is generated according to the rule that the byte index is the integer quotient of the port number divided by 8, and the bit offset is the remainder of the port number modulo 8.

[0073] The generated bitmap data is bound to the VIN code of the vehicle under test, the list of legitimate Ethernet communication ports and the Ethernet port bitmap are merged, the SM3 hash operation program is called to calculate the hash digest value of the entire data block, forming a vehicle-specific compliance baseline snapshot file, which is then encrypted and stored using SM4.

[0074] During offline testing, the edge device reads the VIN code of the vehicle under test through the OBD diagnostic interface, retrieves the corresponding compliance baseline snapshot file, and loads it using a memory-mapped file method. It receives bus messages in real time, synchronously setting the corresponding bits for the CAN ID and Ethernet port in the real-time feature bitmap. After accumulating a preset number of frames, it performs a byte-by-byte XOR comparison between the real-time feature bitmap and the baseline bitmap. If an abnormal bit is found, it calculates the abnormal CAN ID or abnormal Ethernet port in reverse. For abnormal output results, it extracts message data within a 500ms range before and after the abnormal result from the sliding window data buffer, reassembles it into a feature vector, and then uses a local AI-assisted model for binary classification verification (normal or abnormal).

[0075] Step 6.3: Dynamic Update Method for Baseline Snapshots. After a vehicle undergoes a compliant OTA upgrade package or has its certified electronic control unit replaced, the cloud-based SaaS platform issues a baseline update license file. This file contains the VIN code of the vehicle to be updated, the updated list of valid CAN ID increments, the updated list of valid Ethernet port increments, the updated cross-domain access rules, and diagnostic permission configuration information. The cloud uses its own SM2 private key to digitally sign this file. After successful signature verification at the edge, an atomic bitmap update operation is performed in memory, synchronously updating the cross-domain access whitelist and diagnostic permission configuration. After the operation is completed, the SM3 digest is calculated and compared with the expected digest in the license file. If they match, the data is written to flash memory using an atomic file replacement method.

[0076] Step 6.4 Local Rule Engine Judgment and Rectification Instruction Generation: A local rule engine capable of independent offline operation is built into the edge. The corresponding local rule library is stored in local flash memory in the form of a structured configuration file. The cross-domain access whitelist matrix is ​​stored in memory using a hash table data structure. For scenarios where multiple vehicle models share the local rule library, the local rule engine identifies the vehicle model based on the VIN code of the currently detected vehicle when loading the local rule library, extracts the differential rule coefficients corresponding to that vehicle model from the local rule library, and establishes an independent rule execution instance for that vehicle model in memory.

[0077] The diagnostic protection program performs triple protection checks on each diagnostic service request message (an offline message sequence identified as abnormal by the AI-assisted model): source address authorization verification, request frequency limitation, and non-standard instruction feature matching. The storage duration of audit logs for intercepted diagnostic messages (offline messages) is differentiated based on the anomaly level (the level of the detection and diagnostic result): high-confidence anomaly diagnostic interception logs are stored permanently; critically ambiguous diagnostic interception logs are automatically overwritten after 180 days; and normal compliant diagnostic request logs are automatically overwritten after 30 days. The log storage duration can be configured differently for different safety level vehicle models, with higher safety level models having a proportionally extended log storage duration.

[0078] The local rule engine retrieves abnormal records (high-confidence abnormalities and critical fuzzy corresponding records) one by one from the shared memory queue. Using the abnormal type code corresponding to the triggering abnormality as an index, it performs a hash lookup in the abnormal index mapping library. After finding the corresponding rectification instruction template, it fills in context information such as VIN code, timestamp, and specific abnormal value to generate a structured rectification instruction data block.

[0079] Step 6.5 Shard Synchronization After Network Recovery: Once the network link returns to normal, the edge device reports its local rule base version number, baseline snapshot file version number, and AI-assisted model version number to the cloud. After completing the Diff comparison, the cloud sends out incremental update data packets. The hot update is completed after the edge device verifies the signature. If a write interruption or verification failure occurs during the hot replacement process, the system automatically rolls back to the version before the replacement.

[0080] The edge performs fragmentation on all data accumulated during offline periods, assigning each fragment a monotonically increasing sequence number. An SM3 hash checksum is calculated for each fragment and appended to its header. Fragmented data is uploaded to the designated cloud interface in ascending order of sequence number. The cloud maintains a receive status bitmap in memory using the fragment sequence number as an index. For each successfully received fragment, the SM3 hash value is calculated individually and compared with the fragment header checksum. Missing fragments trigger retransmission. After all fragments have been received, the cloud performs a final integrity check by calculating the SM3 hash digest value for the assembled full data.

[0081] like Figure 7 As shown, step 7: Vehicle-side heterogeneous hardware affinity computing power scheduling. This step discloses how to achieve deterministic response to safety-critical tasks through hardware affinity binding when the vehicle-side hardware platform has heterogeneous computing cores. This step is optional when the vehicle-side hardware is a single processor platform. When the vehicle-side is a heterogeneous hardware platform, it includes a real-time microcontroller core that processes the first priority tasks corresponding to high-confidence abnormal events, a dedicated neural network accelerator core that executes vehicle-side AI model inference tasks and has read and write permissions to update the vehicle-side AI model, and an application processor core that executes routine data acquisition and desensitization tasks. Multiple synchronously triggered first priority tasks in the real-time microcontroller core are processed sequentially according to their corresponding security event level and timestamp order, and the task queues of the real-time microcontroller core and the dedicated neural network accelerator core are not discarded.

[0082] Step 7.1 Physical Architecture of the Heterogeneous Hardware Platform: The vehicle-side heterogeneous hardware platform consists of three types of physical computing cores: Type A is a high-performance application processor core (CPU), running an operating system and responsible for performing routine tasks such as SDK data acquisition, desensitization, and encrypted uploading; Type B is a real-time microcontroller core (MCU), running a real-time operating system, physically isolated from Type A cores through an on-chip hardware firewall, dedicated to handling immediate processing of high-confidence abnormal events detected by the vehicle (e.g., real-time blocking instructions); Type C is a dedicated neural network accelerator (NPU) or high-efficiency digital signal processor (DSP) core, dedicated to running lightweight AI inference models (vehicle-side AI models). After the AI ​​model file is loaded into the dedicated memory of the Type C NPU core, this memory area is configured through a memory protection unit (MPU) to allow only Type C cores to read and write permissions. When the AI ​​model needs to be updated, the scheduler temporarily grants memory write permissions to the Type A cores through a secure interrupt mechanism. After the update is completed, the isolation state is immediately restored, and the entire operation log is recorded.

[0083] Step 7.2 Hardware affinity scheduling method: The scheduler performs hardware affinity scheduling according to the binding relationship between task priority and physical core type: all first priority tasks are directly written to the interrupt trigger register of the B-type core by the scheduler and executed immediately by the B-type core within a microsecond delay; all AI inference tasks are fixedly assigned to the C-type core for execution; SDK regular tasks are assigned to the A-type core for sequential processing.

[0084] When multiple high-priority tasks are triggered simultaneously, Class B cores prioritize tasks based on their security event level, and within the same level, they process tasks according to their timestamps. When the load on Class A cores reaches its peak, the scheduler initiates a computing power distribution mechanism, encapsulating deep rule matching and complex feature analysis tasks into collaborative request messages, which are then sent to the edge for collaborative computation via the local Ethernet link.

[0085] The deterministic execution method of the ultimate fallback strategy is as follows: tasks are discarded in a strictly predefined order—first, new enqueueing of third-priority tasks is paused; third-priority tasks are discarded from oldest to newest according to their timestamps; then, non-real-time tasks in the second priority category that have exceeded their maximum processing time limit are discarded. Core task queues of categories B and C are never discarded under any circumstances.

[0086] The specific implementation process and beneficial effects of this application plan are as follows: Example 1: Pre-launch inspection during new vehicle development. In the later stages of developing a new model, an OEM needs to conduct vehicle information security compliance verification. Due to technical confidentiality requirements, the R&D laboratory is physically isolated from the external network. Test engineers deploy edge devices within the laboratory, connecting to the vehicle under development via an OBD diagnostic interface. The vehicle is pre-installed with an embedded SDK module.

[0087] The test engineer starts the system. After performing multi-factor joint detection at the edge, it is determined to be in an offline state. The offline isolation operation is completed in a preset order, the local rule engine and vehicle compliance baseline snapshot file are loaded, and the system is switched to offline detection mode.

[0088] The SDK starts and accesses the vehicle network via promiscuous monitoring mode, capturing CAN / CANFD bus and vehicle Ethernet packets according to the GB 44495 standard. The vehicle-side rule engine IP core embedded in the SDK filters the packets, retaining only those related to compliance detection, and encrypts and stores them locally after performing three-level desensitization.

[0089] The edge device reads the VIN code of the vehicle under test through the OBD diagnostic interface and retrieves the corresponding compliance baseline snapshot file. After passing the SM3 hash check, the file is loaded into memory. The edge device receives bus messages in real time and synchronously sets the corresponding bits for the CAN ID and Ethernet port in the real-time feature bitmap. When the cumulative number of received message frames reaches a preset threshold, a bitmap comparison program is triggered. The comparison program performs a byte-by-byte XOR operation between the real-time feature bitmap and the baseline bitmap. If the XOR result of a certain byte is non-zero, the program calculates the abnormal CAN ID as 0x3E8.

[0090] The edge device extracts message data sequences within a 500ms range before and after the anomaly's CAN ID timestamp from the sliding window data buffer, and performs binary classification verification using a local AI-assisted model. The AI-assisted model outputs that the anomaly is confirmed with a confidence level of 0.92, thus confirming it as a genuine anomaly.

[0091] The local rules engine confirmed that the message with ID 0x3E8 was undefined in the vehicle communication matrix DBC file and belonged to an illegal CAN ID. The local rules engine generated structured rectification instructions, which were encrypted using SM4 and stored in the local encrypted partition at the edge. The test engineer viewed the test report and rectification suggestions through the display terminal connected to the edge, located the problematic electronic control unit, corrected the communication parameters, and restarted the retest, confirming that the anomaly had been eliminated.

[0092] Throughout the entire pre-inspection process, the vehicle never left the R&D laboratory, and no logistics or on-site engineer fees were incurred. Before formally applying for third-party inspection, the OEM had already identified and addressed information security compliance issues through internal pre-inspection.

[0093] Example 2: Full Lifecycle Compliance Monitoring and Unknown Anomaly Identification for Mass-Produced Vehicles. A certain mass-produced vehicle model has been launched and is in daily use by users. The SDK pre-installed on the vehicle runs continuously, performing uninterrupted targeted collection and anonymization of bus communication messages generated during vehicle operation in accordance with the GB 44495 standard, and uploading them to the cloud SaaS platform in real time through an encrypted channel.

[0094] The four cloud-based IP-based analysis engines have begun operating. The timing anomaly filtering IP unit performs sliding window slicing and feature extraction on the packet data stream. Within a certain period, the cloud detected a small but persistent jitter offset in the packet transmission cycle of a certain power domain CAN ID, with multiple consecutive slices of timing anomaly scores exceeding a preset threshold. The timing anomaly filtering IP unit marks the relevant data as requiring in-depth analysis and calculates γ=0.6, which is then passed to the national standard rule engine IP unit.

[0095] The national standard rule engine IP unit adjusts the lower bound of the current critical ambiguity interval to μ+2.6σ based on the γ value and identifies that the comprehensive score of this offset is within the critical ambiguity interval of the cruise condition. The anomaly score given by the AI ​​time series model does not exceed the threshold, so the system maintains the critical ambiguity judgment and simultaneously transmits the anomaly type encoding to the threat level analysis IP unit.

[0096] The threat level analysis IP unit searched the attack tree database for matches and determined that the jitter pattern had some similarities to an attack path associated with a known asymptotic fault in an ECU clock module, but it was still in the early stages, and the threat level was assessed as medium. The OTA upgrade control IP unit did not trigger an upgrade based on the threat level, but added the event to the continuous monitoring list.

[0097] Subsequently, the cloud received reports of similar vibration and deviation events from multiple vehicles in the same batch, and the deviation continued to increase. The cloud's proactive risk prediction mechanism detected the worsening trend and adjusted the risk level to "increased risk." The cloud automatically generated predictive detection instructions and distributed them in batches to the SDK of the affected batch of vehicles.

[0098] After enhanced monitoring data feedback, the cloud-based AI teacher model confirmed that the periodic fluctuations were an unknown anomaly. When the accumulated deviation events reached a preset threshold, the automatic update of the parsing rules (distillation update of the vehicle-side AI model) was automatically triggered, and the vehicle-side AI model file was transmitted back to all vehicles of that model in the network via an encrypted channel. At the same time, the cloud pushed preventive maintenance recommendation orders through the OEM's after-sales service management system to complete preventive handling before the problem developed into formal non-compliance.

[0099] Example 3: Robust Operation Under Frequent Network Switching Conditions. A vehicle enters a mountainous road section where mobile network coverage has blind spots. The edge device is determined to be offline and performs offline isolation operations according to a preset sequence. During the offline period, the vehicle experiences a switch from cruising to idling. The vehicle-side SDK continues to run, and all detection data generated during the offline period is temporarily stored in a local encrypted partition. After the key expires, it automatically switches to offline emergency mode.

[0100] After the vehicle exits the tunnel area, network signal is restored. The edge device reports its version number to the cloud, and the cloud, after completing the Diff comparison, issues an update package for the new version of the vehicle's AI model. After the edge device completes the hot update, it uploads the data accumulated during the offline period to the cloud in a fragmented manner. The four IP addresses on the cloud perform retrospective analysis on the uploaded offline data, and update the vehicle compliance file based on the cloud's conclusions.

[0101] Example 4: Heterogeneous computing power collaboration on the vehicle side ensures driving safety under extreme conditions. A vehicle encounters an emergency braking situation while traveling on an urban expressway, causing overload of the Class A CPU core. A high-confidence anomaly alarm is issued from the cloud, requiring the vehicle to immediately execute a local rapid response strategy. This task is written directly into the interrupt trigger register of the Class B MCU core by the scheduler as the first priority, and the processing is completed within a microsecond delay.

[0102] At this time, two other high-priority tasks were triggered simultaneously. The Class B core processed them sequentially according to the principle of prioritizing the highest security event level. The Class B core sent a CAN frame routing control request to the gateway through a dedicated secure channel. After the gateway verified the request, it added temporary filtering rules to block unauthorized communication. The entire security response process was completed independently on the Class B core, without causing any perceptible impact on the driving safety process.

[0103] The dedicated memory of the Class C NPU core is configured by the MPU to be read and written only by the Class C core, ensuring the safety of the AI ​​model under extreme conditions.

[0104] Example 5: Unified Management and Proactive Recall of Compliance Status for All Vehicles of an Automaker. An OEM accesses real-time compliance data for all its mass-produced models through a cloud-based SaaS platform. One day, the platform detects a collective slow drift trend in the CAN bus load rate of a batch of vehicles in the power domain and automatically generates and issues predictive detection commands in batches.

[0105] Cloud-based analysis confirmed a batch-related performance degradation in the clock modules. The four IP-connected analysis engines completed a full analysis, and OTA upgrades managed the IP unit orchestration upgrade strategy and distributed fix patches. Simultaneously, the platform aggregated fault data, analyzed common issues, and pushed fault analysis reports and proactive recall recommendations to OEMs. Based on the reports, OEMs accurately located the affected batches of vehicles and proactively initiated preventative recalls.

[0106] Thanks to timely intervention, the problem was effectively controlled before it escalated into a large-scale mandatory recall.

[0107] Example 6: Multi-scenario linkage and switching verification. After a vehicle completes offline pre-inspection in the R&D laboratory, a compliance test report is generated on the edge. After the engineer fixes the problems according to the rectification suggestions, the vehicle is driven out of the laboratory and connected to the external network. After the edge network is restored, the offline test data is automatically synchronized to the cloud, and the local rule base and AI-assisted model incremental update packages are received from the cloud.

[0108] Four IP addresses in the cloud conducted a retrospective analysis of the offline data and discovered that a certain critical ambiguity judgment during the offline period was confirmed as an anomaly during the secondary verification in the cloud. The cloud then sent the updated judgment to the edge and simultaneously updated the full vehicle compliance status file.

[0109] After the vehicle OTA upgrade is completed, the cloud automatically triggers the compliance retest process. The SDK replicates the offline testing steps, and the retest data is uploaded to the cloud to verify the upgrade effect. Multi-scenario switching verification confirms the smooth connection between the system's offline pre-inspection, online monitoring, version update, and retest closed loop.

[0110] The above description is merely a preferred embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural modifications made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A vehicle-edge-cloud collaborative method for vehicle information security compliance management, characterized in that, include: Vehicle-side sampling involves capturing the required message data for compliance testing based on national standards, performing three-level de-identification processing, and then uploading it to the cloud via an encrypted channel. The cloud-based time-series anomaly screening process receives and decrypts message data uploaded from the vehicle. Based on the timestamp of the message data, a sliding window slice is performed on the message data. Features of the message data within the slice are extracted to form a feature vector. The AI ​​time-series model calculates the time-series anomaly score based on the feature vector. Based on the time-series anomaly score that exceeds the threshold, a risk correction coefficient γ is calculated, which represents the degree to which the message data within the corresponding slice deviates from the normal pattern and ranges from 0.0 to 1.

0. Cloud-based risk anomaly analysis: Based on the feature vector corresponding to the slice, the current operating condition of the vehicle is determined to obtain several detection feature thresholds and corresponding feature weights corresponding to the current operating condition. Based on the weighted score of each detection feature threshold, the mean μ and standard deviation σ are calculated. Combined with the risk correction coefficient γ corresponding to the slice, the current critical ambiguity interval [μ+nσ+γ·σ, μ+(n+1)σ] is constructed, where n is a value greater than 0. It is matched with the national standard rules. Based on the result of the national standard rule matching and the time series anomaly score, dual-path compliance judgment is performed to output the judgment results of high confidence anomaly, critical ambiguity, and normal compliance. The slices judged as critical ambiguity are sent back to the cloud time series anomaly screening step for secondary analysis and sent to the edge for review and judgment. The cloud-based threat level assessment receives anomaly type codes triggered during the matching process of national standard rules. The threat analysis model performs threat level assessment, attack type classification, and analysis of affected electronic control units based on a pre-built attack tree database and anomaly type codes. Cloud-based upgrades: Based on the threat level that meets preset conditions, the attack type, and the affected electronic control units, an upgrade strategy is automatically arranged to send an OTA upgrade package containing the automatically arranged upgrade strategy to the vehicle. The vehicle baseline model during normal operation is updated based on the upgrade results on the vehicle. Edge anomaly detection involves performing offline isolation operations on the vehicle end under offline conditions and collecting offline message data. The real-time feature bitmap of the offline message data is compared byte by byte with the compliance baseline bitmap in the compliance baseline snapshot file of the corresponding vehicle model. The offline message sequence before and after the timestamp of the abnormal CAN ID and abnormal Ethernet port is extracted. The AI-assisted model performs binary classification verification based on the offline message sequence. The offline message sequence identified as abnormal by the AI-assisted model is matched with the local rules of the edge end to make a compliance judgment and generate rectification instructions.

2. The method according to claim 1, characterized in that, The three-level desensitization process includes: Level 1 high-sensitivity information desensitization, which hides the middle characters of the vehicle VIN code and reduces the accuracy of GPS coordinate data; Level 2 sensitive operating status parameter desensitization, which replaces the original sensitive values ​​with equal-length full-FF hexadecimal bytes and adds a CRC16 cyclic redundancy check code; Level 3 basic communication field desensitization, which retains CANID, message DLC, timestamp, Ethernet source MAC address, and destination MAC address; and adding a desensitization flag indicating the desensitization level to the message data header.

3. The method according to claim 1, characterized in that, The cloud-based time-series anomaly screening includes: the feature vector of the slice includes CAN ID occurrence frequency distribution features, message transmission frequency features, message periodic fluctuation features, and auxiliary features for AI time-series model inference; The AI ​​time series model is trained from a massive amount of message data that has been verified to be compliant through a triple data verification closed loop during the calibration phase, using either an isolated forest model or an autoencoder model. The risk correction coefficient γ is calculated as follows: γ = min(anomaly score / upper limit of anomaly threshold, 1.0).

4. The method according to claim 3, characterized in that, The triple data verification loop includes: the first data verification includes comparing all CAN messages collected by the calibration vehicle under all working conditions with the vehicle communication matrix DBC file frame by frame and signal by signal to obtain all CAN messages that pass all comparisons. The second layer of data verification includes sending the calibrated vehicles to a third-party testing agency for full-item testing according to national standards, and obtaining the calibration data corresponding to the passing of all tests. The third layer of data verification includes independently collecting full-condition message data using at least three calibrated vehicles of the same batch and configuration, and performing statistical significance tests on the three sets of message data to eliminate full-condition message data with significant individual bias.

5. The method according to claim 1, characterized in that, The cloud-based risk anomaly analysis includes: when the risk correction coefficient γ is lower than the lower limit threshold, γ = 0; The dual-path compliance determination includes: if the national standard rule matching result is a high-confidence anomaly, or if the national standard rule matching result output is critically fuzzy and the time-series anomaly score exceeds the threshold, then it is confirmed as a high-confidence anomaly; if the national standard rule matching result output is critically fuzzy and the time-series anomaly score does not exceed the threshold, then it is confirmed as critically fuzzy; if the national standard rule matching result is normal compliance and the time-series anomaly score exceeds the threshold, then a potential unknown anomaly marker is generated; if the national standard rule matching result is normal compliance and the time-series anomaly score does not exceed the threshold, then it is confirmed as normal compliance.

6. The method according to claim 1, characterized in that, The construction of the compliance baseline snapshot file includes: for 11-bit standard CAN IDs, setting the corresponding bits to 1 according to the rule that the byte index is equal to the integer quotient of the ID value divided by 8 and the bit offset is equal to the remainder of the ID value modulo 8; for 29-bit extended CAN IDs, dividing the ID space into 16 segments by the high 4 bits, and maintaining an independent bitmap for each segment; for valid automotive Ethernet communication ports, generating an Ethernet port bitmap according to the rule that the byte index is the integer quotient of the port number divided by 8 and the bit offset is the remainder of the port number modulo 8. The vehicle's CAN ID bitmap, Ethernet port bitmap, and corresponding VIN are bound together and merged into a list of valid Ethernet communication ports to form a vehicle-specific compliance baseline snapshot file.

7. The method according to claim 1, characterized in that, The method also includes a hardware affinity computing power scheduling step: the vehicle-side hardware platform includes a real-time microcontroller core for processing the first priority task corresponding to high confidence anomaly events, a dedicated neural network accelerator core for executing vehicle-side AI model inference tasks and having read and write permissions to update the vehicle-side AI model, and an application processor core for executing routine data acquisition and desensitization tasks. In the real-time microcontroller core, multiple synchronously triggered first-priority tasks are processed sequentially according to their corresponding security event levels and timestamps, and the task queues of both the real-time microcontroller core and the dedicated neural network accelerator core are not discarded.

8. The method according to claim 1, characterized in that, The method also includes cloud-based full lifecycle compliance monitoring: each vehicle connected to the cloud has a vehicle baseline model with a data distribution profile composed of several indicator quantiles when the vehicle is running normally. This model is used to continuously monitor the deviation of the real-time message data uploaded by the vehicle from the baseline and to periodically update the parameters in the vehicle baseline model based on the compliance message data of the vehicle in the most recent period. When the cloud-based system detects that a certain vehicle indicator exhibits a stable unidirectional drift across multiple consecutive windows but has not yet exceeded the compliance threshold, it generates a predictive detection command containing the target CAN ID that needs enhanced monitoring and the detection parameters that need temporary adjustment, and sends it to the vehicle. The real-time message data that passes the vehicle baseline model detection is encrypted and stored using SM4 to form an archive record. Each archive record contains a preceding archive hash pointer that points to the SM3 hash value of the previous archive record. Several chained archive records constitute the full vehicle compliance status file of the vehicle. The file deletion and archiving overwrite operations are recorded in the audit log, and the audit log uses chain-style evidence storage.

9. The method according to claim 1, characterized in that, The method includes iteratively updating the vehicle-side AI model for parsing message data based on cloud rules: the cloud performs secondary verification of the parsing and marking information of the message data uploaded by the vehicle, and includes inconsistent message data into the deviation dataset after invalid deviation filtering. The invalid deviation filtering includes identifying and filtering message data that has been manually debugged. When the same type of deviation event in the deviation dataset reaches a threshold, the distillation update of the vehicle-side AI model is triggered. The distillation update includes using the abnormal score output of the cloud-based AI teacher model as a soft label and the abnormal score output of the vehicle-side student model as the predicted value, and using the mean squared error as the distillation loss function to generate an updated vehicle-side AI model. The vehicle-side AI model is also equipped with an independent triggering mechanism. When the number of newly added unknown abnormal samples in the deviation dataset that are not covered by the existing rules of the vehicle-side AI model reaches a threshold, the distillation update of the vehicle-side AI model is triggered. When the vehicle fails to upgrade based on the OTA upgrade package and rolls back the vehicle AI model version, the cloud synchronously rolls back the invalid deviation filtering rules and vehicle baseline model corresponding to the vehicle version.

10. A vehicle-edge-cloud collaborative vehicle information security compliance management system, characterized in that, For performing the method according to any one of claims 1 to 9, comprising: The vehicle-side embedded SDK module contains a vehicle-side rule engine IP core, a program for receiving, parsing, and selectively capturing promiscuous monitoring and selective capture of packet data, a three-level hierarchical desensitization program, and a national cryptographic SM2 / SM3 / SM4 encrypted transmission program; the vehicle-side hardware platform is configured with a heterogeneous computing array including a real-time microcontroller core, a dedicated neural network accelerator core, and an application processor core, with physical isolation between the cores achieved through hardware firewalls and memory protection units; The cloud-based SaaS platform module deploys a time-series anomaly screening IP unit, a national standard rule engine IP unit, a threat level analysis IP unit, and an OTA upgrade control IP unit; it also deploys a deviation monitoring unit that determines the deviation of real-time monitoring message data based on a vehicle-specific vehicle baseline model, a predictive detection command generation and issuance unit, a cloud rule and vehicle-side AI model collaborative iterative update unit, a full lifecycle archive chain storage and management unit, and a disconnection status version synchronization unit for data synchronization after offline recovery of vehicle-side or edge-side devices. The edge industrial control detection module deploys multi-factor network detection and offline isolation programs, security chip verification programs, CAN ID and Ethernet port baseline snapshot file construction and dynamic update programs, bitmap comparison and AI-assisted model verification programs, local rule engine judgment and rectification instruction generation programs, and fragment synchronization programs.

Images