Power transmission line monitoring data disaster recovery method and system

Abstract

This application provides a disaster recovery method and system for transmission line monitoring data, relating to the field of transmission line technology. The method includes: obtaining raw monitoring data by dynamically and continuously monitoring the transmission line through acquisition nodes, and standardizing and converting the raw monitoring data to form standard log information; backing up the standard log information to a blockchain network by activating a smart contract through a consensus node; receiving a disaster recovery instruction, and restoring the on-chain information in the blockchain network based on the disaster recovery instruction through a recovery node. This application solves the technical problem in the prior art where traditional backup methods are easily damaged, leading to data loss or recovery failure during disaster recovery, further affecting the reliability of transmission line monitoring data. By applying blockchain technology to the disaster recovery backup and recovery of transmission line monitoring data, the efficiency of the disaster recovery process is improved, thereby enhancing the reliability of transmission line monitoring data.

Description

Technical Field

[0001] This application relates to the field of power transmission line technology, and in particular to a method and system for disaster recovery of power transmission line monitoring data. Background Technology

[0002] Dynamic and continuous monitoring along power transmission lines is conducted to acquire a large amount of raw monitoring data to ensure the stable operation of power transmission lines. To prevent the loss of raw monitoring data due to equipment failure, natural disasters, human sabotage, or cyberattacks, which could cause irreparable damage, an effective data backup and disaster recovery mechanism is needed. Currently, traditional data backup methods mostly rely on local backup, centralized remote backup, and distributed backup. However, backup systems themselves are vulnerable to various forms of damage, easily leading to the loss, corruption, or inconsistency of backup data. When a disaster occurs and a disaster recovery process needs to be initiated, if the backup data itself is unavailable or invalid, it will directly lead to recovery failure, significantly reducing the reliability and availability of the entire power transmission line monitoring data.

[0003] In summary, existing technologies suffer from the technical problem that traditional backup methods are easily compromised, leading to data loss or recovery failure during disaster recovery, which further affects the reliability of transmission line monitoring data. Summary of the Invention

[0004] The purpose of this application is to provide a disaster recovery method and system for transmission line monitoring data, in order to solve the technical problem in the prior art that the traditional backup method is easily damaged, resulting in data loss or recovery failure during disaster recovery, which further affects the reliability of transmission line monitoring data.

[0005] In view of the above problems, this application provides a method and system for disaster recovery of transmission line monitoring data.

[0006] Firstly, this application provides a disaster recovery method for transmission line monitoring data. This method is implemented through a transmission line monitoring data disaster recovery system. The method includes: obtaining raw monitoring data by dynamically and continuously monitoring the transmission line through acquisition nodes; standardizing and converting the raw monitoring data to form standard log information; backing up the standard log information to a blockchain network by activating a smart contract through a consensus node; receiving a disaster recovery instruction; and restoring the on-chain information in the blockchain network based on the disaster recovery instruction through a recovery node.

[0007] Optionally, raw monitoring data is obtained by dynamically and continuously monitoring the transmission line through acquisition nodes, and the raw monitoring data is standardized and transformed to form standard log information, including: reading predetermined log categories, analyzing the raw monitoring data based on the predetermined log categories to obtain log category data; and forming the standard log information based on the log category data; wherein, the predetermined log categories include execution result code, log identifier, timestamp, database object, table name, operation type, and data content.

[0008] Optionally, before activating the smart contract through the consensus node to back up the standard log information to the blockchain network, the process includes: obtaining a predetermined consensus mechanism and storing the predetermined consensus mechanism in the consensus node; wherein the predetermined consensus mechanism includes proof-of-work and / or proof-of-stake and / or proof-of-authority.

[0009] Optionally, the smart contract includes a data processing smart contract, an identity verification smart contract, and an on-chain data storage smart contract. Activating the smart contract through a consensus node to back up the standard log information to the blockchain network includes: mapping the standard log information to the timestamp using the data processing smart contract to form the on-chain information; after the on-chain information is verified by the identity verification smart contract, obtaining the transaction hash value through the on-chain data storage smart contract; and storing the on-chain information to the blockchain network based on the correspondence between the transaction hash value and the timestamp.

[0010] Optionally, storing the on-chain information in the blockchain network based on the correspondence between the transaction hash value and the timestamp includes: dividing the blockchain network to obtain a set of shards, wherein the set of shards includes a first shard; collecting first real-time state information of the first shard and performing weighted analysis on the first real-time state information to obtain a first real-time state index; sorting and analyzing the first shard based on the first real-time state index to obtain an optimal shard; and storing the on-chain information in the optimal shard based on the correspondence between the transaction hash value and the timestamp; wherein the first real-time state information includes a first CPU utilization rate, a first network speed, a first memory utilization rate, and a first hard disk read / write speed.

[0011] Optionally, receiving a disaster recovery instruction and restoring the on-chain information in the blockchain network through a recovery node based on the disaster recovery instruction includes: completing identity verification through the identity verification smart contract based on the disaster recovery instruction, and verifying the request transaction hash value and request timestamp of the requested data to be restored through the on-chain data storage smart contract; determining the optimal shard based on the request transaction hash value and the request timestamp, and retrieving a predetermined recovery strategy to restore the on-chain information in the optimal shard.

[0012] Optionally, the predetermined recovery strategy includes a first recovery strategy and a second recovery strategy; wherein, the first recovery strategy refers to converting the standard log information into a database operation language and performing ordered recovery based on the timestamp; wherein, the second recovery strategy refers to performing predetermined replacement processing on the operation types in the standard log information, and performing ordered recovery based on the timestamp after the predetermined replacement processing, wherein the predetermined replacement includes mutual replacement of insertion and deletion operations and replacement of data before and after update operations.

