Method for power consumption anomaly chain on-line cooperative judgment

Abstract

The application discloses a kind of on-chain collaborative research and judgment methods for power consumption anomaly, it is related to electric power data processing technical field, specifically includes: obtaining multiple power consumption anomaly clues data and converting into uniform event record, according to target power consumption object and occurrence time period association forms abnormal research and judgment set;Extract chain summary, generate off-chain index, write summary and index into block chain account book, and store clue data in off-chain space;Based on smart contract, generate collaborative research and judgment task, distribute to be checked content according to verification authority;After receiving verification information, with on-chain summary, target power consumption object and clue time sequence are carried out consistency check, generate review instruction when there is conflict, generate research and judgment result when meeting source, quantity and time sequence condition;Research and judgment result is bound with abnormal research and judgment set, generates credible traceability link and outputs research and judgment formation process under the request of traceability.The application improves the credibility of clue merging, verification review and traceability.

Description

Technical Field

[0001] This invention belongs to the field of power data processing technology, specifically relating to a collaborative analysis method for power consumption anomalies. Background Technology

[0002] With the widespread application of smart meters, electricity consumption information collection systems, marketing audit systems, transformer area line loss analysis platforms, and mobile inspection terminals, power supply companies are able to obtain more and more data clues related to electricity consumption anomalies. However, existing methods for judging electricity consumption anomalies typically rely on multiple business systems to collect, store, and process anomaly clues separately. The clue data in different systems differ in data format, field names, object identifiers, time precision, and anomaly type descriptions, making it difficult to merge multiple anomaly clues generated by the same target electricity user within similar time periods in a timely manner. Especially in scenarios such as adjacent time windows, multiple users in the same transformer area, or multiple metering points on the same line branch, problems such as mismerging, omission, or duplicate judgment of anomaly clues are prone to occur, affecting the accuracy of subsequent verification tasks.

[0003] Existing collaborative methods struggle to accurately distribute verification content based on the responsibilities and permissions of different stakeholders, and also lack the capacity for robust constraint management of changes in the status of verification tasks. When verification information returned by different stakeholders is inconsistent in terms of data source, electricity user, or the timing of anomalies, existing systems typically lack mechanisms to automatically identify conflicts, lock task status, and trigger a review process.

[0004] Existing anomaly data, verification records, review opinions, and final judgment results are typically scattered across different business systems or databases, lacking a unified and reliable binding relationship between the data. If data is replaced, verification criteria are modified, judgment results are overwritten, or status records are missing, it becomes difficult to promptly verify the authenticity and completeness of the data upon which the anomaly judgment result is based, and it is also difficult to reconstruct the formation process of the judgment result. Although blockchain technology can provide data tamper-proof and traceability capabilities, simply putting results or file hashes on the chain is still insufficient to solve problems such as merging multi-source clues, controlling collaborative verification status, closing the loop of conflict review, and ensuring complete traceability of the judgment process.

[0005] Therefore, there is an urgent need for a collaborative analysis method for abnormal electricity consumption on the chain to solve the above problems. Summary of the Invention

[0006] The purpose of this invention is to provide a collaborative judgment method for power consumption anomaly chain, which solves the technical problems in the prior art such as the difficulty in accurately merging multi-source power consumption anomaly clues, the lack of credible constraints in the collaborative verification process, the difficulty in timely review of conflicting information, and the difficulty in completely tracing the formation process of judgment results.

[0007] To achieve the above objectives, the present invention adopts the following technical solution:

[0008] A collaborative analysis method for power consumption anomalies includes:

[0009] Step 1: Obtain electricity anomaly clue data submitted by multiple parties, convert the electricity anomaly clue data into unified event records, and associate the relevant unified event records according to the target electricity user and the time period of occurrence to form an anomaly analysis set;

[0010] Step 2: Extract on-chain digests from the anomaly analysis set and generate off-chain indexes. Write the on-chain digests and off-chain indexes into the blockchain ledger, store the corresponding clue data in the off-chain space, and establish a verification relationship between the on-chain digests and the off-chain clue data.

[0011] Step 3: Based on the smart contract, read the on-chain summary and task status of the anomaly assessment set, generate collaborative assessment tasks for the anomaly assessment set, and distribute the content to be verified according to the verification permissions of the collaborating entities; after receiving the verification information returned by the collaborating entities, perform consistency verification using the on-chain summary, target electricity user, and clue timing as verification factors; when any verification factor is inconsistent, mark the corresponding verification information as conflict information and generate a review instruction; when each verification information meets the preset source conditions, quantity conditions, and timing consistency conditions, and there is no unprocessed conflict information, generate the electricity anomaly assessment result, and record the verification status change, conflict mark, and review result to the blockchain ledger;

