A quasimodo defense method and device for power internet of things edge, electronic equipment and storage medium

Abstract

The application discloses a quasi-state defense method and device for an electric power Internet of Things edge, electronic equipment and a storage medium, and belongs to the technical field of Internet of Things security protection. The method comprises the following steps: copying current service data flow to generate the same number of data copies as the maximum number of parallel execution bodies; selecting the same number of execution bodies as the maximum number of parallel execution bodies as target execution bodies, so that each target execution body performs parallel data operation processing on the data copies to obtain corresponding output results; and comparing the output results of each target execution body in pairs. If the number of target execution bodies with consistent output results reaches a preset threshold, it is determined that the current service data flow is normal, otherwise, it is determined that the current service data flow is abnormal and an alarm is given. Therefore, by implementing the application, the problem that quasi-state defense relies on a hardware-level heterogeneous redundant architecture with high cost in the prior art can be solved.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) security protection technology, and in particular to a method, device, electronic device, and storage medium for mimicry defense at the edge of a power IoT network. Background Technology

[0002] With the rapid development of the power Internet of Things (IoT), hundreds of millions of smart meters, edge gateways, sensor terminals, and other edge devices have been deployed across various parts of the power grid, achieving deep collaboration between data acquisition, status monitoring, and intelligent control. However, these devices are typically exposed directly to relatively open physical or network environments, with extremely limited computing and storage resources, and generally employ homogeneous hardware and software architectures, making them vulnerable to cyberattacks. Cyberattacks against the power system, such as data tampering and malicious control command injection, can not only lead to localized power outages but also trigger chain reactions, threatening the safe and stable operation of the large power grid.

[0003] Mimicry defense, as an emerging intrinsic security technology, utilizes a core dynamic heterogeneous redundancy architecture. This architecture constructs functionally equivalent but heterogeneous execution pools, coupled with dynamic scheduling and multi-mode adjudication mechanisms, effectively addressing the uncertain threats posed by unknown vulnerabilities and backdoors. This fundamentally alters the unbalanced "easy to attack, difficult to defend" nature of cyberspace. However, classic mimicry defense relies on hardware-level heterogeneous redundancy architectures, which face high costs and integration difficulties in edge scenarios. To achieve true hardware heterogeneity, it requires deploying processors or dedicated hardware modules with different architectures. This significantly increases the material cost of individual devices and makes it difficult for devices to meet the stringent requirements of edge deployment in terms of size, power consumption, and heat dissipation, thus hindering its widespread adoption and application in large-scale, low-cost power IoT deployments. Summary of the Invention

[0004] This invention provides a method, device, electronic device, and storage medium for mimicry defense at the edge of the power Internet of Things, which can solve the problem that mimicry defense in the prior art relies on a costly hardware-level heterogeneous redundancy architecture.

[0005] To address the aforementioned technical problems, embodiments of the present invention provide a mimicry defense method for the edge of the power Internet of Things, comprising: Obtain the current business data stream of the power Internet of Things; Based on the preset maximum number of parallel execution bodies, the current business data stream is copied to generate the same number of data copies as the maximum number of parallel execution bodies; Select the same number of execution units as the maximum number of parallel execution units as target execution units, and send the generated data copies to the target execution units respectively, so that each target execution unit can perform parallel data operation processing on the data copies to obtain the corresponding output results; The output results of each target executor are compared pairwise to determine whether the output results of each target executor are consistent. If the number of target executors with consistent output results reaches a preset threshold, the current business data flow is determined to be normal. The final security output result is obtained based on the consistent output results and sent to the corresponding downstream system. Otherwise, the current business data flow is determined to be abnormal and an alarm is issued.

[0006] As a preferred embodiment, selecting the same number of execution units as the maximum number of parallel execution units as the target execution units includes: Calculate the normalized selection probability for each executor based on the real-time confidence weight of each executor in the current executor pool; Based on the normalized selection probability corresponding to each executor, sample each executor with no replacement probability, and randomly select the same number of executors as the maximum number of parallel executors from the current executor pool as the target executors.

[0007] As a preferred approach, the output results of two target executors are considered to be consistent when the output results between the two target executors satisfy the following formula: ; in, The output of the i-th target executor For the output of the j-th target executor, This is the preset error threshold.

[0008] As a preferred option, it also includes: Obtain the running status data of each target executor during parallel data processing; wherein, the running status data includes: processing success rate, response time, and resource utilization rate; Based on the operational status data, the response time score, result consistency score, and resource consumption score corresponding to each target executor are calculated, and the response time score, result consistency score, and resource consumption score are weighted and summed to obtain the comprehensive score corresponding to each target executor. The real-time confidence weight of each target executor is updated based on the comprehensive score corresponding to each target executor.

[0009] Based on the above embodiments, another embodiment of the present invention provides a mimicry defense device for the edge of the power Internet of Things, including: a current business data stream acquisition module, a current business data stream copying module, a parallel data operation and processing module, and an output result discrimination module; The current business data stream acquisition module is used to acquire the current business data stream of the power Internet of Things; The current business data stream copying module is used to copy the current business data stream according to the preset maximum number of parallel execution bodies, generating a number of data copies equal to the maximum number of parallel execution bodies; The parallel data processing module is used to select the same number of execution bodies as the maximum number of parallel execution bodies as target execution bodies, and send the generated data copies to the target execution bodies respectively, so that each target execution body performs parallel data processing on the data copies to obtain the corresponding output results; The output result discrimination module is used to compare the output results of each target executor pairwise to determine whether the output results of each target executor are consistent. If the number of target executors with consistent output results reaches a preset threshold, the current business data flow is determined to be normal. The final security output result is obtained based on the consistent output results and sent to the corresponding downstream system. Otherwise, the current business data flow is determined to be abnormal and an alarm is triggered.

[0010] As a preferred embodiment, selecting the same number of execution units as the maximum number of parallel execution units as the target execution units includes: Calculate the normalized selection probability for each executor based on the real-time confidence weight of each executor in the current executor pool; Based on the normalized selection probability corresponding to each executor, sample each executor with no replacement probability, and randomly select the same number of executors as the maximum number of parallel executors from the current executor pool as the target executors.

[0011] As a preferred approach, the output results of two target executors are considered to be consistent when the output results between the two target executors satisfy the following formula: ; in, The output of the i-th target executor For the output of the j-th target executor, This is the preset error threshold.

