A method, system and medium for computing domain elasticity reconfiguration and security degradation control

Abstract

This invention relates to the field of intelligent driving control technology, specifically to a method, system, and medium for flexible reconfiguration and safety degradation control of computing domains. The system includes an arbitration control unit and multiple heterogeneous computing domains. When any computing domain malfunctions, the arbitration unit performs the following: multi-dimensional spatiotemporal fault detection and localization; three-layer isolation of the malfunctioning domain to block the propagation of abnormal information; dynamic calculation of multi-dimensional resource matching scores for task reconfiguration decisions; if computing power is insufficient, a safety level degradation and reconfiguration process is triggered by unloading low-safety-level tasks and switching core tasks to pre-stored simplified algorithms to release resources; finally, a minimum-risk strategy is executed and the recovery of the faulty domain is monitored to achieve reverse migration. This invention achieves millisecond-level flexible reconfiguration and safety degradation in the event of computing domain failure without increasing hardware costs, maximizing the preservation of core safety functions and significantly improving the reliability and robustness of the autonomous driving system.

Description

Technical Field

[0001] This invention relates to the field of intelligent driving control technology, and in particular to a computational domain elastic reconfiguration and safety degradation control method, system and medium. Background Technology

[0002] Autonomous driving systems typically employ a centralized or functionally domain-centric computing architecture. The system contains multiple heterogeneous computing units, each undertaking different autonomous driving tasks and communicating via a high-speed bus. When a severe anomaly occurs in a computing domain (such as overheating and crashing, or hardware lockup), the traditional approach is to degrade the entire system and exit, for example, triggering a minimum risk strategy (MRM) such as emergency braking. However, in high-speed or complex traffic flow scenarios, this can easily lead to rear-end collisions, and even if the minimum risk strategy is triggered, safety cannot be guaranteed.

[0003] The fault domain is marked at the software level, and then repeated application reset → operating system reset → controller reset are performed to achieve restart and normal operation. However, when dealing with failures in the computing domain itself (hardware or system level), the recovery mechanism will completely fail because the faulty unit can no longer function properly, and the system still faces the risk of functional interruption. Furthermore, the fault domain may continue to output abnormal data to the bus (Byzantine Generals Problem) due to ineffective physical / logical isolation, affecting system stability.

[0004] To address this type of failure, existing technologies have proposed several solutions, including: One approach is to use full hardware redundancy, which means setting up a 1:1 hot backup computing unit for critical computing domains (such as sensing and planning domains). When the primary domain fails, the system instantly switches to the backup domain.

[0005] For example, application number 202111444633.8, entitled "A Degradation Control Method and System for an Autonomous Driving Controller," discloses a scheme using 1:1 redundancy switching: switching to the safe path domain when the high-performance domain fails, switching to the second safe domain when the first safe domain fails, etc., which is a typical example of "static redundancy" or "master-slave switching." Application number 202210277998.4, entitled "An Autonomous Driving Vehicle Control System and Method," describes a system redundancy architecture of A / B units, networks, and actuators, achieving three-way selector control, which is a static redundancy backup at the hardware / network level.

[0006] Adopting a primary-backup or primary-backup-remaining system redundancy architecture requires almost doubling the hardware cost and has extremely low resource utilization; the fault detection and switching time is long, and it is prone to creating control blind spots in high-speed scenarios, posing safety hazards.

[0007] Another type of solution is dynamic resource scheduling based on virtualization or container technology. For example, application number CN201810414692.2, entitled "A Method for Managing In-Vehicle Computing Units Using Container Technology," discloses a technical solution for dynamically allocating resources within a computing unit and restarting or migrating applications when an anomaly is detected. This type of solution mainly focuses on dynamic resource allocation and container isolation, with "prevention" and "management" as its core principles. It solves the problems of resource contention and software-level failures within the same computing unit, but it is problematic when the hardware of the entire computing domain fails completely, and the underlying hardware and operating system on which it depends become unavailable, making effective task takeover difficult.

[0008] Another type of solution is based on active or passive migration of tasks based on task status monitoring. For example, Chinese patent application number 202510885040.7, entitled "Unified Resource Pooling Management Method for Multiple Computing Sources of UAV Platform", discloses a method to predict failures by monitoring the temperature and error rate of computing units, calculating health scores, parsing task graphs, actively creating task checkpoints, and migrating tasks to backup units.

[0009] To address the problems in existing technologies, this invention provides a method, system, and medium for flexible reconfiguration and security degradation control of computing domains. Summary of the Invention

[0010] The purpose of this invention is to provide a method, system, and medium for elastic reconfiguration and security degradation control of the computing domain, in order to solve the technical problem of how to address the functional interruption and security risks caused by sudden computing domain failures in high real-time autonomous driving systems without increasing additional hardware costs.

[0011] The technical solution of this invention is: a method for elastic reconfiguration and security degradation control of a computing domain, comprising: The operating status of the computing domain is monitored, and computing domains that exhibit abnormalities are defined as fault domains, while computing domains that operate normally are defined as normal domains. In response to the detected abnormal domain, the abnormal domain is isolated, and the resource requirements of the tasks to be migrated originally undertaken by the abnormal domain and the available resources of all normal domains are obtained; the resource matching score of each normal domain to the task to be migrated is calculated. If there is no normal domain with a resource matching score higher than the preset threshold, or if any normal domain cannot independently undertake the migration task under the constraints of computing power, memory bandwidth and end-to-end communication latency, then a downgrade and reorganization process based on security level will be triggered. The downgrade and reorganization process includes: According to the preset task priority list, at least one low-priority task is determined from the normal domain that meets the preset vehicle safety integrity level requirements and forcibly terminated to release resources. The normal domain after resource release is defined as the dimensionality reduction domain. The simplified algorithm package pre-stored in the normal domain that meets the preset vehicle safety integrity level requirements is called to switch the task to be migrated to the corresponding simplified algorithm task and migrate it to the dimensionality reduction domain for execution.

