Management method and system based on digital infrastructure project

Abstract

The application discloses a management method and system based on digital infrastructure engineering, and relates to the technical field of infrastructure engineering management. The method comprises the following steps: dividing the power grid infrastructure plan stage, constructing an infrastructure task model containing key / non-key processes and device dependence, determining the key process core device and giving the time limit influence weight; generating the stage authority data of the associated device identification, user authority and time dimension according to the model and the stage time limit; generating the device operation management thread based on the authority data, allocating the user access authority and the time limit; collecting and fusing the infrastructure site data, separating the contribution degree of the key and non-key processes to the overall progress; when the key process is abnormal and stagnant due to the core device, the contribution degree calculation of the non-key process is suspended; obtaining the key process delay duration, combining the core device weight to generate the corrected construction progress deviation; and adjusting the user operation authority time limit of the corresponding device of the key process according to the deviation.

Description

Technical Field

[0001] This invention relates to the field of infrastructure project management technology, and in particular to management methods and systems based on digital infrastructure projects. Background Technology

[0002] With the widespread application of digital technology in infrastructure engineering, digital infrastructure management methods have become an important means to improve construction efficiency and safety control. Currently, existing management methods mostly rely on collecting infrastructure data to analyze construction progress and adjust access control accordingly.

[0003] Traditional power grid infrastructure progress management mainly relies on manual statistics and simple percentage completion rate calculations, such as estimating the overall progress through the phased completion status of the bill of quantities. However, this method has significant drawbacks. In actual construction, progress is affected by dynamic factors such as weather, equipment failure, and personnel scheduling. Relying solely on simple completion rate calculations cannot accurately reflect the true construction status. If a phase of the plan is halted due to equipment failure, causing critical processes to stall while non-critical processes are completed ahead of schedule, simple percentage progress calculations may mask the actual risk of delays, leading to lags in the adjustment of authority. Summary of the Invention

[0004] To address the technical problem in existing technologies where power grid infrastructure progress relies on simple completion rate calculations, which cannot accurately reflect the actual construction status and leads to delayed permission adjustments, this invention provides a management method and system based on digital infrastructure projects.

[0005] The technical solution adopted in this invention is:

[0006] The first aspect of this application provides a management method for digital infrastructure projects, including the following steps:

[0007] Step 1: Divide the power grid infrastructure construction plan into phases, establish an infrastructure task model that includes key processes, non-key processes and equipment dependencies, identify the core equipment corresponding to key processes, and assign weights to the impact of core equipment on the construction period.

[0008] Step 2: Based on the infrastructure task model and phased project schedule, generate phased permission data with associated equipment identifiers, user permissions, and time dimensions. The permission data includes the scope of operation and time restrictions.

[0009] Step 3: Generate a device operation management thread based on the staged permission data, and assign user access permissions to the device and corresponding durations.

[0010] Step 4: Collect and process on-site infrastructure data, and separate the contribution of key processes and non-key processes to the overall progress based on the infrastructure task model.

[0011] Step 5: When a critical process is halted due to abnormal operation of core equipment, the progress contribution calculation of non-critical processes is suspended.

[0012] Step 6: Obtain the delay duration of key processes, and generate a corrected construction progress deviation based on the delay duration of key processes and the weight of core equipment.

[0013] Step 7: Adjust the user operation permission period for the core equipment corresponding to the key processes based on the corrected construction progress deviation.

[0014] Preferably, step 1 includes the following sub-steps:

[0015] Sub-step 1.1: Collect all task information in the power grid infrastructure plan, including process name, estimated construction period, and required equipment, and build an initial task dataset;

[0016] Sub-step 1.2: Analyze the initial task dataset using the critical path method, identify the processes on the critical path, define them as critical processes, and define the remaining processes as non-critical processes.

[0017] Sub-step 1.3: Based on the dependencies between each process and equipment, determine the set of core equipment corresponding to each key process;

[0018] Sub-step 1.4: Simulate the shutdown of core equipment and calculate the additional time required for critical processes due to the shutdown of each type of core equipment.

[0019] Sub-step 1.5: Divide the additional time caused by each core device by the total additional time caused by all core devices, and use the result as the weight of the impact of the core device on the time of critical processes.

[0020] Preferably, step 2 includes the following sub-steps:

[0021] Sub-step 2.1: Based on the process information and equipment dependencies in the infrastructure task model, determine the operational requirements of each equipment identifier at different stages;

[0022] Sub-step 2.2: Combining the association rules between user roles and device operations, match the corresponding user permissions for each device identifier to form a device-user permission mapping relationship;

[0023] Sub-step 2.3: Based on the phased project schedule, set the effective time, termination time, and permission change time nodes for each device identifier's corresponding permissions, and generate time-dimensional permission constraints.

[0024] Sub-step 2.4: Integrate the device-user permission mapping relationship with the time-dimensional permission constraints to form phased permission data that includes the scope of operation and time restrictions;

[0025] Preferably, step 3 includes the following sub-steps:

[0026] Sub-step 3.1: Arrange the staged permission data in chronological order and construct a permission status sequence using timestamps as indexes;

[0027] Sub-step 3.2 involves analyzing the permission status sequence to determine the changes in the user's permission status on the device at each point in time, and generating the basic framework for the device operation management thread.

[0028] Sub-step 3.3, based on the basic framework of the device operation management thread, assigns user access permissions and corresponding durations to operable devices in different time periods according to the user's identity and permission data;

[0029] Sub-step 3.4 verifies and reviews the assigned access permissions and their duration to ensure that the permission allocation meets the requirements of the phased permission data, thus forming a device operation management thread.

[0030] Preferably, step 4 includes the following sub-steps:

[0031] Sub-step 4.1: Using multiple sensors and data acquisition devices, collect the operating status data of the equipment at the construction site and the progress data of the process to obtain multi-source data;

[0032] Sub-step 4.2 involves cleaning and preprocessing the collected multi-source data to remove noise and outliers.

[0033] Sub-step 4.3 involves fusing the preprocessed data to generate comprehensive data reflecting the overall construction progress at the infrastructure site.

[0034] Sub-step 4.4: Based on the process dependencies and core equipment weights in the infrastructure task model, separate the contribution of key processes and non-key processes to the overall progress from the comprehensive data.

[0035] Preferably, step 5 includes the following sub-steps:

[0036] Sub-step 5.1: Monitor the operating parameters of the core equipment in real time. When the operating parameters exceed the preset normal range, determine that the core equipment has an abnormality and trigger the abnormality handling mechanism.

[0037] Sub-step 5.2 involves pausing the calculation of the progress contribution of non-critical processes through an exception handling mechanism and recording the pause time.

[0038] Preferably, step 6 includes the following sub-steps:

[0039] Sub-step 6.1: Obtain the planned start time, planned end time, and actual downtime of key processes from the infrastructure task model and real-time monitoring data, and calculate the delay duration of key processes.

[0040] Sub-step 6.2 involves inputting the delay duration of key processes and the weight of the impact on the construction period of the core equipment corresponding to the key processes into the preset schedule deviation calculation model to generate the corrected construction schedule deviation.

[0041] The second aspect of this application provides a management system based on digital infrastructure projects, including,

[0042] The task model construction module is used to divide the power grid infrastructure plan into stages, establish an infrastructure task model that includes key processes, non-key processes and equipment dependencies, identify the core equipment corresponding to key processes, and assign weights to the impact of core equipment on the project schedule.

[0043] The permission data generation module is used to generate phased permission data with associated equipment identifiers, user permissions, and time dimensions based on the infrastructure task model and phased project schedule. The permission data includes the scope of operation and time restrictions.

[0044] The management thread generation module is used to generate device operation management threads based on the staged permission data, and to allocate user access permissions to the device and corresponding durations.

[0045] The data acquisition and processing module is used to collect and process on-site infrastructure data, and to separate the contribution of key processes and non-key processes to the overall progress based on the infrastructure task model.

[0046] The exception handling module is used to suspend the calculation of the progress contribution of non-critical processes when a critical process is stopped due to an abnormality in the core equipment.

[0047] The deviation calculation module is used to obtain the delay time of key processes and generate a corrected construction progress deviation based on the delay time of key processes and the weight of core equipment.

[0048] The permission adjustment module is used to adjust the user operation permission period for core equipment corresponding to key processes based on the corrected construction progress deviation.

[0049] The beneficial effects of the present invention are at least one of the following:

[0050] By constructing an infrastructure task model that includes critical / non-critical processes and equipment dependencies, and combining the schedule impact weights of core equipment, it is possible to identify critical processes and core equipment that play a decisive role in construction progress. When a critical process is halted due to abnormal equipment failure, the calculation of the progress contribution of non-critical processes is suspended, and a corrected schedule deviation is generated based on the delay duration and equipment weight. This avoids the problem of secondary processes completing ahead of schedule and masking critical delays in traditional simple percentage calculations, ensuring that the construction progress reflects the true construction status.

[0051] Based on the corrected construction progress deviation, the user operation permission period for core equipment corresponding to key processes is adjusted, which solves the problem of delayed permission adjustment in traditional methods. This enables refined management of user permissions in terms of time and scope of operation, ensuring that the permission period matches the actual construction needs in real time and reducing the risk of operational errors caused by expired or redundant permissions. Attached Figure Description

[0052] Figure 1 This is a schematic diagram of the method flow of the present invention;

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

[0054] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0055] Example 1

[0056] This embodiment provides a management method based on digital infrastructure projects, such as... Figure 1 As shown, it includes the following steps:

[0057] Step 1: Divide the power grid infrastructure construction plan into phases, establish an infrastructure task model that includes key processes, non-key processes and equipment dependencies, identify the core equipment corresponding to key processes, and assign weights to the impact of core equipment on the construction period.

[0058] In one possible implementation, step 1 includes the following sub-steps:

[0059] Sub-step 1.1: Collect all task information in the power grid infrastructure plan, including process name, estimated construction period, and required equipment, and build an initial task dataset.

[0060] For example, collect all task information in the power grid infrastructure plan, including: basic information of the process: process name, process code, process description (such as "installation of substation main transformer" and "erection of transmission line tower").

[0061] Time attributes: Estimated construction period (unit: days / hour), list of preceding and subsequent processes.

[0062] Equipment Dependencies: A list of equipment required to complete this process (such as transformers, circuit breakers, cranes, tensioners, etc.), including equipment model, rated power, and quantity parameters.

[0063] The collected information is structured according to a preset data format (such as Excel spreadsheets or JSON files) to form an initial task dataset, which is then stored in the project database for subsequent analysis.

[0064] Sub-step 1.2: Analyze the initial task dataset using the critical path method, identify the processes on the critical path and define them as critical processes, and define the remaining processes as non-critical processes.

[0065] For example, based on the initial task dataset, a process logic diagram of the infrastructure project is drawn using a double-code network diagram or a single-code network diagram to clarify the dependencies between each process (e.g., "equipment hoisting" can only be carried out after "equipment foundation pouring" is completed). The time parameters for each process are calculated: earliest start time (ES), earliest finish time (EF); latest start time (LS), latest finish time (LF); and total float time (TF = LS - ES).

[0066] Operations with a total float time of 0 constitute the critical path of the project and are defined as critical operations (such as substation main equipment installation, high-voltage line connection, etc.); operations with a total float time greater than 0 are defined as non-critical operations (such as site clearing, auxiliary equipment commissioning, etc.).

[0067] Sub-step 1.3: Based on the dependencies between each process and equipment, determine the set of core equipment corresponding to each key process.

[0068] Establish a "Process-Equipment Dependency Table," break down each key process one by one, and identify the equipment necessary to complete the process (i.e., the process cannot be executed without the missing equipment). Rank the equipment required for key processes according to their importance, retaining equipment that directly determines whether the process can be executed or significantly affects the process efficiency, forming the core equipment set for each key process, and assigning a unique identifier to each piece of equipment (e.g., equipment ID: E001, E002).

[0069] Sub-step 1.4: Simulate the shutdown of core equipment and calculate the additional time required for critical processes due to the shutdown of each type of core equipment.

[0070] For example, preset shutdown scenarios (such as equipment failure, maintenance, scheduling delays, etc.) are used for each core device to simulate the impact of equipment shutdown on the schedule of critical processes. Input parameters: equipment shutdown start time, shutdown duration (e.g., device E001 shuts down on the 10th day, with an estimated maintenance period of 3 days). Based on the critical path method, the estimated completion time of critical processes after equipment shutdown is recalculated and compared with the original planned completion time to obtain the additional duration of the project.

[0071] For example, the original planned duration for the critical process "transformer hoisting" was 5 days. If the core equipment crane is shut down for 2 days, causing the actual duration of the process to be extended to 7 days, then the additional duration is 2 days.

[0072] Sub-step 1.5: Divide the additional time caused by each core device by the total additional time caused by all core devices, and use the result as the weight of the impact of the core device on the time of critical processes.

[0073] The additional construction time caused by all core equipment under simulated shutdown scenarios is calculated and denoted as t1, t2, ..., t. n (where n is the total number of core equipment). Calculate the total additional construction period:

[0074] in, This represents the additional time required for critical processes due to the shutdown of the i-th core equipment.

[0075] Weight of the duration of a single core device , satisfying (0 < <1) and:

[0076] The calculated weights It is bound to the core equipment identifier and stored in the infrastructure task model, serving as the basis for subsequent schedule deviation calculations.

[0077] Step 2: Based on the infrastructure task model and phased project schedule, generate phased permission data with associated equipment identifiers, user permissions, and time dimensions. The permission data includes the scope of operation and time restrictions.

[0078] In one possible implementation, step 2 includes the following sub-steps:

[0079] Sub-step 2.1: Based on the process information and equipment dependencies in the infrastructure task model, determine the operational requirements of each equipment identifier at different stages.

[0080] For example, the list of procedures corresponding to each stage of the plan can be extracted from the infrastructure task model established in step 1 (e.g., the "substation main construction stage" includes the procedures of "equipment foundation pouring", "main transformer hoisting" and "primary equipment wiring").

[0081] For each process, the required core equipment identifiers (such as E001 and E002 corresponding to "main transformer hoisting") are obtained through the "Process-Equipment Dependency Table".

[0082] Define specific operation types (such as start / stop, parameter setting, status monitoring, maintenance, etc.) for each equipment identifier in the corresponding process.

[0083] Example:

[0084] The operational requirements for equipment E001 (200-ton truck crane) in the "main transformer hoisting" process are: equipment startup, hoisting angle adjustment, and load weight setting;

[0085] The operational requirements for equipment E002 (transformer-specific lifting tool) are: lifting tool connection and balance parameter calibration.

[0086] The equipment operation requirements are divided into phases according to the plan, and an "Equipment-Phase-Operation Requirements Table" is generated, which clarifies the specific set of operation instructions that each piece of equipment needs to execute at different construction phases.

[0087] Sub-step 2.2: Combining the association rules between user roles and device operations, match the corresponding user permissions for each device identifier to form a device-user permission mapping relationship.

[0088] For example, user roles in infrastructure projects can be defined as follows: Equipment Operator (capable of starting up equipment and performing routine operations); Technical Engineer (capable of setting parameters and diagnosing faults); Safety Administrator (capable of approving permissions and performing emergency shutdowns).

[0089] Establish a "Role-Operation Permission Reference Table" to clarify the access permissions of each role to equipment operation commands (e.g., "Equipment Operator" can only execute equipment start and stop, while "Technical Engineer" can execute parameter setting and status monitoring).

[0090] For each device identifier's operational requirements, user roles with corresponding permissions are selected from the "Role-Operation Permission Lookup Table" to form a triplet mapping relationship between device, user role, and operation permission.

[0091] For example, the hoisting angle adjustment operation of equipment E001 can only be performed by the "technical engineer", while the equipment start-up operation can be performed by both the "equipment operator" and the "technical engineer".

[0092] Sub-step 2.3: Based on the phased project schedule, set the effective time, termination time, and permission change time nodes for each device identifier's corresponding permissions, and generate time-dimensional permission constraints.

[0093] For example, the phase plan duration decomposition includes splitting the preset duration of the phase plan by time granularity (such as days / hours) to generate continuous time intervals on the time axis (such as phase 1: 2024-01-01 to 2024-01-30).

[0094] For example, the permission time point settings include:

[0095] Effective time: The time when the device permission allows users to operate it (e.g., the hoisting angle adjustment permission for device E001 takes effect at 09:00 on the day the "main transformer hoisting" process begins).

[0096] Termination time: The time when the equipment permission expires (e.g., 18:00 on the day the process ends).

[0097] Change point: The point in time when the scope of permissions changes (e.g., adding fault diagnosis permissions to a device in the middle of the commissioning phase).

[0098] For example, time constraint visualization includes using Gantt charts or timeline tools to visually match the permission time intervals identified for each device with the planned duration of the phase and the execution time of the process, ensuring that the permission activation / termination time is strictly aligned with the actual execution time of the process.

[0099] Sub-step 2.4 integrates the device-user permission mapping relationship with the time-dimensional permission constraints to form phased permission data that includes the scope of operation and time restrictions.

[0100] For example, a structured permission data model is established, including the following fields:

[0101] Equipment Identifier: A unique identifier for core equipment (e.g., E001, E002).

[0102] User roles: Roles with operational permissions (such as "equipment operator" or "technical engineer");

[0103] Operating scope: The set of operating instructions that are allowed to be executed (such as {equipment start, hoisting angle adjustment});

[0104] Effective time: Permission start time (format: YYYY-MM-DDHH:MM:SS).

[0105] Termination Time: Permission Expiration Time (same format as above);

[0106] Permission version: Records the history of permission changes (e.g., V1.0, V1.1).

[0107] The operational requirements of sub-step 2.1, the mapping relationship of sub-step 2.2, and the time constraints of sub-step 2.3 are linked and integrated to generate the "Stage-based Permission Data Table".

[0108] For example, the verification rules are as follows: the permission taking effect time must not be earlier than the start time of the phase plan; only one user role's operation permission is allowed to take effect on the same device at the same time (to avoid permission conflicts).

[0109] The phased permission data is stored in a cloud database (such as MySQL or MongoDB) and indexed and associated with the infrastructure task model and equipment operation management thread to facilitate subsequent permission allocation and adjustment.

[0110] Through the above steps, a precise mapping from the infrastructure task model to permission data is achieved, ensuring that the operational permissions of each device at different construction stages are strictly matched with user roles and time dimensions. Specifically, the rule configuration of user roles and operational permissions ensures the security of permission allocation (e.g., prohibiting low-privilege users from performing high-risk operations), while time-dimensional constraints prevent management vulnerabilities caused by expired or prematurely effective permissions. Combined with the core device weight assignment in Step 1, a refined permission management system integrating "device-role-time-operation" is formed, providing a data foundation for the subsequent generation of device operation management threads and dynamic permission adjustments.

[0111] Step 3: Generate a device operation management thread based on the staged permission data, and assign user access permissions to the device and corresponding durations.

[0112] In one possible implementation, step 3 includes the following sub-steps:

[0113] Sub-step 3.1: Arrange the staged permission data in chronological order and construct a permission status sequence using timestamps as indexes.

[0114] For example, the effective time and termination time of each permission entry are extracted from the staged permission data generated in step 2 and converted into a unified timestamp format.

[0115] For example, permissions are grouped by device identifier, and the permissions entries for each device are arranged in ascending order of their effective time, forming an independent permission time chain. For scenarios where permissions change (such as adjusting the operation scope of the same device in the middle of a phase), the permissions are split into multiple permission segments at the permission change time node to ensure that the permission status is unique within each time period.

[0116] For example, an index can be built using a key-value pair structure (device identifier-time stamp) to store the permission status (such as the scope of operation and allowed user roles) corresponding to each time point, forming a permission status sequence table that can be queried quickly.

[0117] Sub-step 3.2 involves analyzing the permission state sequence to determine the changes in user permission status for the device at each point in time, thereby generating the basic framework for the device operation management thread.

[0118] For example, the permission status sequence is traversed, and the key nodes of all permission status changes (effective time, termination time, change time) are extracted as time anchors for the management thread. For example, the permission status change points of device E001 include: effective time (08:30), operation scope change time (12:00), and termination time (17:30).

[0119] Create an access control state machine for each device, defining three basic states:

[0120] Permissions not activated (before the effective date);

[0121] Permission activation (from effective time to expiration time, including normal operation scope).

[0122] Permission change (the change in timing triggers an adjustment to the scope of operations);

[0123] Permission expired (after expiration time).

[0124] State transition diagrams are used to describe the logic of permission status changes over time (e.g., from "inactive" to "activated", then to "changed" or "invalid").

[0125] By combining the state machine model with time anchors, a two-dimensional table containing device identifier, time interval, permission status, and operation scope is generated, which serves as the basic framework for the device operation management thread.

[0126] Sub-step 3.3, based on the basic framework of the device operation management thread, assigns user access permissions and corresponding durations to operable devices for different time periods according to the user's identity and permission data.

[0127] For example, by integrating an enterprise unified identity authentication system (such as LDAP or OAuth), user identity identifiers (such as employee IDs) and role information (such as "equipment operator" or "technical engineer") can be obtained.

[0128] Example: User A's identity is U001, and their role is "Device Operator".

[0129] For example, based on the device-user permission mapping relationship in step 2, an "Operable Device List" is generated for each user: the device operation management thread basic framework is traversed to filter out the device identifier and operation scope corresponding to the current user role.

[0130] Example: User A (equipment operator) has the right to start and stop equipment E001, with the corresponding time interval being [08:30, 17:30].

[0131] Extract the effective and expiration times of permissions from the basic framework to serve as the user's access period to the device, and generate the "User-Device Permission Term Table", which includes: user identity, device identity, scope of operation, permission effective time, and permission expiration time.

[0132] Sub-step 3.4 verifies and reviews the assigned access permissions and their duration to ensure that the permission allocation meets the requirements of the phased permission data, thus forming a device operation management thread.

[0133] For example, automated verification rules include: Time validity verification: ensuring that the permission effective time is ≥ the start time of the phase plan and the termination time is ≤ the end time of the phase plan. Role permission matching verification: verifying whether the user role is in the device-user permission mapping relationship and whether the operation scope does not exceed the set of instructions allowed by the role. Conflict detection: checking whether the same user is assigned mutually exclusive permissions (such as allowing "device start" and "emergency stop" at the same time). The permission allocation results that pass the automated verification are pushed to the project security administrator for manual review, focusing on whether the allocation of high-risk operation permissions (such as core parameter modification, device restart) complies with security specifications. After the verification is passed, the permission allocation results are linked in chronological order to form a complete device operation management thread. The timeline visualization tool is used to display the permission status changes of each user to the device, and the data is stored in a blockchain or tamper-proof log system for subsequent auditing.

[0134] Through the above steps, the transformation from phased permission data to device operation management threads was achieved, ensuring the accurate allocation of user permissions in terms of time and operational scope. Specifically, the construction of the permission state sequence ensures traceability of permission changes over time, the state machine model clearly defines the permission state transition logic, and the combination of automated verification and manual review guarantees the security and compliance of permission allocation. Combining the core device weights from step 1 and the phased permission data from step 2, a complete permission management chain covering "planning-modeling-allocation-verification" is formed, providing a reliable data foundation for subsequent dynamic permission adjustments based on construction progress.

[0135] Step 4: Collect and process on-site infrastructure data, and separate the contribution of key processes and non-key processes to the overall progress based on the infrastructure task model.

[0136] In one possible implementation, step 4 includes the following sub-steps:

[0137] Sub-step 4.1: Using a variety of sensors and data acquisition devices, collect the operating status data of the equipment at the construction site and the progress data of the process to obtain multi-source data.

[0138] For example, collecting operational status data of equipment at the construction site includes installing Internet of Things (IoT) sensors on core equipment (such as transformers and cranes) to collect operating parameters (voltage / current, speed, load weight, fault codes) in real time, with a collection frequency of ≥10 times / second. Progress data for each process can be recorded using RFID tags to document the arrival time and installation completion status of materials / equipment; and by utilizing drone aerial photography or BIM model coordinate positioning, the spatial completion status of each process can be obtained (such as tower erection height and cable laying length).

[0139] Sub-step 4.2 involves cleaning and preprocessing the collected multi-source data to remove noise and outliers.

[0140] For example, the Isolation Forest algorithm is used to identify outliers in equipment operating parameters (such as load weight exceeding 150% of the rated value), and these outliers are corrected using interpolation between adjacent time points or standard values ​​from the equipment manual. For process completion data, if the completion rate of the same process changes by more than 30% within one hour, it is marked as suspicious data, triggering a manual review process. The timestamps of multi-source data are uniformly calibrated using the cloud server time as a reference, ensuring time accuracy ≤1 second to avoid analytical bias caused by clock asynchrony. Equipment operating parameters are converted to uniform units (e.g., voltage to kV, speed to rpm); process completion rates are converted to standardized values ​​from 0-100% and stored in a "Real-time Data Record Table" in a relational database (such as PostgreSQL).

[0141] Sub-step 4.3 involves fusing the preprocessed data to generate comprehensive data reflecting the overall construction progress at the infrastructure site.

[0142] For example, the cleaned data is sorted by timestamp to generate a time series of equipment operating status (e.g., the load-weight curve of E001) and a time series of process completion (e.g., the daily completion rate of W001). Combining the 3D coordinates of the BIM model, the process completion data is mapped to a virtual construction scene, and progress is visualized using color coding (green: normal, yellow: lagging, red: stagnant). A "Process-Equipment-Progress Association Table" is established using process codes and equipment IDs, for example:

[0143] Process coding Device ID Collection time Running status Completeness W001 E001 2024-01-0510:00 Normal operation 45%

[0144] Generate Overall Schedule Index (SPI): The weight of critical processes is taken from the weight of the core equipment in step 1 that affects the project duration, while the weight of non-critical processes is taken from the default value (e.g., 0.1).

[0145] Sub-step 4.4: Based on the process dependencies and core equipment weights in the infrastructure task model, separate the contribution of key processes and non-key processes to the overall progress from the comprehensive data.

[0146] Extract a list of key processes (such as W001 and W003) and a list of non-key processes (such as W002 and W004) from the infrastructure task model, and match them with the process codes in the real-time progress data.

[0147] The formula for calculating the contribution of key processes is: , This represents the schedule impact weight corresponding to the core equipment in Step 1, reflecting the degree of influence of this core equipment on the schedule of key processes. For example, the weight of equipment E001 corresponding to W001. =0.4 indicates that the equipment has a relatively large impact on the overall schedule. The actual completion rate of a critical process refers to the percentage of the total workload actually completed at the current point in time. For example, if a critical process has a planned total workload of 100, and 60 has been completed so far, then the actual completion rate is 60%. This indicates all key processes. The sum of the products of (the weighting of the impact of core equipment schedules) and their respective planned completion rates. This sum is used for normalization to ensure that the contribution of key processes is... The value is between 0 and 1, which facilitates comparison and analysis of the relative contribution of each key process to the overall progress.

[0148] The formula for calculating the contribution of non-critical processes is:

[0149] The actual completion rate of non-critical processes is similar to that of critical processes, referring to the percentage of work actually completed by a non-critical process relative to its total workload at the current point in time. It represents the sum of the planned completion rates of all non-critical processes. This sum is used to normalize the actual completion rate of each non-critical process, obtaining the relative contribution of each non-critical process to the overall schedule, thus making the contribution rate of non-critical processes... The value is between 0 and 1.

[0150] It should be noted that critical processes are located on the critical path of the project, and their duration directly determines the overall project duration. Anomalies in core equipment can cause process delays, significantly impacting the schedule (this impact is quantified in step 1 using the weight of core equipment). Therefore, the impact of critical process delays on the overall schedule needs to be accurately measured using the weighting of equipment duration (step 1.5). Non-critical processes have a total float time (step 1.2), and their early or late completion has a smaller impact on the overall project duration. Furthermore, step 5 explicitly states that when a critical process is halted, the contribution of non-critical processes is suspended from calculation. Therefore, the contribution calculation for non-critical processes focuses more on relative completion rather than complex weighting, simplifying the calculation and highlighting the leading role of critical processes.

[0151] Step 5: When a critical process is halted due to abnormal operation of core equipment, the progress contribution calculation of non-critical processes is suspended.

[0152] In one possible implementation, step 5 includes the following sub-steps:

[0153] Sub-step 5.1: Monitor the operating parameters of the core equipment in real time. When the operating parameters exceed the preset normal range, determine that the core equipment has an abnormality and trigger the abnormality handling mechanism.

[0154] Sub-step 5.2 involves pausing the calculation of the progress contribution of non-critical processes through an exception handling mechanism and recording the pause time.

[0155] Step 6: Obtain the delay duration of key processes, and generate a corrected construction progress deviation based on the delay duration of key processes and the weight of core equipment.

[0156] In one possible implementation, step 6 includes the following sub-steps:

[0157] Sub-step 6.1: Obtain the planned start time, planned end time, and actual downtime of key processes from the infrastructure task model and real-time monitoring data, and calculate the delay duration of key processes.

[0158] For example, the planned start time of key processes is extracted from the infrastructure task model established in step 1. and the planned end time This data was calculated using the Critical Path Method (CPM) during the critical path model construction in sub-step 1.2 and is stored in the "Critical Process Schedule," containing fields such as process code, planned duration, and time parameters (ES / EF / LS / LF). When the exception handling mechanism in step 5 is triggered (a core equipment malfunction causes a critical process to stall), the actual stall start time is obtained from the real-time monitoring data. This timestamp is generated from the sensor anomaly warning event record in sub-step 5.1; if the critical process has returned to normal, obtain the actual recovery time. If it remains in a standstill, the current system time will be used as the reference time. 。

[0159] Stasis duration .

[0160] Delay time of key processes This refers to the portion of the work that is actually delayed beyond the planned timeframe. If the delay does not exceed the planned timeframe, the delay duration is 0. For the planned construction period.

[0161] Sub-step 6.2 involves inputting the delay duration of key processes and the weight of the impact on the construction period of the core equipment corresponding to the key processes into the preset schedule deviation calculation model to generate the corrected construction schedule deviation.

[0162] For example, based on the key process code, the corresponding core equipment identifier (e.g., equipment E001 and E002 corresponding to process W001) is obtained from the "Core Equipment Set Table" in step 1, and then the weight of each core equipment is queried from the "Equipment Schedule Impact Weight Table". (Sub-step 1.5 has been calculated and stored).

[0163] Define the formula for correcting schedule deviations: Correcting Schedule Deviations

[0164] in, The delay time of the critical process caused by the i-th core equipment, The weight of its impact on the construction period.

[0165] For example, if device E001 ( =0.6) caused a 2-day delay, E002 ( =0.4) caused a delay of 1 day. The planned duration of the critical process is 5 days. Therefore:

[0166] Step 7: Adjust the user operation permission period for the core equipment corresponding to the key processes based on the corrected construction progress deviation.

[0167] For example, the corrected progress deviation value (e.g., 32%) of the current key process and the corresponding core equipment identifier (e.g., E001, E002) are extracted from the "Construction Progress Deviation Table" generated in step 6. The actual delay time of the key process (e.g., 2 days) and the remaining construction period of the phase plan are obtained simultaneously to determine the time base for permission adjustment.

[0168] By using the core device identifier, the corresponding permission entry is retrieved from the "Device Operation Management Thread Table" generated in step 3 to obtain the effective time of the current user's existing permissions for the device. and termination time

[0169] When the corrected schedule deviation is greater than 0 (i.e., a critical process delay), the new authority termination time is calculated using the following formula:

[0170]

[0171] Example: The original expiration time was 2024-01-10 18:00. The delay was 2 days. The new expiration time is adjusted to 2024-01-12 18:00.

[0172] Example 2

[0173] Example 2 provides a management system based on digital infrastructure projects, such as... Figure 2 As shown, it includes a task model construction module, which is used to divide the power grid infrastructure plan into stages, establish an infrastructure task model that includes key processes, non-key processes and equipment dependencies, determine the core equipment corresponding to key processes, and assign the impact weight of core equipment on the project period.

[0174] The permission data generation module is used to generate phased permission data with associated equipment identifiers, user permissions, and time dimensions based on the infrastructure task model and phased project schedule. The permission data includes the scope of operation and time restrictions.

[0175] The management thread generation module is used to generate device operation management threads based on the staged permission data, and to allocate user access permissions to the device and corresponding durations.

[0176] The data acquisition and processing module is used to collect and process on-site infrastructure data, and to separate the contribution of key processes and non-key processes to the overall progress based on the infrastructure task model.

[0177] The exception handling module is used to suspend the calculation of the progress contribution of non-critical processes when a critical process is stopped due to an abnormality in the core equipment.

[0178] The deviation calculation module is used to obtain the delay time of key processes and generate a corrected construction progress deviation based on the delay time of key processes and the weight of core equipment.

[0179] The permission adjustment module is used to adjust the user operation permission period for core equipment corresponding to key processes based on the corrected construction progress deviation.

[0180] The embodiments described above are merely illustrative of specific implementations of the present invention, and while the descriptions are detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention.

Claims

1. A management method based on digital infrastructure projects, characterized in that, Includes the following steps: Step 1: Divide the power grid infrastructure plan into phases, establish an infrastructure task model that includes key processes, non-key processes and equipment dependencies, identify the core equipment corresponding to key processes, and assign weights to the impact of core equipment on the project schedule. Step 2: Based on the infrastructure task model and phased project schedule, generate phased permission data with associated equipment identifiers, user permissions, and time dimensions. The permission data includes the scope of operation and time restrictions. Step 3: Generate a device operation management thread based on the staged permission data, and assign users operation permissions to the device and corresponding time limits; Step 4: Collect and process on-site infrastructure data, and separate the contribution of key processes and non-key processes to the overall progress based on the infrastructure task model. Step 5: When a critical process is halted due to a core equipment malfunction, the progress contribution calculation of non-critical processes is suspended. Step 6: Obtain the delay duration of key processes, and generate a corrected construction progress deviation based on the delay duration of key processes and the weight of core equipment; Step 7: Adjust the user operation permission period for the core equipment corresponding to the key processes based on the corrected construction progress deviation. Step 4 includes the following sub-steps: Sub-step 4.1: Using multiple sensors and data acquisition devices, collect the operating status data of the equipment at the construction site and the progress data of the process to obtain multi-source data; Sub-step 4.2 involves cleaning and preprocessing the collected multi-source data to remove noise and outliers; Sub-step 4.3 involves fusing the preprocessed data to generate comprehensive data reflecting the overall construction progress at the infrastructure site. Sub-step 4.4: Based on the process dependencies and core equipment weights in the infrastructure task model, separate the contribution of key processes and non-key processes to the overall progress from the comprehensive data. The formula for calculating the contribution of key processes is: , The weights for the impact on the project schedule corresponding to the core equipment in step 1 are as follows: Weights for the impact of core equipment on the project timeline for all critical processes; The formula for calculating the contribution of non-critical processes is: ; Step 5 includes the following sub-steps: Sub-step 5.1: Monitor the operating parameters of the core equipment in real time. When the operating parameters exceed the preset normal range, determine that the core equipment has an abnormality and trigger the abnormality handling mechanism. Sub-step 5.2: Through the exception handling mechanism, suspend the calculation of the progress contribution of non-critical processes and record the suspension time; Step 6 includes the following sub-steps: Sub-step 6.1: Obtain the planned start time, planned end time, and actual downtime of key processes from the infrastructure task model and real-time monitoring data, and calculate the delay duration of key processes; Sub-step 6.2: Input the delay duration of key processes and the impact weight of the construction period of the core equipment corresponding to the key processes into the preset schedule deviation calculation model to generate the corrected construction schedule deviation. The preset schedule deviation calculation model is as follows: ; in, For the first The delays in critical processes caused by key equipment Weights for the impact of core equipment on the project schedule for all critical processes.

2. The management method for digital infrastructure projects according to claim 1, characterized in that, Step 1 includes the following sub-steps: Sub-step 1.1: Collect all task information in the power grid infrastructure plan, including process name, estimated construction period, and required equipment, and build an initial task dataset; Sub-step 1.2: Analyze the initial task dataset using the critical path method, identify the processes on the critical path, define them as critical processes, and define the remaining processes as non-critical processes. Sub-step 1.3: Based on the dependencies between each process and equipment, determine the set of core equipment corresponding to each key process; Sub-step 1.4: Simulate the shutdown of core equipment and calculate the additional time required for critical processes due to the shutdown of each type of core equipment. Sub-step 1.5: Divide the additional time caused by each core device by the total additional time caused by all core devices, and use the result as the weight of the impact of the core device on the time of critical processes.

3. The management method for digital infrastructure projects according to claim 2, characterized in that, Step 2 includes the following sub-steps: Sub-step 2.1: Based on the process information and equipment dependencies in the infrastructure task model, determine the operational requirements of each equipment identifier at different stages; Sub-step 2.2: Combining the association rules between user roles and device operations, match the corresponding user permissions for each device identifier to form a device-user permission mapping relationship; Sub-step 2.3: Based on the phased project schedule, set the effective time, termination time, and permission change time nodes for the corresponding permissions of each device identifier, and generate time-dimensional permission constraints. Sub-step 2.4 integrates the device-user permission mapping relationship with the time-dimensional permission constraints to form phased permission data that includes the scope of operation and time restrictions.

4. The management method for digital infrastructure projects according to claim 3, characterized in that, Step 3 includes the following sub-steps: Sub-step 3.1: Arrange the staged permission data in chronological order and construct a permission status sequence using timestamps as indexes; Sub-step 3.2 involves analyzing the permission status sequence to determine the changes in the user's permission status on the device at each point in time, and generating the basic framework for the device operation management thread. Sub-step 3.3: Based on the basic framework of the device operation management thread, according to the user's identity and permission data, assign the user's operation permissions and corresponding time periods to the operable devices in different time periods; Sub-step 3.4 verifies and reviews the assigned operation permissions and their duration to ensure that the permission allocation meets the requirements of the phased permission data, thus forming a device operation management thread.

5. A management system based on digital infrastructure projects, characterized in that: The management method for digital infrastructure projects according to any one of claims 1-4 includes, The task model construction module is used to divide the power grid infrastructure plan into stages, establish an infrastructure task model that includes key processes, non-key processes and equipment dependencies, identify the core equipment corresponding to key processes, and assign weights to the impact of core equipment on the project schedule. The permission data generation module is used to generate phased permission data with associated equipment identifiers, user permissions, and time dimensions based on the infrastructure task model and phased plan schedule. The permission data includes the scope of operation and time restrictions. The management thread generation module is used to generate device operation management threads based on the staged permission data, and to assign users operation permissions to the device and corresponding time limits. The data acquisition and processing module is used to collect and process on-site infrastructure data, and to separate the contribution of key processes and non-key processes to the overall progress based on the infrastructure task model. The exception handling module is used to suspend the calculation of the progress contribution of non-critical processes when a critical process is stopped due to an abnormality in the core equipment. The deviation calculation module is used to obtain the delay time of key processes and generate a corrected construction progress deviation based on the delay time of key processes and the weight of core equipment. The permission adjustment module is used to adjust the user operation permission period for core equipment corresponding to key processes based on the corrected construction progress deviation.

Images