Fault processing method and system for modular mainboard expansion interface, electronic equipment and storage medium

Abstract

The invention discloses a fault processing method and system for a modular mainboard expansion interface, electronic equipment and a storage medium, and relates to the technical field of computer hardware fault processing and automatic control. The method comprises the following steps: collecting monitoring parameters of an expansion module connected with an expansion interface; cutting off a power supply path of the fault module when the extension module is judged to have a fault based on the monitoring parameters; based on the fault information of the fault module, triggering an operation of releasing hardware resources occupied by the fault module; the availability score of each health module is calculated, the service task of the fault module is migrated to the target health module based on the availability score of each health module, it is ensured that only the fault module is isolated, and system crash caused by traditional global outage is avoided; hardware resources of the fault module are automatically released, service tasks are intelligently migrated through availability scores of the health module, and the system availability and the hardware service life are maximized.

Description

Technical Field

[0001] This application relates to the field of computer hardware fault handling and automated control technology, specifically to a fault handling method and system for a modular motherboard expansion interface, electronic equipment, and storage medium. Background Technology

[0002] Modular motherboard expansion interfaces are physical slots that support hot-swapping, have independent power and communication capabilities, and can accommodate dedicated functional modules, enhancing system flexibility through modular design. Existing power protection mechanisms are mostly focused on the overall power bus or simple physical disconnection, lacking management for individual expansion modules. Most systems trigger a global power outage or restart upon detecting an expansion module malfunction, which forces other normal modules to stop working as well, increasing system recovery time.

[0003] Therefore, it is urgent to solve the problem of how to ensure the system continues to run when the expansion module fails. Summary of the Invention

[0004] The purpose of this application is to provide a fault handling method and system for a modular motherboard expansion interface, an electronic device, and a storage medium to solve the problems mentioned in the background art.

[0005] In a first aspect, one embodiment of this application provides a fault handling method for a modular motherboard expansion interface. The method includes: collecting monitoring parameters of the expansion modules connected to the expansion interface; when a fault is determined based on the monitoring parameters, cutting off the power supply path of the faulty module; triggering the release of hardware resources occupied by the faulty module based on the fault information of the faulty module; calculating the availability score of each healthy module, the availability score being used to characterize the ability and adaptability of the healthy module to undertake the business tasks of the faulty module; and migrating the business tasks of the faulty module to a target healthy module based on the availability score of each healthy module to complete the fault handling.

[0006] In conjunction with the first aspect, in some implementations of the first aspect, when it is determined that the expansion module has failed based on the monitoring parameters, the power supply path of the faulty module is cut off, including: filtering the monitoring parameters to obtain filtered monitoring parameters; standardizing the filtered monitoring parameters according to a preset formula to obtain standardized monitoring parameters; performing multi-level fault determination based on the standardized monitoring parameters; and cutting off the power supply path of the faulty module after confirming that the faulty module has been in a faulty state for a preset time period.

[0007] In conjunction with the first aspect, in some implementations of the first aspect, the standardized monitoring parameters include standardized voltage deviation rate, standardized current load rate, and standardized temperature margin. Based on the standardized monitoring parameters, multi-level fault determination is performed, including: calculating a fault score based on the standardized voltage deviation rate, standardized current load rate, standardized temperature margin, and the corresponding weight values ​​of each parameter; triggering a first-level early warning fault when any of the standardized voltage deviation rate, standardized current load rate, and standardized temperature margin falls within the warning threshold range; triggering a second-level fault determination when any of the standardized voltage deviation rate, standardized current load rate, and standardized temperature margin exceeds the corresponding fault threshold, or when the fault score is greater than the second-level fault threshold; and triggering a third-level severe fault determination when any of the standardized voltage deviation rate, standardized current load rate, and standardized temperature margin exceeds the corresponding severe over-limit threshold, or when the fault score is greater than the third-level fault threshold.

[0008] In conjunction with the first aspect, in some implementations of the first aspect, the operation of releasing the hardware resources occupied by the faulty module is triggered based on the fault information of the faulty module, including: constructing a fault event data packet based on the fault information of the faulty module; querying the resource allocation table based on the fault event data packet to identify the physical address space, logical resources and software resources occupied by the faulty module; and performing the operation of releasing the physical address space, logical resources and software resources occupied by the faulty module.

[0009] In conjunction with the first aspect, in some implementations of the first aspect, the availability score of each health module is calculated, including: determining the functional compatibility coefficient of each health module based on the module's functional type; determining the performance ratio of the health module to the faulty module based on the module's performance specifications; and calculating the availability score based on the functional compatibility coefficient, the performance ratio, and the current load rate of the health module.

[0010] In conjunction with the first aspect, in some implementations of the first aspect, the business tasks of the faulty module are migrated to the target healthy module based on the availability score of each healthy module. This includes: selecting the target healthy module based on the availability score of each healthy module; establishing a task migration priority mechanism based on the importance and real-time information of the business tasks; determining the migration order of the business tasks using the task migration priority mechanism; and migrating the business tasks to the target healthy module according to the migration order of the business tasks.