[0012] Preferably, in response to a detected anomalous domain, the anomalous domain is isolated, including: Network layer blocking, update routing policy at vehicle gateway, and discard all data packets with source addresses in the fault domain; The physical layer goes into hibernation. If the fault domain is determined to be overheating or hardware locked, the power supply to the fault domain is cut off or restarted through the power management chip. After the logic layer is stripped and the data output of the abnormal domain is blocked, a safety threshold or empty data frame is simulated and generated based on the task relationship between the fault domain and other computing domains. The safety threshold or empty data frame is then sent to other normal domains that have a task relationship with the abnormal domain, instructing the other normal domains to stop waiting for and receiving signals from the fault domain.

[0013] Preferably, a resource matching score for each normal domain to the task to be migrated is calculated, the content of which is: Obtain the set of tasks to be migrated that the fault domain originally handled. The current set of available resources in all normal domains is ; Compute any task to be migrated , In each normal candidate domain , Resource matching score The calculation model is as follows: ; in, The available computing power for the normal computation domain x, The required computing power for the task j to be migrated; The available memory bandwidth for the normal computation domain x. The required memory bandwidth for the task j to be migrated; To migrate task j to normal domain x, the additional end-to-end communication latency increment is dynamically calculated based on the preset task dependency graph and the physical topology latency between domains. The expected average latency for the tasks to be migrated; These are preset weighting coefficients.

[0014] Preferably, it also includes a dynamic recovery step: The abnormal domain is continuously monitored; if the abnormal domain returns to normal and its output is consistent with the output of the dimensionality reduction domain currently executing the corresponding task in cross-validation over multiple consecutive periods, then the unexecuted migration task is reverse-migrated from the dimensionality reduction domain to the normal abnormal domain according to the preset recovery strategy.

[0015] Preferably, the preset recovery strategy is divided into three strategy modes based on task type, security level, and current running stage: Immediate full migration: The migration task is a safe task and the current vehicle speed is below 20km / h; pause the execution of the migration task in the dimensionality reduction domain, package the migration task and task status completely, migrate to the abnormal domain that has returned to normal, and the abnormal domain that has returned to normal continues execution from the latest checkpoint; Progressive migration: If the migration task is a real-time task, then migrate a portion of the data in the future prediction window, restore the normal outlier domain and the dimensionality reduction domain to run in parallel for at least one cycle, and complete the full switch after the normal outlier domain has stabilized. New task switching: If the task being migrated is a task that has already been calculated or is about to end, then the current task is completed in the reduced-dimensional domain, and the next task triggered by the new task is directly migrated to the restored abnormal domain to take over the execution.

[0016] Preferably, a simplified algorithm package is pre-stored in at least one computational domain that meets the preset vehicle safety integrity level requirements; when the dimensionality reduction and reorganization process is triggered, the simplified algorithm package is called to switch the task to be migrated to the simplified algorithm task corresponding to the function, and migrate it to the dimensionality reduction domain for execution; The simplified algorithm package includes, but is not limited to: a deterministic backup perception algorithm based on millimeter-wave radar or ultrasonic radar, and a safe following planning algorithm based on lane keeping. The preset simplified algorithm package is pre-stored in a non-volatile memory in the normal domain that meets the preset vehicle safety integrity level requirements, and has undergone functional safety verification. The functional safety verification includes: requirements verification, hardware-in-the-loop testing, deterministic output verification, and static code and data verification. The requirement verification is used to confirm that the simplified algorithm can achieve its stated security objectives under the expected degraded operating environment; Hardware-in-the-loop testing involves injecting corresponding fault conditions into a simulated real vehicle operating scenario to verify that the control commands output by the simplified algorithm are within the physical boundaries and will not lead to dangerous events. For deterministic output verification, for the same set of input data, the simplified algorithm should output the same result in multiple consecutive executions, and the execution time jitter should be less than the preset safety threshold. Static code and data verification perform memory usage analysis, worst-case execution time analysis, and data consistency verification on the simplified algorithm package, and generate an immutable signature stored in a secure storage area.

[0017] Preferably, the low-priority tasks are determined according to a preset task priority list, and the priority list is sorted based on at least the vehicle safety integrity level and the functional type of the task. Construct a task priority list. In the task priority list, the priority ordering principle for function type is: safety-related tasks take precedence over efficiency-related tasks, which in turn take precedence over comfort-related tasks. The priority ordering principle for vehicle safety integrity level is: the higher the level, the higher the priority.

[0018] Preferably, the operational status of multiple computing domains is monitored in the following way: Monitor the operational status feature vectors of each computing domain, including end-to-end task latency, processor utilization, storage fragmentation rate, chip junction temperature, and heartbeat message sequence number continuity. If any parameter exceeds a preset safety threshold for N consecutive computing cycles, an anomaly flag is triggered.

[0019] A computing domain resilient reconfiguration and security degradation control system is provided to implement the aforementioned computing domain resilient reconfiguration and security degradation control method, comprising multiple heterogeneous computing domains and an independent arbitration control unit; The plurality of heterogeneous computing domains include at least a first computing domain, a second computing domain, and a third computing domain. The first computing domain is responsible for environmental perception tasks, the second computing domain is responsible for path planning and decision-making tasks, and the third computing domain is responsible for chassis execution and safety redundancy tasks. The third computing domain is configured as a security-level microcontroller, which has a non-volatile memory inside, and the non-volatile memory pre-stores a verified simplified algorithm package. The arbitration control unit is configured as an independent hardware node based on FPGA or security microcontroller. The arbitration control unit communicates with the multiple heterogeneous computing domains through the vehicle network to perform millisecond-level status monitoring, decision arbitration and resource scheduling.

[0020] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned method for resilient reconfiguration and security degradation control of a computing domain.

[0021] Compared with the prior art, the advantages of the present invention are: This invention includes an arbitration control unit and multiple heterogeneous computing domains. When any computing domain fails, the arbitration unit performs the following: multi-dimensional spatiotemporal fault detection and localization; multi-level isolation of the failed domain at the network, logic, and physical layers, and simulates sending security thresholds; dynamically calculates multi-dimensional resource matching scores and makes task reconstruction decisions; if computing power is insufficient, it triggers fine-grained security degradation based on the vehicle's safety integrity level and function type, releasing resources by unloading low-security-level tasks and switching core tasks to pre-stored simplified algorithms; finally, it executes a minimum-risk strategy and monitors the recovery of the failed domain to achieve reverse migration.