[0013] Optionally, receiving a disaster recovery instruction and restoring the on-chain information in the blockchain network through a recovery node based on the disaster recovery instruction further includes: real-time monitoring to obtain recovery status data, wherein the recovery status data includes first recovery data of a first monitoring indicator; obtaining adjacent monitoring data of the original monitoring data and matching the first adjacent data corresponding to the first monitoring indicator in the adjacent monitoring data; comparing the first adjacent data with the first recovery data to obtain a first support; if the first support does not reach a predetermined support threshold, issuing a first warning signal, wherein the first warning signal is used to characterize the abnormal recovery status of the first monitoring indicator.

[0014] Optionally, obtaining the first support by comparing the first adjacent data with the first recovered data includes: sequentially performing time-series curve processing on the first adjacent data and the first recovered data to obtain the first adjacent curve and the first recovered curve, respectively; comparing the first adjacent curve and the first recovered curve to obtain the curve similarity, and normalizing it to become the first support.

[0015] Secondly, this application also provides a disaster recovery system for transmission line monitoring data, used to execute the disaster recovery method for transmission line monitoring data as described in the first aspect. The system includes: a dynamic monitoring module, used to obtain raw monitoring data by dynamically and continuously monitoring the transmission line through acquisition nodes, and to standardize and convert the raw monitoring data to form standard log information; an information backup module, used to back up the standard log information to the blockchain network by activating a smart contract through a consensus node; and an information recovery module, used to receive disaster recovery instructions and, based on the disaster recovery instructions, to recover the on-chain information in the blockchain network through a recovery node.

[0016] One or more technical solutions provided in this application have at least the following beneficial effects:

[0017] Raw monitoring data is obtained through dynamic and continuous monitoring of transmission lines by data acquisition nodes. This raw monitoring data is then standardized and transformed to form standard log information. A consensus node activates a smart contract to back up this standard log information to the blockchain network. A disaster recovery command is received, and based on this command, a recovery node restores the on-chain information in the blockchain network. In other words, by leveraging the decentralized and immutable nature of blockchain, the security and integrity of the monitoring data after backup are ensured. The automated execution of data backup, verification, and recovery through smart contracts ensures the security and reliability of data recovery, improving disaster recovery efficiency and the credibility of transmission line monitoring data.

[0018] The above description is merely an overview of the technical solution of this application. To better understand the technical means of this application and to facilitate its implementation according to the description, and to make the above and other objects, features, and advantages of this application more apparent, specific embodiments of this application are described below. It should be understood that the content described in this section is not intended to identify key or important features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent through the following description. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are merely exemplary. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating the disaster recovery method for transmission line monitoring data in this application.

[0021] Figure 2 This is a schematic diagram of the disaster recovery system for transmission line monitoring data in this application.

[0022] Explanation of reference numerals in the attached diagram: Dynamic monitoring module 11, information backup module 12, information recovery module 13. Detailed Implementation

[0023] This application provides a disaster recovery method and system for transmission line monitoring data, solving the technical problem in existing technologies where traditional backup methods are easily compromised, leading to data loss or recovery failure during disaster recovery, further affecting the reliability of transmission line monitoring data. By utilizing the decentralized and immutable characteristics of blockchain, the security and integrity of monitoring data are guaranteed after backup. Smart contracts automate the execution of data backup, verification, and recovery, ensuring the security and reliability of data recovery, thus improving disaster recovery efficiency and the reliability of transmission line monitoring data.

[0024] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. It should be understood that this application is not limited to the exemplary embodiments described herein. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application. It should also be noted that, for ease of description, only the parts related to this application are shown in the accompanying drawings, not all of them.

[0025] Example 1, please refer to the appendix. Figure 1 This application provides a disaster recovery method for transmission line monitoring data, wherein the disaster recovery method for transmission line monitoring data is executed through a transmission line monitoring data disaster recovery system, and the specific steps of the disaster recovery method for transmission line monitoring data are as follows:

[0026] Raw monitoring data is obtained by dynamically and continuously monitoring the transmission lines through data acquisition nodes, and the raw monitoring data is then standardized and converted to form standard log information.

[0027] Furthermore, this application also includes the following steps: reading a predetermined log category, and analyzing the original monitoring data based on the predetermined log category to obtain log category data; forming the standard log information based on the log category data; wherein, the predetermined log category includes execution result code, log identifier, timestamp, database object, table name, operation type, and data content.

[0028] Specifically, data acquisition nodes are nodes deployed on power transmission lines, containing various sensors (such as temperature sensors, vibration sensors, tilt sensors, image sensors, etc.) and data acquisition units. They are used to monitor the transmission lines and acquire real-time data on parameters such as current, voltage, temperature, and humidity. Data acquisition nodes perform dynamic and continuous monitoring of the transmission lines, obtaining raw monitoring data such as current, voltage, temperature, and load, which are collected periodically by sensors. This data is unprocessed and typically obtained directly from the sensors or equipment. For example, data acquisition node A performs dynamic and continuous monitoring of tower 45. The raw monitoring data collected at 15:00:00 includes current 150A, voltage 110V, frequency 50.00Hz, temperature 40℃, power 5.5kW, and humidity 60%; the raw monitoring data collected at 15:00:10 includes current 149.5A, voltage 110.2V, frequency 50.01Hz, temperature 40.5℃, power 5.48kW, and humidity 59.5%.

[0029] The system reads predefined log categories and matches the raw monitoring data with these categories for analysis. These categories specify the information fields each log record must contain, including the execution result code, log identifier, timestamp, database object, table name, operation type, and data content. The execution result code records the result of an operation, such as success or failure; the log identifier is a code or number used to uniquely identify a log record; the timestamp records the specific date and time of the event or data collection, usually accurate to the second or millisecond; the database object indicates which database objects (such as tables or records) were operated on, indicating which data object the current operation targeted, such as a specific monitoring data table or device table; the table name is the name of the table storing the data in the database, indicating the specific table involved in the operation; the operation type is the type of operation performed, common operation types include insert, delete, update, and read; and the data content is the core information of the log record, including the specific data values.

