PMS-driven asset full-life-cycle intelligent operation and maintenance management and control method and system

Abstract

The invention discloses a PMS-driven asset full-life-cycle intelligent operation and maintenance management and control method and system, and relates to the technical field of equipment operation and maintenance. Equipment operation and maintenance data are acquired through cooperation of IOT equipment and a PMS; performing dynamic permission grading on the equipment operation and maintenance data based on a smart contract, wherein the dynamic permission grading is at least based on a user role and data sensitivity; automatically adjusting the dynamic permission level of the user based on at least one real-time factor; and performing classified storage on the equipment operation and maintenance data by adopting a Hash anchoring mode, wherein the classified storage data content corresponds to the dynamic permission level of the user. In the aspect of data security, an original owner is prevented from being out of authority and data is prevented from being tampered by means of dynamic authority and hash storage, and a new owner is helped to evaluate equipment; in the aspect of authority management, the authority is accurately controlled through an intelligent contract, and adjustment is performed according to real-time factors; in terms of data circulation, efficient circulation is achieved through a three-level architecture, and the market operation efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of equipment operation and maintenance technology, specifically to a PMS-driven intelligent operation and maintenance management method and system for the entire lifecycle of assets. Background Technology

[0002] In the field of rental and used equipment trading of fixed equipment in construction projects, the current status of operation and maintenance data management for large equipment (such as tower cranes, elevators, and construction hoists) is not optimistic, and there are many technical pain points that urgently need to be solved. In the traditional model of selling or transferring fixed equipment, the original owner may retain access to sensitive data (such as historical fault records and maintenance cost details) based on the old system permission settings after the transaction. This not only poses a data security risk, but also makes it difficult for the new owner to obtain complete and effective equipment operation and maintenance data, making subsequent equipment maintenance work extremely difficult, and the actual value assessment of the equipment may be biased due to the lack or inaccuracy of key data. In the secondhand trading process, the transfer of device data permissions is particularly problematic. Currently, paper contracts are often used to stipulate changes in data permissions; however, paper contracts are highly susceptible to human error and are at risk of being tampered with or lost.

[0003] These pain points severely restrict the healthy and efficient development of the construction equipment leasing and second-hand trading market, and there is an urgent need for an innovative and reliable technical solution to achieve the safe and reasonable management and transfer of operation and maintenance data. Summary of the Invention

[0004] The purpose of this invention is to provide a PMS-driven intelligent operation and maintenance management method and system for the entire asset lifecycle, in order to address the shortcomings of the prior art.

[0005] To achieve the above objectives, this invention provides the following technical solution: a PMS-driven intelligent operation and maintenance management method for the entire asset lifecycle, comprising: Equipment operation and maintenance data is obtained through collaboration between IoT devices and the PMS system; The device operation and maintenance data is dynamically classified into permissions based on smart contracts, and the dynamic permission classification is based at least on user roles and data sensitivity. Automatically adjust the user's dynamic permission level based on at least one real-time factor; The device operation and maintenance data is classified and stored using a hash anchoring method, and the classified and stored data content corresponds to the user's dynamic permission level. Users are set to only be able to view data content in the category storage corresponding to their current dynamic permission level.

[0006] In a preferred embodiment, the dynamic permission classification of the device operation and maintenance data based on smart contracts includes: Static permission templates are set based on user roles, and the roles include at least administrators, operations and maintenance personnel, and auditors; Assign dynamic weights to each type of equipment operation and maintenance data to characterize its sensitivity; The smart contract associates the static permissions of a user role with the sensitivity weight of the data, generating permission matching rules that allow users to access data only within the sensitivity weight range permitted by their role's permission limit.

[0007] In a preferred embodiment, the static permission template is stored in the role permission library of the smart contract. When a new user is added, the template corresponding to the role is automatically matched. Modification of the static permission template requires confirmation by the signatures of the administrator node, the auditor node, and the supervisor node. The data sensitivity weights are automatically calculated by the smart contract according to preset data influence range rules. Among them, the weight of equipment security parameters is higher than that of ordinary operation and maintenance parameters, and the weight of financial cost parameters is the highest.

[0008] In a preferred embodiment, the automatic adjustment of the user's dynamic permission level based on at least one real-time factor includes: Device operating status triggers permission adjustment: When the device triggers a fault alarm, the smart contract automatically elevates the data access permissions of the designated maintenance team; when the device is in maintenance mode, the smart contract automatically restricts the data access permissions to the designated maintenance team. Time window triggers permission adjustment: During the preset peak operation and maintenance period, the smart contract grants all operation and maintenance personnel access to core data; during the preset non-working period, the smart contract restricts data access to emergency operation and maintenance personnel. User behavior anomalies trigger permission adjustments: When a smart contract detects abnormal access behavior by a user, it automatically suspends the corresponding user's permissions and generates a record of evidence.

[0009] In a preferred embodiment, the classification and storage using a hash association method includes: For sensitive data, its hash value and timestamp are stored on the blockchain, while its original file is encrypted and stored off-chain on an offline server. For core data, the hash values ​​of its structured fields are bound to the storage addresses of the off-chain distributed storage system and then stored on-chain. For auxiliary data, the original files are stored in an off-chain distributed file system, while the metadata digest and access control policies are stored on-chain.

[0010] In a preferred embodiment, the ability for a user to view only the data content corresponding to their dynamic permission level is achieved through the following mechanism: Users must submit a digital signature to verify their identity when accessing data; The smart contract generates a dynamic access whitelist based on the user's current dynamic permission level. The whitelist defines the data types and operation scope that the user can access. The core and sensitive data are encrypted using an attribute-based encryption algorithm. To decrypt the data, users need to submit an attribute key that matches their own attributes to the smart contract.

[0011] This invention also provides a PMS-driven intelligent operation and maintenance management system for the entire asset lifecycle, comprising: the system adopts a cloud-edge-device three-level architecture, including: The terminal acquisition layer, which includes an IoT device module and a PMS terminal module, is used to collect equipment operation and maintenance data and integrate it with historical data in the PMS system. The edge preprocessing layer includes an edge computing node module and a local distributed storage module, which are used to perform noise reduction, structured processing and local caching on the device operation and maintenance data. The cloud-based management layer includes a smart contract engine module, a blockchain storage module, a PMS core collaboration module, and a user interaction module, which are used to achieve dynamic permission management, data classification and storage, and audit traceability.

[0012] In a preferred embodiment, the terminal acquisition layer includes: The IoT device module includes status monitoring sensors, environmental sensing devices, and operation recording devices. It supports LORaWAN and 4G / 5G communication and has a built-in encryption chip. The PMS terminal module is deployed on the PMS server and maintenance terminal within the enterprise. It connects to the PMS system through an API gateway and supports OAuth2.0 protocol authentication.

[0013] 9. The PMS-driven intelligent operation and maintenance management system for the entire asset lifecycle according to claim 7, characterized in that the edge preprocessing layer comprises: Edge computing node modules are deployed on edge servers at the asset site to process data in real time with a processing latency of no more than 500ms. The local distributed storage module, which includes IPFS private nodes and a distributed file system, is used to store the original files of auxiliary data and generate unique file identifiers.

[0014] In a preferred embodiment, the edge preprocessing layer includes: Edge computing node module, deployed as an edge server at the asset site, with built-in FPGA chip and processing latency ≤500ms; The local distributed storage module includes IPFS private nodes and the MinIO distributed file system, which stores auxiliary data original files and generates unique file IDs.

