Vehicle-mounted controller memory monitoring method based on differential redundancy

Abstract

The invention provides a vehicle-mounted controller memory monitoring method based on differential redundancy, and relates to the technical field of electric monitoring, and the method comprises the following steps: constructing a multi-dimensional graph representation and feature dictionary of a memory region; utilizing reinforcement learning to adaptively optimize a monitoring strategy according to a real-time state and a prediction risk; executing multi-level differential verification of context awareness, and taking a verification result as an observation evidence; performing deep fault probability prediction and interpretability analysis by adopting a graph neural network; through Bayesian or fuzzy logic intelligent fusion verification observation and model prediction, high-confidence risk assessment is realized; and active protection instructions such as predictive error correction and fault isolation are generated and triggered based on an evaluation result and closed-loop feedback. According to the scheme, prediction, adaptation, efficient verification and intelligent decision making are integrated, the foreseeability, adaptability, efficiency and robustness of vehicle-mounted memory monitoring are remarkably improved, and a comprehensive and advanced guarantee is provided for function safety and information safety of a vehicle.

Description

Technical Field

[0001] The present invention relates to the technical field of electrical monitoring, and in particular to a vehicle-mounted controller memory monitoring method based on differential redundancy. Background Art

[0002] As automotive electrical and electronic (E / E) architectures evolve toward centralization, domain control, and service-oriented architecture (SOA), the functions carried by onboard control units (ECUs / DCUs) are becoming increasingly complex, and the amount of software code is surging. This has led to unprecedented demands for memory capacity, performance, and reliability. As the core vehicle for program execution and data storage, the integrity and stability of memory are directly related to the functional safety and cybersecurity of the vehicle. Traditional memory monitoring methods, such as periodic full memory checks or simple parity checks / ECC, often fall short when faced with complex transient faults, aging effects, potential security attacks, and strict real-time and resource constraints. These methods suffer from issues such as insufficient monitoring coverage, poor real-time performance, high resource consumption, and weak fault prediction capabilities. Summary of the Invention

[0003] Technical problems solved

[0004] In view of the deficiencies of the prior art, the present invention provides a vehicle controller memory monitoring method based on differential redundancy, which solves the problems of the prior art.

[0005] Technical Solution

[0006] To achieve the above objectives, the present invention is implemented through the following technical solutions: a vehicle controller memory monitoring method based on differential redundancy, comprising the following steps:

[0007] S1. Multi-dimensional memory state space construction and initialization: laying the foundation for accurate monitoring

[0008] Central to this step is building a comprehensive, dynamic, and information-rich in-memory digital twin representation.

[0009] Memory graph structure representation (GraphStructureRepresentation):

[0010] It goes beyond the traditional linear address perspective, captures the complex relationships between memory cells, and provides a structured foundation for subsequent pattern recognition and fault propagation analysis.

[0011] Nodes: These can be memory units of varying granularity, including single bits (fine but complex), bytes, words, physical blocks (e.g., cache line size or flash block size), or even abstracted logical function blocks (task-specific stack areas, critical data structures). Choosing the granularity requires a balance between monitoring accuracy and computational overhead.

[0012] Edges: Represents the relationship between nodes. Types include:

[0013] Physical contiguity: Continuity in memory addresses.

[0014] Logical adjacency: pointer relationships within data structures (linked lists, trees).

[0015] Historical access association: Based on the program execution flow or data access pattern, association edges are established between memory units that are frequently accessed together.

[0016] Shared resource association: Establish associations between nodes in the memory area shared by multiple tasks.

[0017] EdgeWeights: Edge weights are dynamically updated, reflecting the strength or importance of the connection. Updates are based on:

[0018] Access frequency: The more frequently two nodes are visited consecutively or within the same time window, the greater their weight.

[0019] Logical dependency strength: pointer relationship, data producer-consumer relationship.

[0020] Historical error correlation: If the error of one node is often accompanied by the error of another node in history, the edge weight between them increases, which helps to reveal potential fault propagation paths or shared physical defects.

[0021] Initial state attribute acquisition:

[0022] Hardware Built-In Self-Test (BIST-Built-InSelf-Test): Hardware-level memory tests (Marchtests and their variants) performed when the controller is powered on or at specific times to detect manufacturing defects or permanent faults (Stuck-at, Transitionfaults, etc.) and obtain the initial "hard fault" state.

[0023] Baseline Checksum / Fingerprint: Calculates the initial checksum, CRC, or hash value for the target memory area (especially the static code segment and configuration data area) as a benchmark (Golden Reference) for subsequent differential comparisons. This benchmark can be generated after system initialization, secure boot, or software update.

[0024] Multi-dimensional fault feature dictionary (Multi-dimensionalFaultFeatureDictionary):

[0025] Associate rich feature information with each node (or subgraph) to provide input for subsequent machine learning models.

[0026] Node history status: records past verification results, number and type of errors detected.

[0027] Error patterns: Statistical analysis of historical error types (single-bit upsets, multi-bit upsets, block errors, specific data pattern errors).

[0028] Access statistics: read / write frequency, last access time, access task distribution, etc.

[0029] Associated context information: software tasks, functional domains (ADAS, power domain), safety levels (ASIL), data types (code, stack, heap, key variables), etc. associated with the memory unit.

[0030] Physical information (optional): associated memory chip physical location, temperature sensor readings, etc.

[0031] S2. Adaptive Monitoring Strategy Optimization Based on Reinforcement Learning: Achieving Intelligent Resource Scheduling

[0032] This step introduces an agent, which enables it to dynamically adjust the monitoring strategy according to the real-time changing system status and environment to achieve the optimal monitoring effect and resource utilization.

[0033] Reinforcement Learning (RL) Agents:

[0034] This replaces traditional fixed, rule-based monitoring strategies to enable online, adaptive optimization of strategies. RL agents interact with their environment (the memory system and its state) through trial-and-error learning, finding the action strategy that maximizes the cumulative reward in a given state.

[0035] Selected algorithm:

[0036] Deep Q-Network (DQN): Applicable to problems with discrete action spaces and high-dimensional state spaces. It uses a neural network to approximate the Q-value function (state-action value function) and stabilizes the learning process through experience replay and target network.

[0037] Actor-Critic: This approach combines value-based (critic, evaluating the quality of actions) and policy-based (actor, deciding which action to take) approaches. The critic learns the value function, while the actor learns the policy function, with the two mutually reinforcing. It is applicable to both continuous and discrete action spaces. Its variants (A3C, DDPG, and SAC) each have advantages in terms of convergence speed and stability.

[0038] Selection basis: depends on the specific design of state space and action space (continuous / discrete, dimensionality), real-time requirements, and available computing resources.

[0039] State Space: This defines the environmental information that the RL agent can observe when making decisions. The richness of its design directly affects the quality of its decisions.

[0040] Memory graph node features: real-time features of each node (from the feature dictionary, including short-term statistics).

[0041] Historical monitoring statistics: recent overall fault detection rate, false alarm rate, error frequency in specific areas, etc.

[0042] Neural network prediction output: The risk probability map output by the GNN / Transformer model in S4 serves as the prediction input for future states.