[0030] The predefined log categories define the structure of the logs and the meaning of each field. Matching the raw monitoring data with these predefined log categories yields log category data. Based on the extracted and populated log category data, and following the structure of the predefined log category template, these data are combined to form one or more structured standard log entries. For example, an execution result code of 0000, log identifier of L00001, timestamp of 0301-14:30:00.000, database object of device status, table name of temperature data table, operation type of temperature sampling, and data content of temperature 40℃. Log category data is categorized data obtained by analyzing raw monitoring data and mapping it to predefined log categories. It includes various detailed information from the device operation logs, such as operation type and data content.

[0031] By further processing and formatting the log category data, standard log information is obtained. Raw monitoring data is obtained through dynamic continuous monitoring of transmission lines via data acquisition nodes. This raw monitoring data is then standardized to form standard log information. Standard log information is data records organized according to a predetermined format (such as including specific fields like timestamps, sensor types, measured values, and status descriptions). By standardizing the raw monitoring data to form standard log information, the problem of data format incompatibility is solved, and the readability and traceability of the data are improved.

[0032] The standard log information is backed up to the blockchain network by activating the smart contract through the consensus node.

[0033] Furthermore, this application also includes the following steps: obtaining a predetermined consensus mechanism and storing the predetermined consensus mechanism in the consensus node; wherein the predetermined consensus mechanism includes proof-of-work and / or proof-of-stake and / or proof-of-authority.

[0034] Specifically, a pre-defined consensus mechanism is a set of rules or algorithms pre-defined and stored within a blockchain network to determine which transactions can be recorded on the blockchain. This determines how consensus is reached among nodes, ensuring data reliability and consistency. Pre-defined consensus mechanisms include Proof-of-Work (PoW) and / or Proof-of-Stake (PoS) and / or Proof-of-Delegation (POD). PoW is a consensus mechanism that requires nodes to perform a certain amount of computational work to gain the right to create new blocks. In PoW, nodes must solve a mathematical problem; only after successfully solving it can they package the transaction information into a new block and add it to the blockchain. The computational difficulty of PoW adjusts with the total computing power of the network and typically requires significant computational resources. PoS is another consensus mechanism that does not require nodes to perform extensive computation. Instead, nodes gain the right to generate new blocks by holding a certain amount of cryptocurrency (i.e., stake). The larger the stake, the higher the probability of being selected as a block generator. PoS is generally more energy-efficient than PoW and has been used in many blockchain systems. In the Proof-of-Delegation consensus mechanism, the validating nodes in the blockchain network are typically pre-authorized, strictly verified trusted nodes responsible for verifying transactions and generating new blocks. The authorization proof mechanism relies primarily on the reputation of these nodes, rather than their computing power or the cryptocurrency they hold.

[0035] Clearly define the consensus mechanism used in the blockchain network to be employed. For example, is it the traditional, computationally intensive Proof-of-Work, the more energy-efficient, token-based Proof-of-Stake, or the more efficient, community-voted Proof-of-Delegation? Select a suitable consensus mechanism based on the needs and store it as the predetermined consensus mechanism on the consensus nodes. Consensus nodes are the nodes in the blockchain network responsible for verifying transactions and maintaining the legitimacy of the blockchain. Storing the consensus mechanism on the consensus nodes ensures that all consensus nodes in the network follow the same rules, guaranteeing data consistency.

[0036] Configure and update the parameters of the consensus algorithm on the consensus nodes. For example, if Proof-of-Work is chosen, the node needs to obtain the settings for the miners' computational difficulty; if Proof-of-Stake is chosen, the node needs to know the staking rules for the participants. The definition, related parameters, and rules of the consensus mechanism are broadcast to all participating consensus nodes through the blockchain network, ensuring that each node can obtain and understand how to verify blocks according to the predetermined consensus mechanism. Consensus nodes participate in the blockchain's consensus process according to the stored consensus mechanism rules, generating new blocks and broadcasting them to other nodes.

[0037] After storing and applying the consensus mechanism, consensus nodes will verify transactions according to the mechanism, determining which transactions can be recorded in the blockchain. In the Proof-of-Work (PoW) mechanism, consensus nodes must perform computational work, solve mathematical problems, and confirm the validity of new blocks; in the Proof-of-Stake (PoS) mechanism, consensus nodes determine the generator of new blocks by verifying the amount of tokens held and their weight; in the Proof-of-Agreement (PoA) mechanism, only authorized nodes can verify transactions and generate new blocks. By ensuring that all consensus nodes use the same consensus mechanism, the blockchain network can reach consensus among distributed nodes, ensuring data consistency. By using a predetermined consensus mechanism, the blockchain network can effectively avoid problems such as data tampering and double-spending, enhancing data security and transparency.

[0038] Furthermore, this application also includes the following steps: the smart contract includes a data processing smart contract, an identity verification smart contract, and an on-chain data storage smart contract; the data processing smart contract maps the standard log information to the timestamp to form the on-chain information; after the on-chain information is verified by the identity verification smart contract, the on-chain data storage smart contract obtains the transaction hash value; based on the correspondence between the transaction hash value and the timestamp, the on-chain information is stored in the blockchain network.

[0039] Furthermore, this application also includes the following steps: dividing the blockchain network to obtain a set of shards, wherein the set of shards includes a first shard; collecting first real-time state information of the first shard and performing weighted analysis on the first real-time state information to obtain a first real-time state index; sorting and analyzing the first shard based on the first real-time state index to obtain an optimal shard; and storing the on-chain information in the optimal shard based on the correspondence between the transaction hash value and the timestamp; wherein the first real-time state information includes a first CPU utilization rate, a first network speed, a first memory utilization rate, and a first hard disk read / write speed.

