Heat supply gas pipeline safety monitoring system and method based on block chain evidence storage

Abstract

The invention relates to a heat supply gas pipeline safety monitoring system and method based on block chain evidence storage. The method comprises the following steps: performing unified identity registration on a pipeline section, a sensor and a responsible mechanism through a block chain network to generate a block chain digital identity; dynamically optimizing sensor load distribution at edge nodes based on the identity, and constructing an efficient data acquisition network; on the basis of extracting a pipeline state feature vector in real time, generating a pipeline state abstract by using an edge-block chain collaborative verification mechanism, and triggering an on-chain smart contract to realize risk grading; automatically matching the plan according to the risk level to generate an encrypted response instruction and distributing the encrypted response instruction to a responsible mechanism; and implementing closed-loop evidence storage on the whole emergency disposal process based on the block chain digital identity. Therefore, the problems of data islands, response delay, unclear responsibility and the like of a traditional monitoring system are solved, full-link credible collaboration from risk perception to emergency response is achieved, and the safety protection level and cross-mechanism emergency response efficiency of a gas pipe network are improved on the premise that data safety is guaranteed.

Description

Technical Field

[0001] This invention belongs to the field of gas pipeline safety management technology, and in particular relates to a heating gas pipeline safety monitoring system and method based on blockchain evidence storage. Background Technology

[0002] In the field of heating and gas pipeline safety management, traditional monitoring systems have long faced several key challenges. Existing technologies generally employ a centralized data processing architecture, resulting in significant delays between data acquisition and decision-making processes. This is particularly problematic in cross-agency collaborative scenarios, where emergency response is often hampered by the inefficiency of manual coordination. Furthermore, the massive amounts of heterogeneous data generated by pipeline sensor networks not only exacerbate communication burdens but their raw transmission mode also creates throughput bottlenecks for blockchain systems, hindering real-time risk analysis capabilities.

[0003] Current blockchain-based solutions mostly remain at the level of data storage and evidence preservation, failing to address the issue of deep collaboration between edge devices and on-chain smart contracts. In cross-agency emergency response processes, ambiguity in responsibility definition and disconnects in response procedures are common, with information barriers between fire departments, gas companies, and emergency management departments causing a significant amount of critical rescue time to be wasted on communication and confirmation.

[0004] While some research has attempted to combine edge computing and blockchain technology in recent years, these efforts have largely been limited to simple splicing, with edge nodes merely serving as data filtering functions and the blockchain acting only as a database for storing evidence. This loosely coupled architecture cannot achieve true dynamic trust management; if edge devices malfunction or are maliciously manipulated, the reliability of the entire system will be directly threatened.

[0005] To address the aforementioned pain points, there is an urgent need for a technical solution that deeply integrates edge intelligence and blockchain characteristics. This solution should ensure data trustworthiness and enable closed-loop management of the entire process, from risk perception and intelligent analysis to collaborative response. It should also solve core challenges such as dynamic assessment of device trust and cross-agency instruction transmission. Summary of the Invention

[0006] Therefore, it is necessary to provide a safety monitoring system and method for heating and gas pipelines based on blockchain evidence storage to address the aforementioned technical issues.

[0007] Firstly, this application provides a method for safety monitoring of heating gas pipelines based on blockchain-based evidence storage, including:

[0008] S1. Register the identities of multiple entities in the gas pipeline system through a blockchain network to generate blockchain digital identities that include unique identifiers for each entity and associated information for each entity; where entities include pipeline segments, sensors, and responsible agencies.

[0009] S2. Based on blockchain digital identity, perform dynamic load balancing allocation for sensors at edge computing nodes to generate sensor data acquisition task topology;

[0010] S3. Based on the sensor data acquisition task topology, perform real-time data streaming processing and feature extraction on the data uploaded by the sensor at the edge computing node to generate pipeline state feature vector.

[0011] S4. Through edge computing nodes and nodes in the blockchain network, the pipeline state feature vector is collaboratively verified to generate a pipeline state summary.

[0012] S5. Submit the pipeline status summary to the blockchain network for notarization, trigger the risk assessment smart contract deployed on the blockchain network to determine the risk level, and obtain the risk level determination result of the corresponding pipeline segment.

[0013] S6. Based on the risk level assessment results, the emergency response smart contract deployed on the blockchain network is used to match the corresponding emergency plan, generate response instructions for the responsible agency, and distribute the response instructions to the corresponding responsible agency through blockchain transactions on the blockchain network.

[0014] S7. Based on blockchain digital identity, record and verify on the blockchain network the emergency response execution status of each responsible agency based on response instructions.

[0015] Secondly, this application also provides a blockchain-based safety monitoring system for heating and gas pipelines, used to implement the method described in the first aspect. The system includes:

[0016] The distributed identity authentication module is used to register the identities of multiple entities in the gas pipeline system through a blockchain network, generating a blockchain digital identity that includes a unique identifier for each entity and its associated information; the entities include pipeline segments, sensors, and responsible agencies.

[0017] The edge task scheduling module is used to perform dynamic load balancing allocation of sensors on edge computing nodes based on blockchain digital identity, and generate sensor data acquisition task topology.

[0018] The real-time feature parsing module is used to perform real-time data streaming processing and feature extraction on the data uploaded by the sensors at the edge computing node based on the sensor data acquisition task topology, and generate pipeline state feature vectors.

[0019] The consensus verification module is used to collaboratively verify the pipeline state feature vector through edge computing nodes and nodes in the blockchain network, and generate a pipeline state summary.

[0020] The risk assessment module is used to submit the pipeline status summary to the blockchain network for notarization, trigger the risk assessment smart contract deployed on the blockchain network to determine the risk level, and obtain the risk level determination result of the corresponding pipeline segment.

[0021] The emergency response distribution module is used to match the corresponding emergency plan with the emergency response smart contract deployed on the blockchain network based on the risk level assessment result, generate response instructions for the responsible agency, and distribute the response instructions to the corresponding responsible agency through blockchain transactions on the blockchain network.

[0022] The on-chain execution verification module is used to record and verify the emergency response execution status of various responsible agencies based on response instructions on the blockchain network, based on blockchain digital identity.

[0023] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement a blockchain-based method for safety monitoring of heating gas pipelines as described in the first aspect.

[0024] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a blockchain-based method for safety monitoring of heating gas pipelines as described in the first aspect.

[0025] The aforementioned blockchain-based safety monitoring system and method for heating and gas pipelines utilizes a blockchain network to register verifiable blockchain digital identities for pipeline sections, sensors, and responsible agencies. Based on these identities, sensor load allocation is dynamically optimized at edge nodes to construct an efficient data acquisition network. Pipeline status feature vectors are extracted in real-time through streaming processing. An immutable pipeline status summary is generated using an edge-blockchain collaborative verification mechanism, triggering on-chain smart contracts for risk assessment. Contingency plans are automatically matched based on risk levels, and encrypted response instructions are distributed to the responsible agencies. Finally, closed-loop evidence storage is implemented throughout the entire emergency response process based on the blockchain digital identities. This solution fundamentally addresses the pain points of traditional monitoring systems, such as data silos, response delays, and unclear responsibilities, achieving trusted collaboration across the entire chain from risk perception to emergency response. While ensuring data security, it significantly improves the safety protection level of gas pipeline networks and the efficiency of cross-agency emergency response. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 A flowchart illustrating a blockchain-based method for safety monitoring of heating and gas pipelines provided by this invention;