[0015] In a preferred embodiment, the cloud management layer includes: The smart contract engine module is developed based on a consortium blockchain and adopts the PBFT consensus mechanism. The blockchain storage module, consisting of a multi-node consortium blockchain cluster, is used to classify and store sensitive data, core data, auxiliary data, and corresponding audit records. The security module includes node authentication, data encryption, and anomaly protection mechanisms. Modification records of sensitive data form an independent audit chain, which can only be accessed by auditors.

[0016] The technical effects and advantages provided by the present invention in the above technical solution are as follows: This patent, through a dynamic permission hierarchy and real-time adjustment mechanism, completely avoids the data access risks inherent in traditional models for the original owner in fixed equipment sales or transfers. Once the transaction is complete, the smart contract automatically and immediately revokes the original owner's access to the equipment's operational data according to preset rules. The new owner, based on their role and permissions, gains corresponding data access rights after verification by the smart contract. Furthermore, data storage employs hash anchoring and categorized storage methods. Sensitive data is stored on the blockchain with hash values ​​and timestamps, while the original files are stored off-chain on an offline encrypted server. Core data is hash-anchored and managed by a multi-party IPFS node cluster, ensuring data security from the storage source, preventing unauthorized access and tampering, providing a reliable data environment for the new owner, and accurately assessing the actual value of the equipment.

[0017] The smart contract system constructed in this patent is both efficient and reliable. Taking the access needs of different personnel to equipment data in the equipment leasing business as an example, it refines the static permission hierarchy based on user roles, clearly defining the role template permissions for administrators, maintenance personnel, auditors, etc.; then, combined with the dynamic weighted calculation of data sensitivity, the smart contract automatically associates user role permissions with data sensitivity weights, generating a role-data weight matching table to achieve precise permission control. At the same time, real-time factors can trigger permission adjustments to ensure that permissions always adapt to the actual business scenario and avoid data abuse caused by permission confusion.

[0018] This system employs a three-tiered cloud-edge-device architecture. The IoT device module and PMS terminal module at the terminal acquisition layer collaboratively collect and integrate data. The edge preprocessing layer performs noise reduction, structured processing, and local caching. The cloud-based management layer implements dynamic access control, data storage, and audit traceability. The entire process is automated and standardized, ensuring efficient and accurate data flow. For example, when a new leasing company takes over equipment, it can quickly obtain complete equipment operation and maintenance data through the system. Based on the permissions allocated by the smart contract, it can smoothly carry out subsequent maintenance work, significantly improving the operational efficiency of the construction equipment leasing and second-hand trading market and promoting its healthy and orderly development. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0020] Figure 1 This is a flowchart of the method of the present invention.

[0021] Figure 2 This is a system block diagram of the present invention. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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, 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.

[0023] Example 1, please refer to Figure 1 As shown in this embodiment, the PMS-driven intelligent operation and maintenance management method for the entire asset lifecycle includes: S1. Obtain equipment operation and maintenance data through collaboration between IoT devices and the PMS system; S2. Dynamically classify permissions for the device operation and maintenance data based on smart contracts; S3. Adjust the user's dynamic permission level considering real-time factors; S4. The device operation and maintenance data is classified and stored using a hash anchoring method, and the classified and stored data content corresponds to the user's dynamic permission level. S5. Users are set to only be able to view data content stored in categories corresponding to the dynamic permission level.

[0024] As described in S1-S5 above, in the field of fixed equipment leasing and used equipment trading in construction engineering, the current state of operation and maintenance data management for large equipment (such as tower cranes, elevators, and construction hoists) is far from satisfactory, with many technical pain points that urgently need to be addressed. In scenarios involving the sale or transfer of fixed equipment, under the traditional model, after the transaction is completed, the original owner may still retain access to sensitive data (such as historical fault records and maintenance cost details) based on the old system permission settings. This not only poses a data security risk, but also makes it difficult for the new owner to obtain complete and effective equipment operation and maintenance data, resulting in numerous difficulties in subsequent equipment maintenance work, and the actual value assessment of the equipment is also biased due to the lack or inaccuracy of key data. In the used equipment transaction process, the transfer of equipment data permissions is even more problematic. Currently, paper contracts are mostly used to stipulate changes in data permissions; however, paper contracts are easily affected by human factors and are at risk of being tampered with or lost.

[0025] By employing a dynamic permission hierarchy and real-time adjustment mechanism, the risk of data access for the original owner is completely avoided in fixed equipment sales or transfer scenarios, unlike traditional models. Once the transaction is complete, the smart contract automatically and immediately revokes the original owner's access to equipment maintenance data according to preset rules. The new owner, based on their role and permissions, gains corresponding data access rights after verification by the smart contract. Furthermore, data storage employs hash anchoring and categorized storage methods. Sensitive data is stored with hash values ​​and timestamps on the blockchain, while the original files are stored off-chain on an offline encrypted server. Core data is hash-anchored and managed by a multi-party IPFS node cluster, ensuring data security from the storage source and preventing unauthorized access and tampering. This provides a reliable data environment for the new owner, enabling accurate assessment of the equipment's actual value. The constructed smart contract system is both efficient and reliable. Taking the different personnel's access needs for equipment data in equipment leasing as an example, static permission hierarchy based on user roles is refined, clearly defining role template permissions for administrators, maintenance personnel, auditors, etc. Combined with dynamic weighted calculation of data sensitivity, the smart contract automatically associates user role permissions with data sensitivity weights, generating a role-data weight matching table for precise permission control. Meanwhile, real-time factors can trigger permission adjustments, ensuring that permissions always adapt to actual business scenarios and avoiding data abuse caused by permission confusion.

[0026] In one embodiment, the dynamic permission hierarchy policy in step S2 includes: S201. Refinement of static permission levels based on user roles: S2011, Administrator Role: The template includes full data viewing (sensitive data details + complete core / auxiliary data content) + sensitive data modification (requires multi-node verification) + permission allocation permissions, but no core / auxiliary data modification permissions, and the upper limit of permission allocation is that the user's own permissions cannot be elevated to the super administrator level; S2012, Operations and Maintenance Personnel Role: The template includes core data viewing (fault codes / complete maintenance records) + auxiliary data viewing (only inspection photos / logs from the last 3 months) + auxiliary data upload + fault record submission permissions, but no permissions to view sensitive data or modify any data; S2013, Auditor Role: The template includes full data read-only viewing (sensitive data is anonymized, such as hiding the specific amount of maintenance costs) + operation traceability record viewing permissions, but no data modification / upload permissions, ensuring audit independence; S2014. Static permission templates are stored in the role permission library of smart contracts. When a new user is added, the corresponding template is automatically matched. Modification of the template requires the signature confirmation of three nodes: administrator node, auditor node, and supervisor node, to avoid omissions in manual configuration or malicious tampering. S202. Dynamic weighting and grading calculation based on data sensitivity: A sensitivity weight value (0-10 points) is assigned to each type of data. The weight value is automatically calculated by the smart contract based on the data's impact range. A weighting calculation model based on a rule engine is adopted, with preset rules including: key parameters related to equipment safety (such as tower crane tilt angle) have a weight of 8 points; parameters related to financial costs (such as maintenance costs) have a weight of 10 points; and ordinary operation and maintenance data (such as temperature logs) have a weight of 3 points. S2021, Equipment operating parameters (such as voltage and current): Weight 3 points, viewing access level is public (all roles can view the full content); S2022, Fault Code (e.g., E001-Motor Fault): Weight 6 points, Viewing Permission Level: Operations and Maintenance Level (Administrators / Operations and Maintenance Personnel can view the full content, Auditors can view the fault code, and the responsible person information is hidden). S2023, Maintenance Records (including repair costs and spare parts prices): Weight 8 points, Viewing permission level: Administrator (only administrators can view the complete cost details, auditors can only view the anonymized repair amount range, and maintenance personnel have no viewing permission). S2024. The smart contract associates user role permissions with data sensitivity weights, generating a role-data weight matching table, allowing users to access only data whose weight value is ≤ the upper limit of the role permission; S203. Verification and adjustment of initial permission assignments (including prevention of administrator over-privilege): S2031. After the smart contract automatically assigns initial permissions, it needs to be verified by three nodes: the administrator node, the auditor node, and the supervisor node respectively verify whether the permission assignment complies with the rule of no over-scope permissions (such as whether the administrator has been assigned core data modification permissions). Only after all three nodes confirm that there are no errors will the initial permissions officially take effect. S2032. If the predefined rules are updated (e.g., auditors need to add full access to fault codes), the smart contract will automatically scan the initial permissions of all users and make batch adjustments to permissions that do not conform to the new rules. The adjustment log must include a comparison of permissions before and after the adjustment + three-node signatures and be stored on the blockchain. Administrators do not have the authority to adjust rules individually.