[0011] In conjunction with the first aspect, in some implementations of the first aspect, the monitoring parameters include voltage deviation rate, current load rate, and temperature margin. After migrating the business tasks of the faulty module to the target healthy module based on the availability score of each healthy module, the method further includes: dynamically tightening the voltage deviation rate, current load rate, and temperature margin based on the system performance retention rate and load redistribution status, and calibrating the environmental interference on the monitoring parameters through an environmental compensation coefficient; calculating the health score of each extended module based on module operating data and historical stress records, generating preventive maintenance instructions according to maintenance priority, and marking faulty modules that have failed to recover multiple times consecutively as permanent fault states.

[0012] Secondly, one embodiment of this application provides a fault handling system for a modular motherboard expansion interface. The system includes: a motherboard management controller; at least two expansion interfaces, each including a power monitoring unit and a controllable power switch circuit. The power monitoring unit is used to collect monitoring parameters of the connected expansion modules; the controllable power switch circuit is integrated into the main power supply circuit of the expansion modules; the motherboard management controller is used to execute multi-level fault determination based on the monitoring parameters collected by the power monitoring unit, send isolation commands to the controllable power switch circuit of the faulty module to cut off the power supply path of the faulty module, and report fault information to the operating system to receive resource remapping feedback signals from the operating system based on the fault information of the faulty module, releasing the hardware resources occupied by the faulty module; and based on the calculated availability score of each healthy module, migrate the business tasks of the faulty module to the target healthy module to complete the fault handling.

[0013] Thirdly, one embodiment of this application provides an electronic device, which includes: a processor; a memory for storing processor-executable instructions; and the processor for performing the method mentioned in the first aspect above.

[0014] Fourthly, one embodiment of this application provides a computer-readable storage medium storing a computer program for performing the method mentioned in the first aspect above.

[0015] The fault handling method for the modular motherboard expansion interface provided in this application embodiment ensures that only the faulty module is isolated through closed-loop control of module-level real-time monitoring → intelligent fault judgment → millisecond-level power supply isolation → dynamic remapping of system resources, thus avoiding system crashes caused by traditional global power outages; it automatically releases the hardware resources of the faulty module and intelligently migrates business tasks through health module availability scoring, thereby maximizing system availability and hardware lifespan. Attached Figure Description

[0016] Figure 1 The diagram shown is a flowchart illustrating a fault handling method for a modular motherboard expansion interface provided in an embodiment of this application.

[0017] Figure 2 The diagram shown is a flowchart illustrating a fault handling method for a modular motherboard expansion interface provided in another exemplary embodiment of this application.

[0018] Figure 3 The diagram shown is a flowchart illustrating the operation of triggering the release of hardware resources occupied by the fault module, as provided in another exemplary embodiment of this application.

[0019] Figure 4 The diagram shown is a flowchart illustrating the calculation of the availability score for each health module according to another exemplary embodiment of this application.

[0020] Figure 5 The diagram shown is a flowchart illustrating a fault handling method for a modular motherboard expansion interface provided in another exemplary embodiment of this application.

[0021] Figure 6 The diagram shown is a structural schematic of a fault handling system for a modular motherboard expansion interface provided in an exemplary embodiment of this application.

[0022] Figure 7 The diagram shown is a structural schematic of an electronic device provided in an exemplary embodiment of this application. Detailed Implementation

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

[0024] Figure 1 The diagram shown is a flowchart illustrating a fault handling method for a modular motherboard expansion interface provided in an embodiment of this application. Figure 1 As shown in the embodiment of this application, the fault handling method for the modular motherboard expansion interface includes the following steps.

[0025] Step 100: Collect monitoring parameters of the expansion module connected to the expansion interface.

[0026] For example, an expansion interface refers to a modular physical slot on the motherboard that integrates an independent power monitoring unit and control circuitry to achieve module-level power supply and communication connectivity.

[0027] For example, an expansion module refers to a pluggable functional unit (such as a memory card) that is inserted into an expansion interface and performs a specific hardware task.

[0028] For example, the monitoring parameters include real-time collected module-level operating data (such as voltage, current, and temperature), which can be used for fault diagnosis and isolation decisions after standardized calculation.

[0029] Step 101: When a fault is detected in the expansion module based on the monitoring parameters, the power supply path to the faulty module is cut off.

[0030] Specifically, each expansion interface is equipped with an independent and controllable power switch, which can complete the partial power cut-off in milliseconds when abnormal parameters are detected, thus preventing the fault from spreading.

[0031] Step 102: Based on the fault information of the faulty module, trigger the operation to release the hardware resources occupied by the faulty module.

[0032] Specifically, resource allocation can be automatically adjusted (remapping) by the system software. By executing the resource release process, it is ensured that the system resources occupied by the isolated modular extension interfaces can be safely reclaimed, creating conditions for subsequent task migration and resource reallocation.

[0033] Step 103: Calculate the availability score for each health module.

[0034] For example, a health module refers to an extension module that monitors parameters (voltage deviation rate, current load rate, temperature margin) in real time and ensures they remain within safe threshold ranges and are not forcibly disabled.

[0035] For example, availability score is used to characterize the ability and adaptability of a healthy module to take over the business tasks of a faulty module.