[0028] Figure 2 This is a schematic diagram illustrating the process of performing dynamic load balancing allocation in an optional embodiment of the present invention;

[0029] Figure 3 This is a schematic diagram of a safety monitoring system for heating and gas pipelines based on blockchain evidence storage, provided by the present invention. Detailed Implementation

[0030] 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 and not intended to limit the scope of this application.

[0031] refer to Figure 1 The document presents a flowchart illustrating a blockchain-based method for safety monitoring of heating and gas pipelines, which includes the following steps:

[0032] S1. Register the identities of multiple entities in the gas pipeline system through a blockchain network to generate a blockchain digital identity that includes a unique identifier for each entity and its associated information; the entities include pipeline sections, sensors, and responsible agencies.

[0033] Specifically, each pipeline segment is first assigned a unique identifier, which, combined with key information such as its geographical location, pipeline material, and installation time, forms its digital identity. Taking a main gas pipeline located in the city center as an example, its identifier can be generated by combining the area code and pipeline serial number. The associated information includes specific parameters such as coordinate location data, pipe diameter, and pressure rating, all encrypted and written to the blockchain via a smart contract. For sensors, manufacturers embed unique serial numbers during production and bind them to the corresponding pipeline segment identifier during installation. Detailed parameter information such as sensor type (e.g., pressure, temperature, or leak detection sensor), measurement range, accuracy level, and calibration cycle are recorded and stored on the blockchain. Responsible organizations, such as local gas companies, fire departments, and emergency management bureaus, generate digital identities based on their organization codes, linking their responsibilities, emergency supplies reserves, personnel structure, and contact information. These identities are then authenticated and authorized using blockchain digital certificates, ensuring the authenticity and immutability of each entity's identity.

[0034] S2. Based on blockchain digital identity, perform dynamic load balancing on sensors at edge computing nodes to generate sensor data acquisition task topology.

[0035] Specifically, before assigning tasks, edge computing nodes proactively probe all sensors within their communication range using network scanning and discovery mechanisms. This probe process utilizes broadcast and multicast technologies. Upon receiving a probe request, the sensor responds with its digital identity information and current status information, including detailed parameters such as sampling rate per second, remaining storage space, battery level, and signal strength. After collecting this information, the edge computing node compares and verifies it against the sensor information registered on the blockchain to ensure the legitimacy of the sensor's identity and the accuracy of its status information.

[0036] Next, the edge computing nodes dynamically allocate tasks to the sensors according to a predefined load balancing algorithm. The load balancing algorithm can employ a weighted round-robin approach, which comprehensively considers multiple factors such as the amount of data from the sensor, data processing complexity, and the sensor's current load status. Specifically, each sensor is assigned a base weight value based on its type and installation location. For example, a pressure sensor, due to its large data volume and high real-time requirements, might be assigned a higher base weight, while a humidity sensor might have a relatively lower weight. Simultaneously, the base weight is dynamically adjusted based on the sensor's current load status (such as current storage utilization and remaining battery power). If a sensor's storage space is about to run out or its battery power is low, its weight will be appropriately reduced, thereby decreasing the amount of tasks allocated to it.

[0037] The task topology is stored in the local database of each edge computing node in the form of an adjacency list. Each sensor node corresponds to an entry in the list, which records information such as the data type to be collected by the sensor, the collection frequency, and the target node for data transmission. To ensure the accuracy and timeliness of the task topology, edge computing nodes periodically exchange task allocation information through a secure communication channel. This information includes their respective task lists and sensor status updates. The exchanged information is first verified locally, including the completeness, timeliness, and identity verification of the sender. After successful verification, the edge computing node merges the received task allocation information with its own local information and updates its local task topology database. This process uses a blockchain verification mechanism to ensure consistency. Each edge computing node packages its task allocation information into a transaction and submits it to the blockchain network. Other nodes verify these transactions, and when consensus is reached, all nodes synchronize their task topology based on the latest transaction information.

[0038] S3. Based on the sensor data acquisition task topology, perform real-time data streaming processing and feature extraction on the data uploaded by the sensors at the edge computing node to generate pipeline state feature vectors.

[0039] Specifically, edge computing nodes are deployed with stream processing engines, such as Apache Flink or Apache Storm, which can process high-concurrency sensor data streams in real time. When sensors upload data according to the task topology requirements, the data first passes through the receiving module for basic format verification and preprocessing. Preprocessing includes removing noise points from the data (e.g., using moving average filtering or Kalman filtering algorithms) and normalizing the data (converting data of different dimensions to the same dimension interval, such as the [0,1] interval), to improve the accuracy and efficiency of subsequent processing.

[0040] After preprocessing, the data enters the feature extraction stage. To comprehensively reflect the pipeline's condition, a combination of various feature extraction techniques can be used. For time-series data, such as data from pressure and temperature sensors, a sliding window mechanism is employed for segmented processing. The size of the sliding window can be dynamically adjusted according to the data's frequency of change and monitoring requirements, typically ranging from 10 seconds to 1 minute. Within each window, wavelet transform technology is applied to extract the signal's time-frequency domain features. Wavelet transform can decompose a signal into waveforms of different scales, thereby capturing key features such as abrupt changes and periodic variations. For example, for pressure signals, wavelet transform can reveal the instantaneous pressure variation characteristics, which helps in detecting water hammer or leaks in pipelines.

[0041] Furthermore, principal component analysis (PCA) can be used to reduce the dimensionality of the extracted features. PCA maps high-dimensional data to a low-dimensional space by identifying the main directions of change in the data, thereby removing redundant information and reducing computational complexity.

[0042] In the feature extraction process, deep learning models can be incorporated to further uncover potential features in the data. For example, Long Short-Term Memory (LSTM) networks can be used to model time-series data and predict future pipeline status trends. LSTM models capture dependencies in long-term series through gating mechanisms. During training, historical pipeline data (including normal operation and failure data) is used for supervised learning to optimize the model's weight parameters. The trained LSTM model is deployed on edge computing nodes to infer real-time data and generate feature values ​​reflecting pipeline status trends. These feature values, along with features obtained from other traditional feature extraction methods, constitute the final pipeline status feature vector. Taking temperature sensor data as an example, after preprocessing, wavelet transform is first used to extract temperature change features at different scales. Then, PCA is used to reduce the dimensionality of these features, removing those with low discriminative power for pipeline status. Simultaneously, the LSTM model predicts temperature change trends over a future period based on historical temperature data, and key features from the prediction results (such as the slope and fluctuation amplitude of the predicted temperature) are also added to the feature vector. The resulting feature vector can comprehensively and accurately reflect the thermal state of the pipeline at the current moment and its possible future trends, providing a data foundation for subsequent risk assessment.

[0043] S4. Through edge computing nodes and blockchain network nodes, the pipeline state feature vector is collaboratively verified to generate a pipeline state summary.

[0044] Specifically, after generating the feature vector, the edge computing node first performs a hash operation on the feature vector to generate a digest of the feature vector. The hash operation can use a secure hash algorithm such as SHA-256. This digest will serve as the digital fingerprint of the feature vector for subsequent verification.

[0045] Simultaneously, the edge computing nodes package the feature vector's metadata into a blockchain transaction. This metadata includes key information such as the feature vector's generation timestamp, a list of sensor identifiers, the edge computing node's identifier, and the feature vector's hash value. This transaction is broadcast to the blockchain network. Upon receiving the transaction, each node in the network first performs a preliminary verification of its legitimacy, including checking if the transaction format is correct and the signature is complete.

[0046] Next, blockchain nodes perform in-depth verification of transactions through smart contracts. Smart contracts can define a series of verification rules, including checking the legitimacy of the edge computing node's identity (by verifying its digital signature), verifying whether the hash value of the feature vector conflicts with previously recorded hash values, and checking whether the sensor identifier matches the information registered on the blockchain. This process may also involve collaborative verification with other blockchain nodes. For example, through multi-party secure computation (MPC) technology, multiple blockchain nodes jointly participate in the computation to verify the consistency of the feature vector while not disclosing their respective privacy data. This process ensures the authenticity and integrity of the feature vector, preventing data from being tampered with or forged during transmission and processing.

[0047] Once verification is successful, the blockchain nodes will generate a pipeline state digest based on the information in the transaction. This digest includes not only the hash value of the feature vector but also the verification timestamp, a list of signatures from the participating blockchain nodes, and other information. The generation of the digest also employs cryptographic techniques such as hash operations to ensure its immutability and traceability.

[0048] S5. Submit the pipeline status summary to the blockchain network for notarization, triggering the risk assessment smart contract deployed on the blockchain network to determine the risk level and obtain the risk level determination result for the corresponding pipeline segment.

[0049] Specifically, a blockchain network can employ distributed ledger technology, where each node maintains a copy of the ledger. When a pipeline state digest is submitted to the blockchain network, it is packaged into a new block. This block is then propagated and verified throughout the blockchain network using a consensus algorithm (such as Raft or PoS). In Raft, the nodes in the network elect a leader responsible for collecting and ordering transactions, and then broadcasting the new block to other nodes for verification and confirmation. In PoS, nodes compete for the right to create a new block based on factors such as the amount of cryptocurrency they hold and their age. Both consensus algorithms aim to ensure that all nodes agree on the state of the blockchain, guaranteeing data consistency and reliability.

[0050] A risk assessment smart contract is an automated program deployed on a blockchain network that contains a predefined risk assessment model. This model can be a classification model based on a deep neural network. In this classification model, the input layer receives pipeline state feature vectors and historical data as input neurons. The hidden layer performs complex nonlinear transformations on the input data through artificial neurons and their connection weights. These weights are optimized during the model training phase using a backpropagation algorithm, utilizing historical pipeline failure data and normal operation data as training samples, allowing the model to learn the mapping relationship between pipeline state features and risk levels. The output layer outputs the pipeline's risk level, which can be divided into four levels: low risk, medium risk, high risk, and severe risk, with each level corresponding to the activation value of a neuron.

[0051] Once the pipeline status summary is successfully recorded on the blockchain, the risk assessment smart contract is automatically triggered. The contract first retrieves the latest feature vectors and historical data related to the pipeline segment from the blockchain ledger, and then inputs this data into the risk assessment model. After calculation, the model outputs the current risk level of the pipeline segment. For example, if the model calculates that the probability of failure in the current state exceeds a set high-risk threshold (e.g., 80%), the pipeline segment is determined to be in a high-risk state. This determination is also recorded on the blockchain and associated with the digital identity of the pipeline segment, ensuring the transparency and traceability of the determination. Simultaneously, the determination can also trigger corresponding early warning mechanisms, notifying relevant personnel to take timely measures. For example, in a heating and gas pipeline monitoring system in a chemical industrial park, when the risk level of a certain pipeline segment is determined to be severe, the risk assessment smart contract will immediately send an alarm to the park's emergency command center, and simultaneously send risk warning information to the pipeline operator, fire department, and other relevant agencies, ensuring that all parties can respond promptly.

[0052] S6. Based on the risk level assessment results, the emergency response smart contract deployed on the blockchain network matches the corresponding emergency plan, generates response instructions for the responsible agency, and distributes the response instructions to the corresponding responsible agency through blockchain transactions on the blockchain network.

[0053] Specifically, the emergency response smart contract stores a contingency plan library, which categorizes and stores contingency plans in detail based on factors such as risk level, pipeline type, geographical location, and accident type. Each contingency plan includes a series of detailed response measures, responsible agencies, execution steps, and required resources.

[0054] The matching algorithm employs rule engine-based technology, such as the Drools rule engine. The rule engine defines a series of matching rules that determine the most suitable emergency response plan based on factors such as risk level, pipeline location information, accident type, and the responsibilities of the responsible agency. For example, when the risk level is high, the accident type is a pipeline leak, and the location is in a densely populated area, the matching rules will filter out the corresponding emergency response plan from the plan database. This plan may include measures such as immediately shutting off upstream and downstream valves of the leaking pipeline section, evacuating nearby residents, and dispatching a professional repair team for emergency repairs.

[0055] The generated response instructions are stored in a structured data format, such as JSON. The instructions specify the operational steps the responsible agency must take, for example, "Fire Department: Establish a cordon within 500 meters of the pipeline leak point, evacuate residents, and prohibit open flames; Gas Company: Shut down the DN300 gas supply valve located in the valve well at the northwest corner of the intersection of XX Road and XX Road; Emergency Management Department: Deploy two gas detection vehicles to monitor the surrounding gas concentration." Execution time requirements and resource allocation information can also be explicitly listed in the instructions.

[0056] The distribution process utilizes the blockchain's transaction mechanism to ensure the security and traceability of instructions. Response instructions are packaged into a blockchain transaction, containing the instruction content, the recipient organization's identifier, and a sending timestamp. The transaction is broadcast to all nodes via the blockchain network, and nodes verify the transaction through a consensus mechanism. Once verified, the transaction is recorded on the blockchain ledger, ensuring the instruction's immutability. The responsible organization decrypts the instruction content in the transaction using its private key to obtain the task to be executed. For example, in a cross-regional gas pipeline leak incident, the emergency response smart contract matches emergency plans involving multiple responsible organizations based on a high-risk assessment. The generated response instructions are simultaneously sent to the fire department, gas company, and emergency management department via blockchain transactions. Upon receiving the instructions, these organizations decrypt and confirm the instruction content using their respective private keys, and then quickly launch emergency response actions according to the instructions. The entire distribution process is transparent and efficient, ensuring that all parties receive instructions and execute tasks in a timely and accurate manner.

[0057] S7. Based on blockchain digital identity, record and verify on the blockchain network the emergency response execution status of each responsible agency based on response instructions.

[0058] Specifically, during the execution of emergency response tasks, the responsible agency regularly submits updates on the execution status to the blockchain network. These updates include the task's progress (e.g., completed steps, ongoing steps), problems encountered (e.g., equipment malfunctions, traffic congestion, etc., affecting progress), resource usage (e.g., the amount of emergency supplies consumed, remaining battery power in rescue equipment), and real-time data from the site (e.g., changes in gas concentration at the leak point, fire control status). This information is submitted to the network in the form of blockchain transactions. Each transaction is associated with a corresponding response command and a digital identity for the pipeline segment, ensuring the accuracy and traceability of the information.

[0059] Nodes in the blockchain network verify these execution status updates through smart contracts. The verification process includes several aspects: First, it checks whether the information submitted by the responsible agency is complete and contains all required fields and data; second, it verifies the legitimacy of the information source by verifying the responsible agency's identity through its digital signature; third, it compares the differences between real-time data, historical data, and model predictions to determine whether the execution meets expectations; furthermore, it verifies whether the execution time is within a reasonable range and whether any delays have occurred. For example, the smart contract checks whether the arrival time submitted by the fire department meets the time requirements specified in the response instructions, compares the actual arrival time with the predicted optimal arrival time, and if the difference is too large, it will trigger further investigation mechanisms.

[0060] Once verified, the responsible agency's execution record is permanently stored on the blockchain, forming a complete emergency response audit chain. These records not only contain key data from the execution process but also the execution time and executor information for each step. For example, in the emergency response to a gas pipeline explosion, the maintenance team submits an execution status update containing detailed information such as repair time, type and quantity of welding materials used, and on-site pressure test results. This information, verified by a smart contract, is recorded on the blockchain, forming a complete history of the entire emergency response along with other relevant records. This provides data support for subsequent post-event analysis, liability determination, experience summarization, and improvement of emergency plans, while also ensuring the transparency and impartiality of the emergency response process, facilitating supervision and evaluation of the entire emergency response by all parties.

[0061] The aforementioned blockchain-based method for safety monitoring of heating and gas pipelines utilizes a blockchain network to register verifiable blockchain digital identities for pipeline sections, sensors, and responsible agencies. Based on these identities, sensor load allocation is dynamically optimized at edge nodes to construct an efficient data acquisition network. Pipeline status feature vectors are extracted in real-time through streaming processing. An immutable pipeline status summary is generated using an edge-blockchain collaborative verification mechanism, triggering on-chain smart contracts for risk assessment. Contingency plans are automatically matched based on risk levels, and encrypted response instructions are distributed to the responsible agencies. Finally, closed-loop evidence storage is implemented throughout the entire emergency response process based on the blockchain digital identities. This solution fundamentally addresses the pain points of traditional monitoring systems, such as data silos, response delays, and unclear responsibilities, achieving trusted collaboration across the entire chain from risk perception to emergency response. While ensuring data security, it significantly improves the safety protection level of gas pipeline networks and the efficiency of cross-agency emergency response.

[0062] refer to Figure 2 In one optional embodiment, S2 includes the following steps:

[0063] S21. Based on the blockchain digital identity, extract the accuracy parameters and deployment location coordinates of each sensor.

[0064] Specifically, the blockchain digital identity stores detailed information for each sensor, including accuracy parameters and deployment location coordinates. Accuracy parameters reflect the accuracy of the sensor's measurement data; for example, for a pressure sensor, the accuracy parameter can be expressed as ± a certain percentage range of the measured value; for a temperature sensor, it can be expressed as ± a certain temperature unit range. Deployment location coordinates can be obtained through a geolocation system (such as GPS), accurately recording the sensor's location within the heating and gas pipeline system in latitude and longitude. In practice, edge computing nodes call the query interface of the blockchain smart contract, passing in the sensor's unique identifier, to retrieve the corresponding accuracy parameters and deployment location coordinates from the blockchain ledger. This information is stored in encrypted form on the blockchain, indexed by the identifier, ensuring data confidentiality and integrity.

[0065] S22. Calculate the regional sensor deployment density based on the deployment location coordinates. The formula for calculating the regional sensor deployment density is ρ = N / S, where N is the number of sensors in the region and S is the area of ​​the region.

[0066] Specifically, the first step is to determine the specific area from which the density calculation needs to be performed. This can be achieved by defining a polygonal region or a circular region centered on a certain point on a Geographic Information System (GIS) platform. Next, the coordinates of the deployment locations of all sensors within this region are collected. The number of sensors N within the region is calculated by counting. Then, the area S of the region is calculated. For regularly shaped regions (such as circles or rectangles), the corresponding geometric formulas are applied directly; for irregularly shaped regions, approximate algorithms can be used, such as dividing the region into multiple small triangles and summing the areas of each triangle. Finally, the sensor deployment density ρ is calculated using the formula ρ = N / S. For example, in a 1000-square-meter area for monitoring heating gas pipelines, if 50 sensors are deployed, the sensor deployment density ρ = 50 / 1000 = 0.05 sensors per square meter. This density value reflects the density of sensor distribution within the region.

[0067] S23. Determine the data acquisition quality level based on the accuracy parameters. The formula for calculating the data acquisition quality level is Q. i =k·A i , where Q i Let A be the data acquisition quality level corresponding to the i-th sensor. i Let be the accuracy parameter of the i-th sensor, and k be the accuracy conversion coefficient.

[0068] Specifically, the accuracy conversion factor k is a constant related to the sensor type and application scenario, used to convert accuracy parameters into a uniform unit of quality level measurement. For example, for a pressure sensor, if the accuracy parameter A represents a measurement error of ±1%, by setting a value of k (e.g., k = 100), then Q... i =100 × (±1%) absolute value, i.e. Q i =1. For a temperature sensor, if the accuracy parameter A is expressed as ±0.5℃, and k is also set to 100, then Q i =100 × 0.5 = 50. The higher this quality level value, the better the data acquisition quality.

[0069] S24. Calculate the regional communication load index based on the regional sensor deployment density and data acquisition quality level; the formula for calculating the regional communication load index is as follows:

[0070]

[0071] Where, d i Let N be the distance from the i-th sensor to the edge node, and N be the number of sensors.

[0072] Specifically, we first calculate the contribution of each sensor one by one, that is... This contribution term considers the data acquisition quality level Q of the sensors i , for sensors closer to the edge node (d i is smaller), the communication load of its data transmission is relatively small. Therefore this term is larger, indicating that it accounts for a relatively large proportion in the communication load; at the same time, multiplying by the regional sensor deployment density ρ reflects the impact of the overall regional sensor density on the communication load. Summing up the contribution terms of all sensors, the communication load index L of the entire region is obtained. For example, in a region with a dense sensor deployment and close to the edge node, the value of L will be relatively low, indicating a light communication load; conversely, in a region with sparse sensors or sensors far from the edge node, the value of L is high, indicating a heavy communication load.

[0073] S25. Input the regional communication load index into the reinforcement learning model to dynamically optimize the connection relationship between the edge node and the sensors, and generate an initial connection topology.

[0074] Specifically, the reinforcement learning model is a learning mechanism based on the trial-and-error method. This model contains an agent whose goal is to learn the optimal strategy through interaction with the environment. In this embodiment, the goal of the agent is to optimize the connection relationship between the edge node and the sensors to reduce the communication load and improve the data transmission efficiency. During specific operations, the agent takes the regional communication load index L as one of the characteristics of the current environmental state, combines other state characteristics (such as data transmission delay, packet loss rate, etc. under the current connection topology), and selects corresponding actions, that is, adjusts the connection relationship between a certain sensor and the edge node (such as changing the connection path, adjusting the data transmission priority, etc.). Then, calculate the new communication load index L' according to the new connection relationship and compare it with the previous L to obtain a reward signal. If L'<L, the reward is positive, indicating that this action effectively reduces the communication load; otherwise, the reward is negative. The agent continuously tries and learns, updates its policy parameters, and gradually converges to an optimal connection strategy to generate an initial connection topology. This topology defines the connection method and data transmission path between the edge node and each sensor, providing a basic connection framework for subsequent data acquisition task allocation.

[0075] S26. Real-time obtain the pressure change rate of each pipeline segment, and calculate the adaptive sampling frequency according to the pressure change rate; the calculation formula of the adaptive sampling frequency is f = f0 + α·|dp / dt|, where f0 is the reference frequency, α is the sensitivity coefficient, dp / dt is the pressure change rate, p is the pressure of the pipeline segment, and t is the time.

[0076] Specifically, real-time acquisition of the pressure change rate is achieved through pressure sensors deployed along the pipeline section. These sensors acquire data at high frequencies (e.g., 100 Hz or higher) to capture minute pressure changes. The pressure change rate, dp / dt, is then calculated using numerical differentiation methods. For example, using the central difference method, dp / dt ≈ [p(t+Δt)-p(t-Δt)] / (2Δt), where p(t) is the pressure value at time t, and Δt is the sampling time interval. After calculating dp / dt, the adaptive sampling frequency f is calculated using the formula f = f0 + α·|dp / dt|. Here, f0 is the reference frequency, the minimum sampling frequency set by the system to ensure sufficient data acquisition even when pressure changes are gradual; α is a sensitivity coefficient used to adjust the degree of influence of the pressure change rate on the sampling frequency. For example, when the pressure change rate is high, |dp / dt| increases, leading to a higher sampling frequency f, which enables more accurate capture of rapidly changing pressure signals. Conversely, when the pressure is stable, the sampling frequency decreases, reducing data volume and communication load. This dynamic adjustment of the sampling frequency improves the efficiency and responsiveness of the monitoring system.

[0077] S27. Integrate the adaptive sampling frequency into the initial connection topology to generate the sensor data acquisition task topology.

[0078] Specifically, the initial connection topology defines the connection relationships and data transmission paths between sensors and edge nodes, but it does not yet consider the dynamic adjustment of the sampling frequency. Integrating the adaptive sampling frequency into the topology means updating the attribute information of each sensor in the topology and adding its current sampling frequency setting. In practice, the edge computing nodes assign corresponding sampling tasks to each sensor according to the adaptive sampling frequency calculated in step S26, and update these tasks to the initial connection topology. This may include modifying the sensor node attributes in the topology database, adding a sampling frequency field, and dynamically updating this field based on real-time calculation results. Simultaneously, the data transmission time scheduling can be adjusted to ensure that each sensor transmits data to the edge nodes according to the new sampling frequency, avoiding data conflicts or congestion. The updated topology is the sensor data acquisition task topology, which describes the task of each sensor (including sampling frequency, data transmission path, etc.), providing precise task guidance for the entire monitoring system and ensuring the efficiency and relevance of data acquisition.

[0079] In an optional embodiment, S3 includes the following steps:

[0080] S31. Based on the topology of the sensor data acquisition task, obtain the synchronous data stream of each sensor; perform time alignment processing on the synchronous data stream through a sliding time window to generate a time-aligned data matrix.

[0081] Specifically, the sensor data acquisition task topology defines the task for each sensor, including sampling frequency, data transmission path, etc. Edge computing nodes receive data streams from each sensor according to this topology. Since sensor sampling frequencies and network transmission delays may differ, the arrival time of data at edge nodes may vary. To ensure data synchronization, a sliding time window is used to time-align the synchronized data streams. The size of the sliding time window is set to the maximum allowable time deviation, ranging from a few milliseconds to tens of milliseconds, depending on system requirements and network conditions. Within the time window, data from each sensor is interpolated and corrected, adjusting data arriving at different times to a unified time reference, generating a time-aligned data matrix. For example, in a gas pipeline monitoring system, the data from pressure and temperature sensors may have time deviations due to different sampling frequencies. By using a sliding time window, the timestamps of the pressure data are aligned with the timestamps of the temperature data, generating a unified time series matrix, ensuring the consistency of subsequent processed data in time.

[0082] S32. Perform spatial location calibration on the time-aligned data matrix to construct a spatiotemporally consistent data matrix; extract pressure data sequences and temperature data sequences from the spatiotemporally consistent data matrix.

[0083] Specifically, based on the sensor deployment coordinates (longitude, latitude, altitude, etc.), the spatial distance and relative positional relationship between each sensor are calculated. Then, spatial interpolation algorithms are used to calibrate the spatial location of the data, making the data spatially comparable and correlated. Pressure and temperature data sequences are extracted from the spatiotemporally consistent data matrix. For example, in a large heating gas pipeline network, sensors are distributed in different geographical locations. Through spatial location calibration, pressure and temperature data from different locations are integrated into a unified spatiotemporal framework, generating a spatiotemporally consistent data matrix. From this matrix, pressure and temperature data sequences arranged in chronological order can be extracted, providing basic data for subsequent feature extraction and analysis.

[0084] S33. Perform wavelet transform decomposition on the pressure data sequence to obtain the pressure wavelet coefficients of the pressure fluctuation component; perform wavelet transform decomposition on the temperature data sequence to obtain the temperature wavelet coefficients of the temperature fluctuation component.

[0085] Specifically, wavelet transform is a time-frequency analysis method that decomposes a signal into wavelet coefficients at different scales, capturing abrupt changes and fluctuations in the signal. By selecting appropriate wavelet basis functions (such as Daubechies wavelet, Symlets wavelet, etc.) and decomposition scales (3-5 levels), multi-scale decomposition can be performed on pressure data sequences. Similarly, wavelet transform decomposition can be applied to temperature data sequences to obtain temperature wavelet coefficients for temperature fluctuation components. For example, when analyzing pressure fluctuations in gas pipelines, wavelet transform can decompose the pressure signal into fluctuation components in different frequency bands. Low-frequency components reflect long-term trend changes in the pipeline, while high-frequency components capture sudden pressure fluctuation events. These wavelet coefficients will serve as the basis for subsequent characteristic energy ratio calculations.

[0086] S34. Calculate the characteristic energy ratio based on the pressure wavelet coefficient and the temperature wavelet coefficient; the formula for calculating the characteristic energy ratio is:

[0087] E=(∑|W p |2) / (∑|W t |2)

[0088] Among them, W p W represents the pressure wavelet coefficient. t For temperature wavelet coefficients.

[0089] Specifically, the total energy of pressure fluctuations is obtained by squaring and summing the moduli of the pressure wavelet coefficients; similarly, the total energy of temperature fluctuations is obtained by squaring and summing the moduli of the temperature wavelet coefficients. Then, the total pressure energy is divided by the total temperature energy to obtain the characteristic energy ratio E. For example, in the event of a gas pipeline leak, pressure fluctuations may be more severe while temperature fluctuations are relatively smaller; in this case, the characteristic energy ratio E may increase significantly. This characteristic energy ratio, as a component of the pipeline state characteristic vector, provides information for subsequent risk assessment.

[0090] S35. Extract acoustic data sequences from the spatiotemporal consistency data matrix, identify leakage feature maps through a pre-trained convolutional neural network, and output anomaly probability scores based on the leakage feature maps.

[0091] Specifically, acoustic sensors are used to monitor sound signals within the pipeline, which can reflect the fluid flow status and potential leaks. The extracted acoustic data sequences are preprocessed (e.g., background noise removal, filtering) and then input into a pre-trained convolutional neural network (CNN). The CNN learns the spatial and temporal features of the acoustic data to identify leak characteristic patterns. For example, when a pipeline leaks, it is accompanied by sound signals of specific frequencies and intensities. The CNN can identify these characteristic patterns and output an anomaly probability score. This score ranges from 0 to 1, with a score closer to 1 indicating a higher probability of a leak. For example, a score exceeding 0.8 might indicate a leak risk in the area, requiring further inspection and confirmation.

[0092] S36. Extract flow data sequences from the spatiotemporal consistent data matrix and calculate the flow rate of change; extract gas concentration data sequences from the spatiotemporal consistent data matrix and calculate the gas concentration gradient.

[0093] Specifically, the flow rate change rate reflects the change in fluid flow rate within the pipeline over time, and its calculation formula is: Flow rate change rate = (ΔQ / Δt) / Q_avg, where ΔQ is the flow rate change, Δt is the time interval, and Q_avg is the average flow rate. Similarly, gas concentration data sequences are extracted from the spatiotemporal consistency data matrix to calculate the gas concentration gradient. The gas concentration gradient reflects the spatial change in gas concentration within the pipeline, and its calculation formula is: Gas concentration gradient = ΔC / Δx, where ΔC is the gas concentration change and Δx is the spatial distance. For example, when monitoring gas pipelines, a sudden increase in the flow rate change rate may indicate a leak or blockage in the pipeline; an abnormally high gas concentration gradient may suggest a risk of gas leakage. These characteristics will provide a basis for subsequent comprehensive assessments.

[0094] S37. By fusing the feature energy ratio, anomaly probability score, flow rate change rate, and gas concentration gradient, a pipeline state feature vector is generated.

[0095] Specifically, these feature values ​​are normalized to eliminate differences in dimensions and data ranges, enabling comparison and fusion on the same scale. For example, the feature energy ratio can be normalized using a logarithmic transformation, the anomaly probability score is already between 0 and 1, and the flow rate change rate and gas concentration gradient can be processed using the max-min normalization method. Then, these normalized feature values ​​are concatenated to generate a comprehensive pipeline state feature vector. This feature vector comprehensively reflects the pipeline's current operating status, including multi-dimensional information such as pressure, temperature, flow rate, and gas concentration, providing a data foundation for subsequent pipeline condition assessment and risk prediction.

[0096] In an optional embodiment, S4 includes the following steps:

[0097] S41. At the edge computing node, use the device-specific private key to perform the first-level signature on the pipeline state feature vector to generate a primary signature feature vector.

[0098] Specifically, edge computing nodes store their own private keys, which are generated during device initialization and registered and authenticated within the blockchain network. The private key is stored in the edge computing node's security module, such as a Trusted Execution Environment (TEE) or Hardware Security Module (HSM), to prevent its leakage. The signing process uses non-symmetric encryption algorithms, such as ECDSA (Elliptic Curve Digital Signature Algorithm) or RSA (Rivest-Shamir-Adleman Algorithm). Taking ECDSA as an example, the edge computing node uses its private key to sign the pipeline state feature vector, generating an information structure containing a random number, a signature value, and the public key—the primary signature feature vector. This signing process ensures the integrity and non-repudiation of the feature vector; that is, the data is not tampered with during transmission, and the signer cannot deny their signature.

[0099] S42. The primary signature feature vector is format-verified on the blockchain node of the blockchain network. After successful verification, a timestamp and a location stamp are added to generate a verification attachment packet.

[0100] Specifically, the verification process includes checking the integrity of the signature, its conformity to ECDSA or RSA format specifications, and the consistency of the public key with the blockchain registration information. After successful verification, the blockchain node adds a timestamp and a location stamp to generate a verification appendix. The timestamp, provided by the blockchain node's clock, records the time the feature vector enters the blockchain network, ensuring data timeliness. The location stamp is generated using the node's geographic location information (such as IP address, GPS coordinates, etc.) to identify the source location of the feature vector. The verification appendix encapsulates the initial signature feature vector, timestamp, and location stamp together, forming a new data structure.

[0101] S43. The verification group, composed of edge computing nodes and blockchain nodes, performs PBFT consensus voting on the verification attachments, calculates the Merkle root hash value of the verification attachments that have reached consensus, and generates a verifiable pipeline state digest.

[0102] Specifically, PBFT (Practical Byzantine Fault Tolerance) is a Byzantine fault-tolerant consensus algorithm suitable for node consensus in blockchain networks. Each node in the validation group (including edge computing nodes and blockchain nodes) votes on the validation appendix. The voting process includes three phases: pre-preparation, preparation, and commit. In the pre-preparation phase, the proposing node broadcasts the validation appendix to other nodes; in the preparation phase, node validation receives the validation appendix and broadcasts its prepared vote; in the commit phase, when a node receives a sufficient number of prepared votes, it broadcasts its committed vote. Once a certain number of nodes reach consensus, the Merkle root hash value is calculated for the consensus-reaching validation appendix. A Merkle tree is a binary tree data structure where each leaf node contains the hash value of the validation appendix, and non-leaf nodes contain the hash values ​​of their child nodes. By calculating the hash values ​​of all leaf nodes, the Merkle root hash value is finally obtained. This value serves as a digest of the validation appendix and is unique and collision-resistant. The generated pipeline state summary includes information such as the Merkle tree root hash, timestamp, location stamp, and a list of nodes participating in consensus, ensuring the credibility and traceability of the pipeline state feature vector.

[0103] In an optional embodiment, the method further includes the following steps:

[0104] S81. Record the historical operation behavior of edge nodes on the blockchain and count the number of successful verifications and the number of abnormal triggers; where the number of successful verifications represents the number of times the data submitted by the edge computing node has passed the collaborative verification of the blockchain network, and the number of abnormal triggers represents the number of times the data submitted by the edge computing node has caused false alarms or verification failures.

[0105] Specifically, each time an edge computing node submits data to the blockchain network, the blockchain nodes collaboratively verify the data. The verification process involves multiple blockchain nodes checking the integrity, consistency, and legality of the data according to preset rules. The number of successful verifications (Ns) refers to the number of times the data submitted by the edge computing node has passed collaborative verification by the blockchain network. This data is permanently recorded in a specific storage area of ​​the blockchain, stored in a structured manner indexed by the edge node's digital identity. The number of anomaly triggers (Nt) refers to the number of times the data submitted by the edge computing node causes false alarms or verification failures due to errors, anomalies, or malicious content; this is also recorded on the blockchain. These records not only include counts but also timestamps of each operation, the hash values ​​of the data involved, and the verification results, ensuring that all historical operations are traceable and auditable.

[0106] S82. Calculate the trust value of the edge computing node based on the number of successful verifications and the number of exception triggers; the formula for calculating the trust value is:

[0107] T = (N s -λ·N t ) / (N s +N t +ε)

[0108] Where, N s N is the number of successful verifications. t λ is the number of times an anomaly is triggered, λ is the anomaly penalty coefficient, and ε is the smoothing factor.

[0109] Specifically, λ is the anomaly penalty coefficient, which can be set between 1 and 5 to aggravate the negative impact of abnormal behavior on the trust value; ε is the smoothing factor, which can take values ​​between 0.1 and 0.001 to prevent the denominator from being zero and to increase computational stability. The trust value can range from 0 to 1, with higher values ​​indicating more trustworthy nodes. The calculation results are stored on the blockchain and associated with the digital identities of edge nodes to ensure transparency and immutability.

[0110] S83. Based on the real-time updated trust value, dynamically adjust the operation permissions of the edge computing node through smart contracts; wherein, the operation permissions include the upper limit of data upload frequency, the range of accessible pipeline segments, and the types of executable instructions.

[0111] Specifically, the smart contract predefines the mapping relationship and adjustment rules between trust values ​​and operational permissions. Operational permissions include the upper limit of data upload frequency, the range of accessible pipeline segments, and the types of executable commands. For example, when the trust value T ≥ 0.9, the edge node enjoys high-level permissions, with the upper limit of data upload frequency set to 10 times per second, access to all pipeline segments, and the ability to execute all command types, including data collection, task allocation, and emergency response. When 0.7 ≤ T < 0.9, permissions are downgraded, the upper limit of data upload frequency is reduced to 5 times per second, accessible pipeline segments are limited to the area specified during registration and its surrounding 1 kilometer radius, and emergency response commands are excluded from the executable command types. When T < 0.7, edge node permissions are restricted, the upper limit of data upload frequency is further reduced to 1 time per second, access to pipeline segments within the registered area is restricted, and only data collection commands can be executed; task allocation and emergency response operations are prohibited. The smart contract monitors changes in the trust value of the edge node in real time, and automatically triggers the permission adjustment mechanism when the trust value crosses the preset threshold. The permission adjustment process is broadcast to all nodes in the network through blockchain transactions, ensuring the transparency and immutability of the adjustment operation. For example, if an edge node submits abnormal data (N) multiple times... t The increase caused the trust value to drop from 0.85 to 0.65. The smart contract automatically detected this change, downgraded its operation permission from advanced to restricted level, adjusted its data upload frequency, access scope and executable instruction types, and recorded this adjustment on the blockchain to ensure the security and reliability of the entire system.

[0112] The aforementioned blockchain-based method for safety monitoring of heating and gas pipelines utilizes a blockchain network to register verifiable blockchain digital identities for pipeline sections, sensors, and responsible agencies. Based on these identities, sensor load allocation is dynamically optimized at edge nodes to construct an efficient data acquisition network. Pipeline status feature vectors are extracted in real-time through streaming processing. An immutable pipeline status summary is generated using an edge-blockchain collaborative verification mechanism, triggering on-chain smart contracts for risk assessment. Contingency plans are automatically matched based on risk levels, and encrypted response instructions are distributed to the responsible agencies. Finally, closed-loop evidence storage is implemented throughout the entire emergency response process based on the blockchain digital identities. This solution fundamentally addresses the pain points of traditional monitoring systems, such as data silos, response delays, and unclear responsibilities, achieving trusted collaboration across the entire chain from risk perception to emergency response. While ensuring data security, it significantly improves the safety protection level of gas pipeline networks and the efficiency of cross-agency emergency response.

[0113] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0114] Based on the same inventive concept, this application also provides a system for implementing the aforementioned blockchain-based evidence-based safety monitoring method for heating and gas pipelines. The solution provided by this system is similar to the implementation described in the above method. Therefore, the specific limitations of one or more embodiments of the blockchain-based evidence-based safety monitoring system for heating and gas pipelines provided below can be found in the limitations of the blockchain-based evidence-based safety monitoring method for heating and gas pipelines described above, and will not be repeated here.

[0115] In one exemplary embodiment, such as Figure 3 As shown, a blockchain-based safety monitoring system 30 for heating and gas pipelines is provided to implement the methods described in the above embodiments. The system includes:

[0116] The distributed identity authentication module 31 is used to register the identities of multiple entities in the gas pipeline system through a blockchain network, and generate a blockchain digital identity that includes a unique identifier for each entity and the associated information of each entity; wherein, the entities include pipeline sections, sensors and responsible agencies.

[0117] The edge task scheduling module 32 is used to perform dynamic load balancing allocation of sensors on edge computing nodes based on blockchain digital identity, and generate sensor data acquisition task topology.

[0118] The real-time feature parsing module 33 is used to perform real-time data streaming processing and feature extraction on the data uploaded by the sensor at the edge computing node based on the sensor data acquisition task topology, and generate pipeline state feature vectors.

[0119] The consensus verification module 34 is used to collaboratively verify the pipeline state feature vector through edge computing nodes and nodes of the blockchain network, and generate a pipeline state summary.

[0120] The risk assessment module 35 is used to submit the pipeline status summary to the blockchain network for notarization, trigger the risk assessment smart contract deployed on the blockchain network to determine the risk level, and obtain the risk level determination result of the corresponding pipeline segment.

[0121] The emergency response distribution module 36 is used to match the corresponding emergency plan with the emergency response smart contract deployed on the blockchain network based on the risk level assessment result, generate response instructions for the responsible agency, and distribute the response instructions to the corresponding responsible agency through blockchain transactions on the blockchain network.

[0122] The on-chain execution verification module 37 is used to record and verify the emergency response execution status of various responsible agencies based on response instructions on the blockchain network, based on blockchain digital identity.

[0123] Embodiments of this application also provide a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the aforementioned method embodiments.

[0124] Embodiments of this application also provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps in the above-described method embodiments.

[0125] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The components described as separate parts may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this disclosure according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0126] The above-described embodiments are merely illustrative of several implementation methods of the embodiments of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of the patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the embodiments of this application, and these modifications and improvements all fall within the protection scope of the embodiments of this application.

Claims

1. A method for safety monitoring of heating gas pipelines based on blockchain-based evidence storage, characterized in that, The method includes: S1. Register the identities of multiple entities in the gas pipeline system through a blockchain network to generate a blockchain digital identity that includes a unique identifier for each entity and the associated information of each entity; wherein, the entities include pipeline sections, sensors, and responsible agencies; S2. Based on the blockchain digital identity, perform dynamic load balancing allocation on the sensor at the edge computing node to generate a sensor data acquisition task topology; S3. Based on the sensor data acquisition task topology, the edge computing node performs real-time data streaming processing and feature extraction on the data uploaded by the sensor to generate a pipeline state feature vector. S4. Through the edge computing node and the nodes of the blockchain network, the pipeline state feature vector is collaboratively verified to generate a pipeline state summary. S5. Submit the pipeline status summary to the blockchain network for notarization, trigger the risk assessment smart contract deployed on the blockchain network to determine the risk level, and obtain the risk level determination result of the corresponding pipeline segment. S6. Based on the risk level determination result, the emergency response smart contract deployed on the blockchain network is used to match the corresponding emergency plan, generate a response instruction for the responsible agency, and distribute the response instruction to the corresponding responsible agency through blockchain transactions on the blockchain network. S7. Based on the blockchain digital identity, record and verify on the blockchain network the emergency response execution status of each responsible agency based on the response instructions.

2. The method according to claim 1, characterized in that, S2 includes: S21. Based on the blockchain digital identity, extract the accuracy parameters and deployment location coordinates corresponding to each of the sensors; S22. Calculate the regional sensor deployment density based on the deployment location coordinates. The formula for calculating the regional sensor deployment density is ρ = N / S, where N is the number of sensors in the region and S is the area of ​​the region. S23. Determine the data acquisition quality level based on the accuracy parameter. The calculation formula for the data acquisition quality level is Q. i =k·A i , where Q i For the data acquisition quality level corresponding to the i-th sensor, A i Let be the accuracy parameter of the i-th sensor, and k be the accuracy conversion coefficient; S24. Based on the regional sensor deployment density and the data acquisition quality level, calculate the regional communication load index; the formula for calculating the regional communication load index is as follows: Where, d i Let N be the distance from the i-th sensor to the edge node, and N be the number of the sensors. S25. Input the regional communication load index into the reinforcement learning model to dynamically optimize the connection relationship between the edge node and the sensor, and generate an initial connection topology; S26. Real-time acquisition of the pressure change rate of each of the pipeline segments, and calculation of the adaptive sampling frequency based on the pressure change rate; the formula for calculating the adaptive sampling frequency is f=f0+α·|dp / dt|, where f0 is the reference frequency, α is the sensitivity coefficient, dp / dt is the pressure change rate, p is the pressure of the pipeline segment, and t is time; S27. Integrate the adaptive sampling frequency into the initial connection topology to generate the sensor data acquisition task topology.

3. The method according to claim 1, characterized in that, S3 includes: S31. Based on the topology of the sensor data acquisition task, obtain the synchronous data stream of each sensor; perform time alignment processing on the synchronous data stream through a sliding time window to generate a time-aligned data matrix; S32. Perform spatial positioning calibration on the time-aligned data matrix to construct a spatiotemporally consistent data matrix; extract pressure data sequences and temperature data sequences from the spatiotemporally consistent data matrix. S33. Perform wavelet transform decomposition on the pressure data sequence to obtain the pressure wavelet coefficients of the pressure fluctuation component; perform wavelet transform decomposition on the temperature data sequence to obtain the temperature wavelet coefficients of the temperature fluctuation component. S34. Calculate the characteristic energy ratio based on the pressure wavelet coefficient and the temperature wavelet coefficient; the formula for calculating the characteristic energy ratio is: E=(∑|W p |2) / (∑|W t |2) Among them, W p Let W be the pressure wavelet coefficient. t The temperature wavelet coefficients; S35. Extract acoustic data sequences from the spatiotemporal consistency data matrix, identify leakage feature maps through a pre-trained convolutional neural network, and output anomaly probability scores based on the leakage feature maps; S36. Extract the flow rate data sequence from the spatiotemporal consistency data matrix and calculate the flow rate change rate; extract the gas concentration data sequence from the spatiotemporal consistency data matrix and calculate the gas concentration gradient; S37. The pipeline state feature vector is generated by fusing the feature energy ratio, the anomaly probability score, the flow rate change rate, and the gas concentration gradient.

4. The method according to claim 1, characterized in that, S4 includes: S41. At the edge computing node, the device-specific private key is used to perform a first-level signature on the pipeline state feature vector to generate a primary signature feature vector. S42. The blockchain nodes of the blockchain network perform format verification on the primary signature feature vector. After the verification is successful, a timestamp and a location stamp are added to generate a verification attachment packet. S43. The verification group, composed of the edge computing node and the blockchain node, performs PBFT consensus voting on the verification attachment, calculates the Merkle root hash value of the verification attachment that has reached consensus, and generates a verifiable pipeline state digest.

5. The method according to any one of claims 1 to 4, characterized in that, The method further includes: S81. Record the historical operation behavior of edge nodes on the blockchain, and count the number of successful verifications and the number of abnormal triggers; wherein, the number of successful verifications represents the number of times the data submitted by the edge computing node has passed the collaborative verification of the blockchain network, and the number of abnormal triggers represents the number of times the data submitted by the edge computing node has caused false alarms or verification failures; S82. Based on the number of successful verifications and the number of abnormal triggers, calculate the trust value of the edge computing node; the formula for calculating the trust value is: T=(N s -λ·N t ) / (N s +N t +e) Where, N s N represents the number of successful verifications. t λ is the number of times the exception is triggered, ε is the exception penalty coefficient, and ε is the smoothing factor. S83. Based on the real-time updated trust value, dynamically adjust the operation permissions of the edge computing node through a smart contract; wherein, the operation permissions include the upper limit of data upload frequency, the range of accessible pipeline segments, and the types of executable instructions.

6. A safety monitoring system for heating and gas pipelines based on blockchain-based evidence storage, used to implement the method according to any one of claims 1 to 5, characterized in that, The system includes: A distributed identity authentication module is used to register the identities of multiple entities in a gas pipeline system through a blockchain network, generating a blockchain digital identity that includes a unique identifier for each entity and associated information for each entity; wherein, the entities include pipeline segments, sensors, and responsible agencies; The edge task scheduling module is used to perform dynamic load balancing allocation of the sensor on the edge computing node based on the blockchain digital identity, and generate sensor data acquisition task topology. The real-time feature parsing module is used to perform real-time data streaming processing and feature extraction on the data uploaded by the sensor at the edge computing node based on the sensor data acquisition task topology, and generate pipeline state feature vectors. The consensus verification module is used to collaboratively verify the pipeline state feature vector through the edge computing node and the nodes of the blockchain network, and generate a pipeline state summary. The risk assessment module is used to submit the pipeline status summary to the blockchain network for notarization, trigger the risk assessment smart contract deployed on the blockchain network to determine the risk level, and obtain the risk level determination result of the corresponding pipeline segment. An emergency response distribution module is used to match the corresponding emergency plan with an emergency response smart contract deployed on the blockchain network based on the risk level determination result, generate response instructions for the responsible agency, and distribute the response instructions to the corresponding responsible agency through blockchain transactions on the blockchain network. The on-chain execution verification module is used to record and verify on the blockchain network the emergency response execution status of each responsible agency based on the response instructions, based on the blockchain digital identity.

7. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 5.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 5.

Images