[0027] S204. Administrator role permission constraint mechanism: S2041. When an administrator submits a data modification request, the smart contract automatically triggers the two-factor approval process for equipment operation and maintenance. First factor: The request must include the administrator's digital signature and the reason for the operation (such as equipment maintenance, equipment procurement cost adjustment, or equipment maintenance). The second factor: Auditor nodes must review the request within 24 hours and submit their audit opinion (agree / reject) on the blockchain; S2042. The smart contract will only execute the data modification operation and generate a device maintenance modification record if both factors pass. Device maintenance includes: Data hash before modification, data hash after modification; Digital signatures for administrators and auditors; Operation timestamp and blockchain block height; S2043, Auditor Review Interface Function: Auditors can view administrator requests through the web-based audit module. The interface includes request details (reason for operation, data type to be modified), administrator signature, current device status, and other information. Auditors can approve or reject requests with one click and add audit comments (such as supplementary proof of maintenance costs if required). S2044, Interface Specification: Administrators submit requests through the RESTful device operation and maintenance API interface ( / api / mOdify-request), and auditors review and approve them through the / api / audit interface, which returns the results. The interface must verify the user's identity and permissions. S2045. If the auditor rejects the request, the smart contract will automatically reject it and notify the administrator, and the rejection record will be synchronously recorded on the blockchain. As mentioned above, to address the multi-party permission requirements of the original owner, new owner, maintenance team, and auditor after equipment transactions, role templates are refined through S201: the new owner, as an administrator, can view all data (such as historical equipment fault records and maintenance costs) to assess equipment value; the maintenance team can only view core fault codes and inspection data from the past three months to conduct maintenance; and the auditor can view anonymized data to ensure transaction compliance. This avoids the problems of incomplete data for the new owner and lack of operational permissions for maintenance personnel caused by the one-size-fits-all approach in traditional models. In S2014, static templates are stored in smart contracts. When new maintenance personnel or auditors are added after equipment transactions, the system automatically matches the corresponding templates, eliminating the need for repeated manual configuration. For example, after a used tower crane transaction, when a new leasing company adds maintenance personnel, the system directly assigns core data viewing and auxiliary data upload permissions, avoiding the risk of missing or unauthorized permissions due to manual configuration omissions. S202 classifies key data such as maintenance costs (weight 10 points) and tower crane tilt angle (weight 8 points) into different levels compared to ordinary temperature logs (weight 3 points), allowing only administrators to view high-weight sensitive data. In secondhand equipment transactions, the original owner can no longer access the repair cost details of the sold equipment, and the new owner does not need to worry about core security data being accessed by unrelated parties, solving the pain point of incomplete data permission transfer in traditional transactions. S2031 requires permission allocation to be verified by the administrator, auditor, and regulatory node. For example, when a new owner applies for permission to modify sensitive data, it must be confirmed by all three parties before it takes effect, preventing a single entity from abusing its permissions to tamper with historical equipment failure data, ensuring the authenticity of equipment data in secondhand transactions, and providing a reliable basis for equipment value assessment. In S2041-2045, administrators modifying sensitive data (such as correcting repair costs for secondhand equipment) must sign themselves and be reviewed by the auditor, and the modification record includes a hash value and timestamp and is recorded on the blockchain. In equipment leasing scenarios, this prevents administrators from unilaterally tampering with equipment maintenance records to cover up operational oversights. Auditors can clearly trace the modification process through the web interface, ensuring the data rights of both the lessor and lessee. Permission operations are standardized through RESTful APIs, and rejection records are synchronously recorded on the blockchain. If an administrator's request to modify equipment data is rejected by the auditor due to a lack of cost proof, the rejection reason and evidence are recorded on the blockchain and cannot be tampered with. In disputes involving the sale of used equipment, this can serve as a basis for determining the reasonableness of data modifications, reducing disputes caused by a lack of transparency in permission operations.

[0028] In one embodiment, the real-time factors in step S3 include: S301. Device operating status permission triggering logic (including permission limit constraints): Device operating status is collected in real time by IoT devices, processed by edge computing nodes, and sent to the smart contract in the form of status codes (e.g., 01-normal operation, 02-fault alarm, 03-maintenance mode). S3011. When the status code is 02-Fault Alarm, the smart contract immediately triggers the operation and maintenance personnel to elevate their privileges. The upper limit of the elevation is the full access to core data, and it cannot be elevated to the access to sensitive data. S3012. When the status code is 03-Maintenance mode, only the designated operation and maintenance team is allowed to access core / auxiliary data. Other user permissions are temporarily frozen, and administrators do not have permission to unfreeze permissions for asset data that are not their responsibility. S302. Time window access control details (including administrator access constraints): The smart contract pre-sets time window rules, which are linked with the PMS system's operation and maintenance plan module: S3021. During peak maintenance periods (e.g., 8:00-18:00): grant all maintenance personnel access to core data, shorten the response time for permission adjustments (≤100ms), and allow administrators to view permission adjustment records without intervention permissions. S3022. During non-working hours (e.g., 0:00-6:00): Only emergency maintenance personnel are allowed to view auxiliary data and core data fault records. When administrators need to access sensitive data, they must trigger secondary authentication by the auditor node and the supervisor node. They can only view the data and cannot modify it. S303. Criteria for detecting abnormal user behavior (including monitoring abnormal administrator behavior): The smart contract has a built-in abnormal behavior detection model. Thresholds are set based on historical behavior data. Administrator behavior is monitored in the same way as ordinary users. S3031. Frequent access to non-authorized data: Accesses ≥ 5 times within 1 hour (including administrator access to core data modification entry), which is considered abnormal. S3032. Login from a different location: If the login IP is located in a different province than the frequently used IP and there is no prior notification record (administrators need to notify on the blockchain 24 hours in advance), it is judged as abnormal. S3033, Operations Beyond Scope: An administrator's attempt to modify core / auxiliary data or elevate their own privileges to the super administrator level is directly judged as abnormal. S3034. Threshold setting rules: The frequent access threshold is dynamically adjusted based on the average of the user's historical behavior. The initial threshold is 5 times / hour. If the user's access frequency continues to increase recently (e.g., the average number of accesses in the past 7 days is ≥4 times), the threshold will be automatically adjusted to 6 times / hour. Upon detecting abnormal behavior, the smart contract immediately suspends the user's current permissions (the suspension of administrator permissions requires simultaneous notification to the regulatory node), sends a three-party abnormality alarm to the administrator, auditor, and regulatory node, and records the abnormal behavior type, occurrence time, login IP, and operation content on the blockchain. This information cannot be deleted. It also triggers an automatic evidence collection process, including intercepting user operation logs, collecting device status data, and generating an evidence collection report on the blockchain. S304. Real-time data stream transmission and processing: Real-time data is transmitted using a Kafka message queue, which is divided into high priority (device failure, abnormal behavior) and low priority (normal device operating parameters). S3041, High-priority data: Directly pushed to the core node of the smart contract, triggering permission adjustment logic, with a processing delay of ≤500ms; S3042, Low-priority data: Batch aggregation and push, processed every 5 minutes to avoid consuming too many on-chain resources; S3043. After the smart contract processes the data stream, it generates the data processing result + timestamp and synchronizes it to the real-time monitoring module of the PMS system, so that the administrator can view the trigger source for permission adjustment.