[0043] Controller real-time resource load: CPU usage, memory bandwidth usage, power consumption, etc.

[0044] Vehicle operating conditions: vehicle speed, driving mode (automatic / manual), operating environment (congested / high-speed), etc., which affect memory access patterns and potential risks.

[0045] Bus Error Frame Rate: The error frame rate of buses such as CAN / Ethernet indirectly reflects system pressure or potential interference sources, affecting memory stability.

[0046] Security module alarm status: An alarm from a hardware security module (HSM) or intrusion detection system (IDS) indicates that the memory is under attack.

[0047] Action Space: defines the actions that the RL agent can perform, that is, how to adjust the monitoring policy.

[0048] Select the verification level: Determine which level or levels of verification (physical layer / semantic layer / association layer) are mainly performed in the current cycle.

[0049] Adjust the check frequency: Increase or decrease the check frequency for the entire memory or a specific area.

[0050] Determine the verification algorithm: Select an appropriate verification algorithm based on risk assessment and resource conditions. Example:

[0051] Quick check: XOR, simple cumulative sum (suitable for low-risk areas or when resources are limited).

[0052] Standard checksum: CRC (CRC-32), providing better error detection capability.

[0053] Advanced hashing: cryptographic hashing such as SHA-256 (computationally expensive, but can detect malicious tampering and can be used for critical code or data segments).

[0054] Specific pattern matching: Perform pattern detection based on known memory failure modes (RowHammer effect) or attack characteristics.

[0055] Select key monitoring areas: Concentrate monitoring resources on high-risk nodes, key subgraphs, or areas with recent frequent access / errors.

[0056] Reward Function: defines the goal of RL agent learning. Designing a reasonable reward function is crucial.

[0057] Goal: Maximize a comprehensive indicator and balance multiple conflicting objectives.

[0058] Composition (weighted combination):

[0059] True Positive Rate: rewards successful detection of actual memory errors.

[0060] Prediction accuracy: The accuracy of the S4 model prediction is rewarded (verified by subsequent verification results).

[0061] Resource consumption efficiency: Penalize excessive CPU usage, memory bandwidth consumption, or monitoring latency.

[0062] Impact on system performance: Penalize application performance degradation (increased response latency) caused by monitoring activities.

[0063] Weight: The weight coefficient needs to be adjusted and calibrated according to the specific application scenario and safety requirements.

[0064] S3, context-aware dynamic layering and differential verification: Performs efficient and accurate checks as input to S4 and S5. This step actually performs memory verification operations based on the strategy optimized in S2.

[0065] Multi-level verification: Balances coverage, depth, and efficiency. Different levels target different types of errors and abstraction levels.

[0066] Basic Physical Layer (BPL): Targets: memory bits, bytes, or physical blocks. Fast integrity check algorithms include XOR checksum, cumulative sum, or hardware-supported fast CRC. Fast, low-overhead, and capable of detecting basic physical errors such as random bit flips. Wide coverage.

[0067] Data Semantic Layer Verification (DataSemanticLayer):

[0068] Object: A specific data type and structure.

[0069] Customized verification rules: Check whether the function pointer points to a legal code area, and check whether the linked list pointer is valid (non-empty, aligned). Invariant Checking: Use predefined properties (Invariants) that must be maintained on key data structures (operating system task control block TCB, scheduling table, safety state machine) for checking. The value of a state variable must be within a predetermined range, and the length of the queue and its element count must match. Functional safety-related variable verification: Perform range checks, logical consistency checks (consistency between vehicle speed sensor readings and wheel speed sensor readings), and timing constraint checks on key variables with high ASIL levels. In-depth inspections can detect errors or inconsistencies at the logical level, which are closely related to specific applications and functional safety requirements.

[0070] Dynamic Association Layer Check (Dynamic Association Layer): Object: A collection of memory areas dynamically formed according to real-time access patterns or logical associations (code segment + data segment + stack of the currently active task, or multiple buffers processing the same sensor data stream). Perform consistency checks on these logically associated areas. Check whether the data written by the producer is correctly read by the consumer and is not corrupted, or compare whether multiple copies of shared data are consistent. Focus on the flow and consistency of data between different areas, and can detect cross-regional data corruption or synchronization problems. Differential Redundancy Check (Differential Redundancy Check): Does not directly verify the absolute correctness of memory contents (requires storing a complete mirror or performing complex recalculations), but verifies whether its changes relative to a baseline are as expected.

[0071] Calculate the current fingerprint: For the selected memory area, use the verification algorithm specified by S2 to calculate the current verification fingerprint (Checksum, CRC, Hash).

[0072] Obtaining a baseline fingerprint: Read the historical baseline fingerprint of the area (stored after S1 initialization or the last successful verification) from memory (a protected, verified area), or read the corresponding fingerprint from a mirror memory area. Compare the current fingerprint with the baseline fingerprint.

[0073] Result judgment:

[0074] Consistent: The memory content has not changed (detectably) at the verification granularity or the change is as expected (the baseline has been updated synchronously).

[0075] Inconsistency: A potential error was detected.

[0076] High efficiency: Computing and comparing fingerprints is often much faster than reading and comparing entire memory regions or recomputing complex state.

[0077] Low overhead: only a relatively small fingerprint needs to be stored as a baseline, rather than a complete memory image.

[0078] Basic Check Report (BasicCheckReport):

[0079] Content: Record the detailed results of this periodic calibration, including:

[0080] Verification result: pass / fail.

[0081] Error Location: Indicates the memory address or area where an inconsistency was detected.

[0082] Error type (preliminary): Based on the verification algorithm and level, the preliminary judgment is single bit error, multiple bit error, block error, etc. Verification level and algorithm: Record the specific verification method used this time.

[0083] S4. Deep fault prediction and explanation based on graph neural networks: Gain insight into potential risks and root causes. This step uses advanced machine learning models to deeply analyze memory status from time and space dimensions, achieving a leap from "detection" to "prediction."

[0084] Model selection: Graph Neural Network: This processes the graph structure data constructed by S1. It can effectively capture the complex dependencies between memory cells (physical adjacency, logical associations, and historical co-occurrences) and simulate the propagation characteristics of faults in the memory space.

[0085] Graph Convolutional Networks: Update node representations by aggregating neighbor node information and excel at capturing local structural features. GraphSAGE generates node embeddings by sampling and aggregating neighbor features, making it particularly well-suited for processing large graphs and performing inductive learning (predicting unseen graphs). Gated Graph Neural Networks: Introducing a gating mechanism similar to GRU or LSTM to better capture long-range dependencies and temporal information in graphs.

[0086] Transformer (with attention mechanism):

[0087] Although originally designed for sequential data, its self-attention mechanism effectively captures long-range dependencies between nodes, unconstrained by the local structure of the graph. It can process graph data (with positional encoding or graph structure encoding) or memory access sequence data. It can be used to analyze memory access timing patterns and verify fingerprint change sequences to identify anomalies or predict future trends.

[0088] Input: In-memory graph structure representation: the graph (nodes, edges, weights) constructed by S1.