[0012] As a preferred option, it also includes: Obtain the running status data of each target executor during parallel data processing; wherein, the running status data includes: processing success rate, response time, and resource utilization rate; Based on the operational status data, the response time score, result consistency score, and resource consumption score corresponding to each target executor are calculated, and the response time score, result consistency score, and resource consumption score are weighted and summed to obtain the comprehensive score corresponding to each target executor. The real-time confidence weight of each target executor is updated based on the comprehensive score corresponding to each target executor.

[0013] Based on the above embodiments, another embodiment of the present invention provides an electronic device, the device including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein when the processor executes the computer program, it implements the mimicry defense method for the edge of the power Internet of Things as described in the above embodiments of the invention.

[0014] Based on the above embodiments, another embodiment of the present invention provides a storage medium, the storage medium including a stored computer program, wherein, when the computer program is running, it controls the device where the storage medium is located to execute the mimicry defense method for the edge of the power Internet of Things described in the above embodiments.

[0015] Compared with the prior art, the embodiments of the present invention have the following beneficial effects: This invention provides a mimicry defense method for the edge of the power Internet of Things (IoT). The method involves acquiring the current business data stream of the power IoT; copying the current business data stream according to a preset maximum number of parallel execution entities to generate a number of data copies equal to the maximum number of parallel execution entities; selecting an number of execution entities equal to the maximum number of parallel execution entities as target execution entities, and sending the generated data copies to each target execution entity so that each target execution entity performs parallel data processing on the data copies to obtain corresponding output results; comparing the output results of each target execution entity pairwise to determine if the output results are consistent; if the number of target execution entities with consistent output results reaches a preset threshold, the current business data stream is determined to be normal; based on the consistent output results, a final secure output result is obtained and sent to the corresponding downstream system; otherwise, the current business data stream is determined to be abnormal and an alarm is triggered. As can be seen, compared with existing technologies that rely on hardware redundancy, this invention selects an executor to process a copy of the current business data stream and judges data anomalies based on the output results. It can achieve mimicry defense at the edge of the power Internet of Things through only the software layer. It can effectively implement the intrinsic security mechanism in edge devices without changing the existing hardware architecture, and can significantly reduce costs and resource consumption while ensuring security. Attached Figure Description

[0016] Figure 1This is a flowchart illustrating a mimicry defense method for the edge of a power Internet of Things according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of a mimicry defense device at the edge of a power Internet of Things according to an embodiment of the present invention. Detailed Implementation

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

[0018] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application; the terms “comprising” and “having”, and any variations thereof, in the specification, claims, and foregoing description of the drawings are intended to cover non-exclusive inclusion.

[0019] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly defined.

[0020] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0021] In the description of the embodiments in this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0022] In the description of the embodiments of this application, the terms "multiple" and "several" refer to two or more (including two), similarly, "multiple groups" refer to two or more (including two groups), and "multiple pieces" refer to two or more (including two pieces).

[0023] In the description of the embodiments of this application, unless otherwise expressly specified and limited, technical terms such as "installation," "connection," "joining," and "fixing" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. For those skilled in the art, the specific meaning of the above terms in the embodiments of this application can be understood according to the specific circumstances.

[0024] Example 1 Please refer to Figure 1 To address the issue that existing mimicry defense technologies rely on costly hardware-level heterogeneous redundancy architectures, this invention provides a flowchart illustrating a mimicry defense method for the edge of a power Internet of Things.

[0025] First, let's explain the following technical terms: Mimic Defense: An intrinsic security technology based on a dynamic heterogeneous redundancy architecture. By constructing multiple functionally equivalent heterogeneous execution entities and combining them with dynamic scheduling and multi-mode adjudication mechanisms, the system presents uncertain structural characteristics to the outside world, thereby effectively defending against attacks based on unknown vulnerabilities and backdoors.

[0026] Dynamic Heterogeneous Redundancy (DHR): The core architecture of mimicry defense, which refers to the system architecture with uncertainty defense capabilities built through a combination of dynamic scheduling, heterogeneous redundancy and multi-mode adjudication.

[0027] Power IoT Edge Device: refers to intelligent terminal devices deployed at the edge of the power system, including smart meters, distribution automation terminals, edge gateways, and new energy monitoring devices, which are responsible for data acquisition, local computing, and real-time control.

[0028] Containerized Heterogeneous Executor: A software module with equivalent functionality but different implementations that is encapsulated using container technology. Each executor may differ in programming language, algorithm implementation, or compilation options. Container isolation ensures an independent runtime environment.

[0029] Confidence Weight: A numerical indicator used to quantify the reliability of the execution entity. It is dynamically calculated based on multi-dimensional data such as historical service success rate, response time, and resource consumption, and is used to guide scheduling decisions.

[0030] Weighted Round Robin Algorithm: An improved scheduling algorithm that considers the weight distribution of each executor during the executor selection process and ensures that each executor can obtain service opportunities in multiple scheduling cycles, avoiding long-term idleness or overload of a single executor.

[0031] Semantic Equivalence Rule Set: A set of rules that define the consistency criteria for output results under different data types, including the relative error tolerance for numerical data, the majority voting mechanism for state data, and the precise matching requirements for control instructions.

[0032] Multi-mode Voter: The core component responsible for verifying the consistency of output results from multiple heterogeneous executors. It employs different comparison strategies based on data type to ensure the correctness and security of the output results.

[0033] Relative Error Tolerance: The threshold parameter for judging the consistency of numerical data, defined as |v1-v2| / max(v1,v2)≤δ, where δ is a preset tolerance value, usually taken as 0.01 (1%).

[0034] Health Score: A quantitative indicator that comprehensively evaluates the operational status of an execution unit. It is calculated based on parameters such as availability, error rate, and performance, and is used for the lifecycle management of the execution unit.

[0035] Feedback Control Module: This module is responsible for monitoring the system's operating status, collecting performance data from the execution units, and dynamically adjusting system parameters to achieve adaptive optimization of the system.

[0036] Scheduling Period Parameter: The time interval at which the system reselects the combination of executors. It is usually set to 3000 milliseconds and can be dynamically adjusted according to the system load.

[0037] Docker container: A lightweight virtualization technology that provides an independent runtime environment for applications through kernel-level isolation mechanisms. In this system, it is used to encapsulate and isolate various heterogeneous execution entities.

