Electric power system dynamic reconfigurable processor heterogeneous execution body scheduling method and system

Abstract

The invention provides a power system dynamic reconfigurable processor heterogeneous execution body scheduling method and system, and relates to the technical field of network communication and information security. Comprising the following steps: for a dynamic reconfigurable processor in a power system, scheduling each heterogeneous execution body in the dynamic reconfigurable processor to execute a target program and extracting behavior track characteristics in an execution process of each heterogeneous execution body; identifying potential abnormal executors on the basis of deviations between behavior track characteristics of the heterogeneous executors and behavior track characteristics of other heterogeneous executors; determining an abnormal executor based on the identification result of the potential abnormal executor and the execution result of each heterogeneous executor for the target program; and controlling the abnormal execution body to perform cleaning recovery operation until the abnormal execution body recovers to a normal state, and rescheduling the abnormal execution body in the normal state to participate in execution decision of the dynamic reconfigurable processor. The problem that safe and stable operation of an electric power system is affected due to high complexity of an existing electric power system mimicry defense processing process is solved.

Description

Technical Field

[0001] This invention relates to the fields of network communication and information security technology, specifically to a method and system for scheduling heterogeneous execution entities of dynamically reconfigurable processors in power systems. Background Technology

[0002] With the construction of new power systems, the power information system is continuously advancing open and interactive new business development across transmission, substation, distribution, and consumption sides, as well as infrastructure, safety monitoring, emergency response, and materials sectors. This has led to the widespread integration of more diverse entities into the power information system compared to traditional models, including distributed power sources, new energy storage, electric vehicles, and virtual power plants. Interactions among power generation, grid, load, and storage are becoming more frequent, the monitoring and control objects of the power information system are more complex, and the access methods are more open and diverse. This has also resulted in a sharp increase in the exposure surface of the power information system to attacks, and a greater reachability of unknown attacks. Existing passive defense mechanisms, which mainly rely on detection and analysis, suffer from defensive lag and poor ability to detect and defend against unknown attacks and vulnerabilities. While mimicry defense mechanisms offer better protection against unknown attacks and vulnerabilities, the simultaneous operation of multiple processors increases system complexity and significantly raises the probability of anomalies, further exacerbating the complexity of system processing and affecting the safe and stable operation of the power system. Summary of the Invention

[0003] To overcome the problem that the high complexity of the above-mentioned power system mimicry defense processing affects the safe and stable operation of the power system, this invention provides a method and system for scheduling heterogeneous execution entities of dynamically reconfigurable processors in power systems.

[0004] On one hand, the present invention provides a method for scheduling heterogeneous execution entities of dynamically reconfigurable processors in a power system, comprising: For a dynamically reconfigurable processor in a power system, schedule each heterogeneous executor within the dynamically reconfigurable processor to execute the target program and extract the behavioral trajectory features of each heterogeneous executor during the execution process; For each heterogeneous executor, potential abnormal executors are identified based on the deviation between the behavioral trajectory characteristics of the heterogeneous executor and the behavioral trajectory characteristics of other heterogeneous executors. Based on the identification results of potential abnormal executors and the execution results of each heterogeneous executor for the target program, abnormal executors are determined; The abnormal execution body is controlled to perform a cleaning and recovery operation until it returns to a normal state. The abnormal execution body in a normal state is then rescheduled to participate in the execution decision of the dynamically reconfigurable processor. Each heterogeneous executor has a different hardware architecture; the execution decision of the dynamically reconfigurable processor is determined based on the execution results of the participating heterogeneous executors; the other heterogeneous executors are those other than the heterogeneous executor mentioned above; the abnormal executor recovers to a normal state when the execution results of the abnormal executor are consistent with the decision result after the abnormal executor has been cleaned up for a specified number of consecutive times.

[0005] Optionally, the target program includes multiple subroutine segments, and the extraction of behavioral trajectory features of each heterogeneous executor during execution includes: Extract the behavioral trajectory features of each heterogeneous executor during the execution of each subroutine segment; The behavioral trajectory features include at least one of the following: execution time, cache hit rate, instruction reordering rate, branch prediction hit rate, and frequency of exception interruption.

[0006] Optionally, the step of identifying potential abnormal executors based on the deviation between the behavioral trajectory characteristics of the heterogeneous executor and the behavioral trajectory characteristics of other heterogeneous executors includes: Based on the similarity between the behavioral trajectory characteristics of the heterogeneous executor and the behavioral trajectory characteristics of other heterogeneous executors, the cumulative behavioral deviation of the heterogeneous executor is determined. If the cumulative behavioral deviation of the heterogeneous executor is greater than a preset threshold and occurs in all specified consecutive subroutine segment executions, the heterogeneous executor is determined to be a potential abnormal executor.

[0007] Optionally, based on the identification results of potential abnormal executors and the execution results of each heterogeneous executor for the target program, abnormal executors are determined, including: For each heterogeneous executor, an anomaly score for the heterogeneous executor is obtained by weighted fusion of the identification results of the potential abnormal executors corresponding to the heterogeneous executor and the execution results of the heterogeneous executor for each subroutine segment. If the anomaly score of the heterogeneous executor exceeds the anomaly threshold, the heterogeneous executor is determined to be an abnormal executor.

[0008] Optionally, before scheduling the execution of the target program by the heterogeneous execution entities within the dynamically reconfigurable processor, the method further includes: Based on the availability status of each heterogeneous execution entity within the dynamically reconfigurable processor, the scheduling strategy of the dynamically reconfigurable processor is determined; Based on the scheduling strategy, a decision list and a backup list are constructed for the dynamically reconfigurable processor; The decision list is used to record heterogeneous executors that participate in the execution of decisions, and the backup list is used to record heterogeneous executors that have executable programs but do not participate in the execution of decisions.

[0009] Optionally, based on the availability status of each heterogeneous execution entity within the dynamically reconfigurable processor, a scheduling strategy for the dynamically reconfigurable processor is determined, including: If all heterogeneous execution units within the dynamically reconfigurable processor are in an available state, the scheduling strategy is as follows: one heterogeneous execution unit acts as a backup execution unit to verify the execution result, and the other heterogeneous execution units, excluding the backup execution unit, act as decision-making execution units to make execution decisions. If at least one of the heterogeneous execution units in the dynamically reconfigurable processor is in an unavailable state, the scheduling strategy is as follows: at least one heterogeneous execution unit in an unavailable state performs a cleaning and recovery operation, one heterogeneous execution unit in an available state serves as a backup execution unit to verify the execution result, and the other heterogeneous execution units in an available state other than the backup execution unit serve as decision execution units to make execution decisions. If only one of the heterogeneous execution entities in the dynamically reconfigurable processor is in an available state, the scheduling strategy is as follows: the heterogeneous execution entity in the available state acts as the decision-making execution entity to make execution decisions, and the other heterogeneous execution entities other than the decision-making execution entity perform cleaning and recovery operations. If all heterogeneous execution entities within the dynamically reconfigurable processor are in an unavailable state, a scheduling strategy is formulated to perform cleaning and recovery operations on each heterogeneous execution entity without outputting execution results.

[0010] Optionally, controlling the abnormal executor to perform a cleanup and recovery operation until the abnormal executor returns to a normal state, and then rescheduling the abnormal executor in a normal state to participate in the execution decision of the dynamically reconfigurable processor, includes: Remove the abnormal executor from the decision list and control the abnormal executor to restart and reset; In response to the completion of the restart and reset of the abnormal executor, the abnormal executor is added to the standby list so that the abnormal executor executes subsequent subroutine segments without participating in the execution decision, until the execution result of the abnormal executor is consistent with the decision result for a specified number of consecutive times. Once it is determined that the abnormal executor has recovered to the normal state, the abnormal executor is moved to the decision list to participate in the execution decision.

[0011] Optionally, after scheduling the execution of the target program by the heterogeneous execution entities within the dynamically reconfigurable processor, the method further includes: In response to receiving a global state modification request containing the current execution result from each heterogeneous executor in the decision list within a preset time window, the corresponding global state value is determined and updated based on each current execution result using a majority voting method. Based on the updated global state value, a global state change notification is sent to each heterogeneous execution entity in the decision list and the backup list, so that the global state data of each heterogeneous execution entity in the decision list and the backup list can be synchronized.

[0012] Optionally, the target program includes multiple subroutine segments, and during the execution of the target program by each heterogeneous executor, it further includes: Save key status information during the execution of each subroutine segment and set corresponding rollback points; The cleaning and recovery operation includes: In response to the completion of the restart and reset of the abnormal executor, the running state of the abnormal executor is rolled back to the key state information corresponding to the rollback point closest to the restart and reset time.

[0013] On the other hand, the present invention also provides a system for scheduling heterogeneous execution entities of dynamically reconfigurable processors in a power system, comprising: The scheduling and execution module, for a dynamically reconfigurable processor in the power system, schedules each heterogeneous executor within the dynamically reconfigurable processor to execute the target program and extracts the behavioral trajectory features of each heterogeneous executor during the execution process; The potential anomaly identification module identifies potential anomalies for each heterogeneous executor based on the deviation between the behavioral trajectory characteristics of the heterogeneous executor and the behavioral trajectory characteristics of other heterogeneous executors. The exception determination module determines the abnormal executor based on the identification results of potential abnormal executors and the execution results of each heterogeneous executor for the target program; An exception recovery module controls the exception execution body to perform a cleaning and recovery operation until the exception execution body returns to a normal state, and then reschedules the exception execution body in the normal state to participate in the execution decision of the dynamic reconfigurable processor. Each heterogeneous executor has a different hardware architecture; the execution decision of the dynamically reconfigurable processor is determined based on the execution results of the participating heterogeneous executors; the other heterogeneous executors are those other than the heterogeneous executor mentioned above; the abnormal executor recovers to a normal state when the execution results of the abnormal executor are consistent with the decision result after the abnormal executor has been cleaned up for a specified number of consecutive times.

[0014] Optionally, the target program includes multiple subroutine segments, and the scheduling execution module includes an extraction submodule, which is used for: Extract the behavioral trajectory features of each heterogeneous executor during the execution of each subroutine segment; The behavioral trajectory features include at least one of the following: execution time, cache hit rate, instruction reordering rate, branch prediction hit rate, and frequency of exception interruption.

[0015] Optionally, the potential anomaly identification module includes: The deviation calculation submodule is used to determine the cumulative behavioral deviation of the heterogeneous executor based on the similarity between the behavioral trajectory features of the heterogeneous executor and the behavioral trajectory features of other heterogeneous executors; The potential anomaly determination submodule is used to determine the heterogeneous executor as a potential anomaly executor if the cumulative behavioral deviation of the heterogeneous executor is greater than a preset threshold and occurs in the execution of a specified number of consecutive subroutine segments.

[0016] Optionally, the anomaly determination module is specifically used for: For each heterogeneous executor, an anomaly score for the heterogeneous executor is obtained by weighted fusion of the identification results of the potential abnormal executors corresponding to the heterogeneous executor and the execution results of the heterogeneous executor for each subroutine segment. If the anomaly score of the heterogeneous executor exceeds the anomaly threshold, the heterogeneous executor is determined to be an abnormal executor.

[0017] Optionally, it also includes: The strategy formulation module is used to determine the scheduling strategy of the dynamic reconfigurable processor based on the availability status of each heterogeneous execution entity within the dynamic reconfigurable processor. A list construction module is used to construct a decision list and a backup list for the dynamically reconfigurable processor based on the scheduling policy. The decision list is used to record heterogeneous executors that participate in the execution of decisions, and the backup list is used to record heterogeneous executors that have executable programs but do not participate in the execution of decisions.

[0018] Optionally, the strategy formulation module includes: The first strategy formulation submodule is used to formulate a scheduling strategy if all heterogeneous execution units in the dynamically reconfigurable processor are in an available state: one of the heterogeneous execution units is used as a backup execution unit to verify the execution result, and the other heterogeneous execution units other than the backup execution unit are used as decision execution units to make execution decisions. The second strategy formulation submodule is used to formulate a scheduling strategy if at least one of the heterogeneous execution entities in the dynamically reconfigurable processor is in an unavailable state: at least one heterogeneous execution entity in an unavailable state performs a cleaning and recovery operation, one heterogeneous execution entity in an available state serves as a backup execution entity to verify the execution result, and the other heterogeneous execution entities in an available state other than the backup execution entity serve as decision execution entities to make execution decisions. The third strategy formulation submodule is used to formulate a scheduling strategy if only one of the heterogeneous executors in the dynamically reconfigurable processor is in an available state: the heterogeneous executor in the available state acts as the decision executor to make execution decisions, and the other heterogeneous executors other than the decision executor perform cleaning and recovery operations; if all heterogeneous executors in the dynamically reconfigurable processor are in an unavailable state, the scheduling strategy is to formulate a scheduling strategy in which each heterogeneous executor performs cleaning and recovery operations and does not output execution results.

[0019] Optionally, the anomaly recovery module includes: The cleaning submodule is used to remove the abnormal execution body from the decision list and control the abnormal execution body to restart and reset. The recovery submodule is used to add the abnormal executor to the standby list in response to the completion of the restart and reset of the abnormal executor, so that the abnormal executor executes subsequent subroutine segments and does not participate in the execution decision, until the execution result of the abnormal executor is consistent with the decision result for a specified number of consecutive times, it is determined that the abnormal executor has recovered to the normal state, and the abnormal executor is moved to the decision list to participate in the execution decision.

[0020] Optionally, it also includes: The state update module is used to respond to the global state modification request sent by each heterogeneous executor in the decision list within a preset time window, which includes its current execution result. Based on each current execution result, the module determines and updates the corresponding global state value using a majority voting method. The state synchronization module is used to send global state change notifications to each heterogeneous execution entity in the decision list and the backup list based on the updated global state value, so as to synchronize the global state data of each heterogeneous execution entity in the decision list and the backup list.

[0021] Optionally, the target program includes multiple subroutine segments, and the scheduling execution module includes an execution submodule, which is used for: Save key status information during the execution of each subroutine segment and set corresponding rollback points; The anomaly recovery module includes: The rollback submodule is used to roll back the running state of the abnormal executor to the key state information corresponding to the rollback point closest to the restart and reset time in response to the completion of the restart and reset of the abnormal executor.

[0022] On the other hand, the present invention also provides an electronic device, comprising: at least one processor and a memory; the memory and the processor are connected via a bus; The memory is used to store one or more programs; When the one or more programs are executed by the at least one processor, the method described in any of the foregoing is implemented.

[0023] On the other hand, the present invention also provides a readable storage medium having an executable program stored thereon, wherein when the executable program is executed, it implements the method described in any one of the above.

[0024] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention provides a method and system for scheduling heterogeneous executors of a dynamically reconfigurable processor in a power system. The method extracts the behavioral trajectory features of each heterogeneous executor during execution; identifies potential abnormal executors based on the deviation between the behavioral trajectory features of the heterogeneous executors and those of other heterogeneous executors; then, based on the identification results of potential abnormal executors and the execution results of each heterogeneous executor for the target program, determines the abnormal executor. By adding behavioral trajectory features for potential anomaly identification and combining this with execution result adjudication, potentially vulnerable abnormal executors can be identified more accurately. This reduces false positives and lowers the processing complexity of the dynamically reconfigurable processor within the system. Simultaneously, by improving anomaly identification accuracy, the system's security defense capabilities are enhanced.

[0025] This invention controls the abnormal executor to perform a cleaning and recovery operation. If the execution result of the abnormal executor is consistent with the adjudication result after the abnormal executor has been cleaned for a specified number of consecutive times, it is determined that the abnormal executor has recovered to a normal state and is added back to the execution adjudication. This cleaning and recovery method ensures the execution stability of the executors participating in the adjudication, thereby reducing the frequency of changes in the adjudication executor, reducing the system complexity from the adjudication perspective, thereby achieving lightweight scheduling and improving the stability of the power system. Attached Figure Description

[0026] Figure 1 This is a flowchart illustrating a method for scheduling heterogeneous execution entities of a dynamically reconfigurable processor in a power system according to the present invention. Figure 2 This is a schematic diagram illustrating the operating states of heterogeneous CPU cores under different working conditions of a dynamically reconfigurable processor, as an example of the present invention. Figure 3 This is a schematic diagram of a two-step cleaning and recovery process according to an example of the present invention; Figure 4 This is a schematic diagram illustrating the global state data modification process of various heterogeneous execution entities, as an example of the present invention. Figure 5 This is a schematic diagram illustrating the scheduling, execution, cleaning, and recovery process of heterogeneous execution entities in a dynamically reconfigurable processor, as an example of the present invention. Figure 6 This is a block diagram of an electronic device according to the present invention. Detailed Implementation

[0027] Introduction to basic concepts: DHR architecture refers to a "dynamic, heterogeneous, and redundant" architecture, a computer hardware and software design architecture based on mimicry defense theory. Its core idea is to introduce a robust control mechanism based on multi-modal decision-making and multi-dimensional dynamic reconfiguration, while ensuring the intrinsic function set remains unchanged. This endows the operating environment with dynamically reconfigurable, software-definable, and algorithmically reconfigurable functional attributes, thereby creating an "uncertainty" effect from the attacker's perspective. This makes the target operating scenario possess iterative convergence dynamism, randomness, and diversity in suppressing generalized uncertain disturbances. The significance of this architecture lies in applying the axiom of "relative correctness" to the field of reliability engineering, thereby ensuring the system's proactive perception and defense capabilities against unknown attacks and threats.

[0028] The specific embodiments of the present invention will be further described in detail below with reference to the accompanying drawings.

[0029] Example 1 This invention provides a method for scheduling heterogeneous execution entities of dynamically reconfigurable processors in a power system, as illustrated in the schematic diagram below. Figure 1 As shown, the method includes: Step S110: For a dynamically reconfigurable processor in the power system, schedule each heterogeneous executor in the dynamically reconfigurable processor to execute the target program and extract the behavioral trajectory features of each heterogeneous executor during the execution process; Step S120: For each heterogeneous executor, potential abnormal executors are identified based on the deviation between the behavioral trajectory characteristics of the heterogeneous executor and the behavioral trajectory characteristics of other heterogeneous executors. Step S130: Based on the identification results of potential abnormal executors and the execution results of each heterogeneous executor for the target program, determine the abnormal executor; Step S140: Control the abnormal execution body to perform a cleaning and recovery operation until the abnormal execution body returns to the normal state, and reschedule the abnormal execution body in the normal state to participate in the execution decision of the dynamic reconfigurable processor; Each heterogeneous executor has a different hardware architecture; the execution decision of the dynamically reconfigurable processor is determined based on the execution results of the participating heterogeneous executors; the other heterogeneous executors are those other than the heterogeneous executor mentioned above; the abnormal executor recovers to a normal state when the execution results of the abnormal executor are consistent with the decision result after the abnormal executor has been cleaned up for a specified number of consecutive times.

[0030] In this example implementation, the dynamically reconfigurable processor (DHR) can be a computing chip within various devices participating in information communication within a power system / power information system. The DHR is configured with executors of different hardware architectures. For example, the DHR includes multiple CPU cores of different architectures, such as x86 and ARM. DHR suppresses the spread of unknown threats such as viruses and Trojans by dynamically adjusting the system structure (e.g., executor migration, configuration changes). This method can be applied to the central processing unit of power equipment based on dynamically reconfigurable technology. When an anomaly is detected, the system automatically triggers a reconfiguration process to eliminate the threat by changing the operating environment, adjusting the adjudication algorithm, or replacing the executor. However, frequent reconfiguration processes increase system complexity; therefore, this invention designs a lightweight operating process. The target program can be an application within the power system. Different architecture CPU cores (heterogeneous executors) within the DHR execute this application, and behavioral trajectory features during execution are extracted. These behavioral trajectory features include, but are not limited to, execution time, cache hit rate, instruction reordering rate, branch prediction hit rate, and anomalies. Interrupt trigger frequency, etc. For each heterogeneous executor, the deviation of the current CPU's behavior trajectory from other CPUs is calculated, and potential abnormal CPUs are identified based on this deviation value. In this example, the execution entity can be a scheduler. The scheduler compares the execution results of each CPU core and then determines the final output result through majority voting. Executors with execution results inconsistent with the output result can be identified as candidate abnormal executors. The final abnormal CPU is determined through potential abnormal CPUs and candidate abnormal CPUs. For example, if CPUA is both a potential abnormal CPU and a candidate abnormal CPU, then it is an abnormal CPU; if CPUA is a potential abnormal CPU but not a candidate abnormal CPU, a comprehensive evaluation is required, such as using expert scoring to determine the final abnormal score. After identifying the abnormal heterogeneous execution, a decision instruction is output on the one hand, and a cleanup and recovery process is performed on the abnormal CPU core on the other hand. When the execution result is consistent with the decision result (correct execution result) for a specified number of consecutive times after the abnormal executor has been cleaned, it is then added back to the mimicry decision combination. This ensures the stability of the mimicry decision combination, thereby reducing the complexity of the execution process.

[0031] In some example implementations, the target program includes multiple subroutine segments, and the step of S110, extracting the behavioral trajectory features of each heterogeneous executor during execution, includes: Extract the behavioral trajectory features of each heterogeneous executor during the execution of each subroutine segment; The behavioral trajectory features include at least one of the following: execution time, cache hit rate, instruction reordering rate, branch prediction hit rate, and frequency of exception interruption.

[0032] In this example implementation, after the target program is read into memory, it can be divided into subroutine segments as needed, dividing the entire application into multiple subroutine segments with controllable granularity. The system will execute each subroutine segment sequentially according to the program order. During the execution of each subroutine segment, the micro-operational characteristics of each heterogeneous CPU are sampled. The behavioral trajectory characteristics include at least one of the following: execution time, cache hit rate, instruction reordering rate / out-of-order execution rate, branch prediction hit rate, and exception interrupt trigger frequency. The behavioral trajectory feature vector of the j-th CPU within this program segment is obtained through behavioral feature acquisition as follows:

[0033] in, Let be the feature vector of the behavioral trajectory of the j-th CPU within the i-th subroutine segment. Let be the execution time of the j-th CPU within the i-th subroutine segment. Let $\frac{i}{j}$ be the cache hit rate of the $j$ CPU within the $i$-th subroutine segment. Let be the instruction reordering rate of the j-th CPU within the i-th subroutine segment. Let the branch prediction hit rate be the value of the i-th subroutine segment for the j-th CPU. This represents the frequency of exception interrupts triggered by the j-th CPU within the i-th subroutine segment.

[0034] Furthermore, the step S120 of identifying potential abnormal executors based on the deviation between the behavioral trajectory characteristics of the heterogeneous executor and the behavioral trajectory characteristics of other heterogeneous executors includes: Based on the similarity between the behavioral trajectory characteristics of the heterogeneous executor and the behavioral trajectory characteristics of other heterogeneous executors, the cumulative behavioral deviation of the heterogeneous executor is determined. If the cumulative behavioral deviation of the heterogeneous executor is greater than a preset threshold and occurs in all specified consecutive subroutine segment executions, the heterogeneous executor is determined to be a potential abnormal executor.

[0035] In this example implementation, methods such as cosine similarity or Euclidean distance, dynamic time warping (DTW), and KL divergence can be used to evaluate trajectory consistency. Specifically, cosine similarity or Euclidean distance is used to calculate the similarity between the behavioral trajectory features of two actors. For example, cosine similarity can be used for measurement:

[0036] in, For the first Behavioral trajectory feature vectors of heterogeneous executors With the Behavioral trajectory feature vectors of heterogeneous executors Similarity between them To find the norm.

[0037] Alternatively, the weighted Euclidean distance form can be used:

[0038] in, for and Euclidean distance, For the first The feature weights of heterogeneous executors can be set through experience or learning.

[0039] Based on similarity, an anomaly scoring function is defined to assist in determining whether a CPU behaves abnormally. The cumulative behavioral deviation or behavioral deviation of the j-th CPU is defined as follows:

[0040] in, Let N be the cumulative behavior deviation / behavior deviation degree of the j-th CPU, and N be the number of heterogeneous execution entities. , If a certain threshold is preset for the system, and the occurrence of a certain number of consecutive occurrences reaches a specified number, the system determines that the CPU is behaving abnormally and marks it as a potentially abnormal executor. This example uses an auxiliary anomaly detection method based on behavioral trajectory features as a supplementary judgment basis to the traditional output comparison mechanism, improving the system's sensitivity and accuracy in detecting anomalies in heterogeneous executors.

[0041] In some example implementations, S130 determines the abnormal executor based on the identification results of potential abnormal executors and the execution results of each heterogeneous executor for the target program, including: For each heterogeneous executor, an anomaly score for the heterogeneous executor is obtained by weighted fusion of the identification results of the potential abnormal executors corresponding to the heterogeneous executor and the execution results of the heterogeneous executor for each subroutine segment. If the anomaly score of the heterogeneous executor exceeds the anomaly threshold, the heterogeneous executor is determined to be an abnormal executor.

[0042] In this example implementation, abnormal behavior is not directly equivalent to functional abnormality. To reduce false positives, this invention combines an output adjudication mechanism and potential anomaly identification results for joint anomaly judgment. For example, the following joint anomaly judgment function is used to determine the abnormal execution body:

[0043] in, Let j be the anomaly score for the j-th CPU. These are the joint judgment weights for output anomaly events and trajectory anomaly events, respectively; This is an indicator function that outputs an exception event. If the exception event is true (the execution result of the j-th CPU is abnormal), then... Otherwise, it is 0; This is an indicator function for trajectory anomaly events, if the trajectory anomaly event is true (the j-th CPU is a potential exception execution body). Otherwise, it is 0. When hour, The CPU is officially marked as abnormal once the anomaly threshold is reached. This example improves the accuracy of anomaly identification through joint judgment.

[0044] In some implementations, before scheduling the heterogeneous execution entities within the dynamically reconfigurable processor to execute the target program, the method further includes: Based on the availability status of each heterogeneous execution entity within the dynamically reconfigurable processor, the scheduling strategy of the dynamically reconfigurable processor is determined; Based on the scheduling policy, a decision list and a backup list are constructed for the dynamically reconfigurable processor.

[0045] In this example implementation, based on the number of CPU cores available for operation (i.e., CPU cores in an available state or the number of available CPUs) within the dynamically reconfigurable processor, for example, some heterogeneous CPU cores may fail due to malfunctions and cannot be restored through reboot, the operating modes of the dynamically reconfigurable processor can be divided into Level A, Level B, and Level C operating modes. Since the number of CPU cores requiring scheduling and cleanup / recovery differs under different operating modes, and to ensure the stability and security of the entire system, different scheduling strategies are adopted for each operating mode. Therefore, different scheduling strategies can be used for different operating modes. The scheduler maintains two sets of processor lists: a decision list, which records heterogeneous executors participating in the execution of decisions, i.e., processors currently running normally and participating in decision / result comparison; and a backup list, which records heterogeneous executors that can execute programs but do not participate in the execution of decisions, i.e., processors that are not yet participating in result comparison but can accept tasks. The scheduler sends the same input data to the processors in the backup list and receives their execution results, but does not use these execution results for decision-making.

[0046] For example, determining the scheduling strategy of the dynamically reconfigurable processor based on the availability status of each heterogeneous execution entity within the processor includes: If all heterogeneous execution units within the dynamically reconfigurable processor are in an available state, the scheduling strategy is as follows: one heterogeneous execution unit acts as a backup execution unit to verify the execution result, and the other heterogeneous execution units, excluding the backup execution unit, act as decision-making execution units to make execution decisions. If at least one of the heterogeneous execution units in the dynamically reconfigurable processor is in an unavailable state, the scheduling strategy is as follows: at least one heterogeneous execution unit in an unavailable state performs a cleaning and recovery operation, one heterogeneous execution unit in an available state serves as a backup execution unit to verify the execution result, and the other heterogeneous execution units in an available state other than the backup execution unit serve as decision execution units to make execution decisions. If only one of the heterogeneous execution entities in the dynamically reconfigurable processor is in an available state, the scheduling strategy is as follows: the heterogeneous execution entity in the available state acts as the decision-making execution entity to make execution decisions, and the other heterogeneous execution entities other than the decision-making execution entity perform cleaning and recovery operations. If all heterogeneous execution entities within the dynamically reconfigurable processor are in an unavailable state, a scheduling strategy is formulated to perform cleaning and recovery operations on each heterogeneous execution entity without outputting execution results.

[0047] In this example implementation, if all heterogeneous execution units within the dynamically reconfigurable processor are in an available state, the dynamically reconfigurable processor is determined to be in Level A operating mode. The scheduling strategy is as follows: one heterogeneous execution unit acts as a backup execution unit to verify the execution result, while the other heterogeneous execution units besides the backup execution unit act as decision-making execution units to make execution decisions. Figure 2 In the Class A operating state, after system power-on initialization, the system is in Class A operating state, where all three heterogeneous CPUs are running normally. The scheduler decides the calculation results of two of the CPUs to produce a unique output result, while simultaneously using the calculation result of the third heterogeneous CPU (as a backup) to verify the output. When the calculation result of the backup CPU matches the decision result, the backup CPU remains in backup state and does not participate in output decision-making. If at least one of the heterogeneous executors in the dynamically reconfigurable processor is in an unavailable state (e.g., an abnormal state), corresponding to Class B operating mode, the scheduling strategy is to perform a cleaning and recovery operation on at least one heterogeneous executor in an unavailable state, one heterogeneous executor in an available state acts as a backup executor to verify the execution result, and the other heterogeneous executors in an available state act as decision executors to make execution decisions. Figure 2The system is divided into Level A recovery state and Level B operating state. In Level A recovery state, one heterogeneous CPU is performing a cleanup and recovery operation, while the other two heterogeneous CPUs are operating normally and participating in output decision-making. In Level B operating state, one heterogeneous CPU participates in output decision-making, another heterogeneous CPU is in backup state, and another heterogeneous CPU is performing a cleanup and recovery operation. If only one of the heterogeneous executors in the dynamically reconfigurable processor is in an available state, corresponding to Level C operating mode, the scheduling strategy is that the heterogeneous executor in the available state acts as the decision-making executor to make execution decisions, while the other heterogeneous executors perform cleanup and recovery operations, such as... Figure 2 The system is divided into Level B recovery state and Level C operating state. Level B recovery state indicates that only one heterogeneous CPU is still participating in output decision-making, while the other two heterogeneous CPUs are performing cleaning and recovery operations. Level C operating state indicates that only one heterogeneous CPU in backup state is working normally and outputting results, while the other two heterogeneous CPUs are in the cleaning and recovery process. If all heterogeneous execution units within the dynamically reconfigurable processor are in an unavailable state, corresponding to Level C operating mode, the scheduling strategy is for each heterogeneous execution unit to perform cleaning and recovery operations without outputting execution results. Figure 2 The C-level recovery state indicates that the system is currently deemed unsafe, and the correctness of any computational results cannot be verified; therefore, no further results are output. In the C-level recovery state, the system needs to determine subsequent operations based on the state verification results of the three CPUs undergoing the cleaning process.

[0048] For example, taking a mimicry CPU with 4 CPU cores as an example, the scheduling strategies under different states are illustrated below: For Level A operation: After power-on initialization, the system is in Level A operation, where all four heterogeneous CPUs are running normally. The scheduler uses a majority vote to determine the output result from three of the CPUs, while simultaneously verifying the output using the output result from the remaining heterogeneous CPU (as a backup). When the backup CPU's output result matches the decision result, the backup CPU remains in backup mode and does not participate in the output decision.

[0049] (1) If the calculation result of the backup heterogeneous CPU is inconsistent with the decision result for M consecutive times, where M is a preset threshold, then the backup CPU is cleaned and restored, and the system enters the A-level recovery state.

[0050] (2) If the calculation result of one heterogeneous CPU participating in the judgment is inconsistent with the other two heterogeneous CPUs for M consecutive times, and the calculation result of the backup heterogeneous CPU is consistent with the judgment result, then the abnormal heterogeneous CPU is cleaned and restored, and the system is switched to the B-level running state.

[0051] (3) If the calculation result of one heterogeneous CPU participating in the judgment is inconsistent with the other two heterogeneous CPUs for M consecutive times, and the calculation result of the backup heterogeneous CPU is also inconsistent with the judgment result, then the abnormal heterogeneous CPU and the backup heterogeneous CPU are cleaned and restored at the same time, and the system enters the B-level recovery state.

[0052] (4) If the calculation results of the three heterogeneous CPUs participating in the decision are inconsistent with each other for M consecutive times, and the calculation result of the backup heterogeneous CPU is consistent with the result of one of the heterogeneous CPUs, then the other two heterogeneous CPUs participating in the decision are cleaned and restored, and the system enters the C-level running state.

[0053] (5) If the calculation results of the three heterogeneous CPUs participating in the decision are inconsistent with each other for M consecutive times, and the calculation result of the backup heterogeneous CPU is inconsistent with the result of any heterogeneous CPU participating in the decision, then only one heterogeneous CPU is retained to continue working, and the other three heterogeneous CPUs are cleaned and restored, and the system enters the C-level recovery state.

[0054] For Level A recovery status: When the system is in Level A recovery status, it means that one heterogeneous CPU is performing a cleaning and recovery operation, while the other three heterogeneous CPUs are running normally and participating in the output decision.

[0055] (1) If the heterogeneous CPU state is successfully restored after cleaning and the three heterogeneous CPUs involved in the judgment have consistent output results, the restored heterogeneous CPU will be added back to the system as a backup and the system will return to the A-level running state.

[0056] (2) If, during the process of cleaning and restoring the heterogeneous CPU, the calculation result of one of the three heterogeneous CPUs involved in the judgment is inconsistent with the other two consecutive M times, then the cleaning and restoration of the abnormal CPU is performed and the system enters the B-level recovery state.

[0057] (3) If the calculation results of the three heterogeneous CPUs involved in the decision are inconsistent with each other for M consecutive times before the heterogeneous CPU has completed the cleaning and recovery process, then only one heterogeneous CPU will be retained to continue working, and the other two heterogeneous CPUs will be cleaned and recovered. The system will then enter the C-level recovery state.

[0058] For Level B operating status: Level B operating status means that there are two heterogeneous CPUs participating in the output decision, another heterogeneous CPU is in backup status, and a third heterogeneous CPU is performing a cleaning and recovery operation.

[0059] (1) If the heterogeneous CPU state is successfully restored after cleaning, it is added back to the decision combination and the system returns to the A-level operating state.

[0060] (2) If the CPU being cleaned and restored still fails to recover after M cleansing cycles, the CPU currently in backup state is added to the decision combination (participating in the output decision), the CPU being cleaned continues to be cleaned, and the system enters the A-level recovery state.

[0061] (3) If, during the CPU cleaning process, the output of the backup CPU is found to be inconsistent with the judgment output for M consecutive times, then the backup CPU will be cleaned and restored, and the system will enter the B-level recovery state.

[0062] (4) If, during the CPU cleaning process, the output results of the two CPUs involved in the judgment are inconsistent for M consecutive times, and the output result of the backup CPU is consistent with the result of one of the CPUs, then the CPU with the abnormal output is cleaned and restored, and the system enters the C-level running state.

[0063] (5) If, during the CPU cleaning process, the output results of the two CPUs involved in the judgment are inconsistent for M consecutive times, and the output result of the backup CPU is inconsistent with the results of the two CPUs, then only one CPU will be retained to continue working, and the remaining CPUs will be cleaned and restored, and the system will enter the C-level recovery state.

[0064] For Level B recovery status: Level B recovery status means that only one heterogeneous CPU in the system is still participating in the output decision, another heterogeneous CPU is in backup status, and the remaining two heterogeneous CPUs are performing cleaning and recovery operations.

[0065] (1) If a CPU in the cleaning and recovery process is completed, the CPU is added to the decision group and the system enters the A-level recovery state.

[0066] (2) If all CPUs in the cleaning and recovery process have completed the recovery, one CPU will be added to the decision combination and the other will be added to the system as a backup. The system will then enter the A-level operating state.

[0067] (3) If the only CPU involved in the decision-making process malfunctions (cannot provide consistent output results) during the cleaning process, the cleaning and recovery process is also performed on that CPU, and the system enters the C-level recovery state.

[0068] For Level C operating status: Level C operating status means that only one heterogeneous CPU is working normally and outputting results, two heterogeneous CPUs are in the cleaning and recovery process, and another heterogeneous CPU is in backup status but does not participate in the decision-making.

[0069] (1) If a CPU in the cleaning and recovery process completes state recovery, it is added to the decision combination and the system enters the B-level running state.

[0070] (2) If both CPUs in the cleaning and recovery process have completed the recovery, they are both added to the decision combination and the system returns to the A-level running state.

[0071] (3) If a CPU that is being cleaned and restored fails to be restored after multiple cleanings, the backup CPU will also be added to the decision group, and the system will enter the B-level recovery state.

[0072] (4) If the calculation results of the current CPU and the backup CPU in the decision combination are inconsistent, the backup CPU is cleaned and restored, and the system enters the C-level recovery state.

[0073] For Level C recovery status: Level C recovery status indicates that the current system is determined to be in an unsafe state, and the correctness of any calculation results cannot be confirmed; therefore, no results are output. In Level C recovery status, the system needs to determine subsequent operations based on the state comparison results between the three CPUs undergoing the cleaning process and the CPU currently participating in the decision-making process. (1) If any CPU that is being cleaned is found to be in the same state as the current judgment CPU, then the CPU is added to the judgment group, the other two CPUs continue to be cleaned and restored, and the system enters the B-level recovery state.

[0074] (2) If two CPUs in the cleaning process are found to be in the same state (and not in the same state as the current judgment CPU), these two CPUs are added to the judgment group, the other CPU continues to clean and recover, and the system enters the A-level recovery state.

[0075] (3) If it is found that the states of three CPUs are consistent, two of the CPUs are added to the decision group, and the other CPU is added to the system as a backup. The system then enters the A-level running state.

[0076] In the above scheduling strategy, when transferring a CPU from decision-making combination to the cleaning and recovery process, the aforementioned behavioral trajectory features can be used for auxiliary anomaly judgment. That is, the joint decision result and trajectory anomaly (potential anomaly) are used for anomaly judgment. After anomaly judgment, the normal decision CPU is transferred to the cleaning and recovery process. The scheduling strategy of this invention allows parallel cleaning and recovery operations to be performed on two or even three heterogeneous CPUs simultaneously when necessary, thereby accelerating the speed of system error correction and recovery. The system's operating state and specific transition conditions are considered to have reached the threshold when a certain type of anomaly occurs M times consecutively. This method can dynamically identify and respond to computational deviations and fault behaviors during the operation of heterogeneous CPUs. The system operating state is divided into six levels (Level A operation / recovery, Level B operation / recovery, Level C operation / recovery), and the credibility of the output results in each round is determined by a majority voting mechanism. When the output of a CPU is inconsistent with the majority result multiple times, or deviates continuously from the backup core, the cleaning mechanism is triggered by the joint judgment of behavioral trajectory. The system introduces trajectory behavior features to assist in judgment, and identifies potential anomalies by combining the dual standards of output consistency and execution behavior stability, forming a multi-dimensional, self-closing, lightweight scheduling and recovery mechanism with fault immunity.

[0077] In some example implementations, S140's control of the abnormal executor to perform a cleanup and recovery operation until the abnormal executor returns to a normal state, and the rescheduling of the abnormal executor in a normal state to participate in the execution decision of the dynamically reconfigurable processor, includes: Remove the abnormal executor from the decision list and control the abnormal executor to restart and reset; In response to the completion of the restart and reset of the abnormal executor, the abnormal executor is added to the standby list so that the abnormal executor executes subsequent subroutine segments without participating in the execution decision, until the execution result of the abnormal executor is consistent with the decision result for a specified number of consecutive times. Once it is determined that the abnormal executor has recovered to the normal state, the abnormal executor is moved to the decision list to participate in the execution decision.

[0078] In this example implementation, when a processor in the backup list outputs the correct result consecutively (i.e., the output result is consistent with the decision result) a specified number of times, the processor is determined to be behaving normally and is moved to the decision list. The specific cleaning and recovery process is as follows: Figure 3As shown, the process can be divided into two steps: Step 1: Cleaning Trigger and Restart. When the scheduler determines that a processor is abnormal, it sends a cleaning signal to the processor and removes it from the decision list. Upon receiving the cleaning signal, the processor immediately restarts and sends an availability signal to the scheduler after restarting. Upon receiving the availability signal, the scheduler adds the processor to the standby list. This completes the first step of the cleaning operation. Step 2: State Update and Verification. After adding the cleaned and recovered processor to the standby list, the scheduler sends a change notification to the processor whenever there is a global state change to ensure it updates its state synchronously. Simultaneously, the scheduler continues to send input data to the processor to perform calculations. When the processor's output is correct a specified number of times consecutively, the scheduler determines that the processor has recovered to a normal working state and adds it back to the decision list. This completes the entire cleaning and recovery process. This invention employs a two-step cleaning strategy based on global state data. The recovery process follows a continuous correctness judgment, ensuring that the processor's state is verified before being reinstated into the decision system, thus fully considering the security of the processor restart process.

[0079] In some implementations, after scheduling the heterogeneous execution entities within the dynamically reconfigurable processor to execute the target program, the method further includes: In response to receiving a global state modification request containing the current execution result from each heterogeneous executor in the decision list within a preset time window, the corresponding global state value is determined and updated based on each current execution result using a majority voting method. Based on the updated global state value, a global state change notification is sent to each heterogeneous execution entity in the decision list and the backup list, so that the global state data of each heterogeneous execution entity in the decision list and the backup list can be synchronized.

[0080] In this example implementation, after completing computations for the same application, the heterogeneous execution entities in the dynamically reconfigurable processor may need to modify the global state of that application. In this case, each heterogeneous execution entity will send a request to the scheduler to modify the global state. For example... Figure 4 As shown, within a preset time window, the scheduler receives global state modification requests from three processors (the request sent by processor 1 at time t1, processor 2 at time t2, and processor 3 at time t3). It compares the state values ​​submitted by each processor (majority voting), selecting, for example, the output value consistent between at least two of the three CPUs as the decision result. Then, at time t4, the majority vote result is written into the application's global state data. After the global state data update is complete, the scheduler sends a global state change notification to each processor at time t5. Upon receiving this notification, each processor, through a global state readback request process from time t6 to t9, uniformly reads back the new global state data at time t10 to complete the application state synchronization.

[0081] In some implementations, the target program includes multiple subroutine segments, and during the execution of the target program by each heterogeneous executor, it further includes: Save key status information during the execution of each subroutine segment and set corresponding rollback points; The cleaning and recovery operation includes: In response to the completion of the restart and reset of the abnormal executor, the running state of the abnormal executor is rolled back to the key state information corresponding to the rollback point closest to the restart and reset time.

[0082] In this exemplary embodiment, the present invention, combining the characteristics of heterogeneous executors' interrupt, reset, and storage systems with the software startup process, proposes a hardware-software collaborative cleaning and recovery method based on interrupt and context rollback strategies. During software execution, key context information (i.e., key state information of subroutine segments) is pre-saved, and rollback points are set to record the CPU state at critical runtime moments. When the scheduler determines that a heterogeneous executor has malfunctioned, the system terminates the malfunctioning CPU's operation via an interrupt and completes software cleanup of the CPU according to a preset exception reset logic. Then, the CPU's running state is rolled back to the nearest context save point. After the malfunctioning CPU synchronizes with the remaining heterogeneous executors' states, it is reinstated into the mimicry decision combination. Figure 5 As shown, the dynamically reconfigurable processor has three CPU cores (CPU A, B, and C). Two CPUs (such as CPU A and CPU B) are selected as the main decision cores, while CPU C is in a hot standby state, only intervening when other CPUs malfunction or the comparison fails. After the program to be executed is read into memory, it can be divided into multiple program segments P with controllable granularity as needed. 1， P2,…,P i P i+1 ..., where i is the program segment index, P i This is the i-th program segment; the system will execute them sequentially according to the program order. For program segment P1, CPU A, CPU B, and CPU C will output instruction Q after execution. a1 Q b1 Q c1 Each CPU stores the key context information D of its respective executed program segment P1. a1 D b1 D c1 By comparing Q a1 Q b1 The two match, and the comparison passes; then it is compared with Q. c1 Comparison passed. Execute program segments P2, ..., P according to the above process. i Until CPU B targets P i Output instruction Qbi If the comparison fails, CPU B enters the cleaning and recovery process, while the other two CPUs continue executing the subsequent program segment P. i+1 In the above process, the instructions come from the instruction set of each CPU. CPU B targets program segment P. i Key Context D bi Corresponding to the current program segment P i The previous code segment P i-1 And the next code segment P i+1 Key status information can include variable values ​​and instruction code units at the current execution time of the corresponding program segment, and can save register snapshots (rollback points) to record the values ​​in the current registers. The key to fault cleaning and recovery in a dynamically reconfigurable processor lies in the backup storage of key context information and the rollback strategy after fault recovery, which are closely related to the CPU subsystem's storage structure, kernel control, and software implementation. Experiments have verified that the context storage backup mechanism and the cleaning and recovery strategy after CPU failures in different operating modes can function stably. In the test environment, the scheduling CPU controls three heterogeneous CPU subsystems to automatically complete the saving of context data (the context processing strategy is configurable), and when the mimicry judgment detects an error in a CPU, it triggers a restart of that CPU in conjunction with auxiliary judgment. Test results show that when a single CPU fails, the scheduling CPU of the dynamically reconfigurable processor can issue an alarm signal in a timely manner, the faulty CPU is successfully cleaned and recovered, while the normal CPU continues to provide correct output results through a 2:1 majority vote, and the entire system ultimately achieves functional recovery under triple redundancy conditions. Based on triple redundancy, the method of this invention can also be based on a "five-mode redundancy" or "heterogeneous dual-mode + backup" architecture.

[0083] Current mimicry defense theories suffer from excessive complexity and limitations due to the inability of traditional Triple Modular Redundancy (TMR) for dynamic replacement and recovery (i.e., insufficient dynamic self-healing capability), lack of recognition of unknown attacks by traditional output adjudication, and high resource overhead and adaptability issues. This invention proposes a hardware-software co-processing cleansing mechanism based on context rollback (or periodically saving system snapshots using checkpointing technology for rapid rollback to a stable state after a failure), enabling rapid recovery and reintegration into the decision-making system after processor failure. An anomaly detection method based on CPU behavior trajectory characteristics, combined with multi-dimensional indicators such as execution time, cache hit rate, and branch prediction, enhances attack detection capabilities. By designing a lightweight scheduler and hierarchical scheduling strategy, redundancy overhead is reduced, improving the system's portability and real-time performance in power equipment.

[0084] This patent proposes a lightweight scheduling method for dynamically reconfigurable processors composed of heterogeneous multi-core CPUs based on mimicry defense theory. It aims to achieve high real-time, high-precision hardware-level detection of unknown attacks without prior knowledge in power information systems, as well as attack mitigation, isolation, and fault self-healing without business disruption or interruption. When inconsistent output results occur among the CPUs in a dynamically reconfigurable processor composed of CPUs with different architectures during operation, this strategy can adjudicate the output results of each heterogeneous CPU, thereby achieving scheduling based on the differences in heterogeneous CPU outputs.

[0085] This invention supports the cleaning, recovery, and re-addition of faulty CPUs through context backup and rollback mechanisms, enabling dynamic redundancy expansion of the system and improving overall availability. By introducing an anomaly detection method based on behavioral trajectory characteristics, it can identify potential attacks in advance when functional results are consistent but behavior is abnormal, thereby preventing the system from being maliciously controlled. By designing a three-level operating mode (Level A / Level B / Level C) based on a finite state machine, the scheduling strategy can be dynamically adjusted under different resource availability conditions, achieving hierarchical scheduling to improve efficiency and ensure the continuous operation of the power system.

[0086] This invention introduces a majority decision-making mechanism and a tiered fault cleaning and recovery strategy. When an abnormal CPU output is detected, the system can quickly isolate the faulty CPU and clean and restore it, allowing the remaining normal CPUs to still provide correct output results through majority voting. This is a scheduling method that maximizes the reliability of dynamically reconfigurable processor systems even when heterogeneous CPUs produce abnormal output results. It can further improve the fault tolerance and stability of power equipment under unknown attacks or processor failures while reducing the computational resources required by existing scheduling algorithms. While ensuring security, the lightweight scheduler design minimizes the impact on system performance, thus possessing high practical value and applicable to embedded power equipment in real-time operation scenarios of power information systems.

[0087] Example 2 Based on the same inventive concept, the present invention also provides a power system dynamic reconfigurable processor heterogeneous execution entity scheduling system, comprising: The scheduling and execution module, for a dynamically reconfigurable processor in the power system, schedules each heterogeneous executor within the dynamically reconfigurable processor to execute the target program and extracts the behavioral trajectory features of each heterogeneous executor during the execution process; The potential anomaly identification module identifies potential anomalies for each heterogeneous executor based on the deviation between the behavioral trajectory characteristics of the heterogeneous executor and the behavioral trajectory characteristics of other heterogeneous executors. The exception determination module determines the abnormal executor based on the identification results of potential abnormal executors and the execution results of each heterogeneous executor for the target program; An exception recovery module controls the exception execution body to perform a cleaning and recovery operation until the exception execution body returns to a normal state, and then reschedules the exception execution body in the normal state to participate in the execution decision of the dynamic reconfigurable processor. Each heterogeneous executor has a different hardware architecture; the execution decision of the dynamically reconfigurable processor is determined based on the execution results of the participating heterogeneous executors; the other heterogeneous executors are those other than the heterogeneous executor mentioned above; the abnormal executor recovers to a normal state when the execution results of the abnormal executor are consistent with the decision result after the abnormal executor has been cleaned up for a specified number of consecutive times.

[0088] In one possible implementation, the target program includes multiple subroutine segments, and the scheduling execution module includes an extraction submodule, which is used for: Extract the behavioral trajectory features of each heterogeneous executor during the execution of each subroutine segment; The behavioral trajectory features include at least one of the following: execution time, cache hit rate, instruction reordering rate, branch prediction hit rate, and frequency of exception interruption.

[0089] In one possible implementation, the potential anomaly detection module includes: The deviation calculation submodule is used to determine the cumulative behavioral deviation of the heterogeneous executor based on the similarity between the behavioral trajectory features of the heterogeneous executor and the behavioral trajectory features of other heterogeneous executors; The potential anomaly determination submodule is used to determine the heterogeneous executor as a potential anomaly executor if the cumulative behavioral deviation of the heterogeneous executor is greater than a preset threshold and occurs in the execution of a specified number of consecutive subroutine segments.

[0090] In one possible implementation, the anomaly determination module is specifically used for: For each heterogeneous executor, an anomaly score for the heterogeneous executor is obtained by weighted fusion of the identification results of the potential abnormal executors corresponding to the heterogeneous executor and the execution results of the heterogeneous executor for each subroutine segment. If the anomaly score of the heterogeneous executor exceeds the anomaly threshold, the heterogeneous executor is determined to be an abnormal executor.

[0091] In one possible implementation, it also includes: The strategy formulation module is used to determine the scheduling strategy of the dynamic reconfigurable processor based on the availability status of each heterogeneous execution entity within the dynamic reconfigurable processor. A list construction module is used to construct a decision list and a backup list for the dynamically reconfigurable processor based on the scheduling policy. The decision list is used to record heterogeneous executors that participate in the execution of decisions, and the backup list is used to record heterogeneous executors that have executable programs but do not participate in the execution of decisions.

[0092] In one possible implementation, the strategy formulation module includes: The first strategy formulation submodule is used to formulate a scheduling strategy if all heterogeneous execution units in the dynamically reconfigurable processor are in an available state: one of the heterogeneous execution units is used as a backup execution unit to verify the execution result, and the other heterogeneous execution units other than the backup execution unit are used as decision execution units to make execution decisions. The second strategy formulation submodule is used to formulate a scheduling strategy if at least one of the heterogeneous execution entities in the dynamically reconfigurable processor is in an unavailable state: at least one heterogeneous execution entity in an unavailable state performs a cleaning and recovery operation, one heterogeneous execution entity in an available state serves as a backup execution entity to verify the execution result, and the other heterogeneous execution entities in an available state other than the backup execution entity serve as decision execution entities to make execution decisions. The third strategy formulation submodule is used to formulate a scheduling strategy if only one of the heterogeneous executors in the dynamically reconfigurable processor is in an available state: the heterogeneous executor in the available state acts as the decision executor to make execution decisions, and the other heterogeneous executors other than the decision executor perform cleaning and recovery operations; if all heterogeneous executors in the dynamically reconfigurable processor are in an unavailable state, the scheduling strategy is to formulate a scheduling strategy in which each heterogeneous executor performs cleaning and recovery operations and does not output execution results.

[0093] In one possible implementation, the anomaly recovery module includes: The cleaning submodule is used to remove the abnormal execution body from the decision list and control the abnormal execution body to restart and reset. The recovery submodule is used to add the abnormal executor to the standby list in response to the completion of the restart and reset of the abnormal executor, so that the abnormal executor executes subsequent subroutine segments and does not participate in the execution decision, until the execution result of the abnormal executor is consistent with the decision result for a specified number of consecutive times, it is determined that the abnormal executor has recovered to the normal state, and the abnormal executor is moved to the decision list to participate in the execution decision.

[0094] In one possible implementation, it also includes: The state update module is used to respond to the global state modification request sent by each heterogeneous executor in the decision list within a preset time window, which includes its current execution result. Based on each current execution result, the module determines and updates the corresponding global state value using a majority voting method. The state synchronization module is used to send global state change notifications to each heterogeneous execution entity in the decision list and the backup list based on the updated global state value, so as to synchronize the global state data of each heterogeneous execution entity in the decision list and the backup list.

[0095] In one possible implementation, the target program includes multiple subroutine segments, and the scheduling execution module includes an execution submodule, which is used for: Save key status information during the execution of each subroutine segment and set corresponding rollback points; The anomaly recovery module includes: The rollback submodule is used to roll back the running state of the abnormal executor to the key state information corresponding to the rollback point closest to the restart and reset time in response to the completion of the restart and reset of the abnormal executor.

[0096] Example 3 like Figure 6 As shown, the present invention also provides an electronic device, which may be a computer device, a microcontroller device, a smart mobile device, etc. The electronic device in this embodiment may include a processor, a memory, a transceiver component, etc. The memory, processor, and transceiver component are connected via a bus; the memory can be used to store executable programs, and an exemplary executable program may include instructions; the processor is used to execute the instructions stored in the memory. The memory can also be used to store data, which can be accessed and / or modified when instructions are executed.

[0097] The processor may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. It is the computing core and control core of the terminal, and it is suitable for implementing one or more instructions. Specifically, it is suitable for loading and executing one or more instructions in the storage medium to realize the corresponding method flow or corresponding function, so as to realize the steps of the dynamic reconfigurable processor heterogeneous execution body scheduling method of the above embodiment.

[0098] Example 4 Based on the same inventive concept, this invention also provides a readable storage medium, specifically an electronic device readable storage medium (Memory). An electronic device readable storage medium is a memory device within an electronic device used to store programs and data. It is understood that the storage medium here can include both the built-in storage medium within the electronic device and extended storage media supported by the electronic device. The storage medium provides storage space, which stores the terminal's operating system. Furthermore, this storage space also stores one or more instructions suitable for loading and execution by a processor. These instructions can be one or more executable programs (including program code). It should be noted that the storage medium here can be high-speed RAM or non-volatile memory, such as at least one disk storage device. Loading and executing one or more instructions stored in the storage medium by the processor can implement the steps of the power system dynamic reconfigurable processor heterogeneous execution entity scheduling method in the above embodiments.

[0099] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0100] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0101] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0102] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0103] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit its scope of protection. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that after reading the present invention, they can still make various changes, modifications or equivalent substitutions to the specific implementation methods of the application, but these changes, modifications or equivalent substitutions are all within the scope of protection of the claims pending approval.

Claims

1. A method for scheduling heterogeneous execution entities of dynamically reconfigurable processors in a power system, characterized in that, include: For a dynamically reconfigurable processor in a power system, schedule each heterogeneous executor within the dynamically reconfigurable processor to execute the target program and extract the behavioral trajectory features of each heterogeneous executor during the execution process; For each heterogeneous executor, potential abnormal executors are identified based on the deviation between the behavioral trajectory characteristics of the heterogeneous executor and the behavioral trajectory characteristics of other heterogeneous executors. Based on the identification results of potential abnormal executors and the execution results of each heterogeneous executor for the target program, abnormal executors are determined; The abnormal execution body is controlled to perform a cleaning and recovery operation until it returns to a normal state. The abnormal execution body in a normal state is then rescheduled to participate in the execution decision of the dynamically reconfigurable processor. Each heterogeneous execution entity has a different hardware architecture; the execution decision of the dynamically reconfigurable processor is determined based on the execution results of the participating heterogeneous execution entities; the other heterogeneous execution entities are those other than the aforementioned heterogeneous execution entity. The abnormal executor is restored to a normal state when the execution result of the abnormal executor is consistent with the ruling result after the abnormal executor is cleaned up for a specified number of consecutive times.

2. The method according to claim 1, characterized in that, The target program includes multiple subroutine segments, and the extraction of behavioral trajectory features of each heterogeneous executor during execution includes: Extract the behavioral trajectory features of each heterogeneous executor during the execution of each subroutine segment; The behavioral trajectory features include at least one of the following: execution time, cache hit rate, instruction reordering rate, branch prediction hit rate, and frequency of exception interruption.

3. The method according to claim 2, characterized in that, The identification of potential abnormal executors based on the deviation between the behavioral trajectory features of the heterogeneous executor and the behavioral trajectory features of other heterogeneous executors includes: Based on the similarity between the behavioral trajectory characteristics of the heterogeneous executor and the behavioral trajectory characteristics of other heterogeneous executors, the cumulative behavioral deviation of the heterogeneous executor is determined. If the cumulative behavioral deviation of the heterogeneous executor is greater than a preset threshold and occurs in all specified consecutive subroutine segment executions, the heterogeneous executor is determined to be a potential abnormal executor.

4. The method according to claim 3, characterized in that, Based on the identification results of potential abnormal executors and the execution results of each heterogeneous executor for the target program, abnormal executors are determined, including: For each heterogeneous executor, an anomaly score for the heterogeneous executor is obtained by weighted fusion of the identification results of the potential abnormal executors corresponding to the heterogeneous executor and the execution results of the heterogeneous executor for each subroutine segment. If the anomaly score of the heterogeneous executor exceeds the anomaly threshold, the heterogeneous executor is determined to be an abnormal executor.

5. The method according to claim 1, characterized in that, Before scheduling the execution of the target program by the heterogeneous execution entities within the dynamically reconfigurable processor, the following steps are also included: Based on the availability status of each heterogeneous execution entity within the dynamically reconfigurable processor, the scheduling strategy of the dynamically reconfigurable processor is determined; Based on the scheduling strategy, a decision list and a backup list are constructed for the dynamically reconfigurable processor; The decision list is used to record heterogeneous executors that participate in the execution of decisions, and the backup list is used to record heterogeneous executors that have executable programs but do not participate in the execution of decisions.

6. The method according to claim 5, characterized in that, Based on the availability status of each heterogeneous execution entity within the dynamically reconfigurable processor, the scheduling strategy of the dynamically reconfigurable processor is determined, including: If all heterogeneous execution units within the dynamically reconfigurable processor are in an available state, the scheduling strategy is as follows: one heterogeneous execution unit acts as a backup execution unit to verify the execution result, and the other heterogeneous execution units, excluding the backup execution unit, act as decision-making execution units to make execution decisions. If at least one of the heterogeneous execution units in the dynamically reconfigurable processor is in an unavailable state, the scheduling strategy is as follows: at least one heterogeneous execution unit in an unavailable state performs a cleaning and recovery operation, one heterogeneous execution unit in an available state serves as a backup execution unit to verify the execution result, and the other heterogeneous execution units in an available state other than the backup execution unit serve as decision execution units to make execution decisions. If only one of the heterogeneous execution entities in the dynamically reconfigurable processor is in an available state, the scheduling strategy is as follows: the heterogeneous execution entity in the available state acts as the decision-making execution entity to make execution decisions, and the other heterogeneous execution entities other than the decision-making execution entity perform cleaning and recovery operations. If all heterogeneous execution entities within the dynamically reconfigurable processor are in an unavailable state, a scheduling strategy is formulated to perform cleaning and recovery operations on each heterogeneous execution entity without outputting execution results.

7. The method according to claim 5, characterized in that, The process of controlling the abnormal executor to perform a cleanup and recovery operation until the abnormal executor returns to a normal state, and then rescheduling the abnormal executor in the normal state to participate in the execution decision of the dynamically reconfigurable processor, includes: Remove the abnormal executor from the decision list and control the abnormal executor to restart and reset; In response to the completion of the restart and reset of the abnormal executor, the abnormal executor is added to the standby list so that the abnormal executor executes subsequent subroutine segments without participating in the execution decision, until the execution result of the abnormal executor is consistent with the decision result for a specified number of consecutive times. Once it is determined that the abnormal executor has recovered to the normal state, the abnormal executor is moved to the decision list to participate in the execution decision.

8. The method according to claim 5, characterized in that, After scheduling the execution of the target program by the heterogeneous execution entities within the dynamically reconfigurable processor, the process further includes: In response to receiving a global state modification request containing the current execution result from each heterogeneous executor in the decision list within a preset time window, the corresponding global state value is determined and updated based on each current execution result using a majority voting method. Based on the updated global state value, a global state change notification is sent to each heterogeneous execution entity in the decision list and the backup list, so that the global state data of each heterogeneous execution entity in the decision list and the backup list can be synchronized.

9. The method according to claim 1, characterized in that, The target program includes multiple subroutine segments, and during the execution of the target program in each heterogeneous executable, it also includes: Save key status information during the execution of each subroutine segment and set corresponding rollback points; The cleaning and recovery operation includes: In response to the completion of the restart and reset of the abnormal executor, the running state of the abnormal executor is rolled back to the key state information corresponding to the rollback point closest to the restart and reset time.

10. A dynamic reconfigurable processor heterogeneous execution unit scheduling system for power systems, characterized in that, include: The scheduling and execution module, for a dynamically reconfigurable processor in the power system, schedules each heterogeneous executor within the dynamically reconfigurable processor to execute the target program and extracts the behavioral trajectory features of each heterogeneous executor during the execution process; The potential anomaly identification module identifies potential anomalies for each heterogeneous executor based on the deviation between the behavioral trajectory characteristics of the heterogeneous executor and the behavioral trajectory characteristics of other heterogeneous executors. The exception determination module determines the abnormal executor based on the identification results of potential abnormal executors and the execution results of each heterogeneous executor for the target program; An exception recovery module controls the exception execution body to perform a cleaning and recovery operation until the exception execution body returns to a normal state, and then reschedules the exception execution body in the normal state to participate in the execution decision of the dynamic reconfigurable processor. Each heterogeneous execution entity has a different hardware architecture; the execution decision of the dynamically reconfigurable processor is determined based on the execution results of the participating heterogeneous execution entities; the other heterogeneous execution entities are those other than the aforementioned heterogeneous execution entity. The abnormal executor is restored to a normal state when the execution result of the abnormal executor is consistent with the ruling result after the abnormal executor is cleaned up for a specified number of consecutive times.

11. The system according to claim 10, characterized in that, The target program includes multiple subroutine segments, and the scheduling execution module includes an extraction submodule, which is used for: Extract the behavioral trajectory features of each heterogeneous executor during the execution of each subroutine segment; The behavioral trajectory features include at least one of the following: execution time, cache hit rate, instruction reordering rate, branch prediction hit rate, and frequency of exception interruption.

12. The system according to claim 11, characterized in that, The potential anomaly identification module includes: The deviation calculation submodule is used to determine the cumulative behavioral deviation of the heterogeneous executor based on the similarity between the behavioral trajectory features of the heterogeneous executor and the behavioral trajectory features of other heterogeneous executors; The potential anomaly determination submodule is used to determine the heterogeneous executor as a potential anomaly executor if the cumulative behavioral deviation of the heterogeneous executor is greater than a preset threshold and occurs in the execution of a specified number of consecutive subroutine segments.

13. The system according to claim 12, characterized in that, The anomaly determination module is specifically used for: For each heterogeneous executor, an anomaly score for the heterogeneous executor is obtained by weighted fusion of the identification results of the potential abnormal executors corresponding to the heterogeneous executor and the execution results of the heterogeneous executor for each subroutine segment. If the anomaly score of the heterogeneous executor exceeds the anomaly threshold, the heterogeneous executor is determined to be an abnormal executor.

14. The system according to claim 10, characterized in that, Also includes: The strategy formulation module is used to determine the scheduling strategy of the dynamic reconfigurable processor based on the availability status of each heterogeneous execution entity within the dynamic reconfigurable processor. A list construction module is used to construct a decision list and a backup list for the dynamically reconfigurable processor based on the scheduling policy. The decision list is used to record heterogeneous executors that participate in the execution of decisions, and the backup list is used to record heterogeneous executors that have executable programs but do not participate in the execution of decisions.

15. The system according to claim 14, characterized in that, The strategy formulation module includes: The first strategy formulation submodule is used to formulate a scheduling strategy if all heterogeneous execution units in the dynamically reconfigurable processor are in an available state: one of the heterogeneous execution units is used as a backup execution unit to verify the execution result, and the other heterogeneous execution units other than the backup execution unit are used as decision execution units to make execution decisions. The second strategy formulation submodule is used to formulate a scheduling strategy if at least one of the heterogeneous execution entities in the dynamically reconfigurable processor is in an unavailable state: at least one heterogeneous execution entity in an unavailable state performs a cleaning and recovery operation, one heterogeneous execution entity in an available state serves as a backup execution entity to verify the execution result, and the other heterogeneous execution entities in an available state other than the backup execution entity serve as decision execution entities to make execution decisions. The third strategy formulation submodule is used to formulate a scheduling strategy if only one of the heterogeneous executors in the dynamically reconfigurable processor is in an available state: the heterogeneous executor in the available state acts as the decision executor to make execution decisions, and the other heterogeneous executors other than the decision executor perform cleaning and recovery operations; if all heterogeneous executors in the dynamically reconfigurable processor are in an unavailable state, the scheduling strategy is to formulate a scheduling strategy in which each heterogeneous executor performs cleaning and recovery operations and does not output execution results.

16. The system according to claim 14, characterized in that, The anomaly recovery module includes: The cleaning submodule is used to remove the abnormal execution body from the decision list and control the abnormal execution body to restart and reset. The recovery submodule is used to add the abnormal executor to the standby list in response to the completion of the restart and reset of the abnormal executor, so that the abnormal executor executes subsequent subroutine segments and does not participate in the execution decision, until the execution result of the abnormal executor is consistent with the decision result for a specified number of consecutive times, it is determined that the abnormal executor has recovered to the normal state, and the abnormal executor is moved to the decision list to participate in the execution decision.

17. The system according to claim 14, characterized in that, Also includes: The state update module is used to respond to the global state modification request sent by each heterogeneous executor in the decision list within a preset time window, which includes its current execution result. Based on each current execution result, the module determines and updates the corresponding global state value using a majority voting method. The state synchronization module is used to send global state change notifications to each heterogeneous execution entity in the decision list and the backup list based on the updated global state value, so as to synchronize the global state data of each heterogeneous execution entity in the decision list and the backup list.

18. The system according to claim 10, characterized in that, The target program includes multiple subroutine segments, and the scheduling execution module includes an execution submodule, which is used for: Save key status information during the execution of each subroutine segment and set corresponding rollback points; The anomaly recovery module includes: The rollback submodule is used to roll back the running state of the abnormal executor to the key state information corresponding to the rollback point closest to the restart and reset time in response to the completion of the restart and reset of the abnormal executor.

19. An electronic device, characterized in that, include: At least one processor and memory; The memory and processor are connected via a bus; The memory is used to store one or more programs; When the one or more programs are executed by the at least one processor, the method as described in any one of claims 1 to 9 is implemented.

20. A readable storage medium, characterized in that, It contains an executable program, which, when executed, implements the method as described in any one of claims 1 to 9.

Images