[0089] Node features: Information from the multidimensional fault feature dictionary constructed by S1, including the current cycle basic verification report generated by S3 as the latest observational evidence. Some information from S2's state space, including vehicle operating conditions and bus load, provides a more comprehensive background for the model.

[0090] Model training:

[0091] Pre-training: Offline pre-training can be performed using historical operation data, simulation data, or data injected with faults.

[0092] Online Update: The model can be incrementally learned or periodically retrained using new monitoring data during vehicle operation to adapt to changing operating conditions and memory aging characteristics. Federated learning (described later) can be used in this phase.

[0093] Output: High-resolution failure probability prediction map: Outputs a future failure probability value for each memory node (or the smallest defined monitoring unit), forming a detailed risk map indicating which areas are most likely to have problems in the short term.

[0094] Explainable AI (XAI): Understand why the model makes predictions, enhance trust, and facilitate debugging, verification, and security certification.

[0095] Attention-based mechanisms: Using Transformers or GNNs with attention, attention weights can be directly visualized to show which nodes, features, or historical events the model focuses on when making predictions. The gradient of the output probability with respect to the input features (node ​​features, edges) is calculated, and features / edges with large gradient values ​​contribute more to the prediction results. Surrogate models: LIME (Local Interpretable Model-agnostic Explanations) or SHAP (SHapley Additive Explanations). These techniques approximate the behavior of complex models by learning a simple, interpretable model near the prediction point, thereby providing local or global explanations of feature importance. They provide visual explanations of the basis for predictions, such as highlighting memory regions, related historical error events, or specific access patterns that contribute most to high-risk predictions. They also display potential fault propagation paths (based on edge influences learned by GNNs).

[0096] S5. Intelligent arbitration and decision-making based on Bayesian fusion or fuzzy logic: Integrate evidence and make accurate assessments. This step combines the “observational evidence” from direct verification (S3) and the “prior / conditional probability” from model prediction (S4) to conduct a more comprehensive and robust risk assessment.

[0097] The fusion method uses a Bayesian network: a directed acyclic graph (DAG) is used to represent the probabilistic dependencies between variables. Nodes represent variables such as memory node status (healthy / faulty), verification results, and GNN prediction probabilities. Edges represent conditional dependencies.

[0098] Fusion process: The S3 basic verification report (the verification result of a specific node) is input into the network as observational evidence. Using Bayes' theorem, combined with the prior probability predicted by the GNN (or as the conditional probability P(prediction|true state)), the posterior probability distribution of the true health state of the memory node is updated.

[0099] Dynamic weight adjustment: The weight of evidence in fusion can be dynamically adjusted based on its reliability. For example, the reliability of basic verification results: Advanced verification algorithms (cryptographic hashes) or consistent results from multiple verifications are given a higher weight. Physical layer fast verification is given a relatively lower weight. GNN prediction confidence: The model typically accompanies its prediction output with a confidence score. High-confidence predictions are given a higher weight.

[0100] Fuzzy Logic System: Uses fuzzy sets and fuzzy rules to process imprecise and uncertain information. Suitable for describing fuzzy concepts such as "high risk" and "minor anomaly." Fusion process: Define the verification results ("pass," "fail," "minor inconsistency") and GNN prediction probabilities ("low," "medium," "high") as fuzzy language variables. Design fuzzy rules (IF-THEN rules), for example: "IF verification fails AND GNN predicts high risk THEN the memory state is extremely dangerous." Calculate the final memory health status (which can be a fuzzy value or a clear risk level) using a fuzzy inference engine (Mamdani or Sugeno model).

[0101] Output: Refined memory health assessment: Provides a more precise health status assessment for each memory node (or area), beyond just "normal / faulty." This includes multiple risk levels (safe, warning, dangerous, and critical). Confidence intervals: Assessment results are accompanied by confidence intervals or probability distributions to quantify the uncertainty of the assessment.

[0102] S6. Closed-loop feedback and active protection command generation: To achieve self-healing and safety assurance, this step completes the closed loop of monitoring-decision-action and takes proactive measures based on the evaluation results.

[0103] Closed-loop feedback: enables continuous learning and adaptive improvement of the system.

[0104] Refined health status assessment and arbitration confidence: This information is fed back to S2's RL agent as richer state input for the next decision cycle. The RL agent can learn which policy combinations lead to more accurate and confident assessment results.

[0105] Prediction Explanations (from XAI): can help the RL agent understand what factors lead to high-risk predictions and thus adjust its attention to specific features or regions.

[0106] Update the multi-dimensional fault feature dictionary: Update the fault information, risk assessment results, and related context information confirmed in this cycle to the feature dictionary of S1 to provide more accurate historical data for future monitoring and prediction.

[0107] Active protection or corrective action command generation:

[0108] Trigger condition: When the S5 evaluation results show that a certain memory area has a confirmed fault, or the probability of a future fault exceeds a preset threshold and the confidence level is high enough.

[0109] Instruction type (select based on risk severity and system capabilities):

[0110] Predictive Error Correction Code: The system is equipped with advanced ECC based on LDPC (Low-Density Parity-Check) code and supports soft decision decoding. It can use the soft information (probability) provided by S4 / S5 to perform more powerful error correction and repair impending errors.

[0111] Memory Scrubbing / Refresh: Active read and write refresh of areas suspected of transient failures (DRAM cell charge leakage) or potential aging issues.

[0112] Online Repair: Hardware support that attempts to remap or repair memory cells / rows / columns with permanent faults.

[0113] Data migration and fault area isolation: Migrate critical data or tasks from affected or high-risk memory areas to spare or safe areas, and mark the faulty area as unavailable, preventing further access.

[0114] Adjust the scheduling of related software tasks: lower the priority of tasks that access high-risk memory areas, or temporarily suspend these tasks to reduce potential impact.

[0115] Triggering the system to enter safety degradation mode (Fail-Operational / Fail-Safe): A serious problem occurs in the critical memory area, and some non-critical functions need to be shut down to ensure the operation of core safety functions, or the vehicle is placed in a safe state.

[0116] Record detailed diagnostic information: Record fault details, timestamps, related context (task, operating conditions, bus status), prediction basis for S4, and evaluation process for S5, etc., and store them in non-volatile memory for offline root cause analysis (Root Cause Analysis). Correlating cross-domain (sensor, actuator, network) context information is particularly important for diagnosing complex problems.

[0117] Send an alarm to the security monitoring system: notify the security monitoring center inside the car or the car-cloud collaboration and report the memory abnormality event.

[0118] In step S1, the edge weights of the memory graph structure are dynamically updated based on memory access frequency, logical dependencies, or historical error correlation. While protecting data privacy, monitoring data from a large fleet (multiple vehicles) is used to improve the performance and generalization ability of the model.

[0119] In step S2, the RL agent uses a deep Q-network (DQN), Actor-Critic or its variants for training and decision-making.

[0120] In step S3, the data semantic layer verification utilizes predefined invariants about specific data structures to perform checks, or performs range and logical consistency checks on key variables related to functional safety.