[0036] Step 104: Based on the availability score of each health module, migrate the business tasks of the faulty module to the target health module to complete the fault handling.

[0037] It should be understood that after the resources of the faulty module are released, the system needs to migrate the business tasks originally undertaken by the faulty module to other available modular extension interfaces to ensure business continuity and the maintenance of overall system performance.

[0038] The fault handling method for the modular motherboard expansion interface provided in this application embodiment ensures that only the faulty module is isolated through closed-loop control of module-level real-time monitoring → intelligent fault judgment → millisecond-level power supply isolation → dynamic remapping of system resources, thus avoiding system crashes caused by traditional global power outages; it automatically releases the hardware resources of the faulty module and intelligently migrates business tasks through health module availability scoring, thereby maximizing system availability and hardware lifespan.

[0039] Figure 2 The diagram shown is a flowchart illustrating a fault handling method for a modular motherboard expansion interface provided in another exemplary embodiment of this application. Figure 1This application extends from the embodiments shown. Figure 2 The illustrated embodiment will be described in detail below. Figure 2 The illustrated embodiments and Figure 1 The differences between the embodiments shown are not repeated here, and the similarities are not repeated here.

[0040] like Figure 2 As shown, in the fault handling method of the modular motherboard expansion interface provided in this application embodiment, when it is determined that the expansion module has failed based on monitoring parameters, the power supply path of the faulty module is cut off, including the following steps.

[0041] Step 201: Filter the monitoring parameters to obtain the filtered monitoring parameters.

[0042] It should be understood that filtering the collected monitoring parameters can eliminate sampling noise.

[0043] For example, a moving average filter can be used, with a filter window length of 3-5 sampling points. The filtered parameter values ​​are denoted as V_filtered, I_filtered, and T_filtered, and used as input data for subsequent anomaly detection.

[0044] Step 202: Standardize the filtered monitoring parameters according to a preset formula to obtain standardized monitoring parameters.

[0045] To ensure that subsequent steps can determine anomalies based on unified parameter standards, it is necessary to standardize the definition of monitoring parameters.

[0046] Standardize the voltage parameters and define the voltage deviation rate δV: δV = (V_filtered - V_nominal) / V_nominal × 100%; Where V_nominal is the nominal operating voltage of the expansion module. The normal operating range is δV ∈ [-5%, +5%], the warning threshold is δV ∈ [-10%, -5%]∪ [+5%, +10%], and the fault threshold is |δV|>10%.

[0047] Standardize the current parameter and define the current load factor λI: λI = I_filtered / I_rated × 100%; Where I_rated is the rated operating current of the expansion module. The normal operating range is λI ∈ [10%, 80%], the overload warning threshold is λI ∈ [80%, 90%], and the overload fault threshold is λI>90% or λI<5% (suspected open circuit).

[0048] Standardize the temperature parameter and define the temperature margin ΔT: ΔT = T_max_spec - T_filtered; Where T_max_spec is the maximum operating temperature specification of the extension module. Normal operation requires ΔT>20°C, the warning threshold is ΔT ∈ [10°C, 20°C], and the fault threshold is ΔT<10°C.

[0049] Standardized monitoring parameters will be directly used in the anomaly detection algorithm to ensure that the system can accurately identify different types of module faults and execute corresponding power isolation strategies. At the same time, the definition of standardized monitoring parameters also provides a clear fault level classification basis for system resource remapping.

[0050] Step 203: Perform multi-level fault determination based on standardized monitoring parameters.

[0051] Step 204: After confirming that the faulty module remains in a faulty state for a preset time period, disconnect the power supply to the faulty module.

[0052] To prevent false alarms caused by transient anomalies, a fault confirmation counter N_confirm and a confirmation time window T_confirm can be set. Only when the fault condition is met for N_confirm consecutive samples within the T_confirm time window, confirming the fault module remains in a fault state, will the actual power isolation operation be performed. The formula for setting the confirmation parameters is: N_confirm = ceil(T_confirm / T_sample); Where T_sample is the sampling period, and T_confirm can be set to 5-20 milliseconds to ensure a balance between fast response and false positive prevention. T_confirm can also be set to other values, depending on the actual situation.

[0053] The fault handling method for the modular motherboard expansion interface provided in this application embodiment achieves high-reliability fault isolation. It eliminates transient noise by performing moving average filtering on the monitoring parameters; performs multi-level fault judgment based on standardized monitoring parameters to distinguish between early warning / isolation / forced isolation states, avoiding over-response; and sets up an anti-false disconnection mechanism to trigger isolation only after a continuous fault, preventing false disconnection caused by transient anomalies.

[0054] In one embodiment of this application, a fault handling method for a modular motherboard expansion interface is provided, which performs multi-level fault determination based on standardized monitoring parameters. The standardized monitoring parameters include standardized voltage deviation rate, standardized current load rate, and standardized temperature margin, and include the following steps.