[0012] Step 4: Bind the results of the power consumption anomaly assessment to the corresponding anomaly assessment set, and generate a trusted traceability link based on the on-chain summary, verification status change, conflict marker, review results and power consumption anomaly assessment results. When a traceability request is received, verify and output the assessment formation process through the trusted traceability link.

[0013] Furthermore, converting the electricity consumption anomaly clue data into a unified event record includes: extracting the electricity consumption object identifier, clue generation time, anomaly information, and submitting entity information from the electricity consumption anomaly clue data, and writing the extraction results into a preset event template to generate a unified event record with a unified field structure.

[0014] Furthermore, associating relevant unified event records according to the target electricity user and the time period includes: grouping unified event records whose electricity user identifier matches the same target electricity user and whose clue generation time falls within the same preset judgment time period into the same anomaly judgment set.

[0015] Furthermore, when the same unified event record can be categorized into multiple anomaly assessment sets, the object matching value and time overlap value between the unified event record and each anomaly assessment set are calculated respectively, and a comprehensive matching value is generated based on the object matching value and time overlap value; when the highest comprehensive matching value is greater than a preset merging threshold, and the difference between the highest comprehensive matching value and the second highest comprehensive matching value is greater than a preset difference, the unified event record is categorized into the anomaly assessment set corresponding to the highest comprehensive matching value; otherwise, the unified event record is marked as a clue to be confirmed.

[0016] Furthermore, the on-chain summary is generated by summarizing the unified event record, target electricity user, and occurrence time period corresponding to the anomaly assessment set; the off-chain index is set in correspondence with the on-chain summary and is used to locate the clue data corresponding to the anomaly assessment set in the off-chain space.

[0017] Furthermore, the collaborative assessment task includes a task identifier, content to be verified, verification period, and task status; the smart contract determines the content to be verified that the collaborative subject can receive based on the verification permissions of the collaborative subject, and distributes the corresponding verification task to the collaborative subject.

[0018] Furthermore, the task status flows between the pending distribution state, the distributed state, the returned state, the review state, and the confirmation state according to the preset state machine rules. Before the task status is updated, the smart contract verifies whether the current task status meets the transition conditions for entering the next task status. If it does not meet the conditions, it refuses to write the corresponding status update record. If it does meet the conditions, it writes the updated task status, the corresponding time information, and the execution entity information into the blockchain ledger.

[0019] Furthermore, determining whether each verification information meets the preset source condition, quantity condition, and timing consistency condition includes: the smart contract generating a source verification value based on the collaborative entity's responsibility type of the returned verification information, generating a quantity verification value based on the quantity of valid verification information, and generating a timing verification value based on the time deviation of the clues corresponding to each valid verification information; when the source verification value, quantity verification value, and timing verification value all meet the corresponding thresholds, the collaborative analysis task is updated to a confirmable state, and an electricity consumption anomaly analysis result is generated.

[0020] Furthermore, generating a trusted traceability link includes: using the anomaly assessment set formation record, on-chain summary writing record, verification status change record, conflict marker record, review result record, and electricity anomaly assessment result record as traceability nodes, and writing the summary value or index information of the previous traceability node into each traceability node, so that adjacent traceability nodes form a front-to-back binding relationship; when a traceability request is received, each traceability node is verified in sequence according to the front-to-back binding relationship, and the assessment formation process is output.

[0021] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are:

[0022] 1. This invention converts electricity anomaly clue data submitted by multiple parties into a unified event record, and combines the target electricity user, occurrence time, object matching value, time overlap value and comprehensive matching value to form an anomaly judgment set. This can reduce the risk of mis-merging and omission of clues from different sources due to inconsistent formats, close time boundaries or similar objects, and improve the accuracy of collection and judgment of multi-source electricity anomaly clues.

[0023] 2. This invention extracts on-chain summaries from the anomaly assessment set and generates off-chain indexes, writes the on-chain summaries and off-chain indexes into the blockchain ledger, stores clue data in off-chain space, and establishes a verification relationship between on-chain summaries and off-chain clue data. This can reduce on-chain storage pressure while ensuring the integrity, authenticity, and verifiability of anomaly clue data.

[0024] 3. This invention generates collaborative assessment tasks through smart contracts, distributes the content to be verified according to the verification permissions, and performs consistency verification, conflict marking, review processing and status recording on the verification information. At the same time, it generates a trusted traceability link, which can realize automatic constraints, conflict closed-loop processing and trusted traceability of the collaborative verification process. Attached Figure Description

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

[0026] Figure 1 The diagram illustrates the steps of a collaborative analysis method for power consumption anomalies along a power consumption chain according to the present invention.

[0027] Figure 2 This invention illustrates the flowchart of on-chain and off-chain collaborative evidence storage and consistency verification for the anomaly judgment set.

[0028] Figure 3 The flowchart of collaborative verification and on-chain automatic control for abnormal power consumption is shown. Detailed Implementation

[0029] 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.

[0030] like Figure 1 The method for collaborative analysis of power consumption anomalies, as shown, specifically includes the following steps:

[0031] Step 1: Obtain electricity anomaly clue data submitted by multiple parties, convert the electricity anomaly clue data into unified event records, and associate the relevant unified event records according to the target electricity user and the time period of occurrence to form an anomaly analysis set;

[0032] The data acquisition engine obtains electricity anomaly clues data submitted by multiple parties. This data is acquired through authorized means such as anti-theft smart meter terminals, marketing audit management systems, transformer area line loss analysis platforms, 95598 customer service hotline records, and mobile terminals used by on-site inspection personnel. Because the clue data from different sources differs in data format, field names, time granularity, and spatial granularity, this embodiment first performs a unified event record conversion on the original clue data.

[0033] Specifically, the data cleaning and filtering operator parses the original message and extracts the electricity user identifier, clue generation time, anomaly information, and submitting entity information from the original message. Then, the extracted information is filled into a preset standardized data specification template to generate a unified event record with a standardized key-value pair structure. The unified event record may include fields such as event number, electricity user identifier, clue generation time, anomaly type, submitting entity, clue source, and original clue index.

[0034] After generating unified event records, the association decision engine associates the unified event records according to the target power user and the time period of occurrence. Specifically, it traverses the unified event records in the current activity cache, matches the power user identifier with the same target power user, and includes unified event records whose clue generation time falls within the same preset judgment time period into the same anomaly judgment set.

[0035] To avoid incorrect merging of clues at the boundaries of adjacent time periods, or incorrect merging of similar electricity users in the same transformer area or on the same line, this embodiment introduces a candidate set comparison mechanism in addition to the basic merging rules. When a unified event record can fall into multiple candidate anomaly assessment sets, the correlation decision engine calculates the object matching value between the unified event record and each candidate anomaly assessment set. Overlapping value with time .

[0036] The object matching value The acquisition method is as follows: the correlation decision engine extracts the electricity user identifier from the unified event record and the candidate anomaly judgment set, and queries the electrical connection relationship in the distribution network physical topology diagram; if the household number or meter asset number is completely consistent, then If the identifiers are inconsistent but belong to the same distribution substation or medium-voltage distribution line branch, the number of edges of the shortest path in the topology is obtained by breadth-first search algorithm. According to the formula Derivation and calculation.

[0037] The time coincidence value The acquisition method is as follows: read the high-precision microsecond-level timestamp of the unified event record as... The mean of the timestamp set within the candidate anomaly assessment set is calculated as... Read the preset standard duration span as D, and use the formula Perform continuous time span projection calculations.

[0038] After obtaining the object matching value and the time overlap value respectively, this method reads the pre-deployed weighted fusion coefficients from the global configuration state variables of the smart contract, for example... ,satisfy The comprehensive matching value is calculated using a linear weighted operator. .

[0039] After the calculation is completed, the correlation decision engine sorts the comprehensive matching values ​​of all candidate anomaly assessment sets in descending order and selects the highest value. Second highest value And read the preset merge threshold from the blockchain ledger parameter configuration area. and preset difference threshold (Optimized and solidified during initialization using a grid search). Strict conditional branching is performed if and only if... and If the record is correct, it will be assigned to the corresponding anomaly analysis set; otherwise, it will be marked as pending confirmation and moved to the pending confirmation clue resource pool, to be manually verified and distributed in subsequent advanced audit processes.

[0040] Through the above processing, this embodiment does not simply mechanically aggregate clues according to time windows or object numbers, but introduces object relationships, time period relationships and distinguishability judgments among multiple candidate sets, thereby reducing the risk of erroneous merging of multi-source abnormal clues at time period boundaries or in scenarios where objects are similar.

[0041] Step 2: Extract on-chain digests from the anomaly analysis set and generate off-chain indexes. Write the on-chain digests and off-chain indexes into the blockchain ledger, store the corresponding clue data in the off-chain space, and establish a verification relationship between the on-chain digests and the off-chain clue data.

[0042] like Figure 2 As shown, after the anomaly assessment set is constructed and locked, the distributed evidence storage control engine immediately starts the distributed two-layer evidence storage and solidification process. The core purpose is to solve the problem of reducing blockchain storage costs and alleviating throughput bottlenecks, and to decouple large-capacity unstructured data from lightweight, highly reliable state credentials.

[0043] Extract on-chain digests from the anomaly assessment set. These on-chain digests consist of all unified event records and the target electricity user within the anomaly assessment set. Start and end timestamps of the occurrence period and end timestamp Based on the input parameters, a fixed-length hash value is generated using the SM3 hash algorithm, which conforms to the national commercial cryptography standard. The specific process is as follows: A byte stream serialization function is called to convert the first to nth unified event records into a normalized injective binary string, and then... , , Concatenated in a fixed order to form a continuous bit stream, the mathematical expression for the on-chain digest is:

[0044]

[0045] in, This is a binary bit concatenation operator. As an injective serialization function, the on-chain digest is bound not only to the clue content in the anomaly assessment set, but also to the target power user and the time period of occurrence. Therefore, when the clue content is replaced, the target power user is incorrectly referenced, or the time period of occurrence is modified, the recalculated digest value will change, thus enabling the identification of situations where off-chain clue data has been tampered with, replaced, or incorrectly referenced.

[0046] In the derivation Subsequently, this method synchronously generates off-chain indexes. Specifically, the distributed storage client packages raw messages from multiple channels, second-level current and voltage sampling waveforms, on-site inspection images, and other clue data, encrypts them using an asymmetric encryption algorithm, and then writes them to the privately deployed distributed storage cluster via streaming. After the data block is successfully written, the client obtains the content routing hash value returned by the cluster, and concatenates it with the storage protocol prefix and the cluster shard routing identifier to construct a globally unique hash. Then, it encapsulates and initiates a blockchain ledger writing transaction to the consensus network, and The transaction payload is persistently written to the global state database of the blockchain ledger. Finally, a verification relationship is enforced at the smart contract level: when a collaborating entity reads the original clue data through the off-chain index, it must first call the FetchOfflineData function to download the encrypted data packet, perform the same serialization and SM3 hash operation locally, and the verification equation is as follows: If the equation holds true, the data is reliable and can proceed to the subsequent collaborative verification stage; otherwise, a runtime exception is thrown and the current reading process is terminated.

[0047] Step 3: Based on the smart contract, read the on-chain summary and task status of the anomaly assessment set, generate collaborative assessment tasks for the anomaly assessment set, and distribute the content to be verified according to the verification permissions of the collaborating entities; after receiving the verification information returned by the collaborating entities, perform consistency verification using the on-chain summary, target electricity user, and clue timing as verification factors; when any verification factor is inconsistent, mark the corresponding verification information as conflict information and generate a review instruction; when each verification information meets the preset source conditions, quantity conditions, and timing consistency conditions, and there is no unprocessed conflict information, generate the electricity anomaly assessment result, and record the verification status change, conflict mark, and review result to the blockchain ledger;

[0048] like Figure 3 As shown, based on the internal state query function of the smart contract, the on-chain digest of the anomaly judgment set, which is fixed in the ledger, is passively triggered or periodically polled. and current task status When the smart contract recognizes When the status is PENDING_DIST (pending distribution), a collaborative analysis task (strongly typed composite data structure, including...) is automatically generated. (Four core fields)

[0049] In this embodiment The hash is generated by combining the current block height, timestamp, and unique identifier of the judgment set using a built-in hash operator.

[0050] Based on the distribution of access control permissions within smart contracts using a role-based access control matrix, for example, in one specific implementation, a municipal power supply company inspector gains advanced verification rights, enabling them to receive full details of leads and line loss mutation characteristic curves; a power supply station's field verification personnel gains on-site operation rights, enabling them to receive anonymized physical geographical locations, meter box asset numbers, and on-site photography requirements; and a third-party metrology and testing institution gains professional metrology rights, enabling them to receive the laboratory seal numbers of dismantled meters and metrology error test waveform data. Through this permission distribution method, different collaborating entities can only receive the content to be verified that matches their responsibilities and permissions, reducing the risk of sensitive data dissemination.

[0051] Add 86,400 seconds (24 hours) to the current block timestamp;

[0052] The initial value is assigned to the distributed state DISTRIBUTED;

[0053] To control the processing lifecycle of collaborative analysis tasks, the task state transitions between PENDING_DIST, DISTRIBUTED, RETURNED, RE_EXAMINE, and CONFIRMED according to preset rules. Before a state update, the smart contract calls the condition transition determination function. ,in The current state is represented by Act, which indicates the state transition action identifier and is determined by the transaction call function signature and the caller's role.

[0054] The state transition action identifier is automatically determined by the smart contract after receiving a transaction, based on "which contract function this transaction called" and "what on-chain role the transaction caller has." It is used to determine whether this transaction is allowed to drive a change in the task state and is defined as follows: ,in This indicates the signature of the smart contract function called in the transaction. This indicates the role of the transaction caller in the on-chain permissions registry. This represents the preset action mapping rules.

[0055] As shown in Table 1:

[0056] Table 1

[0057]

[0058] The process of determining an Act involves the smart contract parsing the transaction input data and obtaining the function signature of the transaction call. For example, if the transaction calls a function to submit verification information, the function signature corresponds to a "verification return action." The smart contract then queries the on-chain role and permission table based on the transaction initiation address to determine the caller's role. For example, if the caller is a field verifier, a third-party metrology agency, or a municipal inspector, the smart contract queries a preset action mapping table based on the function signature and the caller's role to generate the corresponding Act. If the function signature does not match the caller's role, the Act is determined to be an invalid action, INVALID_ACT.

[0059] The smart contract will display the current task state. and state transition action identifier Act input condition transition judgment function ,like This indicates that the action is permitted in the current state. The smart contract allows the task state to be updated. This indicates that the action is not permitted in the current state, and the smart contract refuses to update the state and rolls back the transaction.

[0060] For example, a task can flow from PENDING_DIST to DISTRIBUTED, and from DISTRIBUTED to RETURNED; when conflicting information exists, it flows from RETURNED to RE_EXAMINE; when the review is completed and the confirmation conditions are met, it flows from RE_EXAMINE to CONFIRMED. This state machine control prevents tasks from being confirmed without proper authorization, illegally rolled back, or bypassing the review process.

[0061] Once all collaborating entities have completed verification and submitted the verification information via cryptographic private key signing, the smart contract triggers a consistency check. This consistency check uses on-chain digests, the target electricity user, and the timing of the clues as core verification factors.

[0062] In this embodiment, before calculating the source verification value, quantity verification value, and timing verification value, the smart contract first determines the validity of the verification information returned by the collaborating entity. The verification information includes at least the task identifier, verification entity identifier, entity role, referenced on-chain summary, standardized electricity user identifier, clue timing identifier, verification conclusion, verification basis summary, submission time, and submission entity signature.

[0063] The smart contract determines the verification information as valid verification information when it simultaneously meets the following conditions: First, the submitting entity's signature verification is successful; second, the submitting entity's role in the on-chain permission registry matches the verification permissions required by the collaborative analysis task; third, the task identifier in the verification information is consistent with the current collaborative analysis task; fourth, the referenced on-chain digest in the verification information is consistent with the on-chain digest of the anomaly analysis set; fifth, the standardized electricity user identifier in the verification information is consistent with the target electricity user corresponding to the anomaly analysis set; sixth, the clue timing identifier in the verification information and the clue timing in the anomaly analysis set meet the preset timing deviation condition; seventh, the core fields in the verification information, such as the verification conclusion, submission time, and verification basis summary, are complete; eighth, the verification information is not marked as unprocessed conflict information, or although it is marked as conflict information, it has been confirmed by the review node as acceptable.

[0064] For verification information that does not meet any of the above conditions, the smart contract marks it as invalid verification information or verification information pending review, and writes the reason for invalidity, the submitting entity information, and the corresponding task identifier into the blockchain ledger. Invalid verification information is not included in the calculation of source verification value, quantity verification value, and time sequence verification value.

[0065] Specifically, the smart contract extracts the information submitted by the i-th entity. In ,in This represents the on-chain digest of the anomaly assessment set referenced when the i-th collaborative entity submits verification information. The result is determined by the collaborating entity after reading the clue data based on the off-chain index carried in the task and re-performing the digest verification. It is used to characterize whether the data on which the verification information is based is consistent with the on-chain evidence content of the current anomaly judgment set. The standardized electricity user identifier confirmed when the i-th collaborating entity submits verification information is determined by the collaborating entity based on the household number, user number, metering point number, meter asset number or transformer area number in the verification basis, after mapping through user files, metering asset files and binding relationships. The clue sequence identifier corresponding to the verification information submitted by the i-th collaborative entity is determined after uniform time format conversion, time zone correction and occurrence order sorting based on the anomaly occurrence time, collection time, on-site verification time or business record time in the verification basis. It is used to characterize the time position and chronological relationship of the verification information in the anomaly judgment set.

[0066] If satisfied Make Then mark the conflict information, and The system transitions to the RE_EXAMINE review status and simultaneously generates a review instruction containing a task identifier and a conflict factor index. This review instruction is pushed to a pre-defined review node via a blockchain event mechanism, such as an expert group node of a provincial power research institute or other professional nodes with review authority, which then review the conflict factors.

[0067] When the initial verification is consistent and there is no unprocessed conflict information, this method performs a multi-dimensional trust quantification judgment through a smart contract to determine whether the preset source conditions, quantity conditions, and timing consistency conditions are met.

[0068] Source verification value Obtained by traversing valid verification information. The smart contract acquires the trust weight of the entity's responsibilities. and historical performance rating coefficient And according to the formula The calculation is performed, where K is the total number of valid entities. The source verification value is used to determine whether the source of the collaborating entity returning the verification information meets the trust requirements. ,in, To preset the source threshold, the scores of valid verification sources in historically confirmed cases can be selected as a reference, and the lower limit of the source score that can cover the necessary responsible entities can be determined as the threshold.

[0069] Quantity verification value The digital signature used to verify the validity of each verification message and the non-emptiness of its core fields are summed according to the indicated function:

[0070]

[0071] in This indicates that the digital signature verification of the i-th verification message has passed. This indicates that the core field integrity check of the i-th verification message has passed. This is an indicator function. When the condition within the parentheses is true, =1, otherwise It is 0.

[0072] Determined based on anomaly type, risk level, and business review rules. .

[0073] For example, for low-risk data collection anomalies, at least one or two valid verification reports may be required; for high-risk incidents such as suspected electricity theft, meter malfunction, or abnormal line loss, at least three valid verification reports from different responsible entities may be required. .

[0074] Timing check value This is used to determine whether information verified by multiple parties is consistent in terms of time. The smart contract extracts a set of m valid timestamps. Calculate the mean The standard deviation is calculated using the large integer square root algorithm, and then calculated according to the formula. Derivation, requires ,in The preset timing consistency threshold is determined based on the data collection period, terminal clock error, communication transmission delay, duration of abnormal events, and time deviation range in historical cases.

[0075] For example, if a certain type of anomaly typically lasts for a short period, then a smaller allowable time dispersion is permitted. Set it to a high value; if a certain type of anomaly lasts for a long time or there is a significant delay in data reporting, the threshold can be appropriately lowered.

[0076] The smart contract reads data from the global parameter registration contract that matches the risk level of the electricity anomaly type. , , When the compound Boolean logic condition is satisfied At that time, the smart contract will Update the status to CONFIRMED, and extract the consensus conclusions from all parties through the content aggregation operator to generate an electricity anomaly assessment result that can be used for subsequent auditing or business processing.

[0077] While generating the assessment results, the smart contract triggers the underlying accounting primitives, atomically and persistently writing the verification status changes, conflict markers, review results, and assessment results into the blockchain ledger. Thus, the task distribution, verification return, conflict identification, review processing, and result confirmation in the collaborative assessment process all form verifiable on-chain records.

[0078] Step 4: Bind the results of the power consumption anomaly assessment to the corresponding anomaly assessment set, and generate a trusted traceability link based on the on-chain summary, verification status change, conflict marker, review results and power consumption anomaly assessment results. When a traceability request is received, verify and output the assessment formation process through the trusted traceability link.

[0079] The final generated electricity consumption anomaly assessment result is bound to a unique identifier for the corresponding anomaly assessment set. The binding includes at least the anomaly assessment set identifier, the collaborative assessment task identifier, the on-chain summary, and the assessment result identifier. Through this binding relationship, it is possible to reverse-engineer the corresponding anomaly assessment set, on-chain summary, and collaborative verification process from any assessment result.

[0080] Subsequently, this method generates a trusted traceability link. The trusted traceability link uses the formation record of the anomaly judgment set, the chain summary writing record, the verification status change record, the conflict marker record, the review result record, and the electricity anomaly judgment result record as interconnected traceability nodes, and is arranged in a chain structure according to the order of business occurrence.

[0081] When constructing the current traceability node, extract the current business status data payload. The hash value of the previous node and the current block timestamp The SM3 hash function is called to calculate the concatenated hash fingerprint. The mathematical derivation formula is as follows: .

[0082] In this way, each traceability node carries the hash value of the previous traceability node, thus creating a sequential binding relationship between the formation of the anomaly assessment set, the writing of on-chain digests, the verification of status changes, the collision marking, the review process, and the generation of results.

[0083] At any time after the method runs, when an external audit terminal submits a traceability request containing a specific anomaly assessment set ID via an RPC interface, the total number of traceability nodes M and the ledger-fixed hash set are extracted from the blockchain based on the anomaly assessment set ID. Initiate a forward iterative verification loop, recalculate the cascaded hash of each node according to the binding relationship, and perform real-time equality assertions with the ledger's fixed hash. The global integrity verification equation is as follows: If the result of the verification equation is equal to 1, it is determined that the trusted traceability link has not been tampered with, and the complete formation process of the electricity consumption anomaly assessment is output. The assessment formation process includes the source of anomaly clues, the unified event record conversion process, the anomaly assessment set formation process, the on-chain summary and off-chain index writing records, the collaborative assessment task distribution records, the collaborative subject verification information, the conflict marker records, the review result records, and the final electricity consumption anomaly assessment result.

[0084] If any traceability node fails verification, a traceability anomaly message is output, indicating the type of the anomaly, its location, and its cause. This allows for the identification of missing nodes, data tampering, result replacement, or status transition anomalies during the analysis process.

[0085] In this embodiment, each electricity consumption anomaly clue data generates a clue data packet upon submission. The clue data packet includes the submitting entity identifier, entity role, electricity consumption object identifier, anomaly type, anomaly occurrence time, clue generation time, original data hash value, device signature, and submitting entity signature. The data receiving end verifies the submitting entity signature based on the submitting entity certificate and verifies the device signature based on the device public key. After successful signature verification, the electricity consumption object identifier is mapped to a standardized electricity consumption object identifier, and the anomaly occurrence time and clue generation time are converted to a unified time format.

[0086] The off-chain stored data packets include original clue data, a unified event record list, a data list, the target electricity user, the analysis period, the data packet version number, and the encryption key index. The on-chain digest is generated by concatenating the unified event record list, target electricity user, analysis period, data packet version number, and original clue data hash value from the aforementioned data packets in a preset order, followed by digest calculation. The off-chain index includes the off-chain storage address, fragment identifier, data packet version number, encryption key index, and on-chain digest identifier. After the verification terminal reads the off-chain data packet according to the off-chain index, it recalculates the digest and compares it with the on-chain digest. If they match, the off-chain data packet is considered consistent with the on-chain evidence content.

[0087] The collaborative assessment task status includes pending distribution, distributed, returned, reviewed, confirmable, confirmed, and terminated states. The smart contract only allows state transitions according to a preset state machine. When the on-chain digest of verification information is inconsistent, the standardized electricity user identifier is inconsistent, or the timing deviation of the clues exceeds a preset timing threshold, the smart contract marks the corresponding verification information as conflicting information and updates the task status to reviewed. After the review node submits its review result, if the review result confirms the conflict, the corresponding verification information is excluded as invalid; if the review result confirms the conflict is not valid, the corresponding verification information is restored to valid verification information.

[0088] Valid verification information refers to verification information that simultaneously meets the following requirements: signature verification passed, submission subject permissions matched, core fields complete, referenced on-chain digest consistent, electricity user identifier consistent, and clue timing meets threshold requirements. When there is no unprocessed conflicting information, and the valid verification information meets the source condition, quantity condition, and timing consistency condition, the smart contract updates the task status to the confirmable status; after confirmation by the authorization subject or satisfaction of the automatic confirmation rules, the task status is updated to the confirmed status, and an electricity consumption anomaly assessment result is generated.

[0089] In this embodiment, the method converts multi-source electricity consumption anomaly clues into unified event records, and forms an anomaly judgment set through object matching, time overlap, and difference determination, reducing the risk of erroneous merging of anomaly clues; through the binding relationship between on-chain digests and off-chain indexes, on-chain and off-chain verification of key contents of the anomaly judgment set is realized; through the permission distribution of smart contracts, state machine control, three-factor consistency verification, and conflict review mechanism, on-chain automated control of the collaborative judgment process is realized; through a trusted traceability link composed of anomaly judgment set formation records, on-chain digest writing records, verification state change records, conflict marking records, review result records, and judgment result records, verifiable traceability of the entire electricity consumption anomaly judgment process is realized.

[0090] The above are merely preferred embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

[0091] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to specific implementations. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The invention is limited only by the claims and their full scope and equivalents.

Claims

1. A collaborative analysis method for power consumption anomalies, characterized in that, include: Step 1: Obtain electricity anomaly clue data submitted by multiple parties, convert the electricity anomaly clue data into unified event records, and associate the relevant unified event records according to the target electricity user and the time period of occurrence to form an anomaly analysis set; Step 2: Extract on-chain digests from the anomaly analysis set and generate off-chain indexes. Write the on-chain digests and off-chain indexes into the blockchain ledger, store the corresponding clue data in the off-chain space, and establish a verification relationship between the on-chain digests and the off-chain clue data. Step 3: Based on the smart contract, read the on-chain summary and task status of the anomaly assessment set, generate collaborative assessment tasks for the anomaly assessment set, and distribute the content to be verified according to the verification permissions of the collaborative entities; after receiving the verification information returned by the collaborative entities, perform consistency verification using the on-chain summary, target electricity user, and clue timing as verification factors; when any verification factor is inconsistent, mark the corresponding verification information as conflict information and generate a review instruction. When each verification information meets the preset source conditions, quantity conditions, and time sequence consistency conditions, and there is no unprocessed conflict information, an electricity consumption anomaly assessment result is generated, and the verification status change, conflict marker, and review result are recorded to the blockchain ledger. Step 4: Bind the results of the power consumption anomaly assessment to the corresponding anomaly assessment set, and generate a trusted traceability link based on the on-chain summary, verification status change, conflict marker, review results and power consumption anomaly assessment results. When a traceability request is received, verify and output the assessment formation process through the trusted traceability link.

2. The method for collaborative analysis of power consumption anomalies according to claim 1, characterized in that, Converting electricity consumption anomaly clue data into a unified event record involves: extracting the electricity consumption object identifier, clue generation time, anomaly information, and submitting entity information from the electricity consumption anomaly clue data, and writing the extraction results into a preset event template to generate a unified event record with a unified field structure.

3. The method for collaborative analysis of power consumption anomalies on a chain according to claim 2, characterized in that, Association of relevant unified event records based on target electricity users and time periods includes: grouping unified event records whose electricity user identifier matches the same target electricity user and whose clue generation time falls within the same preset judgment time period into the same anomaly judgment set.

4. The method for collaborative analysis of power consumption anomalies on a chain according to claim 3, characterized in that, When the same unified event record can be classified into multiple anomaly assessment sets, the object matching value and time overlap value between the unified event record and each anomaly assessment set are calculated respectively, and a comprehensive matching value is generated based on the object matching value and time overlap value. When the highest comprehensive matching value is greater than the preset merging threshold, and the difference between the highest comprehensive matching value and the second highest comprehensive matching value is greater than the preset difference, the unified event record will be merged into the abnormal judgment set corresponding to the highest comprehensive matching value; otherwise, the unified event record will be marked as a clue to be confirmed.

5. The method for collaborative analysis of power consumption anomalies according to claim 1, characterized in that, The on-chain digest is generated by digesting the unified event record, target electricity user, and occurrence time period corresponding to the anomaly assessment set. The off-chain index is set in correspondence with the on-chain digest and is used to locate clue data in the off-chain space that corresponds to the anomaly assessment set. The off-chain index includes at least: off-chain storage address, data packet version number, fragment identifier, encryption key index, and on-chain digest identifier.

6. The method for collaborative analysis of power consumption anomalies on a chain according to claim 1, characterized in that, The collaborative assessment task includes a task identifier, content to be verified, verification period, and task status; the smart contract determines the content to be verified that the collaborating entity can receive based on the verification permissions of the collaborating entity, and distributes the corresponding verification task to the collaborating entity.

7. The method for collaborative analysis of power consumption anomalies on a chain according to claim 6, characterized in that, The task status flows between the pending distribution state, the distributed state, the returned state, the review state, and the confirmed state according to the preset state machine rules. Before the task status is updated, the smart contract verifies whether the current task status meets the conditions for entering the next task status. If it does not meet the conditions, it refuses to write the corresponding status update record. If it does meet the conditions, it writes the updated task status, the corresponding time information, and the execution entity information into the blockchain ledger.

8. The method for collaborative analysis of power consumption anomalies according to claim 1, characterized in that, Determining whether each verification message meets the preset source condition, quantity condition, and timing consistency condition includes: the smart contract generates a source verification value based on the collaborative entity's responsibility type of the returned verification information, generates a quantity verification value based on the quantity of valid verification information, and generates a timing verification value based on the clue time deviation corresponding to each valid verification message; the valid verification information is verification information that simultaneously meets the following conditions: the submitting entity's signature verification is passed, the submitting entity's permissions match the verification task's permissions, the core fields are complete, the referenced on-chain digest is consistent with the on-chain digest of the anomaly judgment set, the confirmed standardized electricity user identifier is consistent with the target electricity user, the clue timing meets the preset timing deviation condition, and it is not marked as unprocessed conflict information; when the source verification value, quantity verification value, and timing verification value all meet the corresponding thresholds, the collaborative judgment task is updated to a confirmable state, and an electricity anomaly judgment result is generated.

9. The method for collaborative analysis of power consumption anomalies on a chain according to claim 1, characterized in that, The process of generating a trusted traceability link includes: using the formation record of the anomaly assessment set, the on-chain summary writing record, the verification status change record, the conflict marker record, the review result record, and the electricity anomaly assessment result record as traceability nodes, and writing the summary value of the previous traceability node into each traceability node to form a front-to-back binding relationship between adjacent traceability nodes; when a traceability request is received, each traceability node is verified in sequence according to the front-to-back binding relationship, and the assessment formation process is output.

Images