[0121] In step S4, the GNN model adopts a graph convolutional network (GCN), GraphSAGE or gated graph neural network (GatedGNN) architecture to effectively capture the spatial dependency and propagation characteristics of memory faults.

[0122] In step S4, the XAI technology includes using attention weights, gradient information or proxy models (LIME, SHAP) to identify memory nodes, features or historical events that contribute most to fault prediction.

[0123] In step S5, Bayesian fusion dynamically adjusts the weight of evidence based on the reliability of the basic verification results (related to the verification algorithm and hierarchy) and the confidence of the GNN prediction.

[0124] The vehicle controller memory monitoring method also includes: using the GNN / Transformer model to analyze memory access sequences or verify fingerprint change patterns to detect potential security intrusion activities that match known attack signatures or abnormal behavior patterns.

[0125] The vehicle controller memory monitoring method also includes: through a federated learning mechanism, using monitoring data and model updates from multiple vehicles while protecting user privacy, continuously optimizing the RL agent strategy and GNN / Transformer prediction model.

[0126] Leveraging GNN / Transformer for security intrusion detection: In addition to detecting random or aging faults, abnormal patterns in memory access sequences (continuously writing large numbers of instructions, atypical jumps, unauthorized access to sensitive areas) or specific patterns of changes in verification fingerprints (consistent with known malware modifying data) can indicate security attacks (buffer overflows, code injection, data tampering). GNN / Transformer models can be trained to identify these known attack signatures or common abnormal behavior patterns. Taking memory access logs or verification fingerprint sequences as input, the model outputs a security threat severity assessment. This adds a cybersecurity dimension to memory monitoring.

[0127] The central server distributes the initial RL policy model and GNN / Transformer prediction model to each vehicle. Each vehicle uses the locally collected memory monitoring data (state, action, reward, verification results, prediction results, etc.) to update the model parameters locally. The data is retained on the vehicle side and does not leave the vehicle. Each vehicle uploads the model updates (gradients or model parameters, not the original data) generated by local training to the central server in an encrypted manner. The central server aggregates model updates from multiple vehicles (using the FederatedAveraging algorithm) to generate a better global model. The updated global model is distributed to the vehicle again to start the next round of iteration. It brings together diverse driving scenarios and hardware individual difference data, significantly improving the robustness and accuracy of the model while meeting privacy regulations.

[0128] In order to efficiently execute the above complex monitoring methods, the corresponding hardware supports:

[0129] Functional Unit: Memory Graph Construction and Feature Management Unit: Responsible for maintaining the memory graph structure, updating node / edge features, and managing the fault feature dictionary. This requires efficient data structures and access mechanisms.

[0130] Reinforcement Learning Strategy Optimization Unit: Executing the reasoning (decision-making) process of the RL algorithm requires a certain amount of computing power, especially if using a neural network-based RL algorithm. Online training requires even higher computing resources.

[0131] Context-aware verification execution unit: Efficiently executes various verification algorithms (requires hardware CRC accelerator) and schedules verification tasks according to policy instructions.

[0132] Graph Neural Network Prediction and Interpretation Unit: Performs inference on GNN / Transformer models. This is typically a computationally intensive task that requires a dedicated AI accelerator (NPU - Neural Processing Unit) to meet real-time requirements. Performing XAI calculations also requires additional resources.

[0133] Intelligent arbitration decision unit: implements Bayesian network reasoning or fuzzy logic calculation.

[0134] Active protection instruction generation unit: generates and issues control instructions based on decision results.

[0135] The core hardware includes:

[0136] Processor: A high-performance multi-core CPU / MPU / MCU is required that can handle monitoring tasks, RL decision-making, GNN reasoning, and normal ECU functions in parallel. This includes a dedicated DSP core or AI acceleration core.

[0137] RAM: RAM (LPDDR4 / 5) of sufficient capacity and bandwidth is required to store the memory graph, feature dictionary, model parameters, and run the monitoring algorithm itself.

[0138] Non-volatile memory (NVM): Flash or EEPROM, used to store baseline checksums, pre-trained models, long-term diagnostic logs, RL policies, etc. The erase and write lifespan and speed of NVM need to be considered.

[0139] Hardware support: A hardware CRC engine, ECC controller (soft decision support is preferred), memory management unit (MMU), or memory protection unit (MPU) is required to support address mapping, access control, and isolation.

[0140] Beneficial effects

[0141] The present invention provides a vehicle controller memory monitoring method based on differential redundancy.

[0142] Beneficial effects:

[0143] 1. By leveraging graph neural networks to deeply analyze the complex relationships and historical evolution of memory cells, this system surpasses traditional real-time detection and accurately predicts potential memory failure risks. Combined with decision-making insights provided by explainable artificial intelligence and continuous learning driven by a closed-loop feedback mechanism, the system can trigger proactive protection measures such as predictive error correction, adaptive refresh, or secure isolation, fundamentally improving the reliability and resilience of the vehicle controller, transforming passive response into active defense.

[0144] 2. This invention utilizes a reinforcement learning engine, with monitoring strategies that respond in real time to vehicle dynamics, controller load, and memory health predictions, intelligently adjusting the level, frequency, algorithm, and focus areas of verification. This context-aware, adaptive mechanism, combined with efficient multi-level differential verification technology, ensures the most effective fault coverage with near-optimal resource usage under various operating conditions. This significantly outperforms static or fixed-rule monitoring methods, ensuring efficient parallelization of monitoring tasks and core functions. BRIEF DESCRIPTION OF THE DRAWINGS

[0145] Figure 1 is a system flow chart of the present invention;

[0146] Figure 2 It is a system structure diagram of the present invention;

[0147] Figure 3 This is the system electronic control logic diagram of the present invention. DETAILED DESCRIPTION

[0148] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention. Specific embodiment one:

[0150] include Figure 1-3 As shown, a vehicle controller memory monitoring method based on differential redundancy includes the following steps:

[0151] S1. Multidimensional Memory State Space Construction and Initialization: Build a graph representation of the target memory region, where nodes represent memory cells or blocks and edges represent their logical or physical adjacencies or historical access associations. Use hardware self-test (BIST) and baseline verification to obtain initial node state attributes and build a multidimensional fault signature dictionary containing node historical states, error patterns, access statistics, and associated context information.

[0152] S2. Adaptive monitoring strategy optimization based on reinforcement learning: Utilize reinforcement learning (RL) agents to continuously optimize monitoring strategies. The RL agent's state space (StateSpace) includes at least the characteristics of the current memory graph nodes, historical monitoring statistics, the risk distribution of the neural network prediction output, the controller's real-time resource load, the vehicle's operating conditions, the error frame rate of the associated bus (including CAN / Ethernet), and the safety module's alarm status. The RL agent's action space (ActionSpace) includes at least selecting the verification level, adjusting the verification frequency of each level, determining the verification algorithm (including XOR, CRC variants, advanced hashing, specific pattern matching), and selecting the nodes or subgraphs to be monitored. The RL agent learns and makes decisions based on maximizing a predefined reward function (RewardFunction, including: a weighted combination of the detected actual failure rate, prediction accuracy, resource consumption efficiency, and impact on system performance), and outputs the current optimal monitoring strategy instructions.