[0022] When a hardware or system-level failure occurs in any computing domain, it enables rapid and accurate identification and isolates the abnormal domain at three levels to prevent the spread of "dirty data" that contaminates the control bus.

[0023] When global computing power is insufficient, a fine-grained security degradation mechanism based on ASIL and task type is introduced to maximize the preservation of the vehicle's core safe driving capabilities. Based on multi-dimensional resource matching degree and security level, the remaining computing power of each healthy computing domain is evaluated, and tasks in abnormal domains are migrated to normal domains. Computing power pooling and task drifting are performed to achieve dynamic reconstruction of task allocation.

[0024] Without increasing hardware costs, a complete closed-loop control system of fault detection, isolation, reconstruction, degradation and recovery was constructed, realizing millisecond-level elastic reconstruction and safe degradation when the computing domain fails. This maximizes the preservation of core safety functions, maintains the vehicle's continuous and safe operation in fault conditions, and does not require additional full redundancy hardware costs, significantly improving the reliability and robustness of the autonomous driving system. Attached Figure Description

[0025] The present invention will be further described below with reference to the accompanying drawings and embodiments: Figure 1 A flowchart illustrating the computational domain elastic reconstruction and security degradation control method provided in an embodiment of the present invention; Figure 2 A schematic diagram of the hardware topology architecture of the computational domain elastic reconfiguration and security degradation control system provided in an embodiment of the present invention; Figure 3 This is a logical tree diagram of task degradation and reorganization based on resource matching degree and security level provided for embodiments of the present invention. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It is to be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it.

[0027] like Figure 1 As shown, a method for flexible reconfiguration and security degradation control of computing domains is proposed. This method operates in a distributed control system that includes multiple heterogeneous computing domains and an independent arbitration control unit.

[0028] Specifically, refer to Figure 2 As shown, this embodiment of the invention provides a computing domain resilient reconfiguration and safety degradation control system. The system operates in an in-vehicle distributed communication network (such as an in-vehicle Ethernet / CAN FD hybrid network) and is used to implement a computing domain resilient reconfiguration and safety degradation control method. The system includes at least multiple heterogeneous computing domains and an independent arbitration control unit.

[0029] The multiple heterogeneous computing domains include at least a first computing domain, a second computing domain, and a third computing domain. The first computing domain is configured as a high-performance perception domain, responsible for environmental perception tasks; the second computing domain is configured as a planning and decision-making domain, responsible for path planning and behavioral decisions; and the third computing domain is configured as a chassis safety domain, responsible for chassis execution and safety redundancy tasks. The third computing domain is configured with a high functional safety level microcontroller, such as an ASIL-D microcontroller, which has internal non-volatile memory. The non-volatile memory pre-stores a safety-verified backup algorithm library, i.e., a simplified algorithm package, such as a lightweight millimeter-wave radar perception algorithm and a lane-keeping algorithm.

[0030] The arbitration control unit is a lightweight, highly reliable node independent of multiple heterogeneous computing domains. For example, the arbitration control unit is set as an independent hardware node based on FPGA or security microcontroller. The arbitration control unit communicates with multiple heterogeneous computing domains through the vehicle network to perform global millisecond-level status monitoring, decision arbitration and resource scheduling.

[0031] This invention provides a control method that, without interrupting system operation or relying on additional hardware redundancy, dynamically reconfigures computing tasks and reorganizes security function permissions by real-time assessment of global remaining computing power, thereby improving the reliability and safety of autonomous driving systems. Specifically, this method is executed through an arbitration control unit and includes the following steps: Step 1: Multidimensional spatiotemporal fault detection and localization.

[0032] The computing domain that experiences an anomaly is defined as the fault domain, and the computing domain that operates normally is defined as the normal domain.

[0033] The arbitration control unit acquires the operating status feature vectors of each computing domain at a preset period (e.g., 10ms). This enables the monitoring of the operational status of the computing domain.

[0034] in: End-to-end delay for the task; Processor utilization rate; Storage fragmentation rate; This refers to the chip junction temperature. For the continuity of heartbeat message sequence numbers. When any parameter is continuous... If a calculation cycle exceeds a preset safety threshold, an anomaly flag is triggered, and the anomaly domain is precisely located.

[0035] Step 2: Force isolation of the abnormal domain to prevent the spread of the abnormal impact.

[0036] Once an anomaly is confirmed in a certain computing domain (designated as fault domain A), immediate three-level isolation is implemented, including: Network layer blocking: Update the routing policy at the vehicle gateway to discard all packets with source address in fault domain A to prevent Byzantine error data from entering the control bus.

[0037] Logical layer stripping: After blocking the data output of the faulty domain, based on the task relationship between the faulty domain and other computing domains, a "domain A failed" frame is broadcast globally, instructing other normal domains to stop waiting for signals from the faulty domain A and update their own task relationship tables; at the same time, the arbitration unit simulates and generates a "safety threshold" or "empty data frame" (for example, for control modules that rely on perception results, simulate sending a default message "no effective obstacle ahead") according to the preset task relationship, and sends it to other computing domains that are coupled with the faulty domain A in terms of task relationship, to prevent other computing domains from falling into an error state due to timeout waiting.

[0038] Physical layer hibernation: If overheating or severe hardware lock-up is detected, the power supply to fault domain A is cut off or restarted through the power management chip to achieve physical isolation.

[0039] In distributed systems, "isolation of faulty nodes" is a common and universal principle. The isolation measure is to directly remove the faulty node from the network. In traditional distributed systems, isolation and task recovery are usually separate processes.

[0040] In automotive Ethernet / CAN FD hybrid networks, simply marking faults at the application layer is insufficient to prevent hardware-level abnormal output from fault domains. This invention addresses automotive real-time control systems by decomposing isolation into three independent and progressive layers: the network layer discards fault domain source address data packets at the gateway; the logic layer broadcasts failure frames to cause other domains to stop waiting for synchronization signals; and the physical layer cuts off power supply via a power management chip when necessary. These three layers respectively address software-level faults, communication-level faults, and hardware-level faults (such as overheating lockout), ensuring effective blocking of abnormal data under any fault mode.