[0040] Specifically, a smart contract is a computer program that automatically executes, manages, controls, or documents contract terms on a blockchain. Blockchain technology ensures the contract's content is immutable and automatically executed. Once the triggering conditions are met, the smart contract automatically executes the corresponding operations according to its code logic, without human intervention. Its execution process and results are recorded on the blockchain, ensuring transparency and immutability. Smart contracts include data processing smart contracts, authentication smart contracts, and on-chain data storage smart contracts. Data processing smart contracts are primarily responsible for processing and transforming data, mapping raw standard log information and timestamps to generate data in a format that conforms to blockchain requirements (i.e., on-chain information). Authentication smart contracts verify the identity of the operator, such as verifying whether data comes from a legitimate node or device before being uploaded to the blockchain, ensuring data integrity and credibility, and preventing malicious nodes from submitting false data to the blockchain network. On-chain data storage smart contracts are responsible for storing processed and authenticated data (such as standard log information) on the blockchain, ensuring data immutability.

[0041] Standard log information typically includes raw data and associated timestamps. Data processing smart contracts process the collected standard log information, mapping it to a new data structure or format. This ensures that the data format uploaded to the blockchain meets the storage requirements of the blockchain network and retains crucial time information. For example, certain fields in the standard log information (such as database objects and table names) are encoded and converted, or log identifiers are combined with timestamps to generate a unique on-chain ID, thus forming structured on-chain information. On-chain information is the standard log information processed by data processing smart contracts and prepared for uploading to the blockchain; it is the result of encoding, encryption, or structural reorganization of the original standard log information.

[0042] The identity verification smart contract verifies the identity of information sent to the blockchain to ensure its legitimacy. Identity verification primarily confirms whether the node or device sending the data is a trusted node. For example, it verifies whether the node submitting the information has a valid digital signature and whether it complies with preset permission policies (e.g., only specific consensus nodes or authorized nodes can submit backup data). Only information that passes identity verification is allowed to enter the storage stage. If identity verification is successful, the data is marked as legitimate and can proceed to subsequent steps. If identity verification fails, the data is rejected or marked as invalid.

[0043] Once the information on the blockchain is verified, the transaction hash value is obtained through the on-chain data storage smart contract, serving as the unique identifier for the transaction. The transaction hash value is a unique identifier for a blockchain transaction. It is typically a fixed-length string calculated using a hash algorithm (such as SHA-256) based on the transaction content (including sender, receiver, data, etc.), such as a1b2c3d4. It possesses uniqueness, irreversibility, and tamper-proof properties, and can be used to track and verify transactions.

[0044] Dividing a blockchain network involves splitting a large blockchain network (which may contain numerous nodes) into multiple smaller, relatively independent subnetworks or partitions. Each subnetwork is called a shard, forming a shard set. Each shard is responsible for storing and processing a portion of the data, and the load can be evenly distributed among the shards. The first shard is a specific shard within the shard set; it is simply one of many shards and does not necessarily refer to being the first in the order.

[0045] The first real-time status information of the first shard is collected, reflecting its performance status, including first CPU utilization (representing the computing resource usage of the first shard, usually expressed as a percentage), first network speed (representing the data transfer speed between the first shard and other shards, measuring the efficiency of network bandwidth utilization), first memory utilization (representing the memory resource usage of the first shard, reflecting the degree of shard load), and first hard disk read / write speed (representing the storage device read / write speed of the first shard, reflecting the efficiency of shard data storage and retrieval). For example, the real-time status information of the first shard is as follows: CPU utilization 85%, network speed 100Mbps, memory utilization 70%, and hard disk read / write speed 50MB / s.

[0046] The indicators in the first real-time status information are standardized and normalized to eliminate the influence of different units of measurement. Based on the relative importance of each indicator (such as CPU utilization, network speed, etc.) in the overall status assessment, different weight coefficients are assigned to them. Then, a real-time status index is calculated: Real-time Status Index = CPU Utilization * CPU Utilization Weight + Network Speed ​​* Network Speed ​​Weight + Memory Utilization * Memory Utilization Weight + Disk Read / Write Speed ​​* Disk Read / Write Speed ​​Weight. Indicators with higher importance have larger weights and a greater impact on the final result. For example, if the weight of CPU utilization is 0.3, network speed is 0.2, memory utilization is 0.25, and disk read / write speed is 0.25, then the calculated first real-time status index is 0.3 * 0.85 + 0.2 * 1 + 0.25 * 0.7 + 0.25 * 0.5 = 0.755.

[0047] Repeat the above steps for the other shards in the shard set to obtain the real-time state index for each shard. Sort the shard set according to the real-time state index of each shard, and select the shard with the highest real-time state index as the optimal shard. For example, assuming there are multiple shards in the blockchain network (shard 1, shard 2, shard 3, etc.), and the real-time state indices of each shard are as follows: 0.755, 0.65, and 0.8, then shard 3, with the highest real-time state index, is selected as the optimal shard. The optimal shard is defined as the shard with the best performance, lowest load, and highest resource availability.

[0048] Based on the mapping between transaction hash values ​​and timestamps, the on-chain information that needs to be backed up is stored in the optimal shard of the blockchain network, ensuring that data is stored on the node group with the highest processing power and storage efficiency in the current network. By utilizing the decentralized and immutable characteristics of blockchain, all data, once on-chain, cannot be modified or deleted, ensuring the long-term validity and integrity of the data. On-chain data storage smart contracts efficiently write data to the blockchain, guaranteeing the order of data storage and efficient retrieval. Transaction hash values ​​and timestamps allow for quick location and recovery of required data. By selecting the optimal shard, it is ensured that new on-chain information is always sent to the shard with the lowest load and best performance, avoiding data concentration on some poorly performing or overloaded shards, thereby improving storage efficiency and the timeliness of data writing.