[0153] S3. Context-aware dynamic layering and differential verification: Based on the monitoring policy instructions output by the RL agent, perform multi-level, context-aware differential redundancy verification. The layers include at least:

[0154] Basic physical layer check: fast integrity check of memory bits or physical blocks;

[0155] Data semantic layer verification: Customized verification rules or invariance checks are used for specific data types (including critical operating system data structures, functional safety-related variables, and application stacks);

[0156] Dynamic association layer verification: Consistency verification is performed on dynamic memory areas (including task-specific data sets) formed based on access patterns or logical associations. Differential redundancy verification compares the currently calculated verification fingerprint with historical benchmarks or images, generating a basic verification report for this cycle that includes verification results, error locations, and error types.

[0157] S4. Deep Fault Prediction and Explanation Based on Graph Neural Networks: Memory graph structure representation, node features (including basic verification reports for this cycle), and related contextual information are input into a pre-trained or online updated graph neural network (GNN) or a Transformer model with an attention mechanism. The model outputs a high-resolution memory node-level fault probability prediction map and uses Explainable AI (XAI) technology (including node / edge importance analysis) to provide prediction evidence or a visual explanation of potential fault propagation paths.

[0158] S5. Intelligent arbitration and decision-making based on Bayesian fusion or fuzzy logic: Using a Bayesian network or fuzzy logic reasoning system, the basic verification report of the current cycle (as observational evidence) is integrated with the predicted probability map of the GNN / Transformer model (as prior or conditional probability). This comprehensively assesses the immediate and future risks of each memory node and generates a refined memory health status assessment with confidence intervals.

[0159] S6. Closed-loop feedback and active protection instruction generation: The refined memory health status assessment, prediction basis explanation, and arbitration confidence are fed back to the RL agent as the state input for the next decision cycle, and the multi-dimensional fault feature dictionary is updated. Based on the assessment results, if a fault is detected or predicted with a high probability, the corresponding active protection or corrective action instructions are generated and triggered. The instructions include but are not limited to: triggering predictive error correction code (including LDPC-based soft decision error correction), initiating memory area refresh or online repair, performing data migration and fault area isolation, adjusting related software task scheduling, triggering the system to enter safety degradation mode, recording detailed diagnostic information and associating cross-domain context for root cause analysis, or issuing memory anomaly alerts to the security monitoring system.

[0160] In step S1, the edge weights of the memory graph structure are dynamically updated according to the memory access frequency, logical dependency, or historical error correlation.

[0161] In step S2, the RL agent uses Deep Q Network (DQN), Actor-Critic or its variants for training and decision making.

[0162] In step S3, the data semantic layer verification uses predefined invariants about specific data structures to check, or performs range and logical consistency verification on key variables related to functional safety.

[0163] In step S4, the GNN model adopts the graph convolutional network (GCN), GraphSAGE or gated graph neural network (GatedGNN) architecture to effectively capture the spatial dependency and propagation characteristics of memory faults.

[0164] In step S4, XAI technology includes using attention weights, gradient information or proxy models (including LIME, SHAP) to identify memory nodes, features or historical events that contribute most to fault prediction.

[0165] In step S5, Bayesian fusion dynamically adjusts the weight of evidence according to the reliability of the basic verification results (related to the verification algorithm and hierarchy) and the confidence of the GNN prediction.

[0166] The vehicle controller memory monitoring method also includes: using the GNN / Transformer model to analyze memory access sequences or verify fingerprint change patterns to detect potential security intrusion activities that match known attack signatures or abnormal behavior patterns.

[0167] The vehicle controller memory monitoring method also includes: through the Federated Learning mechanism, while protecting user privacy, using monitoring data and model updates from multiple vehicles to continuously optimize the RL agent strategy and GNN / Transformer prediction model.

[0168] The hardware includes a vehicle controller memory monitoring method. The hardware is used to execute various functional units, including: a memory graph construction and feature management unit, a reinforcement learning strategy optimization unit, a situational awareness verification execution unit, a graph neural network prediction and interpretation unit, an intelligent arbitration decision unit, and an active protection instruction generation unit. The hardware also includes a processor and memory. Specific embodiment two:

[0170] include Figure 1-3 As shown, based on the technical solution of the specific embodiment 1, further application cases are given including the following:

[0171] In high-level autonomous driving systems, the Perception Fusion Domain Controller (ADC) is the core unit for achieving accurate environmental perception and is typically required to meet ISO 26262 ASI L level requirements. This controller integrates data streams from a heterogeneous sensor array (high-resolution image sensors, lidar, millimeter-wave radar, inertial measurement units, etc.) and performs intensive computing tasks, including but not limited to deep neural network (DNN)-based target detection and classification, multi-target tracking (MOT), spatiotemporal alignment and fusion of sensor data, and the construction of a drivable environment (free space, lane lines, etc.). The memory subsystem needs to store massive amounts of raw data, intermediate feature maps, complex dynamic data structures (including trajectory hypothesis trees and occupancy gridmaps in multi-hypothesis trackers), and DNN model parameters. The challenges facing memory include not only potential hardware failures (including soft errors (SEUs) in DRAM cells, permanent failures caused by wear and aging, and neighboring interference effects such as RowHammer), but also potential software errors (including memory leaks, dangling pointers, and data races) introduced by high-concurrency computing, complex data dependencies, and real-time operating system (including AUTOSAR Adaptive Platform) scheduling, as well as growing cybersecurity threats (buffer overflows and code injection attacks targeting memory). Traditional hardware-based ECC (typically only capable of correcting single-bit errors) and periodic memory scrubbing mechanisms have significant limitations in coverage, real-time performance (especially for applications with control cycles less than 10ms), fault prediction capabilities, and the ability to address complex software and security issues.

[0172] S1. Fine-grained memory graph construction: Build a hierarchical memory graph model. Physical layer nodes represent memory particles (die), bank, rank or specific physical address range, and edges represent shared power rails, buses or physical proximity. Logical layer nodes are mapped to memory segments (code, data, BSS, stack) of AUTOSAR software components (SW-C), specific data structure instances (including std::vector <detectedobject>), RTOS objects (task control blocks (TCBs) and semaphores), or specific functional clusters (including LiDAR point cloud processing pipelines). Edges represent data dependencies (producer-consumer), function call relationships, pointer references, and shared memory (including memory regions shared by some / IP via IPC mechanisms). Edge weights are quantified and dynamically updated based on static analysis (including data flow analysis and control flow analysis) and dynamic runtime profiling results (including cache hit / miss rates, access latency, and access frequency).

[0173] Multi-source baseline establishment:

[0174] Hardware layer: Use advanced memory test algorithms (including MarchC- and MarchRAW) in the power-on self-test (POST) to obtain the initial health map of the physical layer. Record and manage the inherent defect information of memory particles (including).

[0175] Software layer: For key code segments loaded into memory (including security-critical algorithms and OS kernels), static configuration data, and fixed DNN model parameters, strong cryptographic hashes (including SHA-3 / 256) are calculated as immutable baselines. For dynamic data areas, the initial state or checksum is defined based on data structure invariants.