[0041] The isolation operation and task refactoring are designed as a tightly coupled, millisecond-level pipeline. Resource matching calculation and task migration begin immediately upon isolation completion, rather than waiting for the fault domain to self-recover and time out before making a decision. This improves response speed and ensures safety.

[0042] Step 3: Dynamic task reconfiguration decision based on task relationships and resource matching degree.

[0043] Obtain the set of tasks to be migrated that were originally handled by fault domain A. And the set of available resources in the remaining normal domains of the current system. .

[0044] First, construct or query a pre-defined task dependency graph to clarify the data flow direction, communication frequency, and maximum allowable latency for each task.

[0045] For any task to be migrated , The arbitration control unit calculates its value in each normal candidate domain. , Resource matching score This scoring model is specifically designed for the real-time performance and safety constraints of autonomous driving, and it integrates factors such as computing power, memory resources, and communication latency. The calculation model is as follows: ; in: Represents computing power resources (TOPS / DMIPS), This represents memory bandwidth resources.

[0046] The available computing power for the normal computation domain x, The required computing power for the task j to be migrated; The available memory bandwidth for the normal computation domain x. The required memory bandwidth for the task j to be migrated; The expected average latency for the tasks to be migrated; For preset weighting coefficients, Set higher for high real-time tasks (such as control command generation).

[0047] To migrate task j to the normal domain x, the additional end-to-end communication latency increment is dynamically calculated based on a preset task dependency graph and inter-domain physical topology latency. In other words, This represents the additional end-to-end latency incurred when migrating task j to the normal domain x due to the change in communication paths between task j and its upstream and downstream tasks (which may be distributed in other domains). This value is dynamically calculated based on the task dependency graph and the physical topology latency between domains. For example, if a control task needs to receive sensing results at a high frequency, migrating it to a computational domain physically far from the sensing domain... A higher value will lower the score for that target domain.

[0048] Allocation Rule 1 (Complete Reconstruction): Select the normal domain with a resource matching score > preset threshold, and the normal domain with the highest score (candidate domain) as the target receiving domain, and migrate the task to be migrated completely.

[0049] Allocation Rule 2 (Computing Power Rush): If all candidate domains If the remaining computing power of the system is insufficient to support the original task, then step S4 is triggered.

[0050] The task refactoring process is based on multi-dimensional resource matching evaluation and threshold calculation, with transparent and deterministic logic (white box), avoiding the problems of uncontrollable response and computing power black hole caused by using complex AI models.

[0051] Step 4: Function downgrade and permission reorganization based on Security Level Indicator (ASIL).

[0052] Reference Figure 3 When a computing power drain is triggered, the system enters a refined degradation mode and remaps tasks according to the following rules: Task Attribute Extraction: Extract the identification attributes of all running tasks, including tasks to be migrated and existing tasks in the normal domain. Task identification attributes include: Automotive Safety Integrity Level (ASIL AD) and Functional Type (Safety / Efficiency / Comfort).

[0053] Non-core task circuit breaking: Dynamically select and forcibly terminate low-priority tasks from the normal computing domain, such as ASILA-level cockpit multimedia rendering and predictive overtaking calculations, to free up computing resources. Definition: The normal domain that releases resources is called the reduced-dimensional domain.

[0054] Low-priority tasks are determined based on a pre-defined task priority list. The priority list is sorted according to at least the vehicle safety integrity level and the task's functional type. A task priority list is constructed where functional types are prioritized in the order of "Safety > Efficiency > Comfort," and vehicle safety integrity levels are prioritized in the order of "ASIL-D > ASIL-C > ASIL-B > ASIL-A > ASIL-QM."

[0055] Task frequency reduction and dimensionality reduction: High-safety-level tasks to be migrated, such as ASIL-D level AEB automatic emergency braking and LKA lane keeping, are switched to a preset simplified algorithm package.

[0056] A simplified algorithm package is pre-stored in at least one computational domain that meets the preset vehicle safety integrity level requirements. The preset simplified algorithm package is pre-stored in the non-volatile memory of the normal domain (e.g., the third computational domain) that meets the preset vehicle safety integrity level requirements and has been functionally safety verified.

[0057] The simplified algorithm package requires less computational resources than the task to be migrated. The simplified algorithm package includes, but is not limited to: deterministic backup perception algorithms based on millimeter-wave or ultrasonic radar, and safe following-planning algorithms based on lane keeping. Dimensionality reduction lowers the computational requirements of the task. sudden drop .

[0058] In detail, for example, the perception task is reduced from "large-scale fusion perception of vision + LiDAR" to "pure millimeter-wave radar 2D target detection and tracking". The planning task is reduced from "complex game-theoretic decision-making planning" to "safe following planning based on lane keeping".

[0059] Task remapping: When the dimensionality reduction and reorganization process is triggered, the simplified algorithm package is called to switch the task to be migrated to the simplified algorithm task corresponding to the function, and then migrate it to the dimensionality reduction domain for execution.

[0060] In detail, the functional safety verification of the preset simplified algorithm package refers to the following verification operations performed according to the ISO 26262 standard on each simplified algorithm package stored in non-volatile memory of at least one computing domain (e.g., an ASIL-D level MCU or safety island chip) that meets the preset automotive safety integrity level requirements before it can be considered "verified" and allowed to be invoked in degraded scenarios. The verification operations include: Requirements validation: Confirm that the simplified algorithm can achieve its stated security objectives under the expected degraded operating environment (limited computing power, latency tolerance limit, and availability of a subset of sensors).

[0061] Hardware-in-the-loop (HIL) testing: In a simulated real vehicle operation scenario, corresponding fault conditions (such as main computing domain failure, computing power reduced to 30% of the original) are injected to verify that the control commands output by the simplified algorithm are within the physical boundaries and will not cause dangerous events.

