Project progress monitoring method, electronic equipment, storage medium and program product

Abstract

The embodiment of the invention provides a project progress monitoring method, electronic equipment, a storage medium and a program product. The method comprises the following steps: acquiring project progress data through a distributed sensor network and an application program interface gateway; performing fragment indexing on the project progress data based on a project construction stage and a data category, and injecting a risk level label in a writing process to form index data with the label; performing streaming synchronization on the index data with the label through a message queue, and pushing the index data to a front end in real time based on a full duplex communication protocol; a task list is dynamically loaded at the front end according to the user view range, a Gantt chart containing a time axis and a task bar is rendered, the scale of the time axis is dynamically generated according to the currently displayed time window, and the position and the color of the task bar are determined according to the risk level label and the time information.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method for monitoring project progress, electronic equipment, storage medium, and program product. Background Technology

[0002] In the construction of large-scale infrastructure projects (such as subways, oil fields, and nuclear power plants), project progress management relies on the collection and analysis of massive amounts of real-time data, including construction task status, structural stress, and equipment vibration. This data is characterized by high frequency, high concurrency, and strong time-series characteristics, requiring dynamic comparison between the "physical flow" and the "planned flow" on a unified platform, and the use of visualization tools such as Gantt charts to support decision-making. Therefore, achieving millisecond-level data synchronization and smooth interaction under tens of thousands of task volumes has become a core requirement of digital project management.

[0003] Currently, most mainstream engineering management systems adopt a batch processing architecture: the front end periodically polls the database or cache layer to obtain progress data, and the back end uses a static sharding strategy to write the data to a general search engine. Gantt charts are generally drawn based on the Document Object Model (DOM) or a two-dimensional drawing interface. Such solutions can run in small-scale scenarios, but they expose serious performance bottlenecks when handling high-concurrency writes (such as thousands of sensor data points per second) or large-scale task displays (such as hundreds of thousands of construction procedures): on the one hand, static sharding is prone to forming hotspots, causing write latency to spike; on the other hand, DOM rendering stutters due to node explosion, and the scaling operation frame rate is less than 10 frames per second, which cannot meet the real-time interaction requirements of the command center's large screen.

[0004] In summary, the existing technology has the following main technical problems: in high-concurrency, large-scale engineering data scenarios, it is difficult to simultaneously ensure the real-time performance of data writing, the efficiency of index querying, and the smoothness of front-end visualization, resulting in lag in progress monitoring, delay in risk warning, and affecting the overall project management efficiency. Summary of the Invention

[0005] This application provides a method, electronic device, storage medium, and program product for monitoring project progress, in order to achieve a highly available, low-latency, and highly interactive integrated progress monitoring effect.

[0006] In a first aspect, embodiments of this application provide a method for monitoring project progress, comprising: collecting project progress data through a distributed sensor network and an application programming interface gateway; segmenting and indexing the project progress data based on the project construction stage and data category, and injecting risk level tags during the writing process to form tagged index data; streaming the tagged index data through a message queue and pushing it to the front end in real time based on a full-duplex communication protocol; dynamically loading a task list on the front end according to the user's view range, and rendering a Gantt chart containing a timeline and task bars, wherein the scale of the timeline is dynamically generated according to the currently displayed time window, and the position and color of the task bars are determined according to the risk level tags and time information.

[0007] In one possible implementation, a two-dimensional sharding key consisting of a project stage field and a data type field is constructed; similar monitoring data under the same construction stage are allocated to the same index shard according to the two-dimensional sharding key; and new indexes are automatically created on a daily or weekly basis using a time series index template.

[0008] In one possible implementation, the project stage identifier and data type identifier corresponding to the current project progress data are obtained; the project stage identifier and data type identifier are concatenated or hashed to generate a unique sharding routing key; based on the sharding routing key, the project progress data is allocated to the target shard in the distributed indexing system, so that data of the same type under the same project stage are centrally stored in the same physical shard.

[0009] In one possible implementation, before the data is written to the index, a rules engine determines whether the current progress data meets preset risk conditions; if it does, a risk level label is added to the data, the risk level label including a high risk or a severe risk indicator; wherein, the risk conditions include: the progress deviation rate exceeds a threshold or the sensor value exceeds the safe range.

[0010] In one possible implementation, the row index range of the current visible area in the task list is calculated, and only page elements corresponding to the row index range are created, with the remaining task rows replaced by blank placeholder elements; each task bar in the Gantt chart is mapped to a geometric primitive that can be processed by the graphics processor, wherein the horizontal position of the task bar is obtained by converting its start and end times, and the vertical position is determined by its row number in the task list; the geometric primitives are subjected to coordinate transformation by the vertex shading unit of the graphics processor, and differentiated display colors are generated by the fragment shading unit according to the risk level label of the corresponding task; in response to user scrolling or zooming operations, the visible row range of the task list and the task bar layout of the Gantt chart are updated synchronously, maintaining their vertical row alignment.

[0011] In one possible implementation, an ordered array of all task timestamps is pre-constructed; in response to a user zoom operation, the start and end timestamps of the currently displayed time window are determined; a binary search is used to quickly locate the task node within the time window in the ordered array; and the timeline scale and task bar layout for the current view are generated based solely on the task node.

[0012] Secondly, this application provides a project progress monitoring device, comprising: a data acquisition module for acquiring project progress data through a distributed sensor network and an application programming interface gateway; an indexing module for segmenting and indexing the project progress data based on the project construction stage and data category, and injecting risk level tags during the writing process to form tagged index data; a push module for streaming the tagged index data through a message queue and pushing it to the front end in real time based on a full-duplex communication protocol; and a rendering module for dynamically loading a task list on the front end according to the user's view range and rendering a Gantt chart containing a timeline and task bars, wherein the scale of the timeline is dynamically generated according to the currently displayed time window, and the position and color of the task bars are determined according to the risk level tags and time information.

[0013] Thirdly, embodiments of this application provide a monitoring device for project progress, including: a memory and a processor;

[0014] The memory stores computer-executed instructions;

[0015] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0016] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0017] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0018] The project progress monitoring method, electronic device, storage medium, and program product provided in this application, after collecting project progress data, first intelligently segments the data according to two dimensions: "which construction stage the project is in" and "what type of data it is," and then labels the data with risk tags. Next, a message queue is used to quickly synchronize the tagged data, and it is pushed to the front end through a bidirectional real-time communication channel. Upon receiving the data, the front end saves resources by loading only the task rows currently visible to the user, and simultaneously uses hardware acceleration to draw a Gantt chart with a timeline and task bars. The timeline can also automatically calculate which scales to display based on the user's zooming operation. Through these methods, high-speed end-to-end synchronization can still be achieved even with tens of thousands of data entries written concurrently per second. This allows project managers to monitor project progress and risk status in real-time, intuitively, and without lag. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0020] Figure 1 Flowchart of the project progress monitoring method provided in this application Figure 1 ;

[0021] Figure 2 Flowchart of the project progress monitoring method provided in this application Figure 2 ;

[0022] Figure 3 A schematic diagram of the structure of the project progress monitoring device provided in this application;

[0023] Figure 4 A schematic diagram of the structure of the project progress monitoring equipment provided in this application.

[0024] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0025] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0026] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0027] Figure 1 Flowchart of the project progress monitoring method provided in this application Figure 1 ,like Figure 1 As shown, the method includes:

[0028] S201. Collect project progress data through a distributed sensor network and application programming interface gateway;

[0029] A distributed sensor network refers to a network system composed of multiple physical or virtual sensor nodes deployed at an engineering site. It is used to collect real-time, multi-source, heterogeneous data related to project progress, such as structural stress, equipment vibration, ambient temperature and humidity, personnel positioning, and material arrival. Each node operates independently and the data converges to a central processing unit via wired or wireless means.

[0030] An Application Programming Interface Gateway (API Gateway) refers to a unified data channel for accessing external business systems. It is used to receive structured progress data (such as task status updates, plan changes, acceptance records, etc.) from non-sensor sources such as project management systems, construction scheduling platforms, and mobile inspection terminals, thereby achieving multi-source data fusion.

[0031] First, a distributed sensor network deployed at the construction site continuously collects various real-time monitoring data, such as the vibration frequency of the drilling platform, the displacement of bridge bearings, and the curing temperature of concrete. Simultaneously, the application programming interface (API) gateway receives task-level progress events (such as "Task ID-1001 status changed to completed") from ERP, BIM, or project management software. Both types of data carry metadata such as timestamps, location identifiers, and equipment / task IDs. After protocol parsing and format standardization, a unified project progress data stream is formed, serving as the input source for subsequent indexing and analysis. This design achieves full coverage of physical world perception (sensors) and business system events (APIs), ensuring the integrity and timeliness of progress data.

[0032] S202. Based on the project construction stage and data category, the project progress data is segmented and indexed, and risk level tags are injected during the writing process to form tagged index data;

[0033] The project construction phase refers to the business division unit in the life cycle of an engineering project, such as "foundation construction", "main structure", "equipment installation" and "system commissioning", which is used to characterize the current construction stage of the project.

[0034] Data categories refer to the classification of data based on the monitoring object or business attributes, such as "structural stress", "equipment vibration", "construction tasks", "environmental parameters", etc.

[0035] Sharded indexes refer to a mechanism in distributed full-text search systems that splits massive amounts of data according to specific rules and stores them in multiple physical shards to improve write throughput and query efficiency.

[0036] Risk level labels are metadata tags dynamically attached before data is written to the index. They are used to identify the risk level of the task or monitoring point corresponding to the data. Typical values ​​include "normal", "high risk" and "severe risk".

[0037] After receiving project progress data, the system first extracts the associated project construction stage (e.g., "equipment installation") and data category (e.g., "equipment vibration"), and combines these two as a two-dimensional sharding key to determine the index shard where the data should be written. For example, data of the category "equipment installation + equipment vibration" is routed to a dedicated shard to avoid being co-stored with data of "main structure + structural stress," thereby improving data locality.

[0038] Subsequently, before the data is officially written into the index, the system calls the rule engine (such as judgment logic based on thresholds or deviation rates) to perform real-time analysis of the data content: if the vibration frequency exceeds 50Hz or the progress deviation rate is greater than 10%, a risk level label (such as risk_level: HIGH) is automatically injected.

[0039] Finally, the original data and tags are written together into the index, forming tagged index data. This mechanism shifts the computational load to the writing stage, significantly reducing the response latency of subsequent queries and alerts.

[0040] S203. The tagged index data is streamed and synchronized through a message queue, and pushed to the front end in real time based on a full-duplex communication protocol;

[0041] Message queues are a type of asynchronous communication middleware that supports high-throughput, reliable message publishing and subscription. They are used to decouple data producers and consumers and ensure the stability of streaming processing.

[0042] Streaming synchronization refers to transmitting data changes from the source system to the target system in a continuous, low-latency manner, rather than periodic batch synchronization.

[0043] Full-duplex communication protocols (such as WebSocket) are network protocols that allow both parties to transmit data bidirectionally at the same time. They are suitable for real-time scenarios where the server needs to actively push data.

[0044] Once the tagged indexed data is written, the system immediately encapsulates it into a message and publishes it to a message queue. The stream processing service, acting as a consumer, pulls these messages from the queue in real time and can perform lightweight filtering, aggregation, or format conversion according to business needs. The processed data is proactively pushed to the front-end browser via a full-duplex communication connection (such as an established WebSocket long connection), eliminating the need for front-end polling requests. For example, when a drilling task is marked as "critical risk," the update can reach the front-end interface within 200 milliseconds. This process achieves end-to-end low-latency synchronization from data writing to front-end awareness, providing a data foundation for real-time visualization and early warning.

[0045] S204. Dynamically load the task list on the front end according to the user's view range, and render a Gantt chart containing a timeline and task bar.

[0046] The timeline scale is dynamically generated based on the currently displayed time window, and the position and color of the task bar are determined based on the risk level label and time information.

[0047] The view range refers to the area currently visible to the user on the interface, such as scrolling to task line 5000–5100, or zooming to a time window of “June 1–7, 2025”.

[0048] Dynamic loading refers to creating and rendering only page elements within the visible area, while the rest of the content is replaced by placeholders and replaced in real time as scrolling or zooming, which greatly reduces memory and computing overhead.

[0049] The timeline is the horizontal axis in a Gantt chart that represents the time dimension. Its scale intervals (such as "year-month-day" or "week-hour") need to be dynamically adjusted based on user interaction.

[0050] Task bars are horizontal bar elements in a Gantt chart that represent individual construction tasks. Their length reflects the construction period, their position reflects the start and end times, and their color reflects the status or risk.

[0051] After receiving the progress data pushed to the front end, the system first calculates the range of task rows to be displayed based on the user's current view range (e.g., the screen height can display 30 rows). Only the task list items within this range are rendered, while the remaining rows are filled with blank placeholder elements to achieve virtual scrolling. Simultaneously, the system constructs a Gantt chart.

[0052] The timeline scale is dynamically generated by the algorithm based on the currently displayed time window (such as when the user zooms to the "week view"). The system first determines the start and end timestamps of the week, then uses binary search to locate visible tasks in the full task time array, and only calculates and draws the scale line for the 168 hours of the week.

[0053] The horizontal position of the task bar is mapped to pixel coordinates by the start and end times of the task, and the vertical position is determined by its row number in the task list;

[0054] The color of the task bar is automatically set according to the risk level label carried in the index data (e.g., red = severe risk, yellow = high risk, green = normal).

[0055] Therefore, even when faced with hundreds of thousands of tasks, the system can complete the initial rendering within 0.8 seconds, and the scaling and scrolling operations maintain a smooth interaction of more than 60 frames per second, truly achieving an engineering visualization experience of "big data, low latency, and high smoothness".

[0056] The project progress monitoring method provided in this application, after collecting project progress data, first intelligently segments the data according to two dimensions: "which construction stage the project is in" and "what type of data it belongs to," and then labels the data with risk tags. Next, it uses a message queue to quickly synchronize the tagged data and pushes it to the front end through a bidirectional real-time communication channel. Upon receiving the data, the front end saves resources by only loading the task rows currently visible to the user, and simultaneously uses hardware acceleration to draw a Gantt chart with a timeline and task bars. The timeline can also automatically calculate which scales to display based on the user's zooming operation. Through these methods, high-speed end-to-end synchronization can still be achieved even with tens of thousands of data entries written concurrently per second. This allows project managers to monitor project progress and risk status in real-time, intuitively, and without lag.

[0058] Figure 2 Flowchart of the project progress monitoring method provided in this application Figure 2 ,like Figure 2 As shown, in this embodiment... Figure 1 Based on the examples, the method for monitoring project progress is described in detail, which includes:

[0059] S301. Construct a two-dimensional sharding key consisting of a project stage field and a data type field; allocate similar monitoring data under the same construction stage to the same index shard based on the two-dimensional sharding key; and automatically create new indexes on a daily or weekly basis using a time series index template.

[0060] The Project Stage field is a metadata field used to identify the current construction stage of an engineering project. Its value is a predefined business stage label, such as "Foundation Construction," "Main Structure," "Equipment Installation," "System Commissioning," and "Final Acceptance." This field reflects the macro-temporal characteristics of the project progress.

[0061] The data type field refers to the metadata field used to distinguish the business attributes of monitoring data. Its value indicates the source or physical meaning of the data, such as "structural stress", "equipment vibration", "ambient temperature and humidity", "construction task status", and "material arrival record". This field describes the micro-semantic characteristics of the data.

[0062] A two-dimensional sharding key is a composite logical key composed of the two fields mentioned above. It is used to uniquely identify a set of data with the same business context in a distributed indexing system, serving as the basis for data routing and sharding allocation.

[0063] An index shard is the smallest physical unit for storing data in a distributed full-text search system. An index can be divided into multiple shards, distributed across different nodes, to achieve horizontal scaling and parallel processing.

[0064] A time series index template refers to a pre-configured index generation rule used to automatically create new index instances with consistent naming conventions and structures at fixed time periods (such as daily or weekly). It includes built-in parameters such as the number of shards, refresh interval, and lifecycle strategy, and is suitable for continuously written time-series data.

[0065] This step first extracts the associated project stage fields (such as "equipment installation") and data type fields (such as "equipment vibration") from the project progress data to be processed, and combines the two to form a two-dimensional sharding key. This sharding key not only reflects the business affiliation of the data, but also implies its spatiotemporal distribution pattern—for example, the "equipment installation" stage is usually concentrated in the later stages of the project, and the "equipment vibration" data has high-frequency bursts.

[0066] Subsequently, the system routes the data to the corresponding index shard based on the sharding key, ensuring that all "equipment installation + equipment vibration" data types are centrally stored in the same physical shard. This design fully utilizes the spatiotemporal locality of engineering data, avoiding the hotspot problem caused by traditional hash sharding (such as a shard becoming overloaded due to a sudden write).

[0067] Meanwhile, the system binds a time-series index template to each type of dual-dimensional combination. When a new day or week begins, the system automatically creates a new index according to the template and writes the data for that day / week into that index. This mechanism achieves both time isolation of data (facilitating daily querying or archiving) and unified management of index configuration through templates, reducing operational complexity.

[0068] In summary, this process significantly improves system throughput and query efficiency in high-concurrency write scenarios through a business semantics-driven sharding strategy and time-aware index lifecycle management.

[0069] For example, the project stage identifier and data type identifier corresponding to the current project progress data are obtained; the project stage identifier and data type identifier are concatenated or hashed to generate a unique sharding routing key; the project progress data is allocated to the target shard in the distributed index system based on the sharding routing key, so that the same type of data under the same project stage is centrally stored in the same physical shard.

[0070] Project phase identifier, the specific value of the project phase field, such as the string "main construction".

[0071] Data type identifier, the specific value that the data type field can take, such as the string "structural stress".

[0072] The shard routing key is the result of a computation that determines which shard data is written to. It is usually a string or an integer and serves as the input for shard selection in a distributed indexing system.

[0073] String concatenation connects two strings in a fixed order (e.g., "Main Construction_Structural Stress").

[0074] Hash operations apply deterministic hash functions (such as MD5 and MurmurHash) to the input string, outputting a fixed-length digest value for uniformly distributed routing.

[0075] In practice, the system first parses a piece of project progress data, extracting its project stage identifier (e.g., "main construction") and data type identifier (e.g., "structural stress"). Then, the system concatenates these two identifiers to generate a raw routing string in the form of "main construction_structural stress"; alternatively, to avoid excessively long strings, a hash operation can be performed on the concatenation result to generate a fixed-length numeric fragmentation routing key (e.g., hash("main construction_structural stress") = 12345).

[0076] The routing key is submitted to the distributed indexing system, which maps the key to a target shard (e.g., shard number 7) based on its internal consistent hashing algorithm. Therefore, the data is written to shard 7. Since all "Main Construction + Structural Stress" data generates the same routing key, they will always be assigned to the same physical shard.

[0077] This mechanism ensures the physical aggregation of similar business data, greatly improves the I / O efficiency of range queries (such as "querying all structural stress anomalies during the main construction phase"), and effectively balances the load of each shard, avoiding single-point bottlenecks caused by a surge in a certain type of data during peak construction periods.

[0078] S302. Before writing data to the index, the rule engine determines whether the current progress data meets the preset risk conditions. If it does, a risk level label is added to the data. The risk level label includes a high risk or a severe risk indicator.

[0079] Among the risk conditions are: the schedule deviation rate exceeds the threshold or the sensor value exceeds the safe range.

[0080] A rule engine is a configurable logic judgment component that can evaluate input data in real time and output judgment results based on predefined business rules. Rules are stored in the form of "condition-action" and support dynamic updates without modifying program code.

[0081] Schedule variability rate refers to the degree of deviation between actual progress and planned progress. The calculation formula is:

[0082]

[0083] Used to measure whether construction tasks are behind schedule.

[0084] Sensor values ​​refer to physical quantity measurements collected by a distributed sensor network, such as vibration frequency, stress value, temperature, displacement, etc., reflecting the real-time status of engineering structures or equipment.

[0085] The safe range refers to the normal operating range set for a specific sensor value (e.g., vibration frequency ≤ 50 Hz). Exceeding this range may indicate equipment failure or structural abnormality.

[0086] Risk level labels are metadata tags attached to raw data to characterize the risk level of the corresponding task or monitoring point. Typical values ​​include "normal", "high risk" and "severe risk", which are used for subsequent visualization coloring and alarm triggering.

[0087] This step is performed before the project progress data is formally written to the distributed indexing system. The system first inputs the current data (e.g., the actual completion rate of a drilling task is 80%, while the planned rate is 95%) into the rules engine. The rules engine loads a pre-defined set of risk condition rules, for example:

[0088] If the schedule deviation rate is greater than 10%, it is judged as "high risk";

[0089] If the schedule deviation rate is greater than 20%, it is judged as "serious risk";

[0090] If the vibration frequency reported by the sensor is > 50 Hz, it is judged as "serious risk".

[0091] The rules engine matches each record in the current data. Once any condition is met, a corresponding risk level label (e.g., risk_level: HIGH) is generated and embedded as a new field into the original data. Subsequently, the labeled data is written to the index.

[0092] This mechanism moves aggregation calculations (such as "calculating the average deviation of a task over the past 7 days"), which were originally performed during the query phase, to the data writing phase. This significantly reduces front-end query latency and ensures that the risk status is determined when the data is written to disk, providing a reliable basis for subsequent real-time push and visualization. Real-world testing shows that this design reduces risk warning response time from seconds to milliseconds.

[0093] S303. Pre-construct an ordered array of all task timestamps; in response to user zooming operations, determine the start and end timestamps of the currently displayed time window; use binary search to quickly locate the task node within the time window in the ordered array; generate the timeline scale and task bar layout for the current view based solely on the task node.

[0094] Task timestamps refer to the start or end time of each construction task, expressed in a standard time format (such as Unix millisecond timestamps), and are used to locate the horizontal position of the task bar in a Gantt chart.

[0095] An ordered array refers to a collection of task timestamps arranged in ascending order, which supports efficient range retrieval.

[0096] The time window refers to the time range that the user is currently viewing on the Gantt chart interface, such as "June 1, 2025 00:00 to June 7, 2025 23:59".

[0097] Binary search is a search algorithm with a time complexity of O(logn) for finding a target value or interval boundary in an ordered sequence. It is suitable for fast location of large-scale data.

[0098] A task node is a data unit in a Gantt chart that represents a single construction task, and includes attributes such as task ID, start and end time, row number, and risk level.

[0099] During the Gantt chart initialization phase, the system iterates through all construction tasks, extracts their start timestamps, sorts them in ascending order of time, and pre-constructs a globally ordered array (e.g., ...). , where t1 <t2<...<tn)。

[0100] When a user performs a zoom operation (such as switching from "Year View" to "Week View"), the front end immediately calculates the start timestamp Tstart and end timestamp Tend of the current time window.

[0101] Subsequently, the system invokes a binary search algorithm to locate the first position ≥ Tstart and the last position ≤ Tend in the ordered array, thereby quickly determining the index range of all task nodes within the current time window. Based solely on task nodes within this range, the system generates the timeline scale required for the current view (e.g., "Monday 00:00", "Tuesday 00:00", ... "Sunday 24:00") and the corresponding task bar layout (calculating the pixel coordinates and color of each task bar). By avoiding the traversal and redrawing of all hundreds of thousands of tasks, this method reduces the time for timeline generation and Gantt chart rendering from over 3 seconds in traditional solutions to less than 0.1 seconds, achieving seamless and smooth scaling of multi-granularity views ("year-month-day" and "week-hour").

[0102] For example, the row index range of the current visible area in the task list is calculated, and only page elements corresponding to the row index range are created, with the remaining task rows replaced by blank placeholder elements; each task bar in the Gantt chart is mapped to a geometric primitive that can be processed by the graphics processor, wherein the horizontal position of the task bar is obtained by converting its start and end times, and the vertical position is determined by its row number in the task list; the geometric primitives are subjected to coordinate transformation by the vertex shading unit of the graphics processor, and differentiated display colors are generated by the fragment shading unit according to the risk level label of the corresponding task; in response to user scrolling or zooming operations, the visible row range of the task list and the task bar layout of the Gantt chart are updated synchronously, maintaining the vertical row alignment between the two.

[0103] Row index range: refers to the starting and ending row numbers covered by the currently visible area in the task list, such as row 5001 to row 5020.

[0104] Page elements: These are visual components used to present individual task information in the front-end interface, including combined display units of fields such as task name, person in charge, and status.

[0105] Blank placeholder elements: These are virtual elements that do not contain actual content and are only used to maintain the overall layout height. Their function is to ensure that the scrollbar length matches the total workload, but they do not consume rendering resources.

[0106] Geometric primitives: refer to data structures used to represent the basic shape of graphics. In this application, they specifically refer to rectangular primitives that represent the task bars of a Gantt chart, and include attributes such as position, size, and color.

[0107] Vertex Shading Unit: A computational module in the graphics processor responsible for transforming and projecting the coordinates of geometric primitive vertices to determine the final position of the primitives on the screen.

[0108] Fragment Shading Unit: A module in the graphics processor responsible for calculating the final color for each pixel (i.e., "fragment") covered by a primitive, supporting dynamic shading based on data attributes.

[0109] Row alignment: This refers to the vertical alignment of a task in the task list with the corresponding task bar in the Gantt chart, ensuring that users can intuitively associate table information with graphical representation.

[0110] The system first calculates the row index range corresponding to the visible area (e.g., rows 8000–8020) based on the current scroll position and container height. Then, it creates and renders only page elements within this range to display the corresponding task's text information; for the remaining tens of thousands of invisible tasks, the system generates blank placeholder elements to fill their spaces. This strategy reduces the actual number of rendered page elements from hundreds of thousands to less than a hundred, significantly reducing memory usage and layout calculation overhead.

[0111] For Gantt charts, the system converts each construction task into a geometric primitive (rectangle):

[0112] The horizontal position is converted to screen pixel coordinates by linear mapping from the start and end times of the task (e.g., "2025-06-01" is mapped to X=100px, and "2025-06-05" is mapped to X=500px).

[0113] The vertical position is determined by the row number of the task in the task list (e.g., task number 8005 corresponds to Y=150px), thus ensuring strict vertical alignment with the task list.

[0114] All geometric primitives are submitted to the graphics processor for drawing. The vertex shading unit receives the coordinates of the four vertices of each primitive, performs normalization and viewport transformation, and outputs the screen space position.

[0115] The fragment coloring unit reads the risk level label (such as "high risk") associated with the task and selects a preset color (such as red) accordingly to generate the final display color for each pixel covered by the primitive.

[0116] This process is executed entirely in parallel by hardware, avoiding the performance bottleneck of traditional pixel-by-pixel CPU rendering.

[0117] When a user scrolls, the system recalculates the visible row index range and synchronously updates the page elements in the task list and the corresponding task bars in the Gantt chart. When a user zooms in on the timeline (such as switching to the "hourly" view), the system recalculates the horizontal coordinates of all visible task bars and triggers the graphics processor to redraw. Throughout this process, the task list and Gantt chart maintain vertical row alignment to ensure a consistent user experience.

[0118] The project progress monitoring method provided in this application, after collecting project progress data, first intelligently segments the data according to two dimensions: "which construction stage the project is in" and "what type of data it belongs to," and then labels the data with risk tags. Next, it uses a message queue to quickly synchronize the tagged data and pushes it to the front end through a bidirectional real-time communication channel. Upon receiving the data, the front end saves resources by only loading the task rows currently visible to the user, and simultaneously uses hardware acceleration to draw a Gantt chart with a timeline and task bars. The timeline can also automatically calculate which scales to display based on the user's zooming operation. Through these methods, high-speed end-to-end synchronization can still be achieved even with tens of thousands of data entries written concurrently per second. This allows project managers to monitor project progress and risk status in real-time, intuitively, and without lag.

[0119] Figure 3 A schematic diagram of the structure of the project progress monitoring device provided in this application is shown below. Figure 3 As shown, the project progress monitoring device 40 provided in this embodiment includes:

[0120] Acquisition module 401 is used to acquire project progress data through a distributed sensor network and an application programming interface gateway;

[0121] Index module 402 is used to segment and index the project progress data based on the project construction stage and data category, and inject risk level tags during the writing process to form tagged index data;

[0122] The push module 403 is used to stream and synchronize tagged index data through a message queue and push it to the front end in real time based on a full-duplex communication protocol.

[0123] The rendering module 404 is used to dynamically load the task list on the front end according to the user's view range and render a Gantt chart containing a timeline and task bars. The scale of the timeline is dynamically generated according to the currently displayed time window, and the position and color of the task bars are determined according to the risk level label and time information.

[0124] In one possible implementation, index module 402 is used to construct a two-dimensional sharding key consisting of a project stage field and a data type field; to allocate similar monitoring data under the same construction stage to the same index shard according to the two-dimensional sharding key; and to automatically create new indexes on a daily or weekly basis using a time series index template.

[0125] In one possible implementation, the index module 402 is used to obtain the project stage identifier and data type identifier corresponding to the current project progress data; perform string concatenation or hash operation on the project stage identifier and data type identifier to generate a unique sharding routing key; and allocate the project progress data to the target shard in the distributed index system based on the sharding routing key, so that the same type of data under the same project stage is centrally stored in the same physical shard.

[0126] In one possible implementation, the index module 402 is used to determine whether the current progress data meets the preset risk conditions through the rule engine before the data is written to the index; if it does, a risk level label is added to the data, and the risk level label includes a high risk or a serious risk indicator; wherein, the risk conditions include: the progress deviation rate exceeds the threshold or the sensor value exceeds the safe range.

[0127] In one possible implementation, the rendering module 404 calculates the row index range of the current visible area in the task list and creates only the page elements corresponding to the row index range, replacing the remaining task rows with blank placeholder elements; it maps each task bar in the Gantt chart to a geometric primitive that can be processed by the graphics processor, wherein the horizontal position of the task bar is obtained by converting its start and end times, and the vertical position is determined by its row number in the task list; it performs coordinate transformation on the geometric primitives through the vertex shading unit of the graphics processor, and generates differentiated display colors according to the risk level label of the corresponding task through the fragment shading unit; in response to the user's scrolling or zooming operation, it synchronously updates the visible row range of the task list and the task bar layout of the Gantt chart, maintaining their vertical row alignment.

[0128] In one possible implementation, the rendering module 404 is used to pre-build an ordered array of all task timestamps; in response to user zooming operations, determine the start and end timestamps of the currently displayed time window; use binary search to quickly locate the task nodes located within the time window in the ordered array; and generate the timeline scale and task bar layout under the current view based only on the task nodes.

[0129] The project progress monitoring device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0130] Figure 4 A structural schematic diagram of the project progress monitoring equipment provided in this application. (See attached diagram.) Figure 4 As shown, the electronic device 50 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the device 50 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.

[0131] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0132] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0133] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0134] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0135] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0136] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0137] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0138] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0139] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0140] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0141] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0142] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0143] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0144] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0145] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A method for monitoring project progress, characterized in that, Includes: Project progress data is collected through a distributed sensor network and an application programming interface gateway. The project progress data is segmented and indexed based on the project construction stage and data category, and risk level tags are injected during the writing process to form tagged index data. The tagged index data is streamed and synchronized via a message queue, and pushed to the front end in real time based on a full-duplex communication protocol; The task list is dynamically loaded on the front end according to the user's view range, and a Gantt chart containing a timeline and task bars is rendered. The scale of the timeline is dynamically generated according to the currently displayed time window, and the position and color of the task bars are determined according to the risk level label and time information.

2. The method according to claim 1, characterized in that, The project progress data is sharded and indexed based on project construction stages and data categories, including: Construct a two-dimensional sharding key consisting of a project stage field and a data type field; Based on the dual-dimensional sharding key, similar monitoring data under the same construction stage are allocated to the same index shard; Create new indexes automatically on a daily or weekly basis using time series index templates.

3. The method according to claim 2, characterized in that, Construct a two-dimensional sharding key consisting of a project stage field and a data type field, including: Retrieve the project stage identifier and data type identifier corresponding to the current project progress data; The project stage identifier and the data type identifier are concatenated or hashed to generate a unique sharding routing key. Based on the sharding routing key, the project progress data is allocated to the target shard in the distributed indexing system, so that data of the same type under the same project stage are centrally stored in the same physical shard.

4. The method according to claim 1, characterized in that, Inject risk level labels during the writing process, including: Before the data is written to the index, the rules engine determines whether the current progress data meets the preset risk conditions. If the conditions are met, a risk level label is added to the data, which includes a high-risk or severe-risk indicator. The risk conditions include: the schedule deviation rate exceeding a threshold or the sensor value exceeding the safe range.

5. The method according to claim 1, characterized in that, The task list is dynamically loaded on the front end based on the user's view scope, and a Gantt chart containing a timeline and task bars is rendered, including: Calculate the row index range of the current visible area in the task list, and create only the page elements corresponding to the row index range, replacing the remaining task rows with blank placeholder elements; Each task bar in the Gantt chart is mapped to a geometric primitive that can be processed by the graphics processor, wherein the horizontal position of the task bar is obtained by converting its start and end times, and the vertical position is determined by its row number in the task list. The geometric primitives are subjected to coordinate transformation by the vertex shading unit of the graphics processor, and differentiated display colors are generated by the fragment shading unit according to the risk level label of the corresponding task. In response to user scrolling or zooming, the visible row range of the task list and the task bar layout of the Gantt chart are updated synchronously, maintaining their vertical row alignment.

6. The method according to claim 1, characterized in that, Before rendering the Gantt chart containing the timeline and task bar, the method further includes: Pre-construct an ordered array of timestamps for all tasks; In response to user zooming, determine the start and end timestamps of the currently displayed time window; Binary search is used to quickly locate the task node within the time window in the ordered array; The timeline scale and task bar layout for the current view are generated based solely on the task node.

7. A device for monitoring project progress, characterized in that, include: The data acquisition module is used to collect project progress data through a distributed sensor network and an application programming interface gateway. The indexing module is used to segment and index the project progress data based on the project construction stage and data category, and inject risk level tags during the writing process to form tagged index data; The push module is used to stream and synchronize the tagged index data through a message queue and push it to the front end in real time based on a full-duplex communication protocol; The rendering module is used to dynamically load a task list on the front end according to the user's view range and render a Gantt chart containing a timeline and task bars. The scale of the timeline is dynamically generated according to the currently displayed time window, and the position and color of the task bars are determined according to the risk level label and time information.

8. A monitoring device for project progress, characterized in that, Includes: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-6.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-6.

Images