[0176] Comprehensive feature vector construction: A high-dimensional feature vector is associated with each graph node, including: physical properties (temperature sensor reading, voltage margin), static properties (ASIL level, memory type, access rights), dynamic statistics (read / write bandwidth, access entropy, ECC correctable / uncorrectable error count), historical status (last verification result, fault occurrence time series), and contextual information (associated AUTOSARSW-C / Runnable, current vehicle dynamic status).

[0177] S2. Hierarchical RL Architecture: Hierarchical reinforcement learning (HRL) or multi-agent RL (MARL) is preferred. High-level agents are responsible for macro-strategy (including adjusting overall monitoring intensity and resource budget allocation in different driving scenarios (urban congestion vs. highway cruising)), while low-level agents are responsible for specific execution-level optimization (including selecting the optimal validation algorithm and frequency for specific memory regions).

[0178] Enhanced state space: Contains predictive inputs from a high-fidelity simulator / digital twin, Trusted Execution Environment (TEE) integrity reports from a Hardware Security Module (HSM), relevant fault codes (DTCs) reported by other domain controllers (including the chassis domain), and fine-grained node-level fault probability distributions output by GNNs.

[0179] Refined action space: Parameterized action space allows RL to not only select discrete strategies (including algorithm type), but also control continuous parameters (including the size and step size of the checksum area, and the precise value of the checksum frequency). Actions can also include dynamically adjusting ECC strategies (including enabling stronger error correction modes, if supported by the hardware) or memory controller parameters (including refresh rate).

[0180] Safety-Oriented Reward Function: The reward function is designed strictly in accordance with the ISO26262 safety goals, maximizing the probability of detecting memory failures that lead to safety goal violations (SGviolations) while minimizing the impact on system response time (including end-to-end perceived latency) and constraining it within preset CPU and memory bandwidth utilization thresholds. A risk-based approach (combining the probability of failure and the severity of the damage) is used to weight the reward.

[0181] S3, hierarchical verification execution:

[0182] Physical layer: Use hardware CRC engine or vector instruction set (including NEON) acceleration to perform high-speed differential check on CacheLine or larger physical blocks (compared with the last check fingerprint or hardware redundant channel (if any)).

[0183] Semantic layer: Runtime assertions and invariant checks are performed on key data structures. These include verifying that the track state transitions in the target tracking list conform to the predefined finite state machine (FSM); checking that the covariance matrix output by the sensor fusion algorithm is positive definite; and verifying that the confidence score output by the DNN inference is within the valid range [0, 1]. These checks are integrated with AUTOSAR's runtime error handling mechanisms (including the E2E protection library and the Check library).

[0184] Correlation layer: Verifies the consistency of shared memory areas across software components or cores. Verifies that the end-to-end (E2E) protection checksums between the raw sensor data written to the shared memory and the data read by the downstream processing components match.

[0185] Differential verification optimization: Content-adaptive differential verification is used. For areas that change slowly (including static configurations), the fingerprint is recalculated only after it is confirmed to be written. For areas that change frequently (including raw data buffers), a lighter-weight incremental verification algorithm is used.

[0186] S4. Application of Advanced GNN Models: Deploy spatiotemporal GNN (STGNN) models, including combining GCN / GraphSAGE to capture spatial dependencies and LSTM / GRU to capture temporal evolution, or using graph transformer models with attention mechanisms. These models operate directly on the memory graph and learn the spatial propagation patterns (including the spread of errors from one bank to neighboring banks) and temporal evolution patterns (including the exponential growth of error rates with temperature and runtime) of faults (including hardware transient errors, software-induced memory corruption, and security attack signatures).

[0187] High-confidence prediction: Outputs node-level failure probability prediction with confidence score, clearly defines the prediction window (including the next 50ms), and focuses on predicting memory areas that lead to "frozen degrees of freedom" or critical decision errors.

[0188] XAI-driven diagnostic insights: Leveraging XAI technologies such as Integrated Gradients, GNN Explainer, or counterfactual explanations, not only high-risk nodes can be identified, but also the driving factors leading to the prediction (including "the high-risk prediction of node X is mainly due to the recent surge in the ECC uncorrectable error count of its associated physical block, and its connection to node Y in the graph, which has historically caused system crashes") and potential impact paths (highlighting the list of downstream target decisions affected by data dependency edges if node X fails).

[0189] S5. Structured Bayesian Network: Build a Bayesian network that includes variables such as memory node health status (latent variables), hardware sensor readings (including temperature and voltage), ECC event reports, multi-layer verification results (observational evidence), GNN prediction probabilities (conditional probability inputs), and the states of related software components. The network structure reflects known causal relationships and dependencies.

[0190] Dynamic evidence weighting and fusion: Probabilistic reasoning is performed using algorithms such as Belief Propagation or MCMC (Markov Chain Monte Carlo). The weight of each piece of evidence in the posterior probability calculation is dynamically adjusted based on the reliability of the evidence source (including hardware self-test results vs. fast XOR check results), the confidence level of the GNN prediction, and the timeliness of the check itself.

[0191] Quantified risk output: Outputs a refined health index (HealthIndex) or failure probability distribution for each critical memory area, including clear confidence intervals. Based on this assessment result and combined with the risk matrix defined in ISO 26262 (hazard level x exposure probability x controllability), a quantitative risk assessment of potential failures is performed.

[0192] S6, multi-dimensional closed-loop feedback: The quantified risk assessment, confidence level, XAI explanation, and the effectiveness of the protective measures taken are fed back to the RL policy optimizer of S2 and the feature dictionary update module of S1, forming a continuous learning and adaptation cycle.

[0193] Hierarchical active protection strategy:

[0194] Low risk / predictive: Triggers enhanced ECC (including a mode that enables stronger error correction capabilities), memory wear leveling (WearLeveling for Flash), and increased frequency of background memory scrubbing.

[0195] Medium risk / transient confirmation: triggers data refresh, task migration (migrating tasks accessing affected memory to other cores or reducing their priority), and redundant data source switching (including temporarily increasing reliance on other sensor data).

[0196] High Risk / Permanent Confirmation / Safety Critical:

[0197] Isolation and reconfiguration: Isolate the faulty area through the MPU / MMU and dynamically remap it if there is spare memory.

[0198] Degraded operation: Notify the Functional Safety Manager (FSM) to safely shut down some non-critical functions or reduce the level of autonomous driving (including from L3 to L2) according to predefined degradation strategies.

[0199] Safe state: If the core functions are damaged, the minimum risk strategy (Minimum Risk Maneuver) is triggered, including safe side parking.

[0200] Diagnostic records: Detailed diagnostic trouble codes (DTCs) are recorded through the AUTOSAR Diagnostic Event Manager (DEM), including freeze frame data (FreezeFrame), timestamp, fault location, and GNN prediction snapshot, supporting subsequent remote diagnosis and repair.

[0201] Security Auditing: Reports potentially security-related memory anomalies to an HSM or secure log server.