[0029] As mentioned above, when a leased tower crane or elevator triggers a fault alarm (status code 02), S3011 immediately elevates the corresponding maintenance team's permissions to core data viewing (such as historical fault codes and maintenance plans) via a smart contract, with the upper limit of access explicitly set to prevent access to sensitive data. Compared to the traditional model where maintenance requires permission applications and time-consuming approvals, this mechanism allows maintenance personnel to quickly obtain critical data. For example, when a used elevator malfunctions, the maintenance team can view fault records without waiting for administrator authorization, improving maintenance response efficiency by more than 50% and reducing downtime losses for leased equipment. When the equipment enters maintenance mode (status code 03), S3012 only grants permissions to the designated maintenance team, freezing permissions for other users (including the original owner), and the administrator cannot unfreeze permissions for assets not under their responsibility. In post-use equipment transaction maintenance scenarios, this prevents the original owner from accessing sensitive equipment data (such as maintenance costs) under the guise of maintenance, while also preventing unauthorized personnel from accidentally affecting maintenance, ensuring a closed-loop data flow during the maintenance process. S3021 grants core data access permissions to maintenance personnel during peak maintenance hours (8:00-18:00) with a response time of ≤100ms, adapting to the centralized maintenance needs of leased equipment. During non-working hours (0:00-6:00), only emergency access is maintained; administrators need dual-node secondary authentication to access sensitive data. For example, after a used tower crane transaction, the original owner cannot illegally access equipment data during non-working hours in the early morning, and the new owner does not need to worry about data leakage during unnecessary periods, resolving the security risks of traditional 24 / 7 access. S303 provides equal monitoring for administrators and ordinary users. For example, frequent attempts by the original owner to access sensitive data of sold equipment (≥5 times per hour), unreported logins from different locations, or attempts by administrators to modify core data will all trigger anomaly interception. Simultaneously, S303's automated evidence collection process (log capture, report generation, and on-chain upload) can secure operational evidence. In disputes involving used equipment transactions, if the original owner maliciously tampers with equipment operating data, auditors can trace responsibility through on-chain evidence reports, protecting the rights of the new owner. S3041 pushes high-priority data such as equipment failures and abnormal behaviors directly to the smart contract via Kafka, with a processing latency of ≤500ms. For example, when a leased construction hoist is at risk of tipping over (high-priority data), the system can immediately trigger permission adjustments and alarms to prevent the accident from escalating due to data transmission delays. Meanwhile, low-priority data such as ordinary temperature logs are processed in batches (S3042), reducing on-chain resource consumption and lowering system maintenance costs. S3043 synchronizes permission adjustment results (such as fault-based privilege escalation, abnormal freezing) to the PMS real-time monitoring module, allowing both the lessor and lessee, as well as the auditor, to view the reasons for permission changes in real time. For example, after a used equipment transaction, the new owner can clearly see through the monitoring module when maintenance permissions were escalated due to a fault and who triggered the permission request outside of working hours, ensuring full transparency of data operations and reducing transaction disputes caused by opaque permission changes.

[0030] In one embodiment, the hash anchoring and categorized storage in step S4 are implemented as follows: S401. Security reinforcement of sensitive data through dual-layer storage (including preventing modification after upload): S4011, On-chain full storage: The hash value of sensitive data (such as device key, user password, maintenance cost) is generated using the SHA-384 algorithm. After the data is uploaded, a hash certificate + timestamp is generated and uploaded to the chain immediately. The hash certificate cannot be modified after it is generated. If sensitive data needs to be modified (such as cost entry error), a modification application + supporting materials must be submitted. After being signed by the administrator node + auditor node + supervisor node, a new hash value is generated and uploaded to the chain. The old hash value is retained as the basis for modification traceability. S4012 Off-chain encrypted storage: The original files of sensitive data are stored on an offline encrypted server. The server is physically isolated from the blockchain network and can only be accessed through on-chain authorization and offline decryption. After decryption, the data can only be viewed and cannot be modified locally. S4013, Data Backup Strategy: Weekly off-site backup of the hash values ​​of sensitive data on the chain and encrypted files off the chain. The hash values ​​of the backup files are uploaded to the chain separately and cannot be modified after backup, ensuring the consistency between the backup data and the original data. S402. Hash anchoring and storage linkage of core data (including data that cannot be modified after uploading): S4021, On-chain hash anchoring: For core data (such as fault codes and maintenance records), first extract structured fields (such as fault time and maintenance personnel employee number), generate field digests, and then calculate SHA-256 hash values. The hash values ​​are bound to the IPFS storage address (CID) of the data and uploaded to the chain. Once the CID is generated, it cannot be modified. If it is necessary to supplement core data (such as adding maintenance notes), a new field digest + hash value must be generated and uploaded to the chain, associated with the original data, and the old data cannot be overwritten. S4022, IPFS Distributed Storage: Upload the original files of core data to the IPFS private node cluster. The node cluster is jointly managed by the asset owner, operation and maintenance team, and regulatory agency. After the file is uploaded, the IPFS node can only read it and cannot modify or delete it, ensuring that no single node can tamper with the data. S4023, Storage Address Verification: The smart contract periodically (every hour) verifies whether the IPFS address stored on the chain is valid. If the address is invalid (e.g., IPFS node failure), it automatically obtains a new address from the IPFS backup node, updates the on-chain record, and the new address is still associated with the original hash value and the original data content cannot be modified. S4024. Ensure off-chain data is not tampered with by adding an off-chain data integrity verification mechanism and clarifying the data recovery process: (1) Edge computing nodes perform hash verification on the auxiliary data stored off-chain every day, generate a verification report (including file hash value, verification time, node signature) and upload it to the blockchain, compare it with the hash value stored on-chain, and trigger the data repair process when they are inconsistent; (2) If the verification finds that the off-chain data has been tampered with, the smart contract will automatically restore the data from the most recent backup, generate a repair record and upload it to the chain, and notify the administrator and auditor at the same time. S403, Lightweight storage optimization for auxiliary data (including data that cannot be modified after uploading): S4031, Off-chain Distributed Storage: Auxiliary data (such as equipment temperature logs, runtime, and inspection photos) are stored in a distributed file system (such as MinIO). Storage nodes are deployed at the edge of the asset site. After a file is uploaded, a unique file ID is generated. The file ID is bound to the data content and the file content cannot be modified. Only new files can be added. S4032, On-chain metadata digest: Only the core metadata of auxiliary data (such as data generation time, device ID, file ID, access control policy) is put on the chain. The metadata digest is generated using the MD5 algorithm. Once the metadata digest is generated, it cannot be modified. The access control policy can only adjust the viewing scope and cannot modify the data association relationship. S4033, Data Cleaning Mechanism: The smart contract automatically triggers data cleanup according to predefined rules (such as retaining auxiliary data for 1 year). Before cleanup, a data hash value is generated and uploaded to the chain. Cleanup only deletes off-chain files, while the on-chain metadata summary and hash value are retained to ensure traceability in the future. Cleanup records cannot be cleaned in advance or tampered with.