[0049] Receive disaster recovery instructions and restore the on-chain information in the blockchain network through the recovery node based on the disaster recovery instructions.

[0050] Furthermore, this application also includes the following steps: based on the disaster recovery instruction, identity verification is completed through the identity verification smart contract, and the request transaction hash value and request timestamp of the requested recovery data are verified through the on-chain data storage smart contract; the optimal shard is determined according to the request transaction hash value and the request timestamp, and a predetermined recovery strategy is invoked to restore the on-chain information in the optimal shard.

[0051] Furthermore, this application also includes the following steps: the predetermined recovery strategy includes a first recovery strategy and a second recovery strategy; wherein, the first recovery strategy refers to converting the standard log information into a database operation language and performing ordered recovery based on the timestamp; wherein, the second recovery strategy refers to performing predetermined replacement processing on the operation type in the standard log information, and performing ordered recovery based on the timestamp after the predetermined replacement processing, wherein the predetermined replacement includes mutual replacement of insertion operations and deletion operations and replacement of data before and after update operations.

[0052] Specifically, after a failure or disaster, in order to recover lost or damaged data, a disaster recovery instruction is received from staff or the control center. This instruction includes the data to be recovered, the target state, the target time point, and relevant parameters during the recovery process. Once the disaster recovery instruction is sent to the blockchain network, an identity verification smart contract is triggered to verify the identity of the received instruction. This contract checks the digital signature or other authentication information provided by the sender and compares it with a pre-stored permission list or whitelist on the blockchain to confirm whether the sender is authorized to perform the data recovery operation. Only after successful identity verification can the recovery process continue.

[0053] During the recovery process, the authentication smart contract ensures that only authorized nodes or users can perform the recovery operation. Authentication verifies the legitimacy of the node or user requesting recovery, preventing unauthorized users from performing data recovery operations. The authentication process includes checking whether the user requesting data recovery has sufficient permissions; verifying the validity of the requester's digital signature or identity credentials to ensure the request comes from a legitimate user. The on-chain data storage smart contract verifies the transaction hash and timestamp of the requested data to ensure the accuracy of the requested data. It is also responsible for extracting relevant data from the blockchain and recovering data as needed. The transaction hash is used to find the corresponding data record, and the timestamp is used to ensure that the recovered data is consistent with the requested time, avoiding recovery to an inaccurate version of data. After verification, the on-chain data storage smart contract returns detailed information about the confirmed data, such as data location and shard information. In other words, the on-chain data storage smart contract is invoked to carefully verify the request transaction hash and request timestamp contained in the instruction, searching for a transaction record on the blockchain that matches the hash value, and confirming that the transaction did indeed occur near the requested timestamp. This verification ensures that the recovery request itself is legitimate and traceable, and that the hash and timestamp of the requested data truly exist on the blockchain. After successful verification, the optimal shard where the data is currently located is determined based on the correspondence between the transaction hash value and the timestamp, as well as the sharding information when the data was initially stored.

[0054] While the optimal shard may have been selected during initial storage, its state may have changed during recovery, requiring re-evaluation or direct determination of the target shard based on records. Based on the optimal shard, a pre-defined recovery strategy is invoked to recover the on-chain information within that shard. The pre-defined recovery strategy is a set of rules or methods that guide the conversion of standard log information obtained from the blockchain back into usable data compatible with the original database structure, ultimately enabling recovery. This includes a first recovery strategy and a second recovery strategy.

[0055] The first recovery strategy directly translates each field in the standard log information (such as operation type, database object, table name, data content, etc.) into the corresponding database operation language (such as SQL statements), and then performs ordered recovery based on timestamps, ensuring that data is recovered according to the log's chronological order. The second recovery strategy is mainly used to handle certain types of logical errors or data inconsistencies. After performing pre-defined replacement processing on the operation types (insert, delete, update) in the standard log information, it performs recovery based on timestamps, ensuring that different operation types (such as insert and delete, data before and after updates) are appropriately handled during the recovery process. That is, for example, if the analysis determines that an insert operation is incorrect and should be a delete operation, or a delete operation should be an insert operation, then this mutual replacement is performed. For update operations, this involves replacing the data before and after the update operation, such as replacing the old data before the update with the new data after the update, or vice versa, depending on the specific recovery requirements (such as forward recovery or backward rollback). After completing these logical replacements, these adjusted operations are also executed based on the timestamp order.

[0056] Based on timestamps, standard log information is converted into database operation language (such as SQL statements), and data is restored in the order of timestamps to ensure that the recovery order is consistent with the historical data. For example, suppose a current of 150A and a temperature of 40℃ are collected at 08:00:00 on March 25th, and then a current of 149A and a temperature of 40.5℃ are collected at 08:00:10. The first recovery strategy will restore these two logs sequentially to ensure that the order of data recovery is consistent with the actual situation.

[0057] When insert and delete operations are encountered during the recovery process, ensure that the order of insert operations is not disrupted by delete operations. If a record is updated, ensure that the data order remains consistent throughout the recovery process, using the second recovery strategy. By selecting an appropriate recovery strategy and combining it with the performance advantages of optimal sharding, the data recovery process is completed. The recovered data is restored in the shards, ensuring that the data is restored to the correct state after a failure or disaster event. For example, suppose we need to restore to the state at 14:30 on July 20th, and the first recovery strategy is selected. Extract standard log information from the optimal shard in timestamp order (from earliest to 14:30). For each log entry, such as 7-20-14:25:10, operation type: insert, database object: line status, table name: temperature reading, data content: {line ID1001, temperature: 38.5℃}, and convert it into the corresponding SQL statement.