[0055] A fault score is calculated based on standardized voltage deviation rate, standardized current load rate, standardized temperature margin, and the corresponding weight values ​​for each parameter. A weighted score can be used to comprehensively evaluate multiple monitoring parameters. The weighted calculation formula for the fault score S_fault is: S_fault = W_v × |δV / δV_threshold| + W_i × (λI / λI_threshold) + W_t× max(0, (T_threshold - ΔT) / T_threshold); Where W_v, W_i, and W_t are the weighting coefficients for the standardized voltage deviation rate, standardized current load rate, and standardized temperature margin, respectively, and their sum equals 1. δV_threshold, λI_threshold, and T_threshold are the fault judgment thresholds for each parameter. A level 2 fault judgment is triggered when the fault score S_fault is greater than 1.0, and a level 3 severe fault judgment is triggered when the fault score S_fault is greater than 2.0.

[0056] In another embodiment, a Level 1 warning fault is triggered when any one of the standardized voltage deviation rate, standardized current load rate, and standardized temperature margin falls within the warning threshold range. A Level 2 fault determination is triggered when any one of the standardized voltage deviation rate, standardized current load rate, and standardized temperature margin exceeds the corresponding fault threshold. A Level 3 severe fault determination is triggered when any one of the standardized voltage deviation rate, standardized current load rate, and standardized temperature margin exceeds the corresponding severe over-limit threshold.

[0057] Specifically, based on standardized voltage deviation rate, standardized current load rate, and standardized temperature margin, module faults are classified into three levels. Level 1 warning status corresponds to a voltage deviation rate δV within the warning threshold range, a current load rate λI within the overload warning range, or a temperature margin ΔT within the warning range. In this case, the system records the warning information but does not perform isolation operations. Level 2 fault status corresponds to any parameter reaching the fault threshold; the system immediately initiates the isolation procedure but retains the opportunity for module recovery. Level 3 severe fault status corresponds to multiple parameters exceeding limits simultaneously or a single parameter severely exceeding limits; the system performs forced isolation and marks the module as permanently faulty.

[0058] The fault handling method for the modular motherboard expansion interface provided in this application embodiment achieves high accuracy and controllability in fault determination and anti-false judgment capability. It integrates multi-dimensional parameter fusion and dynamic threshold grading mechanism, and integrates weighted fault scoring to prevent false triggering by single parameter transient anomalies and to identify complex hidden faults. It only performs power-off for confirmed persistent faults, and combined with subsequent task migration, it maximizes system availability while eliminating the risk of fault propagation.

[0059] Figure 3 The diagram shown is a flowchart illustrating the operation of triggering the release of hardware resources occupied by a fault module, according to another exemplary embodiment of this application. Figure 1 This application extends from the embodiments shown. Figure 3 The illustrated embodiment will be described in detail below. Figure 3 The illustrated embodiments and Figure 1 The differences between the embodiments shown are not repeated here, and the similarities are not repeated here.

[0060] like Figure 3 As shown, based on the fault information of the faulty module, the operation of releasing the hardware resources occupied by the faulty module is triggered, including the following steps.

[0061] Step 300: Construct a fault event data packet based on the fault information of the faulty module.

[0062] For example, the fault event data packet includes fields such as Module_ID, Status_Code, Timestamp_Fault, Fault_Type, and Parameter_Snapshot. Status_Code uses a status enumeration value (ISOLATED=0x01, RECOVERED=0x02, PERMANENT_FAULT=0x03), and Fault_Type records the main reason for triggering isolation (voltage anomaly=0x10, current overload=0x20, temperature exceeding limit=0x30, combined fault=0x40). The Parameter_Snapshot saves the δV, λI, and ΔT parameter values ​​at the time of the fault, used for subsequent fault analysis and recovery strategy formulation.

[0063] Specifically, the fault event data packet adopts a fixed 32-byte format, including a 4-byte module identifier, a 4-byte status code, an 8-byte timestamp, an 8-byte parameter snapshot, and an 8-byte checksum.

[0064] Step 301: Based on the fault event data packet, query the resource allocation table to identify the physical address space, logical resources and software resources occupied by the faulty module.

[0065] An initial resource mapping table can be established by scanning the device identifiers and configuration information of each expansion interface. The initial resource mapping table records the hardware characteristics, driver associations, and service function allocations of each expansion interface. Based on the Module_ID of the faulty module, the system queries the resource allocation table to identify all system resources occupied by the faulty module.

[0066] The system resources are categorized into physical address space (memory-mapped I / O addresses, PCI configuration space addresses), logical resources (I / O port numbers, memory channel allocations, interrupt vectors), and software resources (driver instances, device nodes, process handles). Each type of resource has a corresponding resource identifier (Resource_ID) and allocation status (Allocation_Status) for precise tracking and management.

[0067] Step 302: Perform the operation of releasing the physical address space, logical resources and software resources occupied by the faulty module.

[0068] Resource release employs a multi-stage strategy to ensure system stability. The first stage performs a soft stop, sending stop signals to applications and drivers using the faulty module and waiting for ongoing operations to complete, with a timeout set to T_graceful_stop. The second stage performs a forced stop, terminating all processes and threads related to the faulty module and reclaiming occupied memory and file handles. The third stage performs hardware resource deregistration, marking the module's physical address space as unavailable and disabling related interrupt handlers. The total resource release time T_resource_free is calculated using the following formula: T_resource_free = T_graceful_stop + T_force_stop + T_hardware_unregister + T_verification; Where T_graceful_stop is the soft stop waiting time (usually set to 2-5 seconds), T_force_stop is the forced stop execution time, T_hardware_unregister is the hardware unregistration time, and T_verification is the release verification time.

[0069] The fault handling method for modular motherboard expansion interfaces provided in this application constructs fault event data packets to ensure that the operating system can quickly parse them; it accurately identifies the physical address space, logical resources, and software resources occupied by the faulty module based on the resource allocation table, and realizes lossless recycling and efficient reuse of faulty resources through hierarchical release control.

[0070] Figure 4 The diagram shown is a schematic representation of a process for calculating the availability score of each health module, provided in another exemplary embodiment of this application. Figure 1 This application extends from the embodiments shown. Figure 4 The illustrated embodiment will be described in detail below. Figure 4 The illustrated embodiments and Figure 1 The differences between the embodiments shown are not repeated here, and the similarities are not repeated here.

[0071] like Figure 4 As shown in the embodiment of this application, the fault handling method for the modular motherboard expansion interface calculates the availability score of each healthy module, including the following steps.

[0072] Step 400: Determine the functional compatibility coefficient of each health module based on the module function type.

[0073] Step 401: Based on the module performance specifications, determine the performance ratio between healthy modules and faulty modules.

[0074] Step 402: Calculate the availability score based on the functional compatibility coefficient, performance ratio, and current load rate of the health module.

[0075] Specifically, for all modular extension interfaces that are in normal working order, a comprehensive evaluation is performed based on their Function_Type, Performance_Spec, and Current_Load. The availability score Score_available is calculated using the following formula: Score_available = W_func × Compatibility_func + W_perf ×(Performance_ratio) + W_load × (1 - Current_Load); Wherein, W_func, W_perf, and W_load are the weighting coefficients for functional compatibility, performance matching degree, and load status, respectively. Compatibility_func represents functional compatibility (fully compatible = 1.0, partially compatible = 0.5, incompatible = 0), Performance_ratio represents the performance matching ratio (target module performance / faulty module performance), and Current_Load represents the current load rate (range 0-1).

[0076] The fault handling method for the modular motherboard expansion interface provided in this application eliminates the risk of hardware type mismatch based on the functional compatibility coefficient; quantifies the computing power capacity through the performance ratio to avoid performance bottlenecks; dynamically evaluates the real-time reserve of the module in combination with the current load rate to prevent overload after migration; adopts a weighted scoring formula to automatically select the healthiest module with the strongest comprehensive capabilities to undertake the business; and the availability scoring mechanism prioritizes the migration of critical tasks to low-load, highly compatible modules to ensure business continuity.

[0077] Figure 5 The diagram shown is a flowchart illustrating a fault handling method for a modular motherboard expansion interface provided in another exemplary embodiment of this application. Figure 1 This application extends from the embodiments shown. Figure 5 The illustrated embodiment will be described in detail below. Figure 5 The illustrated embodiments and Figure 1 The differences between the embodiments shown are not repeated here, and the similarities are not repeated here.

[0078] like Figure 5 As shown in the embodiment of this application, the fault handling method for the modular motherboard expansion interface, based on the availability score of each health module, migrates the business tasks of the faulty module to the target health module, including the following steps.

[0079] Step 500: Filter target health modules based on the availability score of each health module.

[0080] Step 501: Establish a task migration priority mechanism based on the importance and real-time information of business tasks.

[0081] Step 502: Use the task migration priority mechanism to determine the migration order of business tasks.

[0082] Step 503: Migrate the business tasks to the target health module according to the migration order of the business tasks.

[0083] Based on the importance and real-time requirements of business tasks, a task migration priority mechanism is established. Critical tasks (such as security control and real-time communication) are prioritized with P_critical=1, important tasks (such as data processing and network services) with P_important=2, and general tasks (such as storage backup and log recording) with P_normal=3. Migration is performed in descending order of priority, and tasks with the same priority are performed in ascending order of resource requirements.

[0084] To avoid overloading the expansion modules after task migration, a load balancing algorithm is used for task redistribution. The formula for calculating the target load rate (Target_Load) is: Target_Load = (Total_Workload - Failed_Module_Workload) / (N_available × Average_Capacity); Where Total_Workload is the total system workload, Failed_Module_Workload is the workload originally handled by the failed module, N_available is the number of available modules, and Average_Capacity is the average processing capacity of the available modules. When Target_Load exceeds 0.8, the system triggers performance degradation protection, prioritizing the execution of critical tasks.

[0085] The fault handling method for modular motherboard expansion interfaces provided in this application provides a method that accurately matches healthy modules capable of handling services through availability scoring. Based on the importance and real-time information of the service tasks, a task migration priority mechanism is established. Using the task migration priority mechanism, the migration order of service tasks is determined, and the service tasks are migrated to the target healthy modules according to the migration order. This reduces the impact of hardware failures on services from "system-level crashes" to "module-level micro-disturbances," significantly improving the industrial applicability and lifecycle management efficiency of modular motherboards.

[0086] In one embodiment, the monitoring parameters include voltage deviation rate, current load rate, and temperature margin. After migrating the business tasks of the faulty module to the target healthy module based on the availability score of each healthy module, the method further includes: dynamically tightening the voltage deviation rate, current load rate, and temperature margin based on the system performance retention rate and load redistribution status, and calibrating the environmental interference on the monitoring parameters through an environmental compensation coefficient; calculating the health score of each extended module based on module operating data and historical stress records, generating preventive maintenance instructions according to maintenance priority, and marking faulty modules that have failed to recover multiple times consecutively as having a permanent fault status.

[0087] In high-sensitivity mode, the voltage deviation rate threshold δV_threshold, current load rate threshold λI_threshold, and temperature margin threshold ΔT_threshold are tightened to 80% of their original values. When system load redistribution causes the average module load rate to exceed 70%, the temperature-related thresholds are further tightened to 70% of their original values ​​to prevent the risk of thermal failure under high load operation. When multiple adjustment mechanisms conflict, the system prioritizes safety and adopts the most stringent threshold setting. The adjustment priorities are as follows: safety protection threshold, environmental compensation threshold, and performance optimization threshold.

[0088] Based on accumulated operational data and stress history, a module health assessment model is established. The formula for calculating the module health score (Health_Score) is as follows: Health_Score = 1 - (Cumulative_Stress / Design_Stress_Limit) - (Operating_Time / Expected_Lifetime) - Degradation_Factor; Where Cumulative_Stress is the cumulative stress value, Design_Stress_Limit is the design stress limit, Operating_Time is the cumulative runtime, Expected_Lifetime is the expected lifespan, and Degradation_Factor is the performance degradation factor. When Health_Score is below 0.3, the system recommends preventative maintenance or module replacement.

[0089] Based on the health assessment results and business importance of each extended module, the system formulates a preventative maintenance plan. Based on the current module distribution and historical fault statistics, the system evaluates overall fault tolerance and provides capacity planning suggestions. Combining machine learning algorithms and historical data analysis, the system establishes a fault prediction model to achieve early warning and proactive protection, providing maintenance personnel with sufficient response time and realizing a shift from a reactive to a proactive prevention management model.

[0090] Figure 6 The diagram shown is a structural schematic of a fault handling system for a modular motherboard expansion interface provided in an exemplary embodiment of this application. Figure 6 As shown, the fault handling system for the modular motherboard expansion interface provided in this application embodiment includes: a motherboard management controller 600 and at least two expansion interfaces 601. Each expansion interface includes a power monitoring unit 6011 and a controllable power switch circuit 6012. The power monitoring unit 6011 is used to collect monitoring parameters of the connected expansion module. The controllable power switch circuit 6012 is integrated in the main power supply circuit of the expansion module.

[0091] The motherboard management controller 600 is used to execute multi-level fault determination based on the monitoring parameters collected by the power monitoring unit 6011, send isolation commands to the controllable power switch circuit 6012 of the fault module to cut off the power supply path of the fault module, and report fault information to the operating system. It also receives resource remapping feedback signals from the operating system based on the fault information of the fault module and releases the hardware resources occupied by the fault module. Based on the calculated availability score of each healthy module, it migrates the business tasks of the fault module to the target healthy module to complete the fault handling.

[0092] In one embodiment, an independent power monitoring unit is integrated at each modular expansion interface of the motherboard. This power monitoring unit includes three detection circuits, each responsible for collecting monitoring parameters of the expansion module. The voltage detection circuit collects the supply voltage V_module of the expansion module in real time; the current sampling circuit collects the operating current I_module of the expansion module in real time; and temperature sensors are located at the power input terminal of the expansion interface, the center of the signal connector, and the contact surface of the heatsink to collect the operating temperature T_module of the expansion module and the interface area. Each monitoring unit is equipped with a signal conditioning circuit and a local buffer for data preprocessing and temporary storage, ensuring that critical monitoring data is not lost when the communication bus is busy.

[0093] The power monitoring units of all expansion interfaces are connected to the motherboard management controller via a communication bus. In addition to the data communication bus, the system also needs to establish a control signal bus for the motherboard management controller to send switching control commands to the metal-oxide-semiconductor field-effect transistor (MOSFET) drive circuits of each expansion interface.

[0094] The motherboard management controller polls and collects monitoring parameters for each modular expansion interface at a preset sampling period T_sample, and then standardizes the monitored parameters. The preset sampling period T_sample can be set to a value that suits the specific circumstances.

[0095] An independent, controllable power switch circuit is integrated into the main power supply loop of each modular expansion interface. This circuit employs a high-side MOSFET switching architecture to ensure complete power isolation in the event of a module failure.

[0096] The motherboard management controller executes a multi-level fault diagnosis algorithm based on standardized monitoring parameters and immediately triggers power isolation operations for the corresponding modular expansion interface upon fault confirmation. When the multi-level fault diagnosis algorithm confirms the need for power isolation, the motherboard management controller immediately controls the MOSFET switch of the corresponding modular expansion interface to perform a shutdown operation and establishes a status feedback mechanism. After power isolation is executed, the isolation status is confirmed by monitoring the drain-source voltage of the MOSFET. When the drain-source voltage rises to above 90% of the supply voltage and remains stable, the power isolation is confirmed to be successful. Simultaneously, the current sampling value of the modular expansion interface is monitored, and the current sampling value is confirmed to drop to the noise level (typically less than 1% of the rated current) to verify that the power is completely disconnected.

[0097] After confirming successful power isolation, the motherboard management controller updates its internal module status register, marking the corresponding modular expansion interface as "ISOLATED". Simultaneously, it records detailed information such as the isolation timestamp, fault type, and fault parameter values, forming a fault event log. This status information and fault log are reported to the operating system or embedded management system via a standardized data interface, providing necessary input data for system resource remapping.

[0098] After power isolation is implemented, the system needs to continuously monitor the status of the isolated modular expansion interface and provide a recovery mechanism when conditions are met to ensure maximum utilization of system resources.

[0099] After the motherboard management controller completes the power isolation operation of the modular expansion interface, the system needs to establish a standardized hardware-software communication interface to accurately transmit fault status information to the operating system or embedded management system, providing a data foundation for subsequent resource remapping operations.

[0100] Upon receiving the reported fault information, the operating system immediately initiates a resource release process to ensure that the system resources occupied by the isolated modular extension interface can be safely reclaimed, creating conditions for subsequent task migration and resource reallocation.

[0101] After releasing the resources of the faulty module, the system needs to migrate the business tasks originally undertaken by the faulty module to other available modular extension interfaces to ensure business continuity and maintain the overall performance of the system.

[0102] After the task migration is completed, the system needs to update the relevant configuration information and status records to ensure that the new resource allocation scheme can be correctly identified and managed, and to provide accurate system status information for anomaly detection and stability control.

[0103] Based on the monitoring system and resource remapping results established in the preceding steps, the system needs to construct an anomaly detection mechanism to achieve accurate assessment and predictive maintenance of the modular extension interface's operating status through multi-dimensional parameter fusion and dynamic threshold adjustment.

[0104] Based on anomaly detection, the system implements a stability control strategy, using multi-layered protection mechanisms and adaptive control algorithms to minimize the impact of misjudgments and frequent switching on system stability.

[0105] The system continuously collects and analyzes operational data to establish an adaptive learning mechanism, constantly optimizing anomaly detection parameters and control strategies to improve long-term operational stability and reliability. A comprehensive long-term maintenance system is established, employing preventative management and proactive maintenance strategies to ensure stable operational performance and reliability throughout the system's entire lifecycle.

[0106] It should be understood that the operation and functions of the relevant modules mentioned in the fault handling system for modular motherboard expansion interfaces can be referenced above. Figures 1 to 5 The troubleshooting methods for the provided modular motherboard expansion interfaces will not be repeated here to avoid repetition.

[0107] Below, for reference Figure 7 This describes an electronic device according to embodiments of the present application. Figure 7 The diagram shown is a structural schematic of an electronic device provided in an exemplary embodiment of this application.

[0108] like Figure 7 As shown, the electronic device 700 includes one or more processors 701 and memory 702.

[0109] The processor 701 may be a central processing unit (CPU) or other form of processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device 700 to perform desired functions.

[0110] The memory 702 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 701 may execute the program instructions to implement the fault handling method of the modular motherboard expansion interface of the various embodiments of this application described above, and / or other desired functions. Various contents, such as monitoring parameters of the expansion module, may also be stored in the computer-readable storage medium.

[0111] In one example, the electronic device 700 may also include an input device 703 and an output device 704, which are interconnected via a bus system and / or other forms of connection mechanism (not shown).

[0112] The input device 703 may include, for example, a keyboard, a mouse, etc.

[0113] The output device 704 can output various information to the outside, including the availability score of each health module. The output device 704 may include, for example, a display, a communication network, and remote output devices connected thereto.

[0114] Of course, for the sake of simplicity, Figure 7Only some of the components of the electronic device 700 relevant to this application are shown in this illustration; components such as buses, input / output interfaces, etc., are omitted. In addition, the electronic device 700 may include any other suitable components depending on the specific application.

[0115] In addition to the methods and devices described above, embodiments of this application may also be computer program products, which include computer program instructions that, when executed by a processor, cause the processor to perform the steps in the fault handling method for the modular motherboard expansion interface according to various embodiments of this application described in the "Exemplary Methods" section of this specification.

[0116] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0117] Furthermore, embodiments of this application may also be computer-readable storage media storing computer program instructions thereon, which, when executed by a processor, cause the processor to perform the steps in the fault handling method for the modular motherboard expansion interface according to various embodiments of this application described in the "Exemplary Methods" section above.

[0118] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

[0119] The basic principles of this application have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this application are merely examples and not limitations, and should not be considered as essential features of each embodiment of this application. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the application to the necessity of employing the aforementioned specific details for implementation.

[0120] The block diagrams of devices, apparatuses, devices, and systems involved in this application are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0121] It should also be noted that in the apparatus, equipment, and methods of this application, the components or steps can be disassembled and / or recombined. These disassemblies and / or recombinations should be considered as equivalent solutions of this application.

[0122] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this application. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other aspects without departing from the scope of this application. Therefore, this application is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features of the invention herein.

[0123] The above description has been given for illustrative and descriptive purposes. Furthermore, this description is not intended to limit the embodiments of this application to the forms of the invention herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations thereof.

Claims

1. A fault handling method for a modular motherboard expansion interface, characterized in that, include: Collect monitoring parameters from the expansion modules connected to the expansion interface; When a fault is detected in the expansion module based on the monitoring parameters, the power supply to the faulty module is cut off. Based on the fault information of the faulty module, the operation of releasing the hardware resources occupied by the faulty module is triggered; Calculate the availability score for each health module, which is used to characterize the ability and adaptability of the health module to take over the business tasks of the faulty module; Based on the availability score of each health module, the business tasks of the faulty module are migrated to the target health module to complete the fault handling.

2. The fault handling method according to claim 1, characterized in that, When the expansion module is determined to be faulty based on the monitoring parameters, the power supply to the faulty module is cut off, including: The monitoring parameters are filtered to obtain the filtered monitoring parameters; The filtered monitoring parameters are standardized according to a preset formula to obtain standardized monitoring parameters; Based on the standardized monitoring parameters, multi-level fault determination is performed; After confirming that the faulty module remains in a faulty state within the preset time period, the power supply to the faulty module is cut off.

3. The fault handling method according to claim 2, characterized in that, The standardized monitoring parameters include standardized voltage deviation rate, standardized current load rate, and standardized temperature margin. Based on these standardized monitoring parameters, multi-level fault determination is performed, including: Based on the standardized voltage deviation rate, the standardized current load rate, the standardized temperature margin, and the weight values ​​corresponding to each parameter, a fault score is calculated. When any of the parameters of the standardized voltage deviation rate, the standardized current load rate, and the standardized temperature margin falls within the warning threshold range, a first-level warning fault is triggered. When any of the parameters of the standardized voltage deviation rate, the standardized current load rate, and the standardized temperature margin exceeds the corresponding fault threshold, or when the fault score is greater than the secondary fault threshold, a secondary fault determination is triggered. When any of the standardized voltage deviation rate, the standardized current load rate, and the standardized temperature margin exceeds the corresponding severe over-limit threshold, or when the fault score is greater than the level 3 fault threshold, a level 3 severe fault determination is triggered.

4. The fault handling method according to any one of claims 1 to 3, characterized in that, The operation of triggering the release of hardware resources occupied by the faulty module based on the fault information of the faulty module includes: Based on the fault information of the faulty module, a fault event data packet is constructed; Based on the fault event data packet, query the resource allocation table to identify the physical address space, logical resources, and software resources occupied by the faulty module; Perform operations to release the physical address space, logical resources, and software resources occupied by the faulty module.

5. The fault handling method according to any one of claims 1 to 3, characterized in that, The calculation of the availability score for each health module includes: Based on the module function type, determine the functional compatibility coefficient of each health module; Based on the module performance specifications, determine the performance ratio between the healthy module and the faulty module; The availability score is calculated based on the functional compatibility coefficient, the performance ratio, and the current load rate of the health module.

6. The fault handling method according to any one of claims 1 to 3, characterized in that, The process of migrating the business tasks of the faulty module to the target healthy module based on the availability score of each healthy module includes: The target health modules are selected based on the availability score of each health module; Based on the importance and real-time information of the business tasks, a task migration priority mechanism is established; The migration order of the business tasks is determined using the task migration priority mechanism. According to the migration order of the business tasks, the business tasks are migrated to the target health module.

7. The fault handling method according to any one of claims 1 to 3, characterized in that, The monitoring parameters include voltage deviation rate, current load rate, and temperature margin. After migrating the service tasks of the faulty module to the target healthy module based on the availability score of each healthy module, the method further includes: Based on the system performance retention rate and load redistribution status, the voltage deviation rate, the current load rate, and the temperature margin are dynamically tightened, and the environmental interference on the monitoring parameters is calibrated through the environmental compensation coefficient. Based on module operation data and historical stress records, a health score is calculated for each extended module. Preventive maintenance instructions are generated according to maintenance priority, and faulty modules that fail to recover multiple times consecutively are marked as having a permanent fault status.

8. A fault handling system for a modular motherboard expansion interface, characterized in that, include: Motherboard management controller; At least two expansion interfaces, each expansion interface including a power monitoring unit and a controllable power switch circuit, wherein the power monitoring unit is used to collect monitoring parameters of the connected expansion module; the controllable power switch circuit is integrated in the main power supply circuit of the expansion module; The motherboard management controller is used to execute multi-level fault determination based on the monitoring parameters collected by the power monitoring unit, send isolation instructions to the controllable power switch circuit of the fault module to cut off the power supply path of the fault module, and report fault information to the operating system to receive the resource remapping feedback signal of the operating system based on the fault information of the fault module and release the hardware resources occupied by the fault module. Based on the calculated availability score of each health module, the business tasks of the faulty module are migrated to the target health module to complete the fault handling.

9. An electronic device, characterized in that, include: processor; as well as A memory that stores computer program instructions, which, when executed by a processor, cause the processor to perform the steps of the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, A computer-readable storage medium stores computer program instructions that, when executed by a processor, cause the processor to perform the steps of the method as described in any one of claims 1 to 7.

Images