Power maintenance dispatching system and method based on big data

Abstract

The application relates to the technical field of power system operation and production management, and particularly discloses a power maintenance scheduling system and method based on big data, which comprises a data analysis module, a blockchain collaboration module and a scheduling execution module. The method mainly comprises the following steps: generating predictive maintenance events and real-time abnormal alarm events through big data analysis; converting the events into smart contracts on the blockchain through an oracle; automatically detecting resource conflicts by using a conflict negotiation engine, and generating a scheduling adjustment scheme through preset rules based on the emergency level of emergency events and the adjustable threshold of planned events; automatically updating the contract state after the on-chain consensus of relevant parties; finally, driving the scheduling instruction to be issued and executed, and feeding back, and utilizing a closed-loop data optimization analysis model. The application realizes the automation, collaboration credibility and continuous optimization of the model of the scheduling process, and improves the response efficiency, collaborative transparency and decision accuracy of power maintenance.

Description

Technical Field

[0001] This invention relates to the field of power system operation and maintenance and production management technology, specifically to a power equipment maintenance scheduling system and method based on big data analysis and blockchain technology, which is particularly suitable for power grid operation and maintenance scenarios that require coordination of planned maintenance and emergency response to sudden faults. Background Technology

[0002] The stable operation of power equipment is fundamental to ensuring a safe and reliable power supply from the power grid. Traditional power maintenance and dispatching mainly rely on manual experience, periodic planning, and reactive responses after faults occur. With the advancement of smart grids and digital transformation, equipment status prediction and fault early warning based on big data analytics have become important technical means.

[0003] However, existing technical solutions still have significant shortcomings. First, predictive maintenance plans based on big data analytics and emergency repair tasks triggered by real-time monitoring are usually managed by different systems. When conflicts arise between these two types of tasks in terms of personnel, equipment, and other resources, there is a lack of efficient and automated coordination mechanisms, often relying on manual communication, resulting in slow responses and difficulty in achieving globally optimal resource allocation. Second, scheduling decisions involve multiple stakeholders, including the scheduling center, operations and maintenance units, and materials departments. The decision-making process and execution records of traditional centralized systems lack sufficient transparency and immutability, which is not conducive to post-event auditing and accountability. Finally, the accuracy of big data analytics models is highly dependent on historical data and expert parameter tuning. There is a lack of mechanisms for continuous and automatic feedback optimization of the model using actual scheduling execution results, limiting the autonomous improvement and optimization of its early warning accuracy.

[0004] Therefore, how to build a power maintenance and dispatching system that can deeply integrate big data intelligent analysis, achieve reliable automatic collaboration among multiple parties, and continuously optimize itself is an urgent problem to be solved in this field. Summary of the Invention

[0005] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a power maintenance dispatching system and method based on big data to address the problems mentioned in the background art, specifically: planned maintenance tasks and sudden emergency tasks are prone to conflict in resource allocation; traditional centralized dispatching systems have slow response and low coordination efficiency; the dispatching process involving multiple parties lacks a transparent and reliable recording and traceability mechanism, making it difficult to clarify responsibilities; the accuracy of data analysis models depends on historical experience and lacks a continuous optimization mechanism based on real closed-loop feedback.

[0006] To solve the above-mentioned technical problems, the present invention adopts the following technical solution.

[0007] On the one hand, a power maintenance and dispatching system based on big data is provided, which includes a data analysis module, a blockchain collaboration module, and a dispatching execution module.

[0008] The data analysis module is used to process monitoring data of power equipment and generate two types of structured events: one is a predictive maintenance event containing a planned adjustable threshold; the other is a real-time anomaly alarm event containing an emergency level.

[0009] The blockchain collaboration module, connected to the data analysis module, is used to convert received predictive maintenance events and real-time anomaly alarm events into on-chain planned maintenance contracts and on-chain emergency maintenance contracts, respectively. This module also includes a conflict resolution engine, which automatically detects resource conflicts between emergency maintenance contracts and existing planned maintenance contracts after the latter are generated, and executes on-chain conflict resolution procedures.

[0010] The process includes: generating a scheduling adjustment plan based on the emergency level of the emergency maintenance contract and the adjustable threshold of the conflict plan maintenance contract according to the preset decision rules; submitting the plan to the relevant participating nodes for consensus verification; and updating the status and time information of the relevant contracts after verification.

[0011] The scheduling and execution module is connected to the blockchain collaboration module. It is used to monitor the contract status and generate and issue scheduling instructions based on the contract content when the emergency maintenance contract status becomes executable.