[0062] Deterministic output verification: For the same set of input data, the simplified algorithm should output the same result at the same bit level in multiple consecutive executions, and the execution time jitter should be less than the preset safety threshold (e.g., ±5ms).

[0063] Static code and data verification: Perform memory usage analysis, worst-case execution time (WCET) analysis, and data consistency verification (CRC or hash) on the simplified algorithm package, and generate an immutable signature to be stored in a secure storage area.

[0064] For ease of understanding, this invention uses a "deterministic backup sensing algorithm based on millimeter-wave radar" as an example, and provides specific verification steps: Input constraint validation.

[0065] The algorithm was verified to rely solely on the target list of the millimeter-wave radar (including distance, relative speed, and angle) and the vehicle's motion state (vehicle speed and yaw rate), without relying on camera images or lidar point clouds.

[0066] Verification showed that the radar raw data frame rate remained stable above 20Hz and the data frame drop rate was less than 1% under all specified vehicle speed ranges (e.g., 0-80km / h) and environmental conditions (rain, fog, night).

[0067] Output correctness verification.

[0068] Construct a standard test dataset: containing 10,000 sets of real road data and their corresponding ground truth values ​​(provided by high-precision integrated navigation and manual annotation).

[0069] Run a simplified perception algorithm to output an obstacle presence indicator, the distance to the nearest obstacle, and the relative speed.

[0070] Permissible error range: Obstacle presence marker accuracy ≥ 99.5%; distance error ≤ 0.5m; relative speed error ≤ 0.5m / s.

[0071] Maximum output delay: The delay from radar data input to output usable by the planning module is ≤40ms.

[0072] Fault injection and robustness verification.

[0073] Simulate abnormal inputs such as missing radar data, data jumps, and a sudden increase in the number of invalid targets (e.g., 200 targets).

[0074] The verification algorithm automatically switches to the safe default output (e.g., output "no obstacles, conservative following distance 50m") within 500ms, and will not output erroneous data that would lead to dangerous control (e.g., sudden and large deceleration command).

[0075] Storage integrity verification.

[0076] For the algorithm binary file stored in non-volatile memory, the SHA-256 hash value is pre-computed using the Hardware Security Module (HSM).

[0077] Before each system power-on or each downgrade call, the arbitration control unit recalculates the hash and compares it with the pre-stored value. If they do not match, the simplified algorithm package is prohibited from being called and a serious fault is reported.

[0078] Recording and authenticating verification results.

[0079] All verification cases, test reports, and coverage analyses (such as statement coverage ≥95% and branch coverage ≥90%) are included in controlled documentation.

[0080] Only after being audited by a third-party functional safety certification body (such as TÜV SÜD or SGS) and obtaining an ASIL-B or higher level certification certificate can it be designated as a "verified simplified algorithm package".

[0081] Step 5: Chassis executes control strategy update and dynamic recovery.

[0082] Minimum Risk Mode (MRM) Execution: The arbitration control unit generates Minimum Risk Mode (MRM) instructions and sends them to the chassis actuators. These instructions include, but are not limited to: limiting the vehicle's maximum speed, for example, a speed limit of 60 km / h; increasing the following distance (Time Gap); and restricting or disabling automatic lane changing.

[0083] Continuously monitor fault domain A. If the heartbeat of fault domain A recovers after restarting, and its output is consistent with the output of the dimension reduction domain currently executing the corresponding task in multiple consecutive cycles, then execute the reverse task migration according to the preset recovery strategy to smoothly restore the system to full-function mode.

[0084] The arbitration control unit sets up a shared memory area to store the most recent N (e.g., N=20) period of input data snapshots and their corresponding timestamps in a circular queue.

[0085] The principle for determining the recovery of an abnormal domain through cross-validation is as follows: if the arbitration control unit receives three consecutive valid heartbeat packets from the abnormal domain through heartbeat monitoring and self-test status register, and the fault code reported by the domain is cleared and the self-test status is "healthy", then it is considered to have "recovered to normal".

[0086] The specific process of cross-validation is as follows: The same input data (such as the original camera image, radar point cloud, and combined navigation positioning result of the same frame) is sent simultaneously to the dimension reduction domain (i.e. the normal computing domain that is currently performing the corresponding task) and the recovery domain / original fault domain (which has now been restored to normal).

[0087] The preset number of consecutive verification cycles K is recommended to be in the range of 3-10. In this embodiment, K=5 is used.

[0088] Backward migration is only allowed if the cross-validation results of each round are "consistent" within 5 consecutive control cycles (each cycle is equal to the main cycle of autonomous driving, for example, 50ms).

[0089] Taking a single cycle as an example, the consistency judgment logic is as follows: For the nth verification cycle, the arbitration control unit performs the following comparison.

[0090] For perception tasks: extract the "obstacle list" (containing the ID, distance, speed, and angle of each obstacle) from the dimensionality reduction domain output and the same fields from the recovery domain output.

[0091] Matching rules: The Hungarian algorithm is used for ID association, and the matching threshold is that the Euclidean distance is ≤1.0m and the speed difference is ≤0.5m / s.

[0092] Consistency conditions: matching rate ≥ 95%; no new "serious false negatives" (i.e., the recovery domain detects obstacles less than 20m away from the vehicle but the dimension reduction domain does not detect them).

[0093] For the planning task: compare the sequence of planned trajectory points (30 points in the next 3 seconds) output by the dimensionality reduction domain with the trajectory points output by the recovery domain, and calculate the root mean square error (RMSE) of the point-by-point position deviation.

[0094] Consistency conditions: RMSE ≤ 0.2m; and the maximum curvature difference between the two trajectories ≤ 0.05m. -1 .

[0095] For control tasks: compare the output steering wheel angle with the desired acceleration / deceleration; Consistency conditions: angular deviation ≤ 2°, acceleration deviation ≤ 0.3 m / s² 2 .

[0096] Continuous periodic consistency records: The arbitration control unit maintains a Boolean array of length K. Each cycle is set to 1 or 0 according to the above conditions. Setting it to 1 indicates consistency, and setting it to 0 indicates inconsistency.