[0038] Forgetting Factor: The decay coefficient ρ (usually 0.8) in the weight update formula is used to balance the influence of historical performance and recent performance, ensuring that the weight value can reflect the latest state of the executor in a timely manner.

[0039] Heterogeneous Executor Image: A container image file containing a complete runtime environment and functional code. Different images may differ in their implementation but provide the same functional interfaces.

[0040] Semantic equivalence refers to the fact that the outputs of different executors have the same meaning and function at the business logic level, without requiring them to be completely consistent in every detail of the data representation.

[0041] Executor Service Set: A combination of executors selected to participate in service during each scheduling cycle. It typically contains k executors running in parallel, with the value of k dynamically determined based on system resources and security requirements.

[0042] The Semantic Equivalence Rule Set defines the rules for judging the consistency of output results under different data types. It is customized after in-depth analysis of the core characteristics and consistency tolerance of power Internet of Things (IoT) business data. The rule set includes the relative error tolerance δ for numerical data, the majority voting mechanism for state data, and the precise matching requirements of control commands.

[0043] The mimicry defense method at the edge of the power Internet of Things includes the following specific steps: S1. Obtain the current business data stream of the power Internet of Things; Specifically, the system architecture of this invention consists of five core components: an input agent, a dynamic scheduler decision-making mechanism, heterogeneous executors for parallel processing, a lightweight voting unit for multi-level adjudication, and a feedback control module for adaptive adjustment. These components work collaboratively to form a complete mimicry defense closed loop.

[0044] First, the input agent listens on a preset port through the TCP / IP protocol stack to receive business data streams from power IoT devices; among them, the power IoT business data stream D includes: structured data packets containing timestamps, device IDs, and data payloads.

[0045] When a data packet arrives, the module first verifies the integrity of the data packet format (such as JSON format verification) and the validity of the data signature. Only after the verification is successful can the next step be performed.

[0046] S2. Based on the preset maximum number of parallel execution bodies, copy the current business data stream to generate a number of data copies equal to the maximum number of parallel execution bodies; Specifically, after verifying the integrity of the data packet format (such as JSON format validation) and the validity of the data signature, the module creates multiple identical copies of the current business data stream. The number of copies is determined by the maximum number of concurrent executions configured in the current system, generating the same number of data copies as the maximum number of concurrent executions. The replication process uses deep copy technology to ensure that each copy exists independently in memory. After replication is complete, the module adds a timestamp and sequence number to each copy, and then stores these copies in the send buffer, awaiting scheduler invocation.

[0047] The maximum number of parallel execution entities k can be dynamically adjusted according to device resources, and the default value is generally k=3.

[0048] S3. Select the same number of execution bodies as the maximum number of parallel execution bodies as target execution bodies, and send the generated data copies to the target execution bodies respectively, so that each target execution body performs parallel data operation processing on the data copies and obtains the corresponding output results; Preferably, selecting the same number of executors as the maximum number of parallel executors as target executors includes: calculating the normalized selection probability corresponding to each executor based on the real-time confidence weight of each executor in the current executor pool; performing no-replacement probability sampling on each executor based on the normalized selection probability corresponding to each executor, and randomly selecting the same number of executors as the maximum number of parallel executors from the current executor pool as target executors.

[0049] Specifically, the set of heterogeneous execution entity images in the current execution entity pool is E={E1,E2,...,E...} n}: This set is a functionally equivalent heterogeneous implementation based on Docker containers, where n is the number of heterogeneous executables. It is constructed and encapsulated using software-layer heterogeneous methods such as employing different programming languages ​​(e.g., Python, C++, Go), different core algorithms, or different compilation chain configurations for the same business function. They are functionally equivalent but heterogeneous in their internal implementation, forming the foundation for intrinsic security.

[0050] The scheduling period parameter T defaults to 3000ms and can be dynamically adjusted based on the load.

[0051] The real-time confidence weights of each executor are W0=[w1,w2,...,w n ],∑wᵢ=1.

[0052] Semantic equivalence rule set S: includes numerical tolerance δ, state mapping table, and instruction whitelist. This rule set is customized by analyzing the types of power Internet of Things (IoT) business data (telemetry, status, control) and their actual consistency requirements (real-time performance, accuracy).

[0053] The semantic equivalence rule set can serve as the basis for consistency judgment by the following voting device, guiding the use of relative error tolerance testing for numerical data, majority voting for state data, and exact matching for control commands, so as to ensure that the system can guarantee security while taking into account fault tolerance and business continuity.

[0054] Before the executable runs, system initialization and resource loading are performed first. During system startup, the heterogeneous executable image set E={E1,E2,...,E...} is first read. n The process involves loading the instance into the Docker engine to instantiate it and build the initial heterogeneous execution pool. Then, the initial weight configuration W0=[w1,w2,...,w] is read. n Each executor Ei in the pool is assigned an initial trust value wᵢ∈W0. The initial weight allocation adopts an average allocation strategy (wᵢ = 1 / n), or is fine-tuned based on pre-test performance metrics. At the same time, the voter is initialized, and the semantic equivalence rule set S (including numerical tolerance δ, state mapping table, and instruction whitelist) is loaded into memory to complete the construction of the mimicry defense environment.

[0055] Then, select the same number of executions as the maximum number of parallel executions from the current execution pool as the target executions. The specific steps are as follows: The dynamic scheduler maintains an execution state database. During each scheduling operation, the scheduler first determines the execution state based on the current weight vector W=[w1,w2,...,w...]. n ] Calculate the normalized selection probability of each executor. The calculation formula is: (1) in These are the real-time confidence weights of the i-th and j-th available executors in the executor pool, respectively. Based on the calculated probabilities, the scheduler uses a round-robin selection method with a probability interval mapping without replacement. The system divides the [0, 1] interval into sub-intervals of corresponding probability lengths, and randomly selects k non-repeating executors to form the current service set. This ensures that high-confidence executors have a higher probability of being selected, while also preserving randomness to disrupt the attack chain.

[0056] The specific steps for performing probability sampling without replacement on each execution entity are as follows: 1. Interval Construction: Divide the interval [0,1] into n subintervals, where the length of the i-th subinterval corresponds to its probability. .

[0057] 2. Random Sampling: Generate a random floating-point number r within the range [0,1]. Determine the selected execution body E based on the sub-interval that r falls into. selected .

[0058] 3. Service set update and deduplication: E selected Add it to the current service set and temporarily remove the execution from the candidate pool.

[0059] 4. Iterative loop: Recalculate the normalized probability of the remaining candidate executors (denominator minus the weight of the selected executor), and repeat steps 2-3 until k executors are selected.

[0060] The final k selected executors simultaneously begin processing. Each executor runs in an independent container environment, with kernel-level isolation mechanisms ensuring no interference between their runtime environments. After receiving a copy of the input data, each executor performs calculations according to predetermined processing logic (such as protocol parsing and business logic verification). The system sets an independent timeout timer for each executor (threshold τ = 2000ms). If an executor fails to complete processing within the predetermined time, the system will forcibly terminate that executor and mark the execution as a failure. After all executors have completed processing, they submit the output results and their metadata (including executor ID, processing time, and status flag) to the voting unit.

[0061] The specific data processing procedures for each target execution entity include: 1. Protocol parsing: Unpack the input raw binary message (such as Modbus TCP or DL / T 645) and extract key business fields (such as voltage value, switch position). 2. Business verification and calculation: Perform data range verification, unit conversion, or control logic calculation according to preset power business rules; 3. Result Encapsulation: The calculation result is encapsulated into a standardized output object. The result output by the execution body consists of three parts: ① Business data payload (standardized numerical values ​​or status codes); ②Metadata (including executor ID, processing time, and timestamp); ③ Status Identifier (indicating whether the processing was completed normally or an internal exception was caught). The system monitors the running status of each executor in real time and sets a processing timeout threshold τ=2000ms. If an executor fails to complete processing within the specified time, the system will forcibly terminate the process and mark it as a service exception.

[0062] S4. Compare the output results of each target executor pairwise to determine whether the output results of each target executor are consistent. If the number of target executors with consistent output results reaches a preset threshold, the current business data flow is determined to be normal. The final security output result is obtained based on the consistent output results and sent to the corresponding downstream system. Otherwise, the current business data flow is determined to be abnormal and an alarm is triggered.

[0063] Preferably, the output results between two target executors are considered to be consistent when the output results between the two target executors satisfy the following formula: ; in, The output of the i-th target executor For the output of the j-th target executor, This is the preset error threshold.

[0064] Specifically, after the output results of each target executor are sent to the voter, the voter adopts a hierarchical decision-making strategy. First, it performs format standardization processing on the received output results, and then selects the appropriate comparison algorithm according to the data type: Numerical data: A pairwise comparison mechanism based on relative error is used, and the consistency judgment formula is as follows: (2) in A preset error threshold (e.g., 0.01) is set. The system counts the number of execution pairs that meet this consistency condition. When the number of mutually consistent execution pairs reaches the threshold (e.g., ⌈2k / 3⌉), the arithmetic mean of these consistency results is taken as the final output. State-type data: A majority voting mechanism is used to select the state value that occurs most frequently as the output; Control instruction data: requires complete consistency; otherwise, the vote is considered a failure.

[0065] Specifically and These represent the business values ​​output by the i-th and j-th executors in the service set, respectively. The larger of the two values ​​is used to normalize the error; δ is a preset relative error tolerance (e.g., 0.01). For state-type data, equivalence is determined based on the state mapping table.

[0066] For control commands, precise matching is performed based on a whitelist. The voting unit counts the number of executors that achieve semantic agreement. When the number of agreement meets the threshold ⌈2k / 3⌉ (i.e., at least two-thirds majority), the vote passes. The system calculates the arithmetic mean of these agreement results as the final security result and outputs it to the downstream system. If there is no agreement, the vote fails if the number of agreement does not reach the threshold (potentially indicating an attack or multiple points of failure). The system will block output, record a security alarm log, and trigger the feedback control module to demote the relevant executors.

[0067] Preferably, the method further includes: acquiring the running status data of each target executor during parallel data processing; wherein the running status data includes: processing success rate, response time, and resource utilization rate; calculating the response time score, result consistency score, and resource consumption score corresponding to each target executor based on the running status data, and performing a weighted summation of the response time score, result consistency score, and resource consumption score to obtain a comprehensive score corresponding to each target executor; and updating the real-time confidence weight of each target executor based on the comprehensive score corresponding to each target executor.

[0068] Specifically, after each executor processes the data, the feedback control module collects real-time operational status data for each executor, including metrics such as processing success rate, response time, and resource utilization. It then dynamically updates the confidence weights based on the performance of each execution. The update algorithm uses a recursive formula for the forgetting factor: (3) in, These are the real-time confidence weights of the i-th available executor in the executor pool before and after the update, respectively. The forgetting factor (e.g., 0.8). and These are the comprehensive scores for the i-th and j-th executors for this service, respectively, and are composed of response time scores ( ), weighting coefficients corresponding to response time scores Consistency score of results ( ), weighting coefficients corresponding to the consistency score of results Resource consumption score ( The weighting coefficients corresponding to the resource consumption scores. Weighted calculation The calculation formula is: (w is the weight coefficient of each item) (4) Response time score ( The calculation formula is: (5) in This refers to the actual time spent. The maximum allowable response time is the timeout timer mentioned above (threshold τ = 2000ms). The shorter the response time, the higher the score.

[0069] Consistency score of results ( If the output of the executor is included in the final consensus set, then Scons=1; otherwise, Scons=0.

[0070] Resource consumption score ( ): (6) in This represents the actual CPU usage during this service execution. CPU quota limits allocated to the executor. This represents the actual amount of memory used during this service execution. The memory quota limit allocated to the executor. The resource consumption score reflects the executor's resource utilization relative to the quota.

[0071] Simultaneously, the feedback control module calculates the execution entity health score Hᵢ based on statistical data from the most recent M scheduling cycles. The scoring formula is as follows: Hᵢ=0.6×A+0.3×(1-E)+0.1×P (7) Availability (A): is defined as This reflects the stability of service operation. Error rate (E): corresponds to the frequency of exception triggering, defined as... Performance Score (P): Calculated based on resource utilization, defined as P = 1 - Average Resource Load Rate, where the average resource load rate is the weighted sum of the average CPU and memory utilization of the execution unit within the period. It comprehensively considers availability, error rate, and performance.

[0072] When Hᵢ is detected to be below a threshold (e.g., 0.7), the system determines that the execution unit is "sub-healthy", automatically isolates the execution unit, and uses the original image in the image set E to restart or reset it, thereby achieving the system's "self-healing".

[0073] Finally, the system outputs a security result O verified by multi-mode voting, and simultaneously generates a comprehensive report containing a health status matrix H for each executor and a security posture assessment A (A = number of successful interceptions / total number of attacks) based on the most recent 100 interactions. The entire defense system continuously cycles with a scheduling period parameter T (e.g., T = 3000ms) as the time base. Every period T triggers a new round of weight evaluation and scheduling strategy adjustment, forming a mimicry defense closed loop with continuous evolution capabilities.

[0074] The final output includes: Safe output result O: The final output verified by multi-modal voting; Execution entity health status report H: contains an evaluation matrix of {availability, response time, error rate}; System security posture assessment A: Quantitative score based on historical attack interception rate.

[0075] Therefore, the core inventive point of this invention lies in the fact that, through the synergy of efficient heterogeneous construction of the software layer, adaptive dynamic scheduling of resources, and lightweight adjudication oriented towards business semantics, an intrinsic security mechanism is successfully implemented in a resource-constrained environment without changing the existing hardware architecture.

[0076] Specifically, the primary inventive point of this invention lies in proposing a lightweight heterogeneous execution entity construction method based on containerization technology. This method abandons the strong dependence of traditional mimicry defense on hardware heterogeneity, instead utilizing mainstream containerization technology to quickly construct multiple functionally equivalent but internally heterogeneous software execution entities by using different programming languages, algorithms, compilation chain options, or basic runtime environments for the same functional module. These execution entities exist in the form of lightweight container images, sharing the underlying operating system kernel, thereby creating sufficient heterogeneity while minimizing resource overhead and deployment costs.

[0077] The second key inventive aspect of this invention lies in the design of a dynamic scheduling algorithm based on confidence weights. This algorithm eliminates the computational resource demands of complex game theory models by maintaining a dynamically changing confidence weight for each heterogeneous executor. This weight integrates the executor's historical service success rate, response time, and the frequency with which it is flagged as anomaly by the arbiter. The scheduler performs probabilistic rotation based on this weight, ensuring both the uncertainty and dynamism of the system structure while ensuring that higher-performing and more reliable executors receive a higher probability of service, thus achieving a balance between security and reliability. This algorithm has low computational complexity, requiring only simple arithmetic operations, making it highly suitable for running on microcontrollers or low-power processors.

[0078] The third key inventive aspect of this invention lies in the introduction of a lightweight multi-mode adjudication mechanism that supports fault tolerance and semantic consistency. This mechanism fully considers the characteristics of power IoT data, no longer pursuing complete bit-level consistency, but instead defining semantic equivalence judgment rules based on business logic. For example, for metering data, consistency is allowed within a reasonable error range; for status commands, consensus voting is conducted based on the majority principle. This "fuzzy" voting strategy significantly reduces the stringent requirements for the consistency of the executor's output, improves the system's availability and robustness, and effectively resists abnormal output caused by attacks.

[0079] Compared with existing technologies, the comprehensive advantages of this invention are particularly prominent. First, in terms of cost and deployment, this solution is purely software-based, requiring no new or replaced hardware, greatly reducing the marginal cost of large-scale applications. Second, in terms of performance and overhead, the lightweight design allows the additional CPU and memory overhead on typical edge devices to be controlled within 20%, ensuring that the real-time performance of power services is not compromised. Finally, in terms of security performance, through multi-layered, fine-grained software heterogeneity and dynamic uncertainty scheduling, the system can effectively disrupt attack chains, significantly improving the success rate of defense against unknown vulnerabilities and backdoor attacks, and building a robust, intrinsic security protection system for power IoT edge devices, possessing "stealth," "variation," and "self-healing" capabilities.

[0080] Example 2 Please refer to Figure 2 This is a schematic diagram of the structure of a mimicry defense device at the edge of a power Internet of Things according to an embodiment of the present invention. The device includes: a current business data stream acquisition module, a current business data stream copying module, a parallel data operation and processing module, and an output result discrimination module. The current business data stream acquisition module is used to acquire the current business data stream of the power Internet of Things; The current business data stream copying module is used to copy the current business data stream according to the preset maximum number of parallel execution bodies, generating a number of data copies equal to the maximum number of parallel execution bodies; The parallel data processing module is used to select the same number of execution bodies as the maximum number of parallel execution bodies as target execution bodies, and send the generated data copies to the target execution bodies respectively, so that each target execution body performs parallel data processing on the data copies to obtain the corresponding output results; The output result discrimination module is used to compare the output results of each target executor pairwise to determine whether the output results of each target executor are consistent. If the number of target executors with consistent output results reaches a preset threshold, the current business data flow is determined to be normal. The final security output result is obtained based on the consistent output results and sent to the corresponding downstream system. Otherwise, the current business data flow is determined to be abnormal and an alarm is triggered.

[0081] Preferably, selecting the same number of execution units as the maximum number of parallel execution units as the target execution units includes: Calculate the normalized selection probability for each executor based on the real-time confidence weight of each executor in the current executor pool; Based on the normalized selection probability corresponding to each executor, sample each executor with no replacement probability, and randomly select the same number of executors as the maximum number of parallel executors from the current executor pool as the target executors.

[0082] Preferably, the output results between two target executors are considered to be consistent when the output results between the two target executors satisfy the following formula: ; in, The output of the i-th target executor For the output of the j-th target executor, This is the preset error threshold.

[0083] Preferred options also include: Obtain the running status data of each target executor during parallel data processing; wherein, the running status data includes: processing success rate, response time, and resource utilization rate; Based on the operational status data, the response time score, result consistency score, and resource consumption score corresponding to each target executor are calculated, and the response time score, result consistency score, and resource consumption score are weighted and summed to obtain the comprehensive score corresponding to each target executor. The real-time confidence weight of each target executor is updated based on the comprehensive score corresponding to each target executor.

[0084] Specifically, in this embodiment, the current business data stream acquisition module first listens to a preset port through the TCP / IP protocol stack to receive business data streams from power IoT devices; wherein, the power IoT business data stream D includes: structured data packets containing timestamps, device IDs, and data payloads.

[0085] When a data packet arrives, the module first verifies the integrity of the data packet format (such as JSON format verification) and the validity of the data signature. Only after the verification is successful can the next step be performed.

[0086] After the integrity of the data packet format (such as JSON format verification) and the validity of the data signature are verified, the current business data stream copy module creates multiple identical copies of the current business data stream. The number of copies is determined by the maximum number of parallel execution entities configured in the current system, generating the same number of data copies as the maximum number of parallel execution entities. The copying process uses deep copy technology to ensure that each copy exists independently in memory. After copying is complete, the module adds a timestamp and sequence number to each copy, and then stores these copies in the send buffer, waiting for the scheduler to call them.

[0087] The maximum number of parallel execution entities k can be dynamically adjusted according to device resources, and the default value is generally k=3.

[0088] Specifically, the set of heterogeneous execution entity images in the current execution entity pool is E={E1,E2,...,E...}n This collection is based on Docker containers and features functionally equivalent heterogeneous implementations. It is constructed and encapsulated using heterogeneous software layer techniques such as different programming languages ​​(e.g., Python, C++, Go), different core algorithms, or different compilation chain configurations for the same business function. While functionally equivalent, they are heterogeneous in their internal implementation, forming the foundation for intrinsic security.

[0089] The scheduling period parameter T defaults to 3000ms and can be dynamically adjusted based on the load.

[0090] The real-time confidence weights of each executor are W0=[w1,w2,...,w n ],∑wᵢ=1.

[0091] Semantic equivalence rule set S: includes numerical tolerance δ, state mapping table, and instruction whitelist. This rule set is customized by analyzing the types of power Internet of Things (IoT) business data (telemetry, status, control) and their actual consistency requirements (real-time performance, accuracy).

[0092] The semantic equivalence rule set can serve as the basis for consistency judgment by the following voting device, guiding the use of relative error tolerance δ test for numerical data, majority voting for state data, and exact matching for control commands, so as to ensure that the system can guarantee security while taking into account fault tolerance and business continuity.

[0093] Before the executable runs, system initialization and resource loading are performed first. During system startup, the heterogeneous executable image set E={E1,E2,...,E...} is first read. n The process involves loading the instance into the Docker engine to instantiate it and build the initial heterogeneous execution pool. Then, the initial weight configuration W0=[w1,w2,...,w] is read. n Each executor Ei in the pool is assigned an initial trust value wᵢ∈W0. The initial weight allocation adopts an average allocation strategy (wᵢ = 1 / n), or is fine-tuned based on pre-test performance metrics. At the same time, the voter is initialized, and the semantic equivalence rule set S (including numerical tolerance δ, state mapping table, and instruction whitelist) is loaded into memory to complete the construction of the mimicry defense environment.

[0094] Then, the parallel data processing module selects the same number of execution bodies as the maximum number of parallel execution bodies from the current execution body pool as the target execution bodies. The specific steps are as follows: The dynamic scheduler maintains an execution state database. During each scheduling operation, the scheduler first determines the execution state based on the current weight vector W=[w1,w2,...,w...]. n ] Calculate the normalized selection probability of each executor. The calculation formula is: (1) in Let be the real-time confidence weight of the i-th available executor in the executor pool. Based on the calculated probability, the scheduler uses a round-robin selection method with a probability interval mapping without replacement. The system divides the interval [0, 1] into sub-intervals with corresponding probability lengths, and randomly selects k non-repeating executors to form the current service set. This ensures that high-confidence executors have a higher probability of being selected, while also preserving randomness to disrupt the attack chain.

[0095] The specific steps for performing probability sampling without replacement on each execution entity are as follows: 1. Interval Construction: Divide the interval [0,1] into n subintervals, where the length of the i-th subinterval corresponds to its probability. .

[0096] 2. Random Sampling: Generate a random floating-point number r within the range [0,1]. Determine the selected execution body E based on the sub-interval that r falls into. selected .

[0097] 3. Service set update and deduplication: E selected Add it to the current service set and temporarily remove the execution from the candidate pool.

[0098] 4. Iterative loop: Recalculate the normalized probability of the remaining candidate executors (denominator minus the weight of the selected executor), and repeat steps 2-3 until k executors are selected.

[0099] The final k selected executors simultaneously begin processing. Each executor runs in an independent container environment, with kernel-level isolation mechanisms ensuring no interference between their runtime environments. After receiving a copy of the input data, each executor performs calculations according to predetermined processing logic (such as protocol parsing and business logic verification). The system sets an independent timeout timer for each executor (threshold τ = 2000ms). If an executor fails to complete processing within the predetermined time, the system will forcibly terminate that executor and mark the execution as a failure. After all executors have completed processing, they submit the output results and their metadata (including executor ID, processing time, and status flag) to the voting unit.

[0100] The specific data processing procedures for each target execution entity include: 1. Protocol parsing: Unpack the input raw binary message (such as Modbus TCP or DL / T 645) and extract key business fields (such as voltage value, switch position). 2. Business Verification and Calculation: Perform data range verification, unit conversion, or control logic calculations based on preset power business rules; 3. Result Encapsulation: The calculation result is encapsulated into a standardized output object. The result output by the execution body consists of three parts: ① Business data payload (standardized numerical values ​​or status codes); ②Metadata (including executor ID, processing time, and timestamp); ③ Status Identifier (indicating whether the processing was completed normally or an internal exception was caught). The system monitors the running status of each executor in real time and sets a processing timeout threshold τ=2000ms. If an executor fails to complete processing within the specified time, the system will forcibly terminate the process and mark it as a service exception.

[0101] In the output result discrimination module, after the output results of each target executor are sent to the voter, the voter adopts a hierarchical decision-making strategy. First, it performs format standardization processing on the received output results, and then selects the appropriate comparison algorithm according to the data type: Numerical data: A pairwise comparison mechanism based on relative error is used, and the consistency judgment formula is as follows: (2) in A preset error threshold (e.g., 0.01) is set. The system counts the number of execution pairs that meet this consistency condition. When the number of mutually consistent execution pairs reaches the threshold (e.g., ⌈2k / 3⌉), the arithmetic mean of these consistency results is taken as the final output. State-type data: A majority voting mechanism is used to select the state value that occurs most frequently as the output; Control instruction data: requires complete consistency; otherwise, the vote is considered a failure.

[0102] Specifically and These represent the business values ​​output by the i-th and j-th executors in the service set, respectively. The larger of the two values ​​is used to normalize the error; δ is a preset relative error tolerance (e.g., 0.01). For state-type data, equivalence is determined based on the state mapping table.

[0103] For control commands, precise matching is performed based on a whitelist. The voting unit counts the number of executors that achieve semantic agreement. When the number of agreement meets the threshold ⌈2k / 3⌉ (i.e., at least two-thirds majority), the vote passes. The system calculates the arithmetic mean of these agreement results as the final security result and outputs it to the downstream system. If there is no agreement, the vote fails if the number of agreement does not reach the threshold (potentially indicating an attack or multiple points of failure). The system will block output, record a security alarm log, and trigger the feedback control module to demote the relevant executors.

[0104] After each executor processes the data, the feedback control module collects real-time operational status data for each executor, including metrics such as processing success rate, response time, and resource utilization. It then dynamically updates the confidence weights based on the performance of each execution. The update algorithm uses a recursive formula for the forgetting factor: (3) in The forgetting factor (e.g., 0.8). The overall score for the service provided by the i-th executor is calculated by weighting the response time score (Stime), result consistency score (Scons), and resource consumption score (Sres). The calculation formula is: (w is the weight coefficient of each item) (4) Response time score (Stime): The calculation formula is as follows: (5) in This refers to the actual time spent. The maximum allowable response time is the timeout timer mentioned above (threshold τ = 2000ms). The shorter the response time, the higher the score.

[0105] Consistency score (Scons): If the output of the executor is included in the final set of consensus votes, then Scons = 1; otherwise, Scons = 0.

[0106] Resource Consumption Score (Sres): (6) in This represents the actual CPU usage during this service execution. CPU quota limits allocated to the executor. This represents the actual amount of memory used during this service execution. The memory quota limit allocated to the executor. The resource consumption score reflects the executor's resource utilization relative to the quota.

[0107] Simultaneously, the feedback control module calculates the execution entity health score Hᵢ based on statistical data from the most recent M scheduling cycles. The scoring formula is as follows: Hᵢ=0.6×A+0.3×(1-E)+0.1×P (7) Availability (A): is defined as This reflects the stability of service operation. Error rate (E): corresponds to the frequency of exception triggering, defined as... Performance Score (P): Calculated based on resource utilization, defined as P = 1 - Average Resource Load Rate, where the average resource load rate is the weighted sum of the average CPU and memory utilization of the execution unit within the period. It comprehensively considers availability, error rate, and performance.

[0108] When Hᵢ is detected to be below a threshold (e.g., 0.7), the system determines that the execution unit is "sub-healthy", automatically isolates the execution unit, and uses the original image in the image set E to restart or reset it, thereby achieving the system's "self-healing".

[0109] Finally, the system outputs a security result O verified by multi-mode voting, and simultaneously generates a comprehensive report containing a health status matrix H for each executor and a security posture assessment A (A = number of successful interceptions / total number of attacks) based on the most recent 100 interactions. The entire defense system continuously cycles with a scheduling period parameter T (e.g., T = 3000ms) as the time base. Every period T triggers a new round of weight evaluation and scheduling strategy adjustment, forming a mimicry defense closed loop with continuous evolution capabilities.

[0110] The final output includes: Safe output result O: The final output verified by multi-modal voting; Execution entity health status report H: contains an evaluation matrix of {availability, response time, error rate}; System security posture assessment A: Quantitative score based on historical attack interception rate.

[0111] Therefore, the core inventive point of this embodiment is that, through the synergy of efficient heterogeneous construction of the software layer, adaptive dynamic scheduling of resources, and lightweight adjudication oriented towards business semantics, an intrinsic security mechanism is successfully implemented in a resource-constrained environment without changing the existing hardware architecture.

[0112] Specifically, the primary invention of this paper lies in proposing a lightweight heterogeneous execution entity construction method based on containerization technology. This method abandons the strong dependence of traditional mimicry defense on hardware heterogeneity, instead utilizing mainstream containerization technology to quickly construct multiple functionally equivalent but internally heterogeneous software execution entities by using different programming languages, algorithms, compilation chain options, or basic runtime environments for the same functional module. These execution entities exist in the form of lightweight container images, sharing the underlying operating system kernel, thereby creating sufficient heterogeneity while minimizing resource overhead and deployment costs.

[0113] The second key inventive aspect of this invention lies in the design of a dynamic scheduling algorithm based on confidence weights. This algorithm eliminates the computational resource demands of complex game theory models by maintaining a dynamically changing confidence weight for each heterogeneous executor. This weight integrates the executor's historical service success rate, response time, and the frequency with which it is flagged as anomaly by the arbiter. The scheduler performs probabilistic rotation based on this weight, ensuring both the uncertainty and dynamism of the system structure while ensuring that higher-performing and more reliable executors receive a higher probability of service, thus achieving a balance between security and reliability. This algorithm has low computational complexity, requiring only simple arithmetic operations, making it highly suitable for running on microcontrollers or low-power processors.

[0114] The third key inventive aspect of this invention lies in the introduction of a lightweight multi-mode adjudication mechanism that supports fault tolerance and semantic consistency. This mechanism fully considers the characteristics of power IoT data, no longer pursuing complete bit-level consistency, but instead defining semantic equivalence judgment rules based on business logic. For example, for metering data, consistency is allowed within a reasonable error range; for status commands, consensus voting is conducted based on the majority principle. This "fuzzy" voting strategy significantly reduces the stringent requirements for the consistency of the executor's output, improves the system's availability and robustness, and effectively resists abnormal output caused by attacks.

[0115] Compared with existing technologies, the comprehensive advantages of this invention are particularly prominent. First, in terms of cost and deployment, this solution is purely software-based, requiring no new or replaced hardware, greatly reducing the marginal cost of large-scale applications. Second, in terms of performance and overhead, the lightweight design allows the additional CPU and memory overhead on typical edge devices to be controlled within 20%, ensuring that the real-time performance of power services is not compromised. Finally, in terms of security performance, through multi-layered, fine-grained software heterogeneity and dynamic uncertainty scheduling, the system can effectively disrupt attack chains, significantly improving the success rate of defense against unknown vulnerabilities and backdoor attacks, and building a robust, intrinsic security protection system for power IoT edge devices, possessing "stealth," "variation," and "self-healing" capabilities.

[0116] It should be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, in the accompanying drawings of the device embodiments provided by this invention, the connection relationships between modules indicate that they have communication connections, which can be specifically implemented as one or more communication buses or signal lines. Those skilled in the art can understand and implement this without any creative effort.

[0117] Those skilled in the art will clearly understand that, for convenience and brevity, the specific working process of the device described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0118] Example 3 Accordingly, embodiments of the present invention provide an electronic device, the device including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein when the processor executes the computer program, it implements the mimicry defense method for the edge of the power Internet of Things as described in the above embodiments of the invention.

[0119] The electronic device may be a desktop computer, laptop, handheld computer, or cloud server, etc. The device may include, but is not limited to, a processor and a memory.

[0120] The processor can be a Central Processing Unit (CPU), or 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. A general-purpose processor can be a microprocessor or any conventional processor. The processor is the control center of the device, connecting various parts of the device via various interfaces and lines.

[0121] Example 4 Accordingly, embodiments of the present invention provide a storage medium, the storage medium including a stored computer program, wherein, when the computer program is running, it controls the device where the storage medium is located to execute the mimicry defense method at the edge of the power Internet of Things described in the above embodiments of the invention.

[0122] The memory can be used to store the computer program. The processor implements various functions of the device by running or executing the computer program stored in the memory and calling data stored in the memory. The memory may mainly include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function, etc.; the data storage area may store data created based on the use of the mobile phone, etc. In addition, the memory may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, RAM, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0123] The storage medium is a computer-readable storage medium, and the computer program is stored in the computer-readable storage medium. When executed by a processor, the computer program can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable file, or some intermediate form. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable medium does not include electrical carrier signals and telecommunication signals.

[0124] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A mimicry defense method for the edge of a power Internet of Things (IoT), characterized in that, include: Obtain the current business data stream of the power Internet of Things; Based on the preset maximum number of parallel execution bodies, the current business data stream is copied to generate the same number of data copies as the maximum number of parallel execution bodies; Select the same number of execution units as the maximum number of parallel execution units as target execution units, and send the generated data copies to the target execution units respectively, so that each target execution unit can perform parallel data operation processing on the data copies to obtain the corresponding output results; The output results of each target executor are compared pairwise to determine whether the output results of each target executor are consistent. If the number of target executors with consistent output results reaches a preset threshold, the current business data flow is determined to be normal. The final security output result is obtained based on the consistent output results and sent to the corresponding downstream system. Otherwise, the current business data flow is determined to be abnormal and an alarm is issued.

2. The method of claim 1, wherein the method is performed by a power internet of things edge. Selecting the same number of execution units as the maximum number of parallel execution units as the target execution units includes: Calculate the normalized selection probability for each executor based on the real-time confidence weight of each executor in the current executor pool; Based on the normalized selection probability corresponding to each executor, sample each executor with no replacement probability, and randomly select the same number of executors as the maximum number of parallel executors from the current executor pool as the target executors.

3. The mimicry defense method for the edge of the power Internet of Things as described in claim 2, characterized in that, The outputs of two target executors are considered to be consistent when the outputs satisfy the following formula: ； in, The output of the i-th target execution body For the output of the j-th target executor, This is the preset error threshold.

4. The mimicry defense method for the edge of the power Internet of Things as described in claim 3, characterized in that, Also includes: Obtain the running status data of each target executor during parallel data processing; wherein, the running status data includes: processing success rate, response time, and resource utilization rate; Based on the operational status data, the response time score, result consistency score, and resource consumption score corresponding to each target executor are calculated, and the response time score, result consistency score, and resource consumption score are weighted and summed to obtain the comprehensive score corresponding to each target executor. The real-time confidence weight of each target executor is updated based on the comprehensive score corresponding to each target executor.

5. A mimicry defense device for the edge of a power Internet of Things, characterized in that, include: The module includes a current business data stream acquisition module, a current business data stream copying module, a parallel data processing module, and an output result discrimination module. The current business data stream acquisition module is used to acquire the current business data stream of the power Internet of Things; The current business data stream copying module is used to copy the current business data stream according to the preset maximum number of parallel execution bodies, generating a number of data copies equal to the maximum number of parallel execution bodies; The parallel data processing module is used to select the same number of execution bodies as the maximum number of parallel execution bodies as target execution bodies, and send the generated data copies to the target execution bodies respectively, so that each target execution body performs parallel data processing on the data copies to obtain the corresponding output results; The output result discrimination module is used to compare the output results of each target executor pairwise to determine whether the output results of each target executor are consistent. If the number of target executors with consistent output results reaches a preset threshold, the current business data flow is determined to be normal. The final security output result is obtained based on the consistent output results and sent to the corresponding downstream system. Otherwise, the current business data flow is determined to be abnormal and an alarm is triggered.

6. The mimicry defense device at the edge of the power Internet of Things as described in claim 5, characterized in that, Selecting the same number of execution units as the maximum number of parallel execution units as the target execution units includes: Calculate the normalized selection probability for each executor based on the real-time confidence weight of each executor in the current executor pool; Based on the normalized selection probability corresponding to each executor, sample each executor with no replacement probability, and randomly select the same number of executors as the maximum number of parallel executors from the current executor pool as the target executors.

7. The mimicry defense device at the edge of the power Internet of Things as described in claim 6, characterized in that, The outputs of two target executors are considered to be consistent when the outputs satisfy the following formula: ； in, The output of the i-th target execution body For the output of the j-th target executor, This is the preset error threshold.

8. The mimicry defense device at the edge of the power Internet of Things as described in claim 7, characterized in that, Also includes: Obtain the running status data of each target executor during parallel data processing; wherein, the running status data includes: processing success rate, response time, and resource utilization rate; Based on the operational status data, the response time score, result consistency score, and resource consumption score corresponding to each target executor are calculated, and the response time score, result consistency score, and resource consumption score are weighted and summed to obtain the comprehensive score corresponding to each target executor. The real-time confidence weight of each target executor is updated based on the comprehensive score corresponding to each target executor.

9. An electronic device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein the processor, when executing the computer program, implements the mimicry defense method for the edge of the power Internet of Things as described in any one of claims 1 to 4.

10. A storage medium, characterized in that, The storage medium includes a stored computer program, wherein, when the computer program is executed, it controls the device where the storage medium is located to perform the mimicry defense method at the edge of the power Internet of Things as described in any one of claims 1 to 4.

Images