[0058] Dual verification through identity verification smart contracts and on-chain data storage smart contracts ensures that only authorized and legitimate requests can trigger the recovery process, and that the requested data actually exists on the blockchain. This effectively prevents unauthorized access and data source forgery, significantly enhancing the security of the recovery process. Verification based on transaction hashes and timestamps guarantees that the recovered data perfectly matches the request, avoiding the recovery of erroneous or incomplete data. By determining the optimal shard for data retrieval, data is prioritized from shards with lower current load or better status, improving recovery efficiency. Two recovery strategies are provided, enhancing the flexibility and accuracy of the recovery process. The first strategy is suitable for regular point-in-time recovery, simple and direct; the second strategy provides the ability to handle specific logical errors, intelligently correcting data problems, such as recovering accidentally deleted data or correcting erroneous update operations, making the recovered data more accurate and reliable.

[0059] Furthermore, this application also includes the following steps: real-time monitoring to obtain recovery status data, wherein the recovery status data includes first recovery data of a first monitoring indicator; obtaining adjacent monitoring data of the original monitoring data, and matching the first adjacent data corresponding to the first monitoring indicator in the adjacent monitoring data; comparing the first adjacent data with the first recovery data to obtain a first support; if the first support does not reach a predetermined support threshold, issuing a first warning signal, wherein the first warning signal is used to characterize the abnormal recovery status of the first monitoring indicator.

[0060] Furthermore, this application also includes the following steps: sequentially performing time-series curve processing on the first adjacent data and the first recovered data to obtain the first adjacent curve and the first recovered curve, respectively; comparing the first adjacent curve and the first recovered curve to obtain the curve similarity, and normalizing it to become the first support.

[0061] Specifically, real-time monitoring of the disaster recovery process yields recovery status data, which is used to determine whether the recovery operation proceeded as expected and whether the post-recovery data meets expectations. From the recovery status data, the first recovery data of the primary monitoring indicator is extracted. This data represents a specific parameter or state quantity of interest from the original monitoring data, such as the temperature, vibration amplitude, or tilt angle at a specific point on a transmission line. The first recovery data of the primary monitoring indicator is the actual value of the primary monitoring indicator after recovery, such as the recovered temperature value at a specific moment.

[0062] Simultaneously, adjacent monitoring data from the original monitoring data before the disaster occurs are acquired. This refers to data segments close to the target time point on the timeline, specifically raw data measured and recorded by the acquisition nodes before or after the point of time requiring restoration. This data represents the actual trend of line status changes during that time period. The first adjacent data corresponding to the first monitoring indicator is matched within the adjacent monitoring data and used as the neighbor of the restoration value to compare whether it deviates from the normal range.

[0063] The recovered temperature values ​​(first recovered data) are compared and analyzed with the actual measured temperature values ​​at adjacent time points (first adjacent data) to determine the degree of similarity or consistency of change trends, thus obtaining the first support score. The two sets of data used for comparison—the first adjacent data representing the changes in the original true state and the first recovered data representing the recovery result—are both processed into time-series curves. A series of scattered points are connected to create a curve that clearly shows the fluctuations of indicators such as temperature and vibration over time. The first adjacent curve is a trend curve generated by processing the first adjacent data through time-series analysis (such as linear interpolation or spline interpolation), representing the data change trend before and after the recovery time point; the first recovered curve is a trend curve obtained after processing the recovered data through time-series analysis, representing the change trend of the recovered data during the recovery process. For example, the first adjacent curve might show how the temperature steadily rises or fluctuates within a few minutes before and after the target recovery time point; while the first recovered curve shows the temperature value at that recovered time point and the potential trend it might exhibit if placed in a time series.

[0064] The first adjacent curve and the first recovered curve are compared, and their similarity is calculated using Euclidean distance. Curve similarity is an indicator that measures the degree of similarity between two curves (i.e., the first adjacent curve and the first recovered curve). Curve similarity is a quantitative indicator that measures the closeness of these two curves in terms of shape, trend, and fluctuation pattern. It is used to determine whether the recovered data curve (the first recovered curve) matches the actual trend of the original data (the first adjacent curve). The curve similarity is obtained by calculating the sum of squared vertical distances between the two curves at corresponding time points and the similarity of the Fourier transform coefficients of the curves. The calculated curve similarity is then standardized to a uniform range, usually between 0 and 1. This standardized value is called the first support. The purpose of normalization is to eliminate the influence of different dimensions or ranges that may exist between different curves, making the similarity comparable and meeting the needs of subsequent threshold judgment. For example, a simple algorithm based on point-to-point distance can be used to calculate the difference between two curves at several key time points. Then, a comprehensive index of these differences (such as the reciprocal of the normalized root mean square error) can be calculated to obtain an original curve similarity value. After normalization, the first support value can be obtained, such as 0.88.

[0065] The predetermined support threshold is a pre-set value used to determine whether the recovered data meets expectations. If the calculated support is lower than the predetermined support threshold, it indicates a significant deviation between the recovered data and historical data, and the recovery status is considered abnormal. This suggests a large discrepancy between the recovered data and adjacent data, potentially indicating problems or errors in the recovery process. When the first support fails to reach the predetermined support threshold, the recovery status is deemed abnormal, possibly due to errors during the recovery process or problems with the backup data itself. Once an anomaly is determined, an initial warning signal is immediately issued to adjust relevant personnel or automated processing modules. The data recovery work has not met the expected quality standards and requires further inspection and processing to ensure that the safety monitoring of the transmission lines is not affected. For example, using 151.7A (07:59:50) and 152.1A (08:00:10), the first adjacent curve is generated: y = 151.7 + (152.1 - 151.7)t, where t is time, t ∈ [0,1]. Using the recovered data 151.5A (recovery time) and the preceding and following adjacent data 151.7A and 152.1A, the first recovery curve is generated: z = 151.7 + (151.5 - 151.7)t, where t is time, t = 0.5. The curve similarity between the first adjacent curve and the first recovery curve is calculated to be 0.3, with a maximum tolerance of 3A. The first support is calculated as 0.9 by subtracting the curve similarity from the maximum tolerance (1 - curve similarity / maximum tolerance), indicating that the difference between the recovered data and the adjacent data is small, and the accuracy of the recovered data is high. A predetermined support threshold of 0.8 will not trigger a warning signal, as the difference between the recovered data and historical data is within an acceptable range, and the recovery process is considered successful.