[0031] As mentioned above, S4011 uses the SHA-384 algorithm to generate hash certificates for sensitive data (such as repair costs of used equipment and equipment keys). Once uploaded, these certificates cannot be modified; any modifications require signatures from three nodes and the retention of the old hash value. In equipment transactions, if the original owner attempts to tamper with the repair cost data of sold equipment, comparing the new hash value with the old hash value on the blockchain will immediately expose the tampering. Furthermore, the old hash is traceable to the original data, preventing data falsification from affecting equipment valuation and providing a reliable data traceability basis for both parties in the transaction. S4012 stores the original sensitive data files on an offline encrypted server, physically isolated from the blockchain, and can only be viewed through authorized on-chain decryption, preventing leaks caused by network attacks. S4013 performs weekly off-site backups and uploads the backup hash to the blockchain. Even if the local server fails, the data can be restored through the backup. For example, the equipment purchase cost data of a leasing company will not be leaked due to server intrusion or lost due to hardware damage, ensuring the security of the company's core financial data. S4021 binds the hash values ​​of core data (such as equipment fault records and maintenance files) to IPFS addresses and uploads them to the blockchain. IPFS nodes are jointly managed by the asset owner, operations and maintenance personnel, and regulators (S4022), ensuring that no single node can tamper with the data. A smart contract verifies the validity of the IPFS address every hour (S4023), and automatically updates the address in case of node failure. In the trading of used tower cranes, the new owner can obtain complete and tamper-proof fault and maintenance records through on-chain hashes and IPFS addresses, eliminating concerns about the original owner concealing equipment risks and providing reliable data support for equipment quality assessment. S4024 ensures consistency between off-chain core data and on-chain data through daily hash verification by edge nodes and automatic repair via smart contracts. If the maintenance records of leased equipment are maliciously tampered with, edge node verification will immediately detect the inconsistency, the smart contract will restore the data from backup and record it on the blockchain, and simultaneously notify the administrator and auditor. This mechanism avoids leasing disputes caused by data tampering (such as operations and maintenance personnel falsifying maintenance records to evade responsibility) and protects the data rights of both parties in the transaction. S4031 stores auxiliary data (such as equipment temperature logs and inspection photos) on the asset site's MinIO cluster, generating a unique file ID bound to the data content, which cannot be modified but can only be added. In equipment leasing scenarios, maintenance personnel can quickly retrieve inspection photos from the past 3 months on-site without remotely accessing the cloud, improving maintenance efficiency. At the same time, the unique file ID prevents data from being replaced (such as the original owner replacing the temperature logs before the equipment malfunction), ensuring that the auxiliary data accurately reflects the equipment's operating status. S4032 only puts the auxiliary data's metadata (such as equipment ID and access policies) on the blockchain, reducing on-chain storage pressure. S4033 automatically cleans up off-chain files according to rules, hashing them on the blockchain before cleaning and retaining the metadata. For example, after a used elevator transaction, although the temperature logs from one year ago are cleaned up, their metadata and hash values ​​can still be traced on the blockchain, which not only meets data storage compliance requirements (avoiding redundant data consuming resources) but also proves the equipment's historical operating status in transaction disputes, balancing efficiency and traceability.

[0032] In one embodiment, the user viewing restriction in step S5 is implemented through the following mechanism: S501. Dual authentication of user identity and permissions (including administrator operation verification): S5011. Smart contracts first verify user digital signatures: When users access data, they need to submit a private key signature. When administrators modify sensitive data, they need to submit dual signatures from the administrator node and the auditor node. If the signature is invalid, access / modification will be blocked directly. S5012. Re-verify the current permission level and the legality of the operation: retrieve the current permission from the on-chain permission record table through the user ID. When the administrator attempts to modify core / auxiliary data, the smart contract directly determines that the operation is illegal and blocks it. When the administrator modifies sensitive data, it is necessary to verify whether there is a modification request with three-node signature. If there is no request, the operation is rejected. S502, Generation and Update of Dynamic Access Whitelist (including Differentiated Viewing Permissions): The smart contract automatically generates a data access whitelist based on the user's current permission level. The whitelist includes the accessible data types, the scope of viewing permissions, and the storage address. S5021, Administrator Permission Whitelist: Includes detailed viewing of sensitive data, complete viewing of core data, full viewing of auxiliary data, and entry point for modifying sensitive data (requires verification), but no entry point for modifying core / auxiliary data; S5022, Operations and Maintenance Personnel Permission Whitelist: Includes full viewing of core data, viewing of auxiliary data for the past 3 months, and an entry point for uploading auxiliary data. There is no entry point for viewing sensitive data or any modification entry point. S5023, Auditor Permission Whitelist: Includes viewing anonymized sensitive data (e.g., repair costs displayed as 1000-5000 yuan) + viewing core data fault codes (hiding the responsible party) + viewing all auxiliary data + viewing traceability records, with no other access points; When a user's permission level is adjusted (such as being upgraded from an operations and maintenance personnel to an administrator), the smart contract updates the whitelist in real time. The update requires verification by two nodes, and the administrator cannot update their own whitelist independently. S503, Fine-grained access control (including tamper protection) for attribute-based encryption (ABE): S5031. For encrypted core and sensitive data, the ABE algorithm is used to set access attributes (e.g., role=administrator + data type=sensitive data + operation=view role=operation and maintenance personnel + data type=core data + time=2025.10). If the administrator modifies the attributes of sensitive data, the supervisory node signature attribute must be added; otherwise, the modification cannot be decrypted. S5032. When a user decrypts data, they must submit an attribute key that matches the access attribute to the smart contract. When an administrator decrypts sensitive data for modification, they must submit a modification request hash value at the same time. Only after the contract verifies that the key and the request hash value are both valid can the corresponding data fragment be decrypted. The modification record generated after decryption must be uploaded to the blockchain again. S5033. Encryption Key Update: When user permissions change, the smart contract automatically updates the user's attribute key, and the old key becomes invalid. The administrator key update needs to be verified by the auditor node to prevent data from being decrypted and modified after permissions are revoked.

[0033] As mentioned above, S5011 requires administrators to submit a double signature (their own signature plus the auditor's signature) when modifying sensitive data (such as the repair cost of used equipment). S5012 further verifies whether there is a modification request with three node signatures; if no request is submitted, it is directly blocked. In equipment transactions, this prevents the original owner (if retaining administrator privileges) from unilaterally tampering with historical equipment fault data or repair costs, ensuring that modifications to sensitive data require multi-party supervision, providing a fair data environment for the new owner, and reducing transaction disputes caused by data tampering. The smart contract retrieves on-chain permission records through the user ID. If an administrator attempts to modify core / auxiliary data (such as equipment fault codes or inspection photos), S5012 directly determines it as illegal and blocks it. For example, administrators in leasing companies cannot arbitrarily modify equipment maintenance records to cover up operational oversights, and maintenance personnel cannot overstep their authority to view equipment procurement costs. Clear operational boundaries prevent the mixing of permissions from causing data leaks and ensure the standardization of data access during leasing and transactions. S502 configures exclusive whitelists for different roles: administrators can view detailed sensitive data, maintenance personnel can only view auxiliary data for the past 3 months, and auditors can view anonymized data. In the used tower crane transaction, the new owner, as the administrator, can access a complete maintenance cost breakdown to assess the equipment's value. The maintenance team can only view fault codes and recent inspection data to conduct maintenance. Auditors can see anonymized cost ranges (e.g., 1000-5000 RMB) to ensure audit independence, satisfying the needs of each role while preventing excessive exposure of sensitive data. When maintenance personnel are promoted to administrators due to job adjustments, S502 automatically updates the whitelist, and the update requires dual-node verification; administrators cannot modify their own permissions independently. In equipment leasing scenarios, if the original lessee's maintenance personnel leave, the system can freeze their permissions and update the whitelist in real time to prevent departing personnel from accessing subleased equipment data using old permissions. Dual-node verification records are recorded on the blockchain, allowing traceability of the permission adjustment process and preventing data security risks caused by opaque operations. S5031 sets multi-dimensional attributes for core / sensitive data, including role, equipment ID, and time (e.g., role = maintenance personnel + equipment ID = tower crane 001 + time = 2025.10), requiring users to submit a matching key for decryption. In cross-regional leasing of used equipment, maintenance personnel can only decrypt data for a specified time period on the equipment they are responsible for, and cannot access data from other equipment or expired data. This avoids the risk of a single key granting access to all data and ensures data security across multiple devices and scenarios. When user permissions change (e.g., the original owner's permissions are revoked after the equipment is sold), the S5033 automatically updates the attribute key, rendering the old key invalid. Furthermore, administrator key updates require auditor verification. For example, after a used elevator transaction, even if the original owner retains the old key, they cannot decrypt the new owner's equipment data. This completely eliminates the risk of access to data after permission is revoked, ensuring clear data ownership after the transaction and that the new owner has complete control over the equipment data.

[0034] In one embodiment, S6, multi-level constraints are implemented on the data modification permissions of the administrator role to ensure that modifications to sensitive data require verification by multiple parties; S601, Extended Operational Constraints for Administrator Roles: S6011. Data modification permissions for administrator roles: Set a whitelist for device operation and maintenance via smart contract. Device operation and maintenance: Only allow modification of non-sensitive data such as device operation and maintenance records and device parameters. S6012. If sensitive data (such as equipment procurement costs) needs to be modified, the administrator must submit the equipment maintenance ownership change certificate, equipment maintenance or equipment maintenance regulatory agency approval document to the smart contract. The contract will verify the validity of the document (such as recognizing the official seal through OCR and comparing the on-chain signature of the regulatory agency) before modification is allowed. S6013. When modifying sensitive data, the smart contract automatically triggers the equipment operation and maintenance data freeze period. Equipment operation and maintenance: within 72 hours after modification, only auditors can view the modification record to prevent data from being maliciously tampered with and immediately overwritten. (1) After the data is modified, the smart contract generates a temporary access control policy (policy ID = freeze period + data hash). The policy content is that only auditors can access it, and it is synchronized to the edge computing node and IPFS storage module. The node blocks non-auditor requests according to the policy. (2) After the freeze period ends, the smart contract automatically deletes the temporary access control policy, restores the original data access permissions, and generates a freeze record on the chain.

[0035] As mentioned above, S6011 uses smart contracts to set up an operation whitelist, allowing administrators to modify only non-sensitive data such as maintenance records and equipment parameters, while prohibiting modifications to core / sensitive data (such as fault codes and procurement costs). In equipment leasing scenarios, this prevents administrators from arbitrarily modifying equipment fault records or adjusting equipment parameters to cover up maintenance oversights. In secondhand transactions, it prevents the original owner from using administrator privileges to tamper with equipment maintenance history, ensuring that modifications to non-sensitive data are always within compliance limits and guaranteeing the authenticity of leasing and transaction data. S6012 requires administrators to submit ownership change certificates or regulatory approval documents when modifying sensitive data (such as equipment procurement costs and asset ownership information). The smart contract verifies the validity of the documents by recognizing official seals using OCR and comparing on-chain signatures. In secondhand equipment transactions, if the original owner needs to modify equipment procurement costs to increase the selling price, they must provide genuine cost change certificates and obtain regulatory approval, preventing the unauthorized modification of sensitive data. In leasing scenarios, administrators must submit lease agreements and other documents when modifying equipment ownership information, ensuring that data modifications are consistent with actual business practices and reducing transaction disputes caused by data falsification. The S6013 sets a 72-hour data freeze period. After modification, only auditors can view the records. The temporary access policy is synchronized to edge nodes and the IPFS module to block requests from non-auditors. At the end of the freeze period, permissions are restored and the records are unfrozen on the blockchain. In construction equipment transactions, if an administrator maliciously tampers with historical equipment fault data, the original records cannot be immediately overwritten during the freeze period. Auditors can verify the reasonableness of the modifications during the freeze period, promptly discovering and blocking violations. Even if the modifications are approved, the unfrozen records on the blockchain provide evidence for subsequent traceability, avoiding the inability to determine responsibility due to tampering without a trace, and ensuring the new owner's right to know and control the equipment data.

[0036] In one embodiment, the logic for adjusting the real-time factor permission level in step S3 includes: S305. Privilege escalation process (including privilege limits) under device failure mode: S3051. When an IoT device detects a device malfunction (such as a tower crane tilting angle exceeding the standard), the edge computing node generates a fault alarm signal and pushes it to the smart contract through a Kafka high-priority queue. S3052. After receiving the signal, the smart contract immediately performs the following operations: locate the maintenance team corresponding to the faulty device (obtained from the asset-personnel association table of the PMS system); upgrade the permission level of all members of the team from auxiliary data access to full core data viewing, with the upper limit of permission being inaccessible sensitive data; generate a permission upgrade record, including the faulty device ID, maintenance team ID, upgrade time, permission scope, and upper limit of permission, and store it on the blockchain; S3053. After the fault is repaired (the PMS system triggers the repair completion event), the smart contract automatically reverts the permission level to the initial state. The revert log must be verified by the auditor node before being uploaded to the chain. Administrators cannot interfere with the revert process. S306. Abnormal control of administrator operations: S3061. When an administrator attempts to modify their own permissions (such as expanding the scope of sensitive data modification), the smart contract immediately triggers an over-authorization interception, suspends the administrator's current permissions, and sends an over-authorization alarm to the auditor and regulatory node. The alarm information includes the operation content, the attempt time, and the administrator ID. The information is stored on the blockchain and cannot be deleted. S3062. When an administrator modifies the permissions of other users (such as elevating the permissions of maintenance personnel to the administrator level), the smart contract needs to verify whether there is an authorization file signed by the supervisory node. If there is no authorization file, the operation is rejected. If there is an authorization file, a permission modification record is generated, including the permissions before and after the modification, the hash value of the authorization file, and the signatures of the three nodes, and the record is stored on the blockchain. S307. Ensuring the integrity of permission adjustment audit trails (including administrator operation tracing): S3071. For each permission adjustment (promotion / demotion / freeze) and data operation (upload / modification), the smart contract generates a standardized audit record, which includes the following fields: S3072, Operation subject (administrator / operation and maintenance personnel / auditor), Operation type (permission adjustment / data upload / sensitive data modification); (1) Operation content (comparison of permissions before and after adjustment / uploaded data hash value / comparison of data before and after modification); (2) Verify node signatures (if modifications require three node signatures, and permission adjustments require two node signatures); (3) Timestamp and blockchain block height (to ensure immutability); Once audit logs are uploaded to the blockchain, they are synchronized to the audit module of the PMS system. Administrators can only view their own operation logs and cannot view audit logs of other roles. Auditors can view all audit logs and can query by operation subject, operation type, and time range in multiple dimensions. Audit logs cannot be deleted or modified.

[0037] Auditors can only query the audit records they participated in. Regulatory agencies can query the full audit records through regulatory nodes. The query operation must be accompanied by the signature of the regulatory node to ensure the confidentiality of the audit records. Each audit record is generated with a hash value. When users query, they can verify whether the hash value is consistent with the on-chain storage to prevent the record from being tampered with.

[0038] As mentioned above, S3051 uses a high-priority Kafka queue to quickly push fault alarms (such as excessive tower crane tilt) to the smart contract, avoiding data congestion and delays. S3052 automatically locates the corresponding operations and maintenance team and elevates their permissions to view core data (such as historical fault records and maintenance plans), without requiring manual authorization. In equipment leasing scenarios, such as a leased construction hoist experiencing a sudden malfunction, the operations and maintenance team can immediately obtain core data, reducing repair response time by more than 60% and minimizing leasing losses due to equipment downtime. Simultaneously, the access limit is set to prevent access to sensitive data (such as maintenance costs), preventing operations and maintenance personnel from unauthorizedly accessing core transaction information. S3053 automatically reverts permissions after fault repair, and the revert logs require auditor verification before being uploaded to the blockchain; administrators cannot intervene. For example, after the repair of a used tower crane, the operations and maintenance team's permissions are automatically restored to viewing only auxiliary data, preventing operations and maintenance personnel from retaining high permissions under the guise of fault repair, ensuring the new owner's control over equipment data, and ensuring compliance throughout the permission adjustment process through audit verification. S3061 intercepts administrators' attempts to elevate their privileges (such as expanding the scope of sensitive data modification) in real time, suspends privileges, and issues an on-chain alert. After a device transaction, if the original owner retains administrator privileges and attempts to elevate their privileges to access the new owner's device cost data, the smart contract can immediately block the attempt and preserve evidence to prevent sensitive data leakage and protect the new owner's data rights. S3062 requires administrators to obtain authorization documents from regulatory nodes when modifying others' privileges (such as promoting maintenance personnel to administrators), and the record must be signed by three nodes and uploaded to the blockchain. In scenarios involving personnel changes in leasing companies, this prevents administrators from privately elevating privileges for related personnel, ensuring that privilege adjustments are consistent with the company's actual needs. The on-chain record allows for traceability of the authorization source, reducing management vulnerabilities caused by privilege confusion. S3071-S3072 generate standardized records containing the operation subject, content, signature, and timestamp. Auditors can query by role, type, and time, while regulatory agencies can view the full record. For example, in disputes involving the sale of used equipment, audit records can be used to trace when maintenance permissions were increased and who modified equipment cost data, thus clarifying the attribution of responsibility. In leasing scenarios, it is possible to verify whether the adjustment of administrator permissions is compliant, meeting the needs of industry regulation and internal auditing.

[0039] Example 2, please refer to Figure 2 As shown in this embodiment, the PMS-driven intelligent operation and maintenance management system for the entire asset lifecycle includes: the system adopts a three-tier cloud-edge-device architecture, including a terminal acquisition layer, an edge preprocessing layer, and a cloud management layer. Terminal acquisition layer: includes IoT device module and PMS terminal module. The IoT device module includes status monitoring sensors (tower crane tilt angle sensor, elevator car position sensor, motor vibration sensor), environmental sensing devices (temperature and humidity sensor, dust concentration sensor), and operation recording devices (intelligent maintenance handheld terminal, asset GPS locator), which are used to collect equipment operation data at a preset frequency. It includes device ID + collection time + sensor number metadata and supports local anomaly pre-judgment and low-power communication. PMS terminal module: includes a PMS server deployed at the enterprise headquarters and PC terminals for operation and maintenance personnel, used to extract historical operation and maintenance data from the PMS database, integrate it with the structured data uploaded by the edge preprocessing layer, and generate asset lifecycle data archives; The system connects to the PMS system through an API gateway, and supports data synchronization interfaces including: / api / pms / asset-infO (to retrieve asset information) and / api / pms / maintenance-recOrd (to submit maintenance records). The interfaces use the OAuth2.0 protocol for authentication. The document verification module communicates with the regulatory agency's server via HTTPS protocol. When verifying regulatory approval documents, it needs to call the / api / verify interface provided by the regulatory agency. The interface returns a result that includes a document authenticity identifier (valid / invalid) and the regulatory node's signature. Edge preprocessing layer: includes edge computing node modules and local distributed storage modules. Edge computing node module: An edge server deployed on-site at the asset site, with a built-in FPGA chip, used for data noise reduction and structured processing (filtering noisy data and extracting core data structured fields), real-time factor monitoring (analyzing equipment operating status and user operation behavior), local caching and breakpoint resume (caching data and uploading it according to priority), with a processing latency of ≤500ms; Local distributed storage module: including IPFS private nodes and MinIO distributed file system, used to store auxiliary data raw files, generate IPFSCID and SHA-256 hash values, and dynamically adjust storage strategy according to access frequency; Cloud-based management layer: includes smart contract engine module, blockchain storage module, PMS core collaboration module, and user interaction module. Smart contract engine module: developed based on Hyperledger Fabric consortium blockchain, supports GO / SOlidity languages, adopts PBFT consensus mechanism, used to realize dynamic permission level, real-time permission adjustment and traceability record generation, block generation time ≤2 seconds; Blockchain storage module: Composed of a 5-node consortium blockchain cluster, used to classify and store sensitive data (encrypted ciphertext + hash value), core data (structured fields + IPFSCID), auxiliary data (hash value + metadata digest), as well as ownership certificates and audit records; The core collaboration module of PMS includes a permission management submodule, an asset ownership submodule, and an audit submodule, which are used to update the user data access whitelist, generate compliant ownership certificates, and provide audit record query and export functions. User interaction module: Includes web and mobile APP, with differentiated interface design based on roles, supports full data management for administrators, core data operation for maintenance personnel, read-only auditing for auditors, and integrates secondary authentication function.

[0040] Two-factor approval module: integrates administrator request submission, auditor review, and smart contract verification functions, and supports custom approval processes (such as one-management-one-review for equipment operation and maintenance, and multiple-management-multiple-review for equipment operation and maintenance). Operation whitelist engine: Based on smart contracts, the whitelist defines the data types and scope that administrators can operate on, and the whitelist content is dynamically bound to user roles and data sensitivity; Document verification module: Built-in OCR algorithm and on-chain public key of regulatory agency to verify the authenticity of external documents (such as ownership certificates and approval documents), and supports parsing and signature comparison of PDF and image format files.

[0041] The system supports accessing new devices via the MQTT protocol. The devices must comply with the "Industrial Internet of Things Device Access Specification". Uploaded data must include standard fields such as device ID, data type, and timestamp. Edge computing nodes automatically parse and standardize the data. The cloud-based management layer adopts a microservice architecture, and each module (such as the two-factor approval module and the document verification module) can be expanded independently. New functions are deployed through DOcker containers without affecting the operation of existing services. The security measures for the blockchain storage module include: Node authentication: Consortium blockchain nodes must pass dual authentication of CA certificate and enterprise qualification; illegal nodes cannot access the network. Data encryption: Transmission uses the TLS1.3 protocol, sensitive data storage uses AES-256 encryption, and user private keys are stored in a hardware encryption chip; Disaster recovery: A multi-site active-active deployment (master node + 2 backup nodes) is adopted, and the data is backed up in full every day. The backup files are stored on an encrypted server in a different location. Anomaly Protection: Built-in DDoS attack protection and data tampering detection; abnormal events trigger SMS / email alerts. Sensitive data modification audit chain: It specifically stores modification records jointly signed by the administrator and the auditor. The audit chain data can only be queried by the auditor, and the query records are automatically uploaded to the chain. Document verification hash library: Stores the hash values ​​of documents approved by regulatory agencies, and works in conjunction with the document verification module to ensure that external documents have not been tampered with.

[0042] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A PMS-driven asset whole life cycle intelligent operation and maintenance management method, characterized in that, The application comprises: Obtaining device operation and maintenance data through IOT devices in cooperation with PMS system; Based on smart contract, the device operation and maintenance data is dynamically classified, and the dynamic classification is based on at least user role and data sensitivity; Based on at least one real-time factor, the dynamic permission level of the user is automatically adjusted; The device operation and maintenance data is stored in a hash anchor way, and the classified storage data content corresponds to the dynamic permission level of the user; The user is set to only view the classified storage data content corresponding to the current dynamic permission level. 2.The PMS-driven asset full life cycle intelligent operation and maintenance management method of claim 1, characterized in that: The dynamic permission classification of the device operation and maintenance data based on smart contract comprises: Based on user role, a static permission template is set, and the role at least includes administrator, operation and maintenance personnel and auditor; For each type of device operation and maintenance data, a dynamic weight representing its sensitivity is set; Through the smart contract, the static permission of the user role is associated with the sensitivity weight of the data to generate a permission matching rule, so that the user is only allowed to access the data within the sensitivity weight range allowed by the upper limit of the role permission. 3.The PMS-driven asset full life cycle intelligent operation and maintenance management method of claim 2, characterized in that: The static permission template is stored in the role permission library of the smart contract, and when a new user is added, the corresponding role template is automatically matched, and the modification of the static permission template needs to be confirmed by three parties of administrator node, auditor node and supervision node; The data sensitivity weight is automatically calculated by the smart contract according to the preset data influence range rule, wherein the weight of device security class parameters is higher than that of ordinary operation and maintenance class parameters, and the weight of financial cost class parameters is the highest. 4.The PMS-driven asset full life cycle intelligent operation and maintenance management method of claim 1, wherein: The dynamic permission level of the user is automatically adjusted based on at least one real-time factor, which comprises: Device running state triggers permission adjustment: when the device triggers fault alarm, the smart contract automatically promotes the data access permission of the specified operation and maintenance team; when the device is in maintenance mode, the smart contract automatically limits the data access permission to the specified operation and maintenance team; Time window triggers permission adjustment: during the preset peak operation and maintenance period, the smart contract opens the core data access permission of all operation and maintenance personnel; during the preset non-working period, the smart contract limits the data access permission to emergency operation and maintenance personnel; User behavior anomaly triggers permission adjustment: when the smart contract detects abnormal access behavior of the user, the permission of the corresponding user is automatically suspended and a record is generated. 5.The PMS-driven asset full life cycle intelligent operation and maintenance management method of claim 1, wherein: The classified storage in the hash association way comprises: For sensitive data, the hash value and timestamp are stored on the chain, and the original file is stored in the offline server off-chain; For core data, the hash value of the structured field is bound to the storage address of the off-chain distributed storage system and stored on the chain; For auxiliary data, the original file is stored in the off-chain distributed file system, and the metadata digest and access control policy are stored on the chain. 6.The PMS-driven asset full life cycle intelligent operation and maintenance management method of claim 1, wherein: The user can only view the data content corresponding to the dynamic permission level of the user through the following mechanism: When the user accesses the data, the digital signature needs to be submitted to verify the identity; The smart contract generates a dynamic access white list according to the current dynamic permission level of the user, which defines the data type and operation range that the user can access. The core data and sensitive data are encrypted by using an attribute-based encryption algorithm, and a user needs to submit an attribute key matched with the user's attribute to the smart contract for decryption.

7. The PMS-driven asset whole life cycle intelligent operation and maintenance management and control system for realizing the PMS-driven asset whole life cycle intelligent operation and maintenance management and control method according to any one of claims 1-6, characterized in that, The system comprises a cloud-edge-end three-level architecture, including: The terminal acquisition layer comprises an IOT device module and a PMS terminal module, which are used for collecting device operation and maintenance data and integrating the data with historical data in the PMS system. The edge preprocessing layer comprises an edge computing node module and a local distributed storage module, which are used for denoising, structuring and locally caching the device operation and maintenance data. The cloud management and control layer comprises a smart contract engine module, a blockchain storage module, a PMS core collaboration module and a user interaction module, which are used for realizing dynamic permission management, data classification storage and audit traceability. The terminal acquisition layer comprises: 8.The PMS-driven asset lifecycle intelligent operation and maintenance management system of claim 7, wherein, The IOT device module comprises a state monitoring sensor, an environment perception device and an operation record device, supports LORaWAN and 4G / 5G communication, and is internally provided with an encryption chip. The PMS terminal module is deployed on a PMS server and an operation and maintenance terminal in an enterprise, is connected to a PMS system through an API gateway, and supports OAuth2.0 protocol identity authentication. The edge preprocessing layer comprises: 9.The PMS-driven asset lifecycle intelligent operation and maintenance management system of claim 7, wherein, The edge computing node module is deployed on an edge server at an asset site, and is used for real-time data processing with a processing delay of not higher than 500 ms. The local distributed storage module comprises an IPFS private node and a distributed file system, and is used for storing original files of auxiliary data and generating unique file identifiers. The cloud management and control layer comprises: 10.The PMS-driven asset lifecycle intelligent operation and maintenance management system of claim 7, wherein, The smart contract engine module is developed based on a consortium chain, and adopts a PBFT consensus mechanism. The blockchain storage module is composed of a multi-node consortium chain cluster, and is used for classifying and storing sensitive data, core data, auxiliary data and corresponding audit records. The security assurance module comprises a node authentication mechanism, a data encryption mechanism and an exception protection mechanism, wherein a modification record of sensitive data forms an independent audit chain, and only an auditor role has the right to query. ​

Images