[0097] Only when right If all elements in the array are true (in Boolean semantics), then it is considered "cross-validation consistent across multiple consecutive periods".

[0098] The handling of cross-validation failures is as follows: if an inconsistency occurs in any validation cycle, the counter is reset and the accumulation of consecutive consistent cycles begins again.

[0099] If the number of consecutive verification failures exceeds the preset maximum number of retries (e.g., 10 times), the recovery domain is determined to be untrusted, reverse migration is prohibited, an alarm message is generated, and execution continues in the reduced-dimensional domain.

[0100] The preset recovery strategy follows the principle of "non-core tasks first, core tasks later." According to the preset recovery strategy, unexecuted migrated tasks are reverse-migrated from the reduced-dimensional domain back to the restored abnormal domain. Specifically, the preset recovery strategy is divided into three strategy modes based on task type, security level, and current operational stage, dynamically selected by the arbitration control unit. Immediate full migration: The migration task is a safe task and the current vehicle speed is below 20km / h; suspend the execution of the migrated task in the dimensionality reduction domain, package the migration task and task status completely and migrate it to the restored abnormal domain. The restored abnormal domain continues execution from the latest checkpoint.

[0101] Progressive migration: If the migration task is a real-time task (such as control or planning), then migrate a portion of the data in the future prediction window, restore the normal outlier domain and the dimensionality reduction domain in parallel for at least one cycle (e.g., three cycles in parallel), and complete the full switchover only after confirming that the restored normal outlier domain is running stably.

[0102] New task switching: If the task being migrated is a task that has already been calculated or is about to end, then the current task is completed in the reduced-dimensional domain, and the next task triggered by the new task is directly migrated to the restored abnormal domain to take over the execution.

[0103] Taking the gradual migration strategy as an example, the complete execution steps of its migration recovery strategy are explained as follows: Preparation Phase: The arbitration control unit sends a "Prepare to Take Over" command to the recovery domain, informing it of the task ID and resource requirements of the task to be migrated. The recovery domain reserves the corresponding computing resources (CPU time slice, memory) and enters hot backup mode.

[0104] Parallel operation phase: Set the number of parallel cycles P=3 (3 consecutive control cycles). Within each cycle: normal calculation and output in the dimensionality reduction domain. It is used for actual vehicle control to ensure safety; the recovery domain calculates the output based on the same input data. Arbitration control unit comparison and Perform the cross-validation operation described above; if cross-validation fails in any cycle, abort the backtracking and continue execution in the dimensionality reduction domain.

[0105] Switching Phase: After all three cycles pass verification, the arbitration control unit sends a "switch" command, which includes: switching the source of control from the reduced-dimensional domain to the recovery domain; the reduced-dimensional domain releasing the resources occupied by the task and entering a standby state. The switching employs seamless switching technology, for example, atomically modifying the task scheduling table at the boundary of a control cycle (e.g., the start of the next frame) to avoid data races.

[0106] Post-verification phase: During the first 10 cycles after the switch, continue to compare the output of the recovery domain with a lightweight shadow copy (the original dimension reduction domain). If an anomaly is found, immediately switch back to the dimension reduction domain.

[0107] Taking the immediate full migration strategy as an example, the specific details of state packaging and restoration are explained as follows: State package contents: For planning tasks, the sequence of planned but not yet executed trajectory points, target lane, and decision intent (e.g., lane change, parking). For perception tasks, the currently maintained obstacle tracking list (Kalman filter state matrix).

[0108] Packaging and Transmission: State data is encapsulated into a serialized byte stream using DDS (Data Distribution Service) or shared memory zero-copy technology.

[0109] The arbitration control unit assigns a unique migration ID to this migration and sets a timeout timer of 100ms.

[0110] Resume execution: Restore the domain deserialized state data, load it into its own memory space, and resume execution from the moment it was interrupted.

[0111] Anomaly handling for the recovery strategy: If the recovery domain fails again during migration, the migration is immediately stopped, the dimensionality reduction domain continues to execute, and an unrecoverable failure is reported. If cross-validation fails for 5 consecutive cycles after migration, a rollback operation is performed, the recovery strategy reverts to the dimensionality reduction domain, and the recovery domain is locked to prevent further rollback until maintenance.

[0112] The following specific embodiments further illustrate the method and system. The logical tree diagram of the task degradation and reorganization based on resource matching degree and security level implemented in this embodiment is shown in the appendix. Figure 3 .

[0113] Dynamic reconstruction process of perception domain (first computational domain) failure in high-speed navigation-assisted driving (NOA) scenario.

[0114] Initial state: The vehicle is traveling at 120 km / h on the highway with NOA (Noise, Arrival, and Assist) enabled. The perception domain / first computing domain is configured with a high-performance SoC (System on Chip) to run a vision + LiDAR fusion model; the planning domain / second computing domain runs a complex game-theoretic decision-making algorithm to generate the trajectory; the control domain / third computing domain is configured with an ASIL-MCU to handle chassis execution and has a pre-installed lightweight millimeter-wave radar perception backup algorithm.

[0115] Fault Trigger: Sensing domain temperature rises due to liquid cooling system malfunction. The threshold was exceeded momentarily, causing localized overheating and computational delay. A sudden surge occurred, with three consecutive heartbeat frames lost within 30ms. The arbitration control unit determined that the sensing domain had entered a failure / crash state.

[0116] Emergency Isolation: The arbitration control unit sends a blocking command to the central gateway. The central gateway discards all messages from the perception domain and cuts off the perception domain's data output to prevent false sensing targets (such as phantom obstacles) from causing sudden braking of the chassis. The arbitration unit broadcasts a "perception domain failure" message to the planning and control domains and simulates sending a default perception result of "no valid obstacle" to the planning domain to maintain basic cruise and avoid errors due to missing data. Simultaneously, the PMIC cuts off the power to the perception domain.

[0117] Evaluation and Reconstruction: Arbitration evaluation found that the original perceptual domain task The total available computing power is as high as 200 TOPS, while the remaining second and third computing domains have a total of only 50 TOPS. There is no normal domain that can independently undertake the original sensing task under the constraints of computing power, memory bandwidth and communication latency. This cannot meet the resource requirements of the sensing domain migration task, triggering a computing power squeeze (conditional allocation rule 2).