[0202] Providing memory safety assurance capabilities that surpass traditional methods, it helps meet the stringent ISO 26262 ASI L requirements for memory and other hardware elements, and provides a traceable chain of evidence. GNN predictions proactively identify areas of memory aging or potential failure, supporting predictive maintenance and reducing unplanned downtime. Proactive, hierarchical protection measures improve system robustness and availability in the face of memory interference or failures. The deep insights provided by XAI significantly shorten the root cause analysis time for complex memory issues. RL-driven adaptive monitoring ensures safety objectives are met. Specific embodiment three:

[0204] include Figure 1-3 As shown, based on the technical solution of the specific embodiment 1, further application cases are given including the following:

[0205] The Central Computing Platform (CCP) in modern vehicle E / E architectures is typically based on a high-performance SoC, running a complex operating system (including Linux or QNX with an AUTOSAR layer or hypervisor), and is responsible for coordinating the vehicle-wide OTA update process. The OTA process involves securely downloading large update packages (hundreds of MB to several GB) from the cloud, decrypting and decompressing them within the CCP's memory, and integrity-verifying them. The verified images are then distributed and burned into the non-volatile memory (including eMMC / UFS Flash) of target ECUs (including the CCP itself and other domain controllers). This process is highly concurrent, memory-intensive, and long-lasting, presenting a critical target window for cyberattacks. Memory challenges include: data corruption during the download / decompression process (caused by network jitter, transient hardware errors, or resource exhaustion); malicious tampering with update packages or memory contents (injecting backdoors or modifying configurations); ensuring the memory stability of key background services (including security gateways and diagnostic services) during the update process; and ensuring the atomicity of update operations to prevent update interruptions or "bricking" of target ECUs due to memory errors.

[0206] S1. Memory graph for OTA: Nodes specifically focus on memory areas related to the OTA process: network protocol stack buffers, TLS / SSL decryption workspaces, downloaded file buffers, decompression algorithm (including zlib and lz4) working memory pools, signature verification module memory, temporary storage for images to be flashed, Flash driver memory, and the memory space for core CCP services that maintain basic vehicle operations (including diagnostic stacks DEM / DCM, SOME / IP communication stacks, and security monitoring services). Edges represent data flows (download -> decryption -> decompression -> verification -> distribution / flashing), process dependencies, and potential shared library or kernel service calls.

[0207] Security and Functional Baseline: Beyond hardware BIST, establishing a security baseline is crucial. A secure boot chain provided by an HSM (Hardware Security Module) / TPM (Trusted Platform Module) ensures a trusted CCP boot environment. A trusted hash baseline is calculated for the OTAAgent code itself, security libraries (including cryptographic libraries), and key OS components. The update package itself includes a digital signature and manifest file, serving as an external verification baseline.

[0208] OTA-specific feature vector: Node features include: area usage (including DownloadBuffer and DecompressionWorkArea), security attributes (whether sensitive keys are stored, whether it is an executable code area), resource consumption indicators (current / peak memory usage, page error rate), associated OTA phase, and historical OTA success / failure records (related to this area).

[0209] S2. Stage-aware RL strategy: The state space of the RL agent explicitly contains the precise stage of the current OTA (Downloading, VerifyingSignature, Decompressing, ValidatingImage, FlashingTargetECU, Finalizing).

[0210] Security situational awareness: State inputs are integrated from intrusion detection systems (IDS, monitoring network traffic and system calls), abnormal events reported by HSMs (including key access violations), and memory patterns predicted by GNNs that indicate potential attacks (including abnormal memory allocation / release patterns, code segments being written).

[0211] Security-reinforcement actions: RL's action space includes not only adjusting the verification algorithm / frequency / range, but also: dynamically adjusting the access control policy of the memory area (through MPU / MMU or SELinux / SMACK); triggering memory snapshots and analysis of specific suspicious processes; requesting HSM to provide additional hardware-level protection for key operations (including signature verification and Flash writing); and prioritizing the memory integrity of core services rather than OTA processes when high risks are detected.

[0212] Reliability and security-first rewards: The reward function is designed to prioritize maximizing the atomic success rate (no interruption, no corruption) and security (no known vulnerability exploits, no unauthorized modifications) of OTA updates, followed by update efficiency (time) and resource consumption. Heavy penalties are imposed on any memory events that lead to security baseline violations or update failures.

[0213] S3, multi-anchor verification:

[0214] Downloading: Perform streaming hash check on data blocks and compare them with the checksum provided by the download source to quickly detect transmission errors.

[0215] After decryption / decompression: Strict integrity and signature verification is performed using the trusted public key stored in the HSM.

[0216] Before flashing: Perform a full strong hash check on the final image segment to be written to Flash as the last line of defense.

[0217] Runtime: Perform periodic or event-triggered (including before and after system calls) differential verification and key invariant checks on the CCP's own OS, OTAAgent, and core service memory.

[0218] Security semantic verification: Checks the consistency of the update package manifest, the satisfaction of version dependencies, and the target ECU compatibility declaration. Scans the decompressed code / configuration for known malware signatures or dangerous function call patterns. Checks whether key security parameters in memory (including encryption keys and access control lists) have been modified abnormally.

[0219] S4. Behavioral Pattern Analysis: GNNs not only predict hardware failures but also focus on learning and detecting memory behavior patterns that indicate potential attacks. These include: identifying unusual memory allocation sequences associated with stack / heap overflow attacks; detecting common memory layout features in return-oriented programming (ROP) or jump-oriented programming (JOP) attacks; and discovering unusual modifications to memory execution permissions after code injection.

[0220] Attack stage prediction: Based on memory access patterns and verification result sequences, predict the stage of the attack (including "shellcode has been successfully injected, the next step is to attempt privilege escalation").

[0221] XAI explains the attack path: explaining why an attack is believed to exist, including: "Continuous overwrite operations on the network receive buffer were detected, which are consistent with the initial stage characteristics of a typical buffer overflow attack, and are followed by abnormal read attempts on specific system library function addresses."

[0222] S5. Multi-source intelligence fusion: Combine internal monitoring (verification results, GNN predictions), external threat intelligence (known CVE vulnerabilities, attack signature libraries), and HSM security incident reports, and use Bayesian networks or similar frameworks (including DS evidence theory based on evidence theory) for fusion.

[0223] Dynamic risk assessment: Dynamically assesses the overall security risk of the current OTA session, distinguishing between random hardware failures, benign software errors, and high-confidence malicious attacks.

[0224] Decision support: Provides clear risk levels (including "low risk / normal", "medium risk / suspicious activity", and "high risk / confirmed attack") and recommended response measures.

[0225] S6. Security event-driven feedback: Detected security events and their response results are prioritized to update RL strategies and feature libraries to ensure that the system can quickly learn and adapt to new attack methods.

[0226] Defense-in-depth response:

[0227] Suspicious activity: Increase monitoring frequency, enable more detailed logging, and apply resource limits or sandboxing to suspicious processes.

[0228] Confirmed attack / critical check failure: Immediately abort the OTA; isolate the affected areas and processes; clear all OTA-related temporary data; utilize HSM to record non-repudiation security event logs; report alarms to the Vehicle Security Operations Center (VSOC); execute predefined security rollback procedures (including attempting to restore to a previously trusted state if the update has been partially written, which requires special Flash partitioning strategy support).