[0012] On the other hand, a power maintenance and dispatching method based on big data is provided and applied to the aforementioned system. The method includes the following steps: Process power equipment monitoring data to generate predictive maintenance events that include planned adjustable thresholds and real-time anomaly alarm events that include emergency levels; Predictive maintenance events and real-time anomaly alert events are converted into on-chain planned maintenance contracts and emergency maintenance contracts, respectively; After an emergency maintenance contract is generated, resource conflicts between it and existing planned maintenance contracts are automatically detected. Based on the emergency level of the emergency maintenance contract and the adjustable threshold of the conflict plan maintenance contract, a scheduling adjustment plan is generated according to the preset decision rules. The scheduling adjustment plan will be submitted to the relevant participating nodes for consensus verification. Once consensus verification is successful, update the status and time information of the relevant contracts; Monitor the contract status, and when the emergency maintenance contract status becomes executable, generate and issue scheduling instructions based on its content.

[0013] Furthermore, the step of generating events includes: assessing health trends by periodically analyzing historical status data of the equipment, generating predictive maintenance events and calculating planned adjustable thresholds; and generating alarm events and determining the urgency level when an anomaly occurs by continuously comparing real-time data with dynamic thresholds.

[0014] Furthermore, the contract conversion steps are executed through an oracle service, including listening for events, formatting data, and calling on-chain smart contract factory functions.

[0015] Furthermore, the step of generating a scheduling adjustment scheme specifically includes: identifying resource conflicting contracts; querying a pre-set two-dimensional decision matrix based on the urgency level and the plan's adjustable threshold to determine the conflict resolution strategy; and calculating a specific adjustment scheme based on the strategy. The decision matrix defines the strategies corresponding to different combinations of urgency levels and plan flexibility ranges, including resource preemption, negotiated delay, or parallel execution.

[0016] Furthermore, when the strategy is "negotiate and delay the planned task", the calculation of the adjustment plan follows the principle of minimizing the total adjustment time without exceeding the adjustable threshold of each conflicting contract plan.

[0017] Furthermore, the method also includes a data tracing step: calculating a data fingerprint for the core data upon which the event is based after the event is generated and attaching it to the event, and storing the fingerprint when creating the on-chain contract.

[0018] Furthermore, the method also includes a model optimization step: periodically obtaining the completed contract execution results and their data fingerprints from the blockchain, tracing the original data to assess the accuracy of the analysis, and adjusting the model parameters or threshold logic used to generate events accordingly.

[0019] Furthermore, the step of issuing scheduling instructions also includes: receiving on-site operation progress feedback and transmitting it back to the blockchain to drive contract state updates.

[0020] Compared with the prior art, the technical solution provided by the present invention can produce the following beneficial effects: 1. By using blockchain smart contracts to automate conflict detection and negotiation between planned and emergency tasks, the multi-party coordination process is transformed from the traditional manual, serial mode to a parallel, rule-driven automatic negotiation mode, shortening emergency response time and achieving global optimization of resource scheduling.

[0021] 2. All scheduling events, contract rules, negotiation processes, consensus results, and execution status are stored on the blockchain in an immutable manner, providing a reliable audit trail for the entire process, effectively clarifying the responsibilities of each participant, and enhancing the credibility of the scheduling system.

[0022] 3. By utilizing the complete "data-decision-result" information stored on the blockchain, the prediction and anomaly detection models can be evaluated and calibrated regularly and automatically. This allows the system's analytical and early warning capabilities to continuously evolve with the accumulation of operational data, improving the accuracy and foresight of maintenance decisions.

[0023] 4. By generating and associating data fingerprints with the core data on which the analysis of events is based from the source, a trusted verification channel from on-chain decision results to off-chain raw data is established, ensuring the reliability and tamper resistance of the scheduling decision basis. Attached Figure Description

[0024] Figure 1 This is a flowchart of the overall processing flow of the power maintenance and dispatching system of the present invention.

[0025] Figure 2 A detailed flowchart of event generation and contract creation for this invention is provided.

[0026] Figure 3 This is a flowchart of the conflict detection and negotiation resolution branch of the present invention. Detailed Implementation

[0027] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0028] Example 1 As attached Figures 1 to 3 The power maintenance and dispatching system and method based on big data, as shown below, will be described in detail through an embodiment deployed in a provincial power grid and its operation and maintenance partner system. Those skilled in the art will understand that, without departing from the concept of the present invention, adaptive adjustments, substitutions, or combinations can be made to the specific parameters, equipment models, and operating procedures described in the embodiment.

[0029] The hardware system of this embodiment includes the following three main parts: 1. A cluster of big data analytics servers deployed in a cloud data center.

[0030] 2. A consortium blockchain network consisting of server nodes from at least three participating parties (e.g., provincial power dispatch center, municipal power supply company, and equipment maintenance service provider).

[0031] 3. Enterprise-level communication gateway and message middleware for connecting mobile work terminals in the field.

[0032] The software system consists of the following four functional modules working together: Data analysis module: running on a big data server cluster, responsible for processing monitoring data of power equipment and generating structured scheduling events.

[0033] Blockchain Collaboration Module: Deployed across the participating nodes of the consortium blockchain network, including a smart contract factory, a conflict negotiation engine, and contract instance maintenance.

[0034] Oracle Service Module: Serves as a standardized data interface between the off-chain data world and the on-chain trusted execution environment.

[0035] The scheduling and execution module is responsible for generating and issuing executable job instructions based on the on-chain consensus results, and synchronizing the on-site job status back to the blockchain.

[0036] Step 1: Multi-source data processing and standardized event generation The goal of this step is to transform heterogeneous power equipment operation data from different data sources into two types of scheduling events with a unified format.

[0037] S101: Periodic batch processing generates predictive maintenance events.

[0038] The batch processing analysis unit in the data analysis module starts tasks on a fixed daily schedule. This unit extracts historical status data sequences of specific power equipment from the data warehouse for analysis. Taking a device identified as... Taking a 220kV oil-immersed power transformer as an example, the extracted data sequence includes the daily dissolved gas (hydrogen) in the oil over the past 365 days. Acetylene Total hydrocarbon content, percentage of maximum daily load rate, and average daily top oil temperature.

[0039] This time-series data is fed into a pre-trained device health assessment model. The model calculates a quantitative device health score based on the correlation between input features and historical failure modes. In this embodiment, the scoring range is set to a continuous value from 0 to 100, where 0 represents a complete failure state and 100 represents an ideal healthy state. The model calculation yields... The system has two preset key thresholds: a warning threshold and a warning threshold. With critical threshold .because The model determined that the equipment posed a risk and that preventative maintenance should be arranged.

[0040] Subsequently, the unit calculates the planned adjustable threshold for this maintenance task. The unit is days. This calculation requires determining the historical health degradation rate of the equipment. The unit is "daily decline in score value". The daily average deterioration rate was obtained by performing linear regression analysis on the device's health score series over the past six months. . The calculation formula is: ; The physical meaning of this formula lies in the margin between the current health state and the critical dangerous state of the equipment. ), divided by the average daily consumption rate in a healthy state This allows for the estimation of the remaining safe operating days before the health level drops to a critical value; this number of days serves as the maximum adjustable limit for the planned time window. Substituting the values ​​into the calculation yields: .

[0041] Finally, the batch analysis unit generates a predictive maintenance event. This event is a structured data object (e.g., in JSON format) that contains at least the following fields: event_type: Event type identifier, whose value is the fixed string "PREDICTIVE".

[0042] device_id: A unique identifier for a device, such as "T-1001".

[0043] suggested_time: The suggested execution time, using the ISO8601 standard timestamp format, such as "2023-11-20T08:00:00Z".

[0044] flexibility_days: The planned adjustable threshold, which is a calculated value, such as 72.

[0045] resources: A list of estimated required resources, such as ["High Voltage Test Team A", "Insulating Oil Vacuum Filter"].

[0046] S102: Real-time stream processing generates an abnormal alarm event.

[0047] The stream processing and analysis unit in the data analysis module continuously receives and processes real-time telemetry data streams from the monitoring and data acquisition system. A stream is identified as... Taking a 110kV cross-linked polyethylene cable line as an example, the unit receives the sampled value of its current sensor every second.

[0048] The unit has a built-in dynamic threshold management service, which, based on statistical process control principles, automatically updates the normal value range for each monitored object every hour. For lines... During the 14:00-15:00 period, the input for this service is a sample of all historical RMS current values ​​for the line during the same time period (14:00-15:00) daily over the past 30 days. By calculating the statistical characteristics of the samples, the output is the dynamic control upper limit for that period. and lower limit To control the upper limit. Taking the calculation as an example, the formula is as follows: ,in It is the arithmetic mean of the historical samples. Its standard deviation. For example, calculated as follows: ampere.

[0049] At 14:08 that day, the stream processing unit calculated the line Average current value within the previous minute sliding time window Ampere. The unit will Dynamic control limit for the current time period Comparison. Because The system determines that an abnormality has occurred where the current exceeds the upper limit.

[0050] The unit automatically classifies the urgency level of events based on the severity of the violation. Violation rate. The calculation formula is: Substituting the values ​​into the equation... According to a preset rule mapping table (e.g., when...), When the alarm is mapped to "Medium" emergency, the emergency level of this alarm is determined as severity="MEDIUM".

[0051] Finally, the stream processing analysis unit generates a real-time anomaly alarm event. This event is also a structured data object, and its content includes at least the following fields: event_type: Event type identifier, whose value is the fixed string "ALERT".

[0052] device_id: A unique identifier for the device, such as "L-2005".

[0053] alert_type: Description of the exception type, such as "CURRENT_OVER_LIMIT".

[0054] timestamp: The precise timestamp of the exception, such as "2023-10-05T14:08:00Z".

[0055] severity: level of emergency, such as "MEDIUM".

[0056] resources: A list of resources estimated to be needed for emergency response, such as ["Line Inspection Team B", "Portable Partial Discharge Detector"].

[0057] Step 2: On-chain transformation of scheduling events and conflict initialization detection This step aims to reliably anchor off-chain generated scheduling events to the blockchain via the oracle module and trigger an automated resource conflict detection process.

[0058] S201: Create on-chain smart contract instances via oracle services.

[0059] The oracle service continuously listens for event message queues from the data analytics module's output channel. When a predictive maintenance event generated by S101 is captured, the oracle performs the following operations: 1. Parameter extraction and formatting: Extract key fields such as device_id, suggested_time, flexibility_days, and resources from the event object.

[0060] 2. Unique identifier generation: Combine the timestamp and device identifier to generate a globally unique contract identifier, such as "PC-T1001-20231120".

[0061] 3. Initiate an on-chain transaction: Using its authorized blockchain account, send a transaction to the consortium blockchain network. This transaction calls the createPlanContract function of the "Plan Maintenance Contract Factory" smart contract deployed on the chain, passing in the formatted parameters as input.

[0062] The consortium blockchain network (maintained jointly by multiple participating nodes) reaches consensus and executes the transaction. The "Planned Maintenance Contract Factory" smart contract creates and initializes a new, independent planned maintenance contract instance (denoted as contract P1) in the on-chain state database based on the input parameters. The storage state of this contract instance is initialized to include: written device information, a list of resource requirements, the planned start time, flexibility_days=72, and its status field is set to "PLANNED".

[0063] Similarly, when the oracle captures a real-time anomaly alert event generated by S102, it calls the "Emergency Maintenance Contract Factory" in the same process to create and initialize an emergency maintenance contract instance (denoted as contract E1), whose status field is initialized to "PENDING".

[0064] S202: Automatically triggers on-chain conflict detection.

[0065] In the operation mechanism of a consortium blockchain, the creation of a smart contract triggers an on-chain event that can be listened to by other contracts. In this embodiment, after successfully creating contract E1, the "emergency maintenance contract factory" will issue an on-chain event of type EmergencyContractCreated.

[0066] A smart contract called the Conflict Negotiation Engine, designed specifically for scheduling and coordination, has subscribed to all EmergencyContractCreated events from the Emergency Contract Factory through its predefined event listener callback function. This is a mechanism for automating inter-contract triggering on the blockchain. When the engine listens for the creation event of contract E1, its internal pre-defined response logic is automatically triggered. The engine's execution steps are as follows: 1. Read emergency requirements: Obtain the address of the newly created emergency contract E1 from the event log, and then read its stored resources field by querying the public status of the contract, such as ["Line Inspection Team B", "Portable Partial Discharge Detector"].

[0067] 2. Scan for potential conflicts: The engine iterates through the chain to query all planned maintenance contract instances whose current status field is "PLANNED".

[0068] 3. Execution Conflict Determination: For each planned contract in the "planned" state (e.g., an existing planned contract P2), the engine performs two checks: Resource overlap check: Compare the resource list of the planned contract with the resource list of the emergency contract E1 to determine whether there are shared resource items (e.g., whether both need "Line Inspection Team B").

[0069] Proximity check: Determines whether the suggested_time of the plan contract is within a future configurable time window (e.g., the next 72 hours) starting from the current moment. This time window can be adjusted according to actual business needs.

[0070] 4. Constructing a Conflict Set: If a planned contract satisfies both the conditions of resource overlap and time proximity, the engine adds its contract address to a conflict contract set temporarily stored on-chain. For example, suppose there is a planned contract P2 whose resources list contains "Line Inspection Team B" and is scheduled to be executed the next day, then it will be included in this conflict set.

[0071] Step 3: On-chain automated negotiation and consensus formation based on a pre-built rule base This step resolves resource contention and establishes a deterministic and mutually agreed-upon final scheduling solution. The entire process is automated through on-chain smart contract code logic, ensuring transparency, consistency of rules, and immutability of the results.

[0072] S301: Determine the conflict resolution strategy based on the two-dimensional decision matrix.

[0073] After identifying a set of conflicting contracts containing conflicting contract P2, the conflict negotiation engine needs to determine how to handle the conflict based on a predefined business rule base. This rule base is stored in the on-chain state variables of the conflict negotiation engine contract in the form of a two-dimensional decision matrix data structure.

[0074] The engine first reads the key attributes of both sides in the conflict: Read the severity field from the state of emergency contract E1; its value is "MEDIUM".

[0075] Read the flexibility_days field from the state of the planned contract P2; its value is... .

[0076] The engine has a built-in function that maps a specific number of days to a flexible range. For example, the mapping rule is defined as: if flexibility_days If the sky is 1, then it is mapped to "HIGH_FLEX"; if flexibility_days If it is "MEDIUM_FLEX", then it is mapped to "MEDIUM_FLEX"; if flexibility_days Then it is mapped to "LOW_FLEX". Based on this, P2's... The sky is mapped to the elastic range "HIGH_FLEX".

[0077] Subsequently, the engine queries the decision matrix stored on the query chain. This matrix uses the urgency level as the row key and the planned flexibility range as the column key. The matrix defines standardized output strategies for various input combinations; for example, for an emergency event with severity="HIGH" (high urgency), the strategy is typically preset to "PREEMPT" (immediate resource preemption). In this embodiment, the engine performs a query operation: The query returns a strategy of "NEGOTIATE_DELAY" (where "decisionMatrix" is defined as "decisionMatrix["MEDIUM"]["HIGH_FLEX"]), which means "resolve resource conflicts by negotiating and delaying scheduled tasks".

[0078] S302: Calculate and generate specific scheduling adjustment plans.

[0079] After deciding to adopt the "NEGOTIATE_DELAY" strategy, the conflict negotiation engine needs to generate an executable specific operation plan, the core of which is to calculate a new start time for the scheduled task P2.

[0080] The engine obtains the following input parameters from the on-chain state: : The original planned start time of contract P2 (Unix timestamp, in seconds).

[0081] The value of the flexibility_days field in contract P2, which is the maximum number of days of delay allowed.

[0082] Estimated duration of emergency response task E1 (in days).

[0083] The engine first calculates the time constraint boundaries: the latest allowed start time. (Convert days to seconds). Then, calculate the earliest time point at which P2 would execute immediately following E1. .

[0084] Engine verification Once the conditions are met, a clear scheduling adjustment proposal is generated. The specific operation instruction included in this proposal is: modify the suggested_time field of contract P2 to... At the same time, confirm and lock the conflicting resource "Line Inspection Team B" for Contract E1.

[0085] S303: Organize multi-party consensus and atomically update the on-chain state.

[0086] The generated scheduling adjustment proposal needs to be confirmed by all stakeholders to take effect. The conflict negotiation engine encapsulates the proposal into a special blockchain transaction, which contains call instructions to the updateSchedule function of contract P2 and the confirmAndAssign function of contract E1.

[0087] According to the access control rules defined in the relevant smart contract, this transaction requires the digital signature endorsement of the nodes of the parties involved in the conflicting contracts. Specifically, it requires: The signature of the owner of the planned contract P2 (usually representing the equipment maintenance node).

[0088] The signature of the owner of the emergency contract E1 (usually representing the dispatching and commanding node).

[0089] Upon receiving the proposal transaction, the client software of each node automatically executes pre-defined verification logic (e.g., verification). (Whether it is within the time frame allowed by P2's flexibility_days, verifying whether the operation process complies with security procedures). After successful verification, the node signs the proposal transaction using its private key.

[0090] When a proposal successfully collects all the necessary signatures, a consensus is reached. The fully signed transaction is broadcast to the consortium blockchain network, sorted by a network consensus algorithm (such as a Practical Byzantine Fault Tolerance algorithm), and then packaged into a new block. Within the block, the transaction is executed as an indivisible atomic transaction, meaning that all the following operations either succeed or fail simultaneously as an indivisible whole: 1. The suggested_time field of the planned contract P2 has been updated to... .

[0091] 2. The status field of emergency contract E1 is updated from "PENDING" to "CONFIRMED", and the allocation result of resource "Line Inspection Team B" is recorded in its newly added assigned_resources field.

[0092] 3. All participants' signatures and the final state changes are permanently and immutably recorded on the blockchain's distributed ledger.

[0093] Step 4: Trusted Evidence of Data Sources In order to establish a trusted audit link from the final scheduling decision back to the original analysis data that triggered the decision, this embodiment introduces a data fingerprint evidence storage mechanism during the event on-chain process.

[0094] S401: Generate and associate data fingerprints.

[0095] In S102, while the stream processing unit generates an abnormal alarm event, a data tracing component is simultaneously invoked. This component extracts the core raw data segment that directly leads to the anomaly determination. For example, for a current over-limit alarm on line L-2005, it extracts the sequence of all raw current sample values ​​within a time window before and after the timestamp (e.g., two minutes before and after).

[0096] The component first converts the data sequence into a normalized, deterministic string representation (e.g., by sorting the sampled values ​​in ascending order of timestamps and constructing a JSON array string). Then, a cryptographic hash function (e.g., the SHA-256 algorithm) is applied to this string to obtain a fixed-length hash value, which is the data fingerprint. This fingerprint is unidirectional and collision-resistant, used to uniquely identify and ensure that the associated original data fragment is not tampered with during storage and transmission.

[0097] The data fingerprint This is appended as a new field (e.g., named data_hash) to the upcoming anomaly alert event object. In S201, when the oracle service creates the emergency contract E1, data_hash is written into the storage state of contract E1 as one of the input parameters. Thus, the on-chain smart contract E1 establishes a unique and verifiable cryptographic association with a specific, tamper-proof fragment of the original off-chain data.

[0098] For predictive maintenance events, the data tracing component extracts data used to calculate the health score. The core characteristic data (e.g., the complete array of oil chromatographic gas content of transformer T-1001 and the corresponding load rate sequence) are used to generate data fingerprints and attach them to the events using the same process, and finally associated and stored in the corresponding planned maintenance contract P1.

[0099] Step 5: Closed loop of scheduling instruction generation, issuance, and execution status feedback. This step transforms the consensus-reached, state-defined scheduling scheme on the blockchain into executable work instructions on-site, and reliably synchronizes the execution progress in the physical world back to the blockchain in real time, achieving closed-loop management of digital instructions and physical execution processes.

[0100] S501: Monitor contract status and generate standardized work instructions.

[0101] The scheduling and execution module includes a state monitoring service that continuously listens for state change events of relevant smart contracts by subscribing to the event logs of blockchain nodes or periodically polling the application programming interfaces of blockchain nodes.

[0102] When an on-chain event is detected that the status of emergency maintenance contract E1 has changed from "PENDING" to "CONFIRMED", the status monitoring service is triggered. The service then obtains complete and up-to-date status information of contract E1 through the blockchain network's query interface, including device location, fault type, allocated resource list, safety precautions, and all task details.

[0103] After acquiring the information, the status monitoring service invokes the instruction conversion unit. This unit is configured with work order templates that conform to power industry standards. Based on the template definition, the unit maps and fills the structured information in the contract into the corresponding fields of the template, generating a standardized and complete electronic work order file (e.g., a CIM / XML format work order conforming to IEC61968).

[0104] S502: Synchronization between instruction issuance and execution status.

[0105] The communication interface unit of the scheduling and execution module is responsible for pushing the generated electronic chemical work order file to the mobile operation terminal of the target work team (corresponding resource "line inspection team B") through a secure and reliable enterprise internal network or message middleware.

[0106] On-site personnel receive and view work orders via a terminal application. When the work team arrives on-site and officially begins maintenance work, the person in charge triggers the "Start Execution" operation on the terminal application. The terminal application then sends a status update message to the feedback application interface provided by the scheduling execution module. The message body contains the unique identifier of contract E1 and the status enumeration value "IN_PROGRESS".

[0107] Upon receiving this feedback message, the status synchronization unit of the scheduling execution module first verifies and validates its source. If verification is successful, the unit automatically constructs a blockchain transaction that calls the `updateStatus` function of contract E1 and sets the target status parameter to "IN_PROGRESS". The unit signs the transaction using the private key of the system service account and broadcasts it to the blockchain network. After the transaction is confirmed by network consensus, the `status` field of contract E1 is atomically updated to "IN_PROGRESS".

[0108] Once all on-site operations are completed and accepted, the operator enters the processing result (e.g., "Found and tightened loose clamps") on the terminal and triggers the "Completed" operation, sending feedback with a status of "COMPLETED". This feedback then drives the status synchronization unit to initiate a transaction, ultimately updating the status of contract E1 to "COMPLETED", and optionally writing the processing result text to the contract storage. The visualization module reads these continuous status changes from the blockchain, providing managers with a global, real-time view of the scheduling situation.

[0109] Step Six: Iterative Optimization of Data Analysis Model Based on Execution Feedback The system utilizes case data accumulated on the blockchain that includes complete "early warning-decision-execution-result" processes to regularly evaluate the accuracy and adaptability of the front-end data analysis model and optimize its parameters.

[0110] S601: Collect closed-loop data and evaluate model performance.

[0111] The model optimization unit in the data analysis module automatically starts a batch evaluation task on a weekly cycle. This task performs the following operations: 1. Query completed cases: Connect to the consortium blockchain node and query the list of all smart contracts whose status field is "COMPLETED" in the past period, especially emergency maintenance contracts.

[0112] 2. Extract related information: For each such contract (e.g., E1), read its stored data_hash (data fingerprint) field and the actual_outcome (actual processing result) field written in the field feedback. actual_outcome may contain enumeration values ​​or text descriptions such as "confirmed fault, repaired" or "no abnormalities found, false alarm".

[0113] 3. Retrace the original data: Based on the data_hash value, retrieve the original data fragment that triggered the creation of the contract in the secure data archive storage system.

[0114] 4. Perform performance labeling: Compare the actual_outcome with the initial judgment from the data analysis module. Label the performance category of this analysis case, for example: True positive (TP): An alert was issued, and the actual result confirmed that the problem was faulty.

[0115] False positive (FP): An alert is issued, but no abnormalities are found during actual inspection (false alarm).

[0116] False negative (FN): No warning was issued, but the equipment subsequently malfunctioned (missed report).

[0117] S602: Adjust model parameters and judgment logic.

[0118] The model optimization unit calibrates the model parameters or rules in the data analysis module based on the statistical analysis results of S601 to improve the accuracy of future event generation.

[0119] For dynamic thresholds (stream processing unit): If the false positive (FP) rate of a specific type of abnormal alarm (such as instantaneous current exceeding the limit for a certain type of line) consistently exceeds a preset acceptable threshold, the optimization unit will initiate adjustments to the dynamic threshold generation logic or stream processing rules. For example: Modify the historical data filtering criteria used to calculate the dynamic threshold to automatically exclude data samples from non-faulty operating periods (such as planned capacitor switching operations and large motor start-up periods) that are known to produce similar interference signals.

[0120] Add auxiliary judgment conditions to the stream processing rule engine. For example, when a current over-limit is detected, the associated switch status change signal or load switching command should be checked simultaneously. If it is confirmed that the instantaneous impact is caused by a planned operation, the over-limit event should be suppressed or its emergency level downgraded.

[0121] For the health model (batch processing unit): If statistics show that the "true positive (TP)" rate (i.e., actual fault verification rate) for predictive maintenance events of a certain type of equipment is low, it indicates that the model may be overly sensitive or that some feature weights are biased. The optimization unit may: Appropriately raise the warning threshold of the model This makes its early warning system more conservative.

[0122] By using newly accumulated, accurately labeled case data, the health assessment model can be incrementally trained or fine-tuned to optimize its feature weight parameters.

[0123] The optimized new parameter configuration file or updated rule base is published to the corresponding storage location in the data analysis module. In subsequent analysis task cycles, the system will automatically load these optimized configurations.

[0124] Finally, the following points should be noted: First, in the description of this application, it should be noted that, unless otherwise specified and limited, the terms "installation", "connection", and "linkage" should be interpreted broadly, and can be mechanical or electrical connections, or internal connections between two components, or direct connections. "Up", "down", "left", "right", etc. are only used to indicate relative positional relationships. When the absolute position of the described object changes, the relative positional relationship may change. Secondly: The accompanying drawings of the embodiments disclosed in this invention only involve the structures involved in the embodiments disclosed in this invention. Other structures can refer to the general design. In the absence of conflict, the same embodiment and different embodiments of this invention can be combined with each other. In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A power maintenance and dispatching system based on big data, characterized in that, include: The data analysis module is used to process monitoring data of power equipment and generate predictive maintenance events that include planned adjustable thresholds and real-time anomaly alarm events that include emergency levels. A blockchain collaboration module, connected to the data analysis module, is used to convert received predictive maintenance events into on-chain planned maintenance contracts and received real-time abnormal alarm events into on-chain emergency maintenance contracts, and to automatically detect resource conflicts between the emergency maintenance contract and existing planned maintenance contracts after the emergency maintenance contract is generated. The blockchain collaboration module includes a conflict negotiation engine, which is used to execute the on-chain conflict resolution process. Based on the emergency level of the emergency maintenance contract and the adjustable threshold of the conflicting planned maintenance contract, a scheduling adjustment plan is generated according to the preset decision rules. The aforementioned scheduling adjustment plan is submitted to the relevant participating node for consensus verification. Once consensus verification is successful, update the status and timing information of the emergency maintenance contract and the conflicting planned maintenance contract. And a scheduling execution module, connected to the blockchain collaboration module, is used to generate and issue scheduling instructions based on the content of the emergency maintenance contract when the status of the emergency maintenance contract is updated to be executable.

2. A power maintenance and dispatching method based on big data, characterized in that, The method, applied to the big data-based power maintenance and dispatching system of claim 1, comprises: S1: Processes monitoring data of power equipment to generate predictive maintenance events containing planned adjustable thresholds and real-time anomaly alarm events containing emergency levels; S2: Convert the predictive maintenance events into on-chain planned maintenance contracts, and convert the real-time anomaly alarm events into on-chain emergency maintenance contracts; S3: After the emergency maintenance contract is generated, automatically detect resource conflicts between it and existing planned maintenance contracts; S4: Based on the emergency level of the emergency maintenance contract and the adjustable threshold of the conflicting planned maintenance contract, generate a scheduling adjustment scheme according to the preset decision rules; S5: Submit the scheduling adjustment plan to the relevant participating nodes for consensus verification; S6: Once consensus verification is successful, update the status and timing information of the emergency maintenance contract and the conflict-planned maintenance contract; S7: When the status of the emergency maintenance contract is updated to be executable, a scheduling instruction is generated and issued according to the content of the contract.

3. The power maintenance and dispatching method based on big data according to claim 2, characterized in that, Step S1 includes: By periodically analyzing the historical status data sequence of the equipment, the health trend of the equipment is evaluated, and when it is determined that maintenance is required, the predictive maintenance event is generated, and the plan adjustable threshold is calculated based on the rate of deterioration of the equipment health. By continuously comparing real-time monitoring data with dynamically generated threshold ranges, the real-time anomaly alarm event is generated when data is abnormal, and the urgency level is determined according to the degree of anomaly.

4. The power maintenance and dispatching method based on big data according to claim 2, characterized in that, The S2 step is executed through the oracle service and includes: listening to and obtaining the events generated by the data analysis module, formatting the events and calling the corresponding smart contract factory function to create the corresponding maintenance contract on the blockchain.

5. A power maintenance and dispatching method based on big data according to claim 2, characterized in that, Steps S4, S5, and S6 are executed by the conflict negotiation engine, wherein step S4 includes: Based on the resource requirements of the emergency maintenance contract, all planned maintenance contracts within a future preset time period are retrieved from the blockchain, and contracts with overlapping resource requirements are identified as conflicting contracts. Based on the urgency level of the emergency maintenance contract and the adjustable threshold of each conflicting contract, a preset two-dimensional decision matrix is ​​queried to determine the conflict resolution strategy. Based on the determined conflict resolution strategy, calculate specific scheduling adjustment plans.

6. The power maintenance and dispatching method based on big data according to claim 5, characterized in that, The row index of the preset two-dimensional decision matrix represents different urgency levels, and the column index represents flexible intervals divided based on the plan's adjustable threshold. Each cell in the matrix defines a corresponding conflict resolution strategy, which includes preempting resources for emergency tasks, negotiating the delay of planned tasks, or allowing tasks to be executed in parallel.

7. The power maintenance and dispatching method based on big data according to claim 5, characterized in that, When the conflict resolution strategy is "negotiating and delaying the planned task", the specific logic for calculating the scheduling adjustment scheme is as follows: under the premise of not exceeding the maximum delay time allowed by the adjustment threshold of each conflicting contract, calculate one or more new planned execution time points to minimize the total adjustment time of all conflicting contracts.

8. A power maintenance and dispatching method based on big data according to claim 2, characterized in that, It also includes step S0: before generating and sending the event, calculate the data fingerprint for the core raw data that triggers the event, and attach the data fingerprint to the event; When creating the maintenance contract in step S2, the data fingerprint is stored in the associated field of the on-chain contract.

9. A power maintenance and dispatching method based on big data according to claim 8, characterized in that, It also includes step S8: periodically retrieving the execution results of completed maintenance contracts and their associated data fingerprints from the blockchain; The original data is traced back based on the data fingerprint, and the accuracy of the previous analysis is evaluated based on the execution results; Based on the evaluation results, adjust the model parameters or threshold logic used when generating predictive maintenance events or real-time anomaly alarm events.

10. A power maintenance and dispatching method based on big data according to claim 2, characterized in that, The S7 step includes: listening for state change events of the maintenance contract on the blockchain; When the contract status is detected to be executable, a standard work order instruction conforming to the target operating system format is generated and issued based on the task details recorded in the contract. In addition, it receives progress feedback from the work site and sends the progress feedback back to the blockchain as a state update event to drive the state flow of the corresponding maintenance contract.

Images