Information interaction method of power generation system and related device
By constructing a multi-level trust chain in the power production system and utilizing a triple verification mechanism of hardware identifiers, software identifiers, and dynamic tokens, the problem of information exchange delays caused by frequent authentication between power nodes is solved, thereby improving system efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- GUANGZHOU KETENG INFORMATION TECH
- Filing Date
- 2026-01-29
- Publication Date
- 2026-06-02
AI Technical Summary
In power production systems, information exchange between different power nodes is delayed due to the frequent authentication processes caused by differences in responsibilities and security requirements.
By constructing a multi-level trust chain among cascaded nodes and utilizing a triple verification mechanism of hardware identifiers, software identifiers, and dynamic tokens, the authentication frequency of controlled nodes is reduced, enabling efficient information exchange.
This effectively reduced the workload of controlled nodes, decreased the delay in information exchange, and improved the efficiency of the power production system.
Smart Images

Figure CN122137093A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of power monitoring technology, and in particular to an information interaction method and related equipment for a power production system. Background Technology
[0002] In power generation systems, different power nodes need to exchange power information. However, due to the different responsibilities performed by each power node and for power security reasons, security authentication adapted to each power node is also required when exchanging power information. Therefore, in related technologies, the authentication performed by power nodes increases the information exchange delay in the power generation system when the power nodes process data frequently and there is a lot of information exchange between them.
[0003] In summary, the technical problems existing in the relevant technologies need to be improved. Summary of the Invention
[0004] The main objective of this application is to propose an information interaction method and related equipment for a power production system, so as to reduce the workload of nodes that need to perform power information interaction.
[0005] To achieve the above objectives, one aspect of this application proposes an information interaction method for a power production system. The power production system includes multiple cascaded nodes, which are hierarchical nodes (superior, peer, and subordinate) based on their authority levels. The superior nodes are used to manage the subordinate nodes. When the method is applied to a controlled node, the method includes:
[0006] In response to a call request from the initiating node, the first docking request and first identity information of the controlled node are uploaded to the first superior node. The first superior node is the superior node of the initiating node and the controlled node. The first superior node is used to verify the legality of the first docking request based on the first identity information. Receive local verification information from the first superior node, wherein the local verification information is the verification information sent by the first superior node to the controlled node after determining the legality of the first docking request based on the first identity information; When the call information sent by the initiating node is received, the local verification information is used to verify the peer verification information in the call information to obtain a verification result. The peer verification information is the verification information distributed to the initiating node when the first superior node agrees to the call request. If the verification result is normal, perform power information interaction with the startup node.
[0007] In some embodiments, receiving local verification information from the first parent node includes: The system receives local verification information from the first superior node, which is authorized by the second superior node. The second superior node is the superior node of the controlled node, and the first superior node is the superior node of the second superior node. After receiving the first connection request through the first superior node and determining the legality of the first identity information, the second superior node allows the first superior node to send the local verification information.
[0008] In some embodiments, before uploading the first docking request and first identity information of the controlled node to the first parent node in response to a call request from the initiating node, the method further includes: Obtain the first identity information of the controlled node, the first identity information including hardware identification information, software identification information and dynamic token; The step of responding to a call request from the initiating node by uploading the first docking request and first identity information of the controlled node to the first parent node includes: In response to a call request from the initiating node, the first identity information is used to perform identity authentication on the first parent node; After the identity authentication of the first superior node is successful, the first docking request and the first identity information of the controlled node are uploaded to the first superior node.
[0009] In some embodiments, obtaining the first identity information of the controlled node includes: Determine the hardware identifier of the controlled node; The controlled node uploads its identity authorization and hardware identifier to the first superior node. After determining that the controlled node is legitimate based on the identity authorization, the first superior node generates software identification information for the controlled node and stores the hardware identifier. The system receives software identification information from the first parent node, combines the software identification information and hardware identification information to generate first identity information, wherein the hardware identification information is information generated by the first parent node based on the hardware identifier.
[0010] Another aspect of this application proposes an information interaction method for a power production system. The power production system includes multiple cascaded nodes, which are hierarchical nodes (superior, peer, and subordinate) based on their authority levels. The superior nodes are used to manage the subordinate nodes. When the method is applied to a node, it includes: Send a call request to the controlled node, and upload the second docking request and second identity information of the starting node to the third superior node. The third superior node is the superior node of the starting node, and the controlled node is the target node for the starting node to perform information interaction. Receive peer verification information from the third superior node, wherein the peer verification information is the verification information sent by the third superior node to the initiating node after determining the legality of the second docking request based on the second identity information; The call information sent to the controlled node and the peer verification information; After the peer verification information is verified by the controlled node, power information interaction is performed with the controlled node according to the call information.
[0011] In some embodiments, receiving peer verification information from the third upstream node includes: The system receives peer verification information from the third superior node, which is the superior node of the starting node and the superior node of the third superior node. After receiving the second docking request through the third superior node and determining the legality of the second identity information, the fourth superior node allows the third superior node to send the peer verification information.
[0012] In some embodiments, before sending the call request to the controlled node and uploading the second docking request and second identity information of the starting node to the third parent node, the method further includes: Determine the second hardware identifier of the boot node; The first identity license and the second hardware identifier of the startup node are uploaded to the third parent node. After the third parent node determines that the startup node is legitimate based on the identity license, it generates the second software identifier information of the startup node and stores the second hardware identifier. The system receives second software identification information from the third upstream node, combines the second software identification information, second hardware identification information, and dynamic token to generate second identity information. The second hardware identification information is information generated by the second upstream node based on the second hardware identifier.
[0013] To achieve the above objectives, one aspect of this application proposes an information interaction device for a power production system, the device comprising: The first upload module is used to respond to a call request from the starting node and upload the first docking request and the first identity information of the controlled node to the first superior node. The first superior node is the superior node of the starting node and the controlled node. The first superior node is used to verify the legality of the first docking request based on the first identity information. The first receiving module is used to receive local verification information from the first superior node. The local verification information is the verification information sent by the first superior node to the controlled node after determining the legality of the first docking request based on the first identity information. The verification module is used to verify the peer verification information in the call information using the local verification information when it receives the call information sent by the initiating node, and obtain the verification result. The peer verification information is the verification information distributed to the initiating node when the first superior node agrees to the call request. The first interaction module is used to perform power information interaction with the startup node if the verification result is normal.
[0014] Another aspect of this application provides an information interaction device for a power production system, the device comprising: The second upload module is used to send a call request to the controlled node and upload the second docking request and second identity information of the starting node to the third superior node. The third superior node is the superior node of the starting node, and the controlled node is the target node for the starting node to perform information interaction. The second receiving module is used to receive peer verification information from the third superior node. The peer verification information is the verification information sent by the third superior node to the initiating node after determining the legality of the second docking request based on the second identity information. The sending module is used to send the call information and the peer verification information to the controlled node; The second interaction module is used to perform power information interaction with the controlled node according to the call information after the peer verification information is verified by the controlled node.
[0015] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described above.
[0016] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods described above.
[0017] To achieve the above objectives, another aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the methods described above. The embodiments of this application include at least the following beneficial effects: This application provides an information interaction method, device, electronic device, storage medium and program product for a power production system. This solution allows the initiating node to obtain information interaction authorization from the controlled node's superior node before each power information interaction, without needing to obtain authorization from the controlled node. Under the condition that the controlled node faces a high-frequency working environment, this can effectively reduce the authentication frequency of the controlled node and alleviate the working pressure of the controlled node. Attached Figure Description
[0018] Figure 1 This is a structural diagram of the power generation system provided in the embodiments of this application; Figure 2 This is a flowchart of an information interaction method for a power production system provided in an embodiment of this application; Figure 3 This is a flowchart of another information interaction method for a power production system provided in an embodiment of this application; Figure 4 This is a flowchart illustrating an information interaction method provided in an embodiment of this application; Figure 5 This is a flowchart illustrating another information interaction method provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an information interaction device for a power production system provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of another information interaction device for a power production system provided in an embodiment of this application; Figure 8 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation
[0019] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.
[0020] 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 belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.
[0021] Before providing a detailed description of the embodiments of this application, some of the nouns and terms involved in the embodiments of this application will be explained first. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.
[0022] 1) Power production system: refers to the system that converts various primary energy sources into electrical energy and transmits and distributes it to users, including power generation, transmission, distribution, transformation and sales.
[0023] 2) Controlled node: A node that passively executes information exchange requests.
[0024] 3) Initiating node: The node that actively initiates a request for information exchange.
[0025] The information interaction method for a power production system provided in this application relates to the field of power monitoring technology. This method can be applied to a terminal, a server, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or vehicle-mounted terminal, but is not limited to these. The server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network. The software can be an application implementing the information interaction method for the power production system, but is not limited to the above forms.
[0026] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.
[0027] The power monitoring system is classified into multiple hierarchical nodes according to its functional type and data sensitivity. Three-dimensional authentication is defined for each hierarchical node, and a multi-level trust chain is built between the multiple hierarchical nodes. The multi-level power monitoring system is hierarchically divided according to functional type and data sensitivity, resulting in cascaded hierarchical nodes. These nodes are classified as superior, peer, and subordinate nodes based on their authority levels. Superior nodes can control other superior nodes. In this embodiment, the power production system is as follows: Figure 1 As shown, the nodes include multiple levels, and the specific hierarchical criteria are as follows: L1 level nodes (plant / station level monitoring nodes): These are the lowest level nodes, including power plant unit monitoring terminals, substation equipment monitoring units, and distribution room sensors—terminal nodes that directly collect equipment operation data. Data sensitivity is "low-medium" (e.g., real-time current and voltage data). The core requirement is "high-frequency authentication + lightweight process" to avoid authentication time-consuming processes affecting real-time data transmission.
[0028] Level 2 nodes (regional dispatch nodes): These are the superior nodes of Level 1 nodes, encompassing the servers and data aggregation gateways of the primary power dispatch center. They are responsible for receiving data from Level 1 nodes, performing local anomaly analysis, and reporting aggregated data to Level 3 nodes. Data sensitivity is "medium-high" (e.g., regional load curves, equipment fault early warning data). The requirement is "two-way authentication + access control," which verifies the identity of the Level 1 node and also proves its legitimacy to the Level 3 node.
[0029] Level 3 nodes (provincial dispatch nodes): These are the superior nodes of Level 2 nodes, serving as the core server and collaborative platform for the secondary power dispatch center. They are responsible for power data aggregation and issuing cross-regional dispatch instructions. The data sensitivity is "high" (e.g., provincial power supply shortage data, cross-regional power transmission plans), requiring "high-strength authentication + audit traceability," and needing to prevent unauthorized instruction tampering and data leakage.
[0030] Level 4 nodes (national root trust nodes): These are the superior nodes of Level 3 nodes and the root authentication servers of the three-tier power dispatch center. As the source of trust for the entire system, they are responsible for issuing root software identifiers and formulating authentication rules for Level 3 nodes, but do not directly participate in underlying data authentication. The data sensitivity is "extremely high" (e.g., national power supply and demand balance data), and the requirement is "physical isolation + multiple protections" to ensure that the root trust is not compromised.
[0031] For each level of node, define the three-dimensional authentication identity information for each node to ensure the uniqueness and integrity of the authentication. The three-dimensional authentication identity information includes: Hardware identification information: The device employs a dual hardware identification system consisting of a "TPM2.0 Trusted Platform Module + Hardware Unique Identifier (HUID)". The TPM chip incorporates national cryptographic algorithms (SM2 / SM3) and an immutable hardware root key for the storage node. The HUID is programmed into the device's motherboard at the factory and is bound to the device's physical hardware, preventing modification through software and ensuring "one device, one identifier".
[0032] Software Identification Information: A top-down software identification chain is constructed. The L4-level node acts as the root CA (Software Identification Issuing Authority), issuing "Provincial CA Software Identifiers" to L3-level nodes; the L3-level node acts as a secondary CA, issuing "Regional CA Software Identifiers" to L2-level nodes; and the L2-level node acts as a tertiary CA, issuing "Terminal Software Identifiers" to L1-level nodes. The software identification adopts the X.509v3 standard, adding three custom fields: "Level Identifier," "Data Access Permission," and "Software Identifier Validity Period." The "Level Identifier" clarifies the L1-L4 level to which the node belongs; the "Data Access Permission" limits the range of data that the node can read / modify (e.g., an L1 node can only access data collected by its own devices); and the "Software Identifier Validity Period" is dynamically set according to the node level (3 months for L1-level terminal software identifiers and 2 years for L3-level CA software identifiers).
[0033] Dynamic Tokens: Introducing Time-Based One-Time Tokens (TOTPs), each node has a built-in TOTP algorithm, and the key is synchronously issued by the superior node when the software identifier is issued. The token is updated every 30 seconds and together with the hardware identifier and software identifier serial number, it forms a "triple verification factor" for authentication, preventing identity forgery if a single factor is cracked.
[0034] In some embodiments, the writing of identity information is primarily implemented by the previous node of each node, specifically including: Determine the hardware identifier of the controlled node; The controlled node uploads its identity authorization and hardware identifier to the first parent node. After the first parent node determines that the controlled node is legitimate based on the identity authorization, it generates the software identification information of the controlled node and stores the hardware identifier. Receive software identification information from the first parent node, combine the software identification information and hardware identification information to generate first identity information, whereby the hardware identification information is generated by the first parent node based on the hardware identifier.
[0035] When an L4-level root trusted node leaves the factory, the national power security agency writes a root key (stored in a physically isolated encrypted server) and generates a root software identifier. The root software identifier is only used to issue software identification information for L3-level nodes and is not directly transmitted externally.
[0036] When an L3 node applies for identity information authentication, it must submit "node qualification documents" (such as administrative permits from the superior dispatch center and equipment lists) and "hardware identifier hash values" (SM3 (HUID+TPM root key)) to the L4 node. After verifying the authenticity of the qualification documents, the L4 node issues software identification information for the L3 node using the root key and stores the hardware identifier and software identifier information of the L3 node in the "root trust database". Similarly, when an L3 node issues regional software identification information for an L2 node, it needs to verify the hardware identifier and qualification of the L2 node and store its information in the trust database; when an L2 node issues software identification information for an L1 node, it needs to confirm the equipment ownership of the L1 node (such as the power plant / substation to which it belongs) and associate it with its corresponding monitoring equipment number to ensure that the "software identifier-equipment-level" are bound together.
[0037] In some embodiments, the hierarchical generation and distribution of key seeds are implemented, specifically including: For example, during key seed distribution, the L4 root node generates a "root seed" (a 256-bit random number encrypted using the SM2 algorithm) for the L3 nodes, and each L3 node has a unique root seed; the L3 nodes generate "region seeds" for their subordinate L2 nodes (based on the root seed and the hardware identifier of the L2 nodes, generated by SM3 hashing, i.e., region seed = SM3(root seed + HUID_L2)); the L2 nodes generate "terminal seeds" for their subordinate L1 nodes (based on the region seed and the device number of the L1 nodes, i.e., terminal seed = SM3(region seed + DeviceId_L1)).
[0038] Seed Distribution: Seeds are distributed via an "encrypted channel + dual verification" method. When distributing root seeds from L4 to L3, a dual protection mechanism of "Quantum Key Distribution (QKD) + SM2 encryption" is used (L3 nodes are located in the provincial dispatch center and have QKD access capabilities). When distributing regional seeds from L3 to L2, "IPsec VPN + SM2 encryption" is used. When distributing terminal seeds from L2 to L1, "LoRaWAN encrypted channel (applicable to wireless monitoring nodes) or industrial Ethernet encryption (applicable to wired nodes) + SM2 encryption" is used. After distribution, the lower-level nodes store the seeds in the "sealed storage area" of the TPM chip, which can only be read by a designated key derivation program and cannot be accessed by other software.
[0039] Seed Update: The seed update cycle is dynamically set according to node level—the root seed of L3 nodes is updated every 3 months, the regional seed of L2 nodes is updated every month, and the terminal seed of L1 nodes is updated every 15 days. During the update, after the parent node generates a new seed, it sends it to the lower-level nodes through the original encrypted channel; after the lower-level nodes verify the signature of the new seed (the SM2 signature of the parent node), they replace the old seed with the new seed and delete the old seed (forced erasure by the TPM chip, which cannot be recovered).
[0040] In some embodiments, a node can generate a corresponding dynamic key based on a key seed. Specifically, it reads the seed issued by the upper-level node from the TPM sealed storage area (e.g., an L1-level node reads the terminal seed); selects local monitoring data corresponding to the call request of the starting node (e.g., an L1-level node selects the instantaneous current and voltage values of the current transmission cycle and converts them into 32-bit binary numbers); and reads the real-time clock of the local TPM chip (accurate to milliseconds to avoid key mismatch caused by time synchronization errors between different nodes). A 256-bit AES key is generated using "SM3 hash + key expansion", with the specific formula: Dynamic key K = KeyExpansion(SM3(seed + real-time data feature + timestamp)). Here, "KeyExpansion" is the AES key expansion algorithm, which expands the 256-bit hash value generated by SM3 into a round key conforming to the AES-256 standard; "+" indicates string concatenation (e.g., if the seed is 256 bits, the real-time data feature is 64 bits, and the timestamp is 32 bits, the concatenated input is 352 bits).
[0041] The dynamic key is used only for the current data transmission. The sender encrypts the data with K (AES-256-GCM mode, and generates a data verification code (GCM-Tag)) and sends the "timestamp + hash value of real-time data feature (SM3 (real-time data feature))" along with the encrypted data. After receiving the data, the receiver reads the local real-time data feature of the same period, combines it with the sender's timestamp and its own stored seed, generates the same dynamic key K, uses K to decrypt the data and verify the GCM-Tag. After the data transmission is completed (decryption is successful and verification is passed), the sender and receiver immediately destroy K (K is forcibly cleared from memory by the TPM chip to avoid key residue).
[0042] When an anomaly is detected in the key stored in the TPM sealed storage area, this embodiment can perform key anomaly repair. Specifically, key anomaly repair is achieved through a tiered repair method: L1-level node repair: The L1-level node sends a "key repair request" to the L2-level node, which includes "hardware identifier + HUID + current timestamp". After verifying the validity of the request, the L2-level node generates a "temporary seed" (based on the regional seed and the request timestamp, i.e., temporary seed = SM3(regional seed + timestamp)) and sends it to the L1-level node through an encrypted channel. The L1-level node uses the temporary seed to generate a dynamic key and simultaneously starts a TPM chip self-test. If the self-test passes, the original terminal seed is restored. If the self-test fails, it is marked as "hardware abnormality", reported to the L2-level node, and awaits manual repair.
[0043] L2 / L3 level node repair: L2 level nodes send repair requests to L3 level nodes, and L3 level nodes generate temporary region seeds; L3 level nodes send repair requests to L4 level nodes, and L4 level nodes generate temporary root seeds; the validity period of temporary seeds is limited to 1 hour to avoid security risks caused by long-term use of temporary seeds.
[0044] When a key expiration is detected, key self-healing is performed: When a node generates a dynamic key, if it detects that the seed has expired, it immediately sends a "seed update request" to its parent node. The request includes "hardware identifier + current timestamp + old seed digest (SM3 (old seed))". After the upstream node verifies the legitimacy of the request, it generates a new seed (according to the seed generation rules in step two) and sends it to the node through an encrypted channel; After the node verifies the signature of the new seed (the SM2 signature of the parent node), it replaces the old seed with the new seed (the TPM chip forcibly erases the old seed), generates a new dynamic key, and resumes data transmission. After self-healing is complete, the node sends a "self-healing successful" response to the superior node, and the superior node updates the seed information in the trust database.
[0045] Software identification configuration error self-healing: When a node initiates identity verification, if the receiver finds that the software identification field is missing (such as the "data access permission" field is missing), it will report "software identification configuration error" to the sender and inform them of the missing field. The sending direction sends a "software identifier retransmission request" to its parent node. The request includes "hardware identifier + software identifier serial number + error reason". The upstream node queries the local software identifier database, regenerates a software identifier containing complete fields, signs it using the SM2 algorithm, and then sends it to the sender. The sender replaces the old software identifier with the new software identifier (deletes the old software identifier), re-initiates identity verification, and the self-healing process is complete.
[0046] TOTP token synchronization deviation self-healing: When the receiver verifies the TOTP token, it finds that the current token does not match, but "current token ±1" matches, which is determined to be a time synchronization deviation. The receiver sends a "time synchronization request" to the sender, which includes "the receiver's current timestamp + time synchronization deviation value (e.g., the sender's time is 5 seconds slower than the receiver's)"; The sender adjusts its local time based on the deviation value (calibrated via the BeiDou time synchronization system), regenerates the TOTP token, and completes self-healing after successful verification.
[0047] The specific construction process for building a multi-level trust chain among multiple hierarchical nodes is as follows: Trust Initialization: When the L4-level root trust node leaves the factory, the national power security agency writes the root key (stored in a physically isolated encrypted server) and generates a root software identifier. The root software identifier is only used to issue CA software identifiers for L3-level nodes and is not directly transmitted externally.
[0048] Trust Transfer: When an L3 node applies for authentication, it must submit "node qualification documents" (such as administrative permits and equipment lists from the provincial dispatch center) and "hardware identifier hash values" (SM3 (HUID+TPM root key)) to the L4 node. After verifying the authenticity of the qualification documents, the L4 node issues a provincial CA software identifier for the L3 node using the root key and stores the hardware and software identifier information of the L3 node in the "root trust database". Similarly, when an L3 node issues a regional CA software identifier for an L2 node, it must verify the hardware identifier and qualification of the L2 node and store its information in the provincial trust database; when an L2 node issues a terminal software identifier for an L1 node, it must confirm the equipment ownership of the L1 node (such as the power plant / substation to which it belongs) and associate it with its corresponding monitoring equipment number to ensure that the "software identifier-equipment-level" are bound together.
[0049] Peer-to-peer trust: When peer-to-peer nodes (such as two substation monitoring nodes within the same L2 level area) need to exchange data, mutual trust is achieved through "cross-authentication by the superior CA". For example, before L2 level node A and L2 level node B exchange data, both send a "mutual trust request" to their respective L3 level provincial CA. After verifying the validity of the software identifiers of both nodes, the provincial CA generates a "mutual trust authorization token" and issues it to A and B respectively. After receiving the token, A and B verify each other's identity through the token, eliminating the need to repeatedly forward data through L3 level nodes and reducing cross-node authentication latency.
[0050] For interactions between sibling nodes that do not belong to the same parent node, the method is to achieve this through "cross-authentication by a common parent CA". If sibling nodes that do not belong to the same parent node need to interact (taking L2 level nodes A and B as an example, where A belongs to L3 level node X and B belongs to L3 level node Y, and the common parent of X and Y is the L4 level root trusted node), mutual trust needs to be established by extending to the common parent CA (L4 level root CA) based on the "cross-authentication of parent CA" logic in the document. The specific process derivation is as follows (strictly following the core rules of "software identification chain" and "trust transfer" in the document): Initiating a mutual trust request: L2 node A submits a "cross-superior mutual trust request" to its direct superior L3 node X, along with its own "terminal software identifier (issued by X) + hardware identifier hash value (SM3(HUID+TPM root key))"; at the same time, L2 node B submits a "cross-superior mutual trust request" with the same content to its direct superior L3 node Y.
[0051] The direct parent CA forwards the request to the next higher level: After L3 node X verifies the validity of A's software identifier (based on its own CA software identifier), it forwards the request to the common parent level of X and Y - the L4 root trust node (root CA); similarly, after L3 node Y verifies the validity of B's software identifier, it also forwards the request to the L4 root trust node.
[0052] Common upper-level CA verification and authorization: The L4 root trust node verifies the legitimacy of A and B's identities through "software identifier chain tracing". Verify the CA software identifiers of L3 nodes X and Y (issued by L4 and possessing legitimacy); Based on the CA software identifiers of X and Y, the terminal software identifiers of A and B are further verified (issued by X and Y respectively, conforming to hierarchical identifiers and data access permission rules); after the verification is successful, the L4 root trust node generates a "cross-upper-level mutual trust authorization token" and issues it to the L2 nodes A and B respectively through the L3 nodes X and Y.
[0053] Peer-to-peer trust verification: After receiving the "mutual trust authorization token", L2 nodes A and B verify each other's identity through the "L4 root CA signature" in the token (without direct communication with L4 nodes). Once the verification is successful, data interaction can be achieved without forwarding through their respective direct superior nodes.
[0054] The objects of authentication and mutual trust are the two peer nodes that are interacting. Regardless of whether they belong to the same parent node, the core authentication objects for "peer trust" in the document are the two peer nodes that initiated the interaction, not the parent node. The specific authentication content strictly follows the "three-dimensional authentication" and "software identification rules" defined in the document, that is, verifying the other party's: Hardware identification (HUID + TPM chip identification, ensuring the legitimacy of physical devices); Software identifier (the hierarchical identifier of the terminal software, data access permissions, and validity period, ensuring compliance with system hierarchy rules); Mutual trust authorization token (issued by the superior CA / common superior CA, ensuring verification through the trust chain).
[0055] After each node completes the entry of its identity information, it can also realize anomaly detection and anomaly response strategies during the operation of the power production system. Level 1 anomaly (minor anomaly, can be automatically repaired): Anomaly types: Key expired (seed was found to have expired during dynamic key generation), Certificate configuration error (certificate fields are missing or format is incorrect), TOTP token synchronization deviation (deviation ≤ 2 cycles), Single verification failure (not continuous).
[0056] Scope of impact: Only affects a single node; it does not affect data transmission on other nodes.
[0057] Response strategy: Initiate an automatic self-healing process without manual intervention; during the self-healing process, the node pauses data transmission (≤10 seconds), and automatically resumes transmission after self-healing is completed; at the same time, record the abnormal log and mark it as "self-healed".
[0058] Level 2 abnormality (moderate abnormality, requiring limited human intervention): Anomaly types: 3 consecutive verification failures, seed update failure (caused by network interruption), level 1 behavioral anomaly warning lasting 5 minutes, hardware identifier verification mismatch (possibly due to device failure).
[0059] Scope of impact: A single node or a small number of peer nodes (≤5) may affect local data aggregation (e.g., if an L1 node is abnormal, it may affect the regional data aggregation of its corresponding L2 node).
[0060] Response strategy: First, initiate the automatic self-healing process. If self-healing fails (e.g., seed update failure, continuous network interruption), send a "self-healing failure request" to the parent node. The parent node will attempt remote repair (e.g., re-distribute the seed, remotely reset the certificate). If remote repair fails, trigger manual intervention warning (send SMS / email reminder to the administrator) and isolate the abnormal node (prohibit it from communicating with other nodes) to avoid affecting other nodes.
[0061] Level 3 abnormality (severe abnormality requiring urgent manual intervention): Anomaly types: Identity forgery (simultaneous authentication of the same HUID at different locations), key leakage (detection of unfamiliar devices using legitimate keys), TPM chip hardware failure (unable to read hardware identifiers), and Level 3 warning for abnormal behavior (such as identity mismatch in a batch of L1 nodes).
[0062] Impact scope: Multiple nodes (≥10) or high-level nodes (L3 / L4 level) may cause regional or provincial data transmission interruptions, and may even affect power dispatch.
[0063] Response strategy: Immediately isolate the abnormal node (cut off its network connection) and report it to the L4 root trusted node; activate the "emergency data transmission channel" (e.g., L2 nodes bypass the abnormal L1 node and directly obtain data from the backup L1 node) to ensure core data transmission; the administrator must respond within 30 minutes, conduct on-site investigation (e.g., check the hardware of the abnormal node and trace the source of the attack), and after the repair is completed, identity authentication and key distribution must be re-performed before node access can be restored.
[0064] After the power generation system in this embodiment is configured as described above, during operation, if... Figure 2 As shown, when information interaction is applied to the startup node, the specific steps include: Step 201: Send a call request to the controlled node and upload the second docking request and second identity information of the starting node to the third superior node. The third superior node is the superior node of the starting node, and the controlled node is the target node for the starting node to perform information interaction. Step 202: Receive peer verification information from the third superior node. The peer verification information is the verification information sent by the third superior node to the initiating node after determining the legality of the second docking request based on the second identity information. Step 203: Send the call information and peer verification information to the controlled node; Step 204: After the peer verification information is verified by the controlled node, power information interaction is performed with the controlled node according to the call information.
[0065] At the controlled node end, such as Figure 3 As shown, the specific steps include: Step 301: In response to the call request from the starting node, the first docking request and the first identity information of the controlled node are uploaded to the first parent node. The first parent node is the parent node of both the starting node and the controlled node. The first parent node is used to verify the legality of the first docking request based on the first identity information. Step 302: Receive local verification information from the first superior node. The local verification information is the verification information sent by the first superior node to the controlled node after determining the legality of the first docking request based on the first identity information. Step 303: When receiving the call information sent by the starting node, the local verification information is used to verify the peer verification information in the call information to obtain the verification result. The peer verification information is the verification information distributed to the starting node when the first superior node agrees to the call request. Step 304: If the verification result is normal, perform power information interaction with the startup node.
[0066] When the initiating node and the controlled node (such as two substation monitoring nodes within the same L2 level area) need to exchange data, mutual trust is achieved through the parent node of both the initiating node and the controlled node. For example, ... Figure 4 As shown, before L2 node A and L2 node B interact with each other, they both send a "mutual trust request" to their respective L3 node. After verifying the validity of the identity information of both parties, the L3 node generates a "mutual trust authorization token" and issues it to A and B respectively. After receiving the token, A and B verify each other's identity through the token, without having to forward data through the L3 node again, thus reducing cross-node authentication latency.
[0067] In some embodiments, the initiating node and the controlled node do not belong to the same parent node. In this case, it is necessary to further determine the parent node of the initiating node and the controlled node, and the parent node shall perform the verification between the initiating node and the controlled node.
[0068] When determining the next higher level node of the controlled node, the local verification information from the first higher level node is received with the permission of the second higher level node. The second higher level node is the higher level node of the controlled node, and the first higher level node is the higher level node of the second higher level node. After the second higher level node receives the first docking request through the first higher level node and confirms the legality of the first identity information, it allows the first higher level node to send the local verification information.
[0069] When determining the next higher level node of the starting node, the fourth higher level node receives peer verification information from the third higher level node, which is allowed by the fourth higher level node. The fourth higher level node is the higher level node of the starting node and the higher level node of the third higher level node. After receiving the second docking request through the third higher level node and verifying the legality of the second identity information, the fourth higher level node allows the third higher level node to send peer verification information.
[0070] like Figure 5 As shown, L2 node A submits a "cross-superior mutual trust request" to its direct superior L3 node X, along with its own primary identity information "terminal certificate (issued by X) + hardware identifier hash value (SM3(HUID+TPM root key))"; at the same time, L2 node B submits the same "cross-superior mutual trust request" to its direct superior L3 node Y.
[0071] After L3 node X verifies the validity of A's first identity information, it forwards the request to the common parent node of X and Y—the L4 root trust node; similarly, after L3 node Y verifies the validity of B's second identity information, it also forwards the request to the L4 root trust node.
[0072] The L4 root trust node verifies the legitimacy of A and B's identities through traceability. Once the verification is successful, the L4 root trust node generates a "cross-superior mutual trust authorization token" and issues it to L2 nodes A and B through L3 nodes X and Y, respectively.
[0073] Please see Figure 6 This application also provides an information interaction device for a power production system, which can implement the above-described method. The device includes: The first upload module 61 is used to respond to a call request from the starting node and upload the first docking request and the first identity information of the controlled node to the first superior node. The first superior node is the superior node of the starting node and the controlled node. The first superior node is used to verify the legality of the first docking request based on the first identity information. The first receiving module 62 is used to receive local verification information from the first superior node. The local verification information is the verification information sent by the first superior node to the controlled node after determining the legality of the first docking request based on the first identity information. Verification module 63 is used to verify the peer verification information in the call information using the local verification information when it receives the call information sent by the initiating node, and obtain a verification result. The peer verification information is the verification information distributed to the initiating node when the first superior node agrees to the call request. The first interaction module 64 is used to perform power information interaction with the startup node if the verification result is normal.
[0074] In some embodiments, the first receiving module 62 is configured to: The system receives local verification information from the first superior node, which is authorized by the second superior node. The second superior node is the superior node of the controlled node, and the first superior node is the superior node of the second superior node. After receiving the first connection request through the first superior node and determining the legality of the first identity information, the second superior node allows the first superior node to send the local verification information.
[0075] In some embodiments, the information interaction device of the power production system further includes: a first identity information acquisition module 65, used to acquire the first identity information of the controlled node, wherein the first identity information includes hardware identification information, software identification information and dynamic token; The first upload module 61 is used to respond to a call request from the starting node and perform identity authentication of the first superior node using the first identity information; After the identity authentication of the first superior node is successful, the first docking request and the first identity information of the controlled node are uploaded to the first superior node.
[0076] In some embodiments, the first identity information acquisition module 65 is configured to: Determine the hardware identifier of the controlled node; The controlled node uploads its identity authorization and hardware identifier to the first superior node. After determining that the controlled node is legitimate based on the identity authorization, the first superior node generates software identification information for the controlled node and stores the hardware identifier. The system receives software identification information from the first parent node, combines the software identification information and hardware identification information to generate first identity information, wherein the hardware identification information is information generated by the first parent node based on the hardware identifier.
[0077] refer to Figure 7 This application also provides another information interaction device for a power production system, which can implement the above method. The device includes: The second upload module 71 is used to send a call request to the controlled node and upload the second docking request and second identity information of the starting node to the third superior node. The third superior node is the superior node of the starting node, and the controlled node is the target node for the starting node to perform information interaction. The second receiving module 72 is used to receive peer verification information from the third upper-level node. The peer verification information is the verification information sent by the third upper-level node to the starting node after determining the legality of the second docking request based on the second identity information. The sending module 73 is used to send the call information and the peer verification information to the controlled node; The second interaction module 74 is used to perform power information interaction with the controlled node according to the call information after the peer verification information is verified by the controlled node.
[0078] In some embodiments, the second receiving module 72 is configured to receive peer verification information from the third upper-level node, which is allowed by the fourth upper-level node. The fourth upper-level node is the upper-level node of the starting node and the upper-level node of the third upper-level node. After receiving the second docking request through the third upper-level node and determining the legality of the second identity information, the fourth upper-level node allows the third upper-level node to send the peer verification information.
[0079] In some embodiments, an information interaction device for a power production system further includes a second identity information acquisition module 75, used for: Determine the second hardware identifier of the boot node; The first identity license and the second hardware identifier of the startup node are uploaded to the third parent node. After the third parent node determines that the startup node is legitimate based on the identity license, it generates the second software identifier information of the startup node and stores the second hardware identifier. The system receives second software identification information from the third upstream node, combines the second software identification information, second hardware identification information, and dynamic token to generate second identity information. The second hardware identification information is information generated by the second upstream node based on the second hardware identifier.
[0080] It is understood that the content of the above method embodiments is applicable to the present device embodiments. The specific functions implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.
[0081] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.
[0082] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.
[0083] Please see Figure 8 , Figure 8 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 801 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 802 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 802 can store the operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 802 and is called and executed by the processor 801 using the methods described in the embodiments of this application. The 803 input / output interface is used to implement information input and output. The communication interface 804 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 805 transmits information between various components of the device (e.g., processor 801, memory 802, input / output interface 803, and communication interface 804); The processor 801, memory 802, input / output interface 803, and communication interface 804 are connected to each other within the device via bus 805.
[0084] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.
[0085] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.
[0086] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.
[0087] It is understood that the content of the above method embodiments is applicable to the embodiments of this program product. The specific functions implemented by the embodiments of this program product are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.
[0088] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.
[0089] The information interaction method, apparatus, electronic device, storage medium, and program product for power production systems provided in this application embodiment can effectively reduce the authentication frequency of controlled nodes and alleviate their workload under conditions where controlled nodes face high-frequency working environments. This is achieved by allowing the initiating node to obtain information interaction authorization from the controlled node's superior node before each power information interaction, without needing to obtain authorization from the controlled node.
[0090] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.
[0091] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.
[0092] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; 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.
[0093] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.
[0094] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0095] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.
[0096] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.
[0097] The units described above as separate components may or may not be physically separate. 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 units can be selected to achieve the purpose of this embodiment according to actual needs.
[0098] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0099] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0100] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.
Claims
1. An information interaction method for a power production system, characterized in that, The power production system includes multiple cascaded nodes, which are hierarchical nodes, peer nodes, and subordinate nodes based on their authority levels. The superior nodes are used to manage the subordinate nodes. When the method is applied to the controlled nodes, it includes: In response to a call request from the initiating node, the first docking request and first identity information of the controlled node are uploaded to the first superior node. The first superior node is the superior node of the initiating node and the controlled node. The first superior node is used to verify the legality of the first docking request based on the first identity information. Receive local verification information from the first superior node, wherein the local verification information is the verification information sent by the first superior node to the controlled node after determining the legality of the first docking request based on the first identity information; When the call information sent by the initiating node is received, the local verification information is used to verify the peer verification information in the call information to obtain a verification result. The peer verification information is the verification information distributed to the initiating node when the first superior node agrees to the call request. If the verification result is normal, perform power information interaction with the startup node.
2. The method according to claim 1, characterized in that, The receiving of local verification information from the first superior node includes: The system receives local verification information from the first superior node, which is authorized by the second superior node. The second superior node is the superior node of the controlled node, and the first superior node is the superior node of the second superior node. After receiving the first connection request through the first superior node and determining the legality of the first identity information, the second superior node allows the first superior node to send the local verification information.
3. The method according to claim 1, characterized in that, Before uploading the first docking request and first identity information of the controlled node to the first parent node in response to the call request from the initiating node, the method further includes: Obtain the first identity information of the controlled node, the first identity information including hardware identification information, software identification information and dynamic token; The step of responding to a call request from the initiating node by uploading the first docking request and first identity information of the controlled node to the first parent node includes: In response to a call request from the initiating node, the first identity information is used to perform identity authentication on the first parent node; After the identity authentication of the first superior node is successful, the first docking request and the first identity information of the controlled node are uploaded to the first superior node.
4. The method according to claim 3, characterized in that, The step of obtaining the first identity information of the controlled node includes: Determine the hardware identifier of the controlled node; The controlled node uploads its identity authorization and hardware identifier to the first superior node. After determining that the controlled node is legitimate based on the identity authorization, the first superior node generates software identification information for the controlled node and stores the hardware identifier. The system receives software identification information from the first parent node, combines the software identification information and hardware identification information to generate first identity information, wherein the hardware identification information is information generated by the first parent node based on the hardware identifier.
5. An information interaction method for a power production system, characterized in that, The power production system includes multiple cascaded nodes, which are hierarchical nodes, peer nodes, and subordinate nodes based on their authority levels. The superior nodes manage the subordinate nodes. The method, when applied to a node startup, includes: Send a call request to the controlled node, and upload the second docking request and second identity information of the starting node to the third superior node. The third superior node is the superior node of the starting node, and the controlled node is the target node for the starting node to perform information interaction. Receive peer verification information from the third superior node, wherein the peer verification information is the verification information sent by the third superior node to the initiating node after determining the legality of the second docking request based on the second identity information; The call information sent to the controlled node and the peer verification information; After the peer verification information is verified by the controlled node, power information interaction is performed with the controlled node according to the call information.
6. The method according to claim 5, characterized in that, The receiving of peer verification information from the third upstream node includes: The system receives peer verification information from the third superior node, which is the superior node of the starting node and the superior node of the third superior node. After receiving the second docking request through the third superior node and determining the legality of the second identity information, the fourth superior node allows the third superior node to send the peer verification information.
7. The method according to claim 6, characterized in that, Before sending the call request to the controlled node and uploading the second docking request and second identity information of the starting node to the third superior node, the method further includes: Determine the second hardware identifier of the boot node; The first identity license and the second hardware identifier of the startup node are uploaded to the third parent node. After the third parent node determines that the startup node is legitimate based on the identity license, it generates the second software identifier information of the startup node and stores the second hardware identifier. The system receives second software identification information from the third upstream node, combines the second software identification information, second hardware identification information, and dynamic token to generate second identity information. The second hardware identification information is information generated by the second upstream node based on the second hardware identifier.
8. An information interaction device for a power production system, characterized in that, The device includes: The first upload module is used to respond to a call request from the starting node and upload the first docking request and the first identity information of the controlled node to the first superior node. The first superior node is the superior node of the starting node and the controlled node. The first superior node is used to verify the legality of the first docking request based on the first identity information. The first receiving module is used to receive local verification information from the first superior node. The local verification information is the verification information sent by the first superior node to the controlled node after determining the legality of the first docking request based on the first identity information. The verification module is used to verify the peer verification information in the call information using the local verification information when it receives the call information sent by the initiating node, and obtain the verification result. The peer verification information is the verification information distributed to the initiating node when the first superior node agrees to the call request. The first interaction module is used to perform power information interaction with the startup node if the verification result is normal.
9. An information interaction device for a power production system, characterized in that, The device includes: The second upload module is used to send a call request to the controlled node and upload the second docking request and second identity information of the starting node to the third superior node. The third superior node is the superior node of the starting node, and the controlled node is the target node for the starting node to perform information interaction. The second receiving module is used to receive peer verification information from the third superior node. The peer verification information is the verification information sent by the third superior node to the initiating node after determining the legality of the second docking request based on the second identity information. The sending module is used to send the call information and the peer verification information to the controlled node; The second interaction module is used to perform power information interaction with the controlled node according to the call information after the peer verification information is verified by the controlled node.
10. An electronic device comprising a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the method as claimed in any one of claims 1 to 7.