[0229] Memory resource warning: When GNN predicts insufficient or fragmented memory, it proactively triggers memory cleanup (Garbage Collection, if applicable), adjusts the memory application strategy of the OTA process, or suspends non-critical background services.

[0230] Post-update verification: Use memory graphs and baselines to verify whether the memory layout of key components after the new system is started is as expected and whether there is any abnormal memory usage.

[0231] It greatly improves the resilience of the OTA process against memory errors (hardware, software, and security), significantly reduces the update failure rate and the risk of "bricking", and provides powerful memory-level security monitoring and protection capabilities for OTA, a key exposure surface. It effectively resists attacks on memory and meets the security requirements of the Internet of Vehicles safety regulations (including UNR155 / R156) for the software update process. It provides auditable evidence and balances security requirements with OTA execution efficiency (update duration) and resource consumption through intelligent scheduling of monitoring tasks. Combined with GNN interpretation and detailed logs, it can accurately distinguish whether OTA failures are caused by network problems, software package damage, memory hardware failures, or security attacks.

[0232] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprise," "include," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device that includes a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a reference structure" does not preclude the presence of additional identical elements in the process, method, article, or device that includes the element.

[0233] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to these embodiments without departing from the principles and spirit of the invention, and that the scope of the invention is defined by the appended claims and their equivalents.< / detectedobject>

Claims

1. A vehicle controller memory monitoring method based on differential redundancy, characterized by: The following steps are involved: S1. Multidimensional Memory State Space Construction and Initialization: Build a graph representation of the target memory region, where nodes represent memory cells or blocks, and edges represent their logical or physical adjacencies or historical access associations. Use hardware self-test and baseline verification to obtain initial node state attributes, and build a multidimensional fault signature dictionary containing node historical states, error patterns, access statistics, and associated context information. S2. Adaptive Monitoring Strategy Optimization Based on Reinforcement Learning: Utilizes a reinforcement learning agent to continuously optimize the monitoring strategy; the state space of the RL agent includes at least the characteristics of the current memory graph nodes, historical monitoring statistics, the risk distribution of the neural network prediction output, the controller's real-time resource load, the vehicle's operating conditions, the associated bus error frame rate, and the safety module's alarm status; the action space of the RL agent includes at least selecting the verification level, adjusting the verification frequency of each level, determining the verification algorithm, and selecting the nodes or subgraphs to be monitored; the RL agent learns and makes decisions based on maximizing a predefined reward function, and outputs the current optimal monitoring strategy instructions; S3. Context-aware dynamic layering and differential verification: Based on the monitoring policy instructions output by the RL agent, perform multi-level, context-aware differential redundancy verification; the layers include at least: Basic physical layer check: fast integrity check of memory bits or physical blocks; Data semantic layer validation: Customized validation rules or invariance checks are used for specific data types; Dynamic association layer verification: performs consistency verification on dynamic memory areas formed according to access patterns or logical associations. The differential redundancy check compares the currently calculated verification fingerprint with the historical benchmark or image, and generates a basic verification report for this cycle that includes the verification results, error location, and error type. S4. Deep Fault Prediction and Interpretation Based on Graph Neural Networks: The memory graph structure representation, node features, and related contextual information are input into a pre-trained or online updated graph neural network or a Transformer model with an attention mechanism. The model outputs a high-resolution memory node-level fault probability prediction map and uses explainable AI technology to provide prediction evidence or a visual explanation of potential fault propagation paths. S5. Intelligent arbitration and decision-making based on Bayesian fusion or fuzzy logic: Using a Bayesian network or fuzzy logic reasoning system, the basic verification report for this period is integrated with the predicted probability map of the GNN / Transformer model. This system comprehensively assesses the immediate and future risks of each memory node and generates a refined memory health status assessment including confidence intervals. S6. Closed-loop feedback and active protection instruction generation: The refined memory health status assessment, prediction basis explanation, and arbitration confidence are fed back to the RL agent as the state input for the next decision cycle, and the multi-dimensional fault feature dictionary is updated; based on the assessment results, if a fault is detected or predicted with a high probability, corresponding active protection or corrective action instructions are generated and triggered, and the instructions include but are not limited to: triggering predictive error correction code, initiating memory area refresh or online repair, performing data migration and fault area isolation, adjusting related software task scheduling, triggering the system to enter a safe degradation mode, recording detailed diagnostic information and associating cross-domain context for root cause analysis, or issuing a memory anomaly alert to the security monitoring system.

2. The vehicle controller memory monitoring method based on differential redundancy according to claim 1, characterized in that: In step S1, the edge weights of the memory graph structure are dynamically updated according to memory access frequency, logical dependency or historical error correlation.

3. The vehicle controller memory monitoring method based on differential redundancy according to claim 1, characterized in that: In step S2, the RL agent uses a deep Q-network (DQN), Actor-Critic or its variants for training and decision-making.

4. The vehicle controller memory monitoring method based on differential redundancy according to claim 1, characterized in that: In step S3, the data semantic layer verification utilizes predefined invariants about specific data structures to perform checks, or performs range and logical consistency checks on key variables related to functional safety.

5. The vehicle controller memory monitoring method based on differential redundancy according to claim 1, characterized in that: In step S4, the GNN model adopts a graph convolutional network (GCN), GraphSAGE or gated graph neural network (GatedGNN) architecture to effectively capture the spatial dependency and propagation characteristics of memory faults.

6. The vehicle controller memory monitoring method based on differential redundancy according to claim 1, characterized in that: In step S4, the XAI technology includes using attention weights, gradient information or proxy models (such as LIME, SHAP) to identify memory nodes, features or historical events that contribute most to fault prediction.

7. The vehicle controller memory monitoring method based on differential redundancy according to claim 1, characterized in that: In step S5, Bayesian fusion dynamically adjusts the weight of evidence based on the reliability of the basic verification results (related to the verification algorithm and hierarchy) and the confidence of the GNN prediction.

8. The vehicle controller memory monitoring method based on differential redundancy according to claim 1 is characterized in that: The vehicle controller memory monitoring method also includes: using the GNN / Transformer model to analyze memory access sequences or verify fingerprint change patterns to detect potential security intrusion activities that match known attack signatures or abnormal behavior patterns.

9. The vehicle controller memory monitoring method based on differential redundancy according to claim 1, characterized in that: The vehicle controller memory monitoring method also includes: through a federated learning mechanism, using monitoring data and model updates from multiple vehicles while protecting user privacy, continuously optimizing the RL agent strategy and GNN / Transformer prediction model.

10. A vehicle controller memory monitoring method based on differential redundancy according to any one of claims 1 to 9, characterized in that: The hardware includes a vehicle controller memory monitoring method, and the hardware is used to execute various functional units, including: a memory graph construction and feature management unit, a reinforcement learning strategy optimization unit, a context-aware verification execution unit, a graph neural network prediction and interpretation unit, an intelligent arbitration decision unit, and an active protection instruction generation unit. The hardware also includes a processor and memory.

Images