[0066] By using time-series curve mapping and curve similarity analysis, the degree of agreement between the recovered data and historical data is evaluated, thereby verifying the accuracy of data recovery. Even slight differences between the recovered data and adjacent data can be effectively identified, and the reasonableness of the recovered data is quantified using support indicators. The verification method based on the support of adjacent data is more refined and reliable than simply checking whether the recovered data is within a preset reasonable range. By promptly identifying problems, erroneous or unreliable data is avoided in subsequent monitoring analysis and decision-making, thus ensuring the credibility of transmission line monitoring data and the stable operation of transmission lines.

[0067] In summary, the disaster recovery method for transmission line monitoring data provided in this application has the following beneficial effects:

[0068] Raw monitoring data is obtained through dynamic and continuous monitoring of transmission lines by data acquisition nodes. This raw monitoring data is then standardized and transformed to form standard log information. A consensus node activates a smart contract to back up this standard log information to the blockchain network. A disaster recovery command is received, and based on this command, a recovery node restores the on-chain information in the blockchain network. In other words, by leveraging the decentralized and immutable nature of blockchain, the security and integrity of the monitoring data after backup are ensured. The automated execution of data backup, verification, and recovery through smart contracts ensures the security and reliability of data recovery, improving disaster recovery efficiency and the credibility of transmission line monitoring data.

[0069] Example 2: Based on the same inventive concept as the transmission line monitoring data disaster recovery method in Example 1, this application also provides a transmission line monitoring data disaster recovery system. Please refer to the appendix. Figure 2 The power transmission line monitoring data disaster recovery system includes:

[0070] The dynamic monitoring module 11 is used to obtain raw monitoring data by dynamically and continuously monitoring the transmission line through the acquisition node, and to standardize and convert the raw monitoring data to form standard log information; the information backup module 12 is used to back up the standard log information to the blockchain network by activating the smart contract through the consensus node; the information recovery module 13 is used to receive disaster recovery instructions and restore the on-chain information in the blockchain network through the recovery node based on the disaster recovery instructions.

[0071] Furthermore, the dynamic monitoring module 11 in the power transmission line monitoring data disaster recovery system is also used to: read a predetermined log category, and analyze the original monitoring data based on the predetermined log category to obtain log category data; and form the standard log information based on the log category data; wherein the predetermined log category includes execution result code, log identifier, timestamp, database object, table name, operation type and data content.

[0072] Furthermore, the information backup module 12 in the power transmission line monitoring data disaster recovery system is also used to: obtain a predetermined consensus mechanism and store the predetermined consensus mechanism in the consensus node; wherein, the predetermined consensus mechanism includes proof-of-work and / or proof-of-stake and / or proof of authorization.

[0073] Furthermore, the information backup module 12 in the power transmission line monitoring data disaster recovery system is also used for: the smart contract including a data processing smart contract, an identity verification smart contract, and an on-chain data storage smart contract; mapping the standard log information and the timestamp through the data processing smart contract to form the on-chain information; after the on-chain information is verified by the identity verification smart contract, obtaining the transaction hash value through the on-chain data storage smart contract; and storing the on-chain information in the blockchain network based on the correspondence between the transaction hash value and the timestamp.

[0074] Furthermore, the information backup module 12 in the power transmission line monitoring data disaster recovery system is also used for: dividing the blockchain network to obtain a set of shards, wherein the set of shards includes a first shard; collecting the first real-time status information of the first shard and performing weighted analysis on the first real-time status information to obtain a first real-time status index; sorting and analyzing the first shard based on the first real-time status index to obtain an optimal shard; and storing the on-chain information in the optimal shard based on the correspondence between the transaction hash value and the timestamp; wherein the first real-time status information includes a first CPU utilization rate, a first network speed, a first memory utilization rate, and a first hard disk read / write speed.

[0075] Furthermore, the information recovery module 13 in the power transmission line monitoring data disaster recovery system is also used to: complete identity verification through the identity verification smart contract based on the disaster recovery instruction, and verify the request transaction hash value and request timestamp of the requested data recovery through the on-chain data storage smart contract; determine the optimal shard according to the request transaction hash value and the request timestamp, and retrieve the predetermined recovery strategy to recover the on-chain information in the optimal shard.

[0076] Furthermore, the information recovery module 13 in the power transmission line monitoring data disaster recovery system is also used for: the predetermined recovery strategy includes a first recovery strategy and a second recovery strategy; wherein, the first recovery strategy refers to converting the standard log information into a database operation language and performing orderly recovery based on the timestamp; wherein, the second recovery strategy refers to performing predetermined replacement processing on the operation type in the standard log information, and performing orderly recovery based on the timestamp after the predetermined replacement processing, wherein, the predetermined replacement includes mutual replacement of insertion operations and deletion operations and replacement of data before and after update operations.

[0077] Furthermore, the information recovery module 13 in the power transmission line monitoring data disaster recovery system is also used for: real-time monitoring to obtain recovery status data, wherein the recovery status data includes first recovery data of a first monitoring indicator; acquiring adjacent monitoring data of the original monitoring data, and matching the first adjacent data corresponding to the first monitoring indicator in the adjacent monitoring data; comparing the first adjacent data with the first recovery data to obtain a first support; if the first support does not reach a predetermined support threshold, issuing a first warning signal, wherein the first warning signal is used to characterize the abnormal recovery status of the first monitoring indicator.

[0078] Furthermore, the information recovery module 13 in the power transmission line monitoring data disaster recovery system is also used to: sequentially perform time-series curve processing on the first adjacent data and the first recovered data to obtain the first adjacent curve and the first recovered curve respectively; compare the first adjacent curve and the first recovered curve to obtain the curve similarity, and normalize it into the first support.

[0079] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Figure 1 The disaster recovery method and specific examples of transmission line monitoring data in Embodiment 1 are also applicable to the disaster recovery system of transmission line monitoring data in this embodiment. Through the foregoing detailed description of the disaster recovery method of transmission line monitoring data, those skilled in the art can clearly understand the disaster recovery system of transmission line monitoring data in this embodiment. Therefore, for the sake of brevity, it will not be described in detail here.

[0080] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0081] Obviously, those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. A method for disaster recovery of power line monitoring data, characterized in that, The method comprises the following steps: obtaining original monitoring data by means of dynamic continuity monitoring of the power transmission line by the collection node, and standardizing and converting the original monitoring data to form standard log information; backing up the standard log information to the blockchain network by activating the smart contract through the consensus node; receiving a disaster recovery instruction and recovering the on-chain information in the blockchain network based on the disaster recovery instruction through the recovery node; obtaining original monitoring data by means of dynamic continuity monitoring of the power transmission line by the collection node, and standardizing and converting the original monitoring data to form standard log information, comprising: reading a predetermined log category and analyzing the original monitoring data based on the predetermined log category to obtain log category data; forming the standard log information based on the log category data; wherein the predetermined log category comprises an execution result code, a log identifier, a timestamp, a database object, a table name, an operation type and data content; the smart contract comprises a data processing smart contract, an identity verification smart contract and an on-chain data storage smart contract, and the standard log information is backed up to the blockchain network by activating the smart contract through the consensus node, comprising: mapping the standard log information and the timestamp through the data processing smart contract to form the on-chain information; obtaining a transaction hash value through the on-chain data storage smart contract after the on-chain information passes the identity verification of the identity verification smart contract; storing the on-chain information to the blockchain network based on the correspondence between the transaction hash value and the timestamp, comprising: dividing the blockchain network to obtain a sharding set, wherein the sharding set comprises a first shard; collecting first real-time state information of the first shard and performing weighted analysis on the first real-time state information to obtain a first real-time state index; sorting and analyzing the first shard based on the first real-time state index to obtain an optimal shard; storing the on-chain information to the optimal shard based on the correspondence between the transaction hash value and the timestamp; wherein the first real-time state information comprises a first CPU utilization, a first network rate, a first memory utilization and a first hard disk read-write rate.

2. The method of claim 1, wherein the method further comprises: Before the standard log information is backed up to the blockchain network by activating the smart contract through the consensus node, comprising: obtaining a predetermined consensus mechanism and storing the predetermined consensus mechanism to the consensus node; wherein the predetermined consensus mechanism comprises proof of work and / or proof of stake and / or proof of authority.

3. The method of claim 1, wherein the method further comprises: Receiving a disaster recovery instruction and recovering the on-chain information in the blockchain network based on the disaster recovery instruction through the recovery node, comprising: based on the disaster recovery instruction, completing identity verification through the identity verification smart contract and verifying a request transaction hash value and a request timestamp of the request recovery data through the on-chain data storage smart contract; determining the optimal shard according to the request transaction hash value and the request timestamp, and calling a predetermined recovery strategy to recover the on-chain information in the optimal shard.

4. The disaster recovery method for transmission line monitoring data as described in claim 3, characterized in that, The predetermined recovery strategy includes a first recovery strategy and a second recovery strategy; The first recovery strategy refers to converting the standard log information into a database operation language and performing ordered recovery based on the timestamp; The second recovery strategy refers to performing predetermined permutation processing on the operation type in the standard log information, and performing ordered recovery based on the timestamp after the predetermined permutation processing, wherein the predetermined permutation includes mutual permutation of the insert operation and the delete operation and permutation of the front and rear data in the update operation.

5. The method of claim 1, wherein the method further comprises: Receiving a disaster recovery instruction and recovering the uplink information in the blockchain network through a recovery node based on the disaster recovery instruction, further comprising: Real-time monitoring to obtain recovery state data, wherein the recovery state data includes first recovery data of a first monitoring indicator; Obtaining adjacent monitoring data of the original monitoring data, and matching first adjacent data corresponding to the first monitoring indicator in the adjacent monitoring data; Comparing the first adjacent data and the first recovery data to obtain a first support degree; If the first support degree does not reach a predetermined support threshold, a first early warning signal is issued, wherein the first early warning signal is used to represent an abnormal recovery state of the first monitoring indicator.

6. The method of claim 5, wherein the method further comprises: Comparing the first adjacent data and the first recovery data to obtain a first support degree, comprising: Sequentially performing time series curve processing on the first adjacent data and the first recovery data to obtain a first adjacent curve and a first recovery curve, respectively; Comparing the first adjacent curve and the first recovery curve to obtain a curve similarity, and normalizing the curve similarity into the first support degree.

7. A power line monitoring data disaster recovery system, characterized by, The power line monitoring data disaster recovery system for implementing the steps of the power line monitoring data disaster recovery method of any one of claims 1 to 6, comprising: A dynamic monitoring module for continuously monitoring the power line through a collection node to obtain original monitoring data, and performing standardization conversion on the original monitoring data to form standard log information; An information backup module for activating a smart contract through a consensus node to backup the standard log information to a blockchain network; An information recovery module for receiving a disaster recovery instruction and recovering the uplink information in the blockchain network through a recovery node based on the disaster recovery instruction.

Images