[0118] The system performed a degradation and reorganization: In the planning domain (second domain), based on the priority list, the tasks of "lane change and overtaking game decision-making" (efficiency category, ASIL-B) and "high-precision map online matching" (comfort category, ASIL-A) were forcibly terminated, releasing 30 TOPS of computing power. Adopting an ASIL-based safety level dimensionality reduction strategy, "comfort" was discarded while "safety" was preserved when computing power was compromised, ensuring that the vehicle would not suddenly stop on the highway due to the failure of a single node, thus guaranteeing the safety of the occupants.

[0119] The arbitration unit retrieves the pre-stored and verified "lightweight millimeter-wave radar backup sensing algorithm" from the firmware of the control domain (third domain) and dynamically loads it into the planning domain (second domain). At this point, the requirement for the sensing task is reduced from 200 TOPS to 5 TOPS.

[0120] Reduce the dimensionality of perception tasks: Abandon the large visual model and enable the "lightweight millimeter-wave radar backup perception code block" stored in the third computing domain (control domain), reducing the computing power requirement to less than 10 TOPS.

[0121] Strategy Execution: The vehicle status changes to "Degraded Operation Mode," and the system prompts the driver, "Perception is limited; please take over." Simultaneously, the maximum speed limit smoothly decreases from 120 km / h to 80 km / h. A red warning light illuminates on the instrument panel, and a voice prompt states, "The system's perception module is limited; basic driving has been taken over. Please take over the steering wheel immediately."

[0122] The entire reconfiguration process was completed within 100ms. The vehicle maintained stable cruising within its lane without any unexpected braking or directional swaying, smoothly transitioning to driver takeover or parking.

[0123] Compared to existing technologies that rely on single-domain in-situ recovery, this invention employs a cross-domain task migration and reconstruction mechanism. When a computing domain malfunctions, the system does not repeatedly reset in an attempt to recover in place; instead, it immediately isolates the faulty domain and migrates its tasks to other normal domains. This is a fault-tolerant mechanism that combines global computing power pooling and dynamic task reconstruction. This invention employs a three-layer forced isolation mechanism (network layer routing blocking, logic layer synchronization signal stripping, and physical layer power supply disconnection) to fundamentally prevent abnormal data from corrupting the execution loop in fault domains, effectively solving the "Byzantine Generals Problem." By introducing ASIL levels, it guides priority decisions for cross-domain task reorganization: when computing power is strained, the system determines which tasks should be circuit-broken to release computing power and which should be retained and migrated based on ASIL levels and functional types (security / efficiency / comfort), assisting in the multi-dimensional reallocation of global resources.

[0124] By employing a fine-grained strategy combining non-core task circuit breaking with core task frequency and dimensionality reduction, this invention achieves tiered functional retention even when computing power is compromised. For example, the perception task is reduced from 3D point cloud fusion to millimeter-wave radar 2D tracking, and the computing power required for core perception tasks is reduced to a level that can be handled by the normal domain, such as reducing the computing power requirement from 200 TOPS to less than 10 TOPS. Simultaneously, the invention uses MRM (Minimum Risk Management) instructions to adjust vehicle driving strategies, ensuring that the vehicle does not suddenly stop in high-speed scenarios due to a single domain failure. Furthermore, this invention designs a complete reverse recovery path: continuously monitoring the restart status of the faulty domain, and if the faulty domain recovers, performing reverse task migration according to the principle of "non-core first, then core," ultimately restoring to full-function mode. The entire process requires no manual intervention. This maintains system-level functional continuity; even if the faulty domain becomes completely unrecoverable, the system can still maintain vehicle operation at an acceptable safety level through task migration and function degradation.

[0125] This invention also provides a computer-readable storage medium, which can be disposed in an electronic device to store at least one instruction, at least one program, code set, or instruction set related to implementing the computational domain resilient reconstruction and security degradation control method in the method embodiments. The at least one instruction, at least one program, code set, or instruction set can be loaded and executed by the processor of the electronic device to implement the computational domain resilient reconstruction and security degradation control method provided in the above method embodiments.

[0126] Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0127] It should be noted that the order of the above embodiments of the present invention is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, the above description focuses on specific embodiments, while other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0128] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0129] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0130] The above description is merely a preferred embodiment of the present invention and should not be construed as limiting the scope of the invention. Therefore, any equivalent variations made in accordance with the claims of the present invention are still within the scope of the present invention.

Claims

1. A method for elastic reconfiguration and security degradation control of a computing domain, characterized in that, include: The operating status of the computing domain is monitored, and computing domains that exhibit abnormalities are defined as fault domains, while computing domains that operate normally are defined as normal domains. In response to the detected abnormal domain, the abnormal domain is isolated, and the resource requirements of the tasks to be migrated originally undertaken by the abnormal domain and the available resources of all normal domains are obtained. Calculate the resource matching score of each normal domain for the task to be migrated; If there is a normal domain with a resource matching score higher than the threshold, then the task to be migrated will be migrated to the normal domain with the highest score. If there is no normal domain with a resource matching score higher than the preset threshold, or if any normal domain cannot independently undertake the migration task under the constraints of computing power, memory bandwidth and end-to-end communication latency, then a downgrade and reorganization process based on security level will be triggered. The downgrade and reorganization process includes: According to the preset task priority list, at least one low-priority task is determined from the normal domain that meets the preset vehicle safety integrity level requirements and forcibly terminated to release resources. The normal domain after resource release is defined as the dimensionality reduction domain. The simplified algorithm package pre-stored in the normal domain that meets the preset vehicle safety integrity level requirements is called to switch the task to be migrated to the corresponding simplified algorithm task and migrate it to the dimensionality reduction domain for execution.

2. The computational domain elastic reconstruction and security degradation control method according to claim 1, characterized in that, In response to detected anomalous domains, the anomalous domains are isolated, including: Network layer blocking, update routing policy at vehicle gateway, and discard all data packets with source addresses in the fault domain; The physical layer goes into hibernation. If the fault domain is determined to be overheating or hardware locked, the power supply to the fault domain is cut off or restarted through the power management chip. After the logic layer is stripped and the data output of the abnormal domain is blocked, a safety threshold or empty data frame is simulated and generated based on the task relationship between the fault domain and other computing domains. The safety threshold or empty data frame is then sent to other normal domains that have a task relationship with the abnormal domain, instructing the other normal domains to stop waiting for and receiving signals from the fault domain.

3. The computational domain elastic reconstruction and security degradation control method according to claim 1, characterized in that, Calculate the resource matching score for each normal domain to the task to be migrated, as follows: Obtain the set of tasks to be migrated that the fault domain originally handled. The current set of available resources in all normal domains is ; Compute any task to be migrated , In each normal candidate domain , Resource matching score The calculation model is as follows: ； in, The available computing power for the normal computation domain x, The required computing power for the task j to be migrated; The available memory bandwidth for the normal computation domain x. The required memory bandwidth for the task j to be migrated; To migrate task j to normal domain x, the additional end-to-end communication latency increment is dynamically calculated based on the preset task dependency graph and the physical topology latency between domains. The expected average latency for the tasks to be migrated; These are preset weighting coefficients.

4. The computational domain elastic reconstruction and security degradation control method according to claim 1, characterized in that, It also includes a dynamic recovery step: The abnormal domain is continuously monitored; if the abnormal domain returns to normal and its output is consistent with the output of the dimensionality reduction domain currently executing the corresponding task in cross-validation over multiple consecutive periods, then the unexecuted migration task is reverse-migrated from the dimensionality reduction domain to the normal abnormal domain according to the preset recovery strategy.

5. The computational domain elastic reconstruction and security degradation control method according to claim 4, characterized in that, The preset recovery strategy is divided into three strategy modes based on task type, security level, and current stage of operation: Immediate full migration: The migration task is a safe task and the current vehicle speed is below 20km / h; pause the execution of the migration task in the dimensionality reduction domain, package the migration task and task status completely, migrate to the abnormal domain that has returned to normal, and the abnormal domain that has returned to normal continues execution from the latest checkpoint; Progressive migration: If the migration task is a real-time task, then migrate a portion of the data in the future prediction window, restore the normal outlier domain and the dimensionality reduction domain to run in parallel for at least one cycle, and complete the full switch after the normal outlier domain has stabilized. New task switching: If the task being migrated is a task that has already been calculated or is about to end, then the current task is completed in the reduced-dimensional domain, and the next task triggered by the new task is directly migrated to the restored abnormal domain to take over the execution.

6. The computational domain elastic reconstruction and security degradation control method according to claim 1, characterized in that, A simplified algorithm package is pre-stored in at least one computational domain that meets the preset vehicle safety integrity level requirements; when the dimensionality reduction and reorganization process is triggered, the simplified algorithm package is called to switch the task to be migrated to the simplified algorithm task corresponding to the function, and migrate it to the dimensionality reduction domain for execution. The simplified algorithm package includes, but is not limited to: a deterministic backup perception algorithm based on millimeter-wave radar or ultrasonic radar, and a safe following planning algorithm based on lane keeping. The preset simplified algorithm package is pre-stored in a non-volatile memory in the normal domain that meets the preset vehicle safety integrity level requirements, and has undergone functional safety verification. The functional safety verification includes: requirements verification, hardware-in-the-loop testing, deterministic output verification, and static code and data verification. The requirement verification is used to confirm that the simplified algorithm can achieve its stated security objectives under the expected degraded operating environment; Hardware-in-the-loop testing involves injecting corresponding fault conditions into a simulated real vehicle operating scenario to verify that the control commands output by the simplified algorithm are within the physical boundaries and will not lead to dangerous events. For deterministic output verification, for the same set of input data, the simplified algorithm should output the same result in multiple consecutive executions, and the execution time jitter should be less than the preset safety threshold. Static code and data verification perform memory usage analysis, worst-case execution time analysis, and data consistency verification on the simplified algorithm package, and generate an immutable signature stored in a secure storage area.

7. The computational domain elastic reconstruction and security degradation control method according to claim 1, characterized in that, The low-priority tasks are determined according to a preset task priority list, and the priority list is sorted based on at least the vehicle safety integrity level and the functional type of the task. Construct a task priority list. In the task priority list, the priority ordering principle for function type is: safety-related tasks take precedence over efficiency-related tasks, which in turn take precedence over comfort-related tasks. The priority ordering principle for vehicle safety integrity level is: the higher the level, the higher the priority.

8. The computational domain elastic reconstruction and security degradation control method according to claim 1, characterized in that, The operational status of multiple computing domains is monitored in the following way: Monitor the operational status feature vectors of each computing domain, including end-to-end task latency, processor utilization, storage fragmentation rate, chip junction temperature, and heartbeat message sequence number continuity. If any parameter exceeds a preset safety threshold for N consecutive computing cycles, an anomaly flag is triggered.

9. A computational domain resilient reconfiguration and security degradation control system, used to implement the computational domain resilient reconfiguration and security degradation control method as described in any one of claims 1-8, characterized in that, It includes multiple heterogeneous computing domains and an independent arbitration control unit; The plurality of heterogeneous computing domains include at least a first computing domain, a second computing domain, and a third computing domain. The first computing domain is responsible for environmental perception tasks, the second computing domain is responsible for path planning and decision-making tasks, and the third computing domain is responsible for chassis execution and safety redundancy tasks. The third computing domain is configured as a security-level microcontroller, which has a non-volatile memory inside, and the non-volatile memory pre-stores a verified simplified algorithm package. The arbitration control unit is configured as an independent hardware node based on FPGA or security microcontroller. The arbitration control unit communicates with the multiple heterogeneous computing domains through the vehicle network to perform millisecond-level status monitoring, decision arbitration and resource scheduling.

10. A computer-readable storage medium storing a computer program thereon, characterized in that, When the computer program is executed by the processor, it implements a computing domain elastic reconfiguration and security degradation control method as described in any one of claims 1-8.

Images