Building design application behavior monitoring and algorithm analysis project work hour statistical analysis system

Abstract

The application relates to the technical field of architectural design, in particular to a project work hour statistical analysis system for architectural design application behavior monitoring and algorithm analysis, which comprises a page behavior record module, a task trajectory generation module, a project identification collection module, a personnel time consumption verification module and an error offset tracking module. In the application, a task window and an operation path sequence in design software are extracted, irrelevant operation contents are removed, a task behavior chain is reconstructed, a clear task execution structure is formed, a continuous operation time period is aggregated by combining task attribution information, a precise mapping relationship between behavior data and project content is established, effective work hours and responsible personnel are matched and compared after collection, a time offset section between behavior records and declaration data is identified, an offset rate is quantified, and work hour declaration rationality is determined, so that dynamic checking and precision improvement of the work hour distribution and the task corresponding relationship are realized.

Description

Technical Field

[0001] This invention relates to the field of architectural design technology, and in particular to a project time statistical analysis system for architectural design application behavior monitoring and algorithm analysis. Background Technology

[0002] The field of architectural design technology primarily involves the systematic planning and implementation management of the entire process of architectural projects, from conception, design, modeling to drawing production. This field encompasses multiple professional directions, including architectural scheme design, structural design, water supply and drainage design, electrical design, and HVAC design. Its core aspects include the decomposition and allocation of design tasks, the formation and optimization of design schemes, the organization and coordination of collaborative work processes, the preparation and review of design drawings, and the simultaneous control of project progress and quality. With the widespread application of digital design tools, architectural design activities increasingly rely on computer-aided design platforms. While improving design efficiency and accuracy, this also places higher demands on the data management, behavior monitoring, and resource scheduling of the design process. Among them, the project time statistics analysis system for traditional architectural design application behavior monitoring and algorithm analysis refers to the recording of information on the designer's operation behavior, task execution and file interaction during the use of professional software in architectural design activities, in order to estimate the time distribution of the designer on different design tasks. Traditional methods usually use the log function built into the design software to record the opening and closing time of files and command execution records, or rely on manually filling in time sheets to count the working time of each stage. These methods rely on fixed rules to record specific operation data or on human subjective judgment of work content and duration to form a basic understanding and preliminary summary of project time.

[0003] Existing technologies use operation logs or manual recording of work hours to statistically analyze project task time. This only obtains the start and end information of tasks and cannot reconstruct the entire operational structure of the task. When there are frequent window switching or overlapping tasks in the project, operation segments are easily mixed with content that is not part of the task and cannot be removed. The corresponding time is mistakenly included in the target project, causing data deviation. Especially when there are no clear boundaries between multi-stage tasks, logs are difficult to distinguish the corresponding operation range of each task, while manual recording relies on subjective judgment and lacks verifiable paths, which can easily lead to inaccurate work hour attribution. In the process of project management, the granularity of work hour data is insufficient, which is difficult to meet the requirements of data accuracy and matching precision in high-frequency task decomposition or concurrent execution scenarios. Summary of the Invention

[0004] To address the technical problems existing in the prior art, embodiments of the present invention provide a project time statistical analysis system for monitoring and algorithmic analysis of architectural design application behaviors. The technical solution is as follows:

[0005] On the one hand, it provides a project time statistics analysis system for monitoring and analyzing architectural design application behavior and algorithms. This system includes:

[0006] The page behavior recording module acquires the user's front-end operation behavior during the use of design software such as AutoCAD, Revit, and SketchUp. It records the software startup action, extracts the software name and task window identifier, identifies window switching events and corresponds them to the operation sequence, segments and serializes the task operation into timelines, and extracts continuous design operation segments.

[0007] Based on the continuous design operation segments, the task trajectory generation module receives monitoring plugin data, identifies drawing paths and task call content, splices together repeated call path files, removes behavioral fragments unrelated to the task, and generates design task trajectory fragments.

[0008] The project identification collection module calls the design server interface through the design task trajectory fragment, extracts the project number in the drawing path, connects the project information source, compares the project type and design stage, and completes the classification by combining the behavior time and drawing annotation content to obtain the professional task attribution content.

[0009] The personnel time verification module writes the responsible person's behavior into the database based on the professional task attribution content, extracts the continuous time value of each task segment and merges them for calculation, compares it with the user's work hour record, identifies verifiable time segments, and obtains the project work time distribution.

[0010] As a further embodiment of the present invention, the continuous design operation segment includes the design software name, task window identifier, and window switching sequence; the design task trajectory segment includes the drawing file path, task call order, and irrelevant behavior stripping result; the professional task attribution content includes the project number field, project type identifier, design stage classification, and drawing annotation information; and the project work duration distribution includes the assigned task time, merged task time period, and work hour comparison data.

[0011] As a further aspect of the present invention, the task-independent behavior fragment refers to non-design-related operation records that do not involve project drawing editing, viewing, and task invocation paths;

[0012] The verifiable time segment refers to a continuous working period in which the behavior records are consistent with the user's work hour declaration and can be cross-verified through operational data.

[0013] As a further aspect of the present invention, the page behavior recording module includes:

[0014] The software identification submodule obtains the user's operation records when opening the design software, extracts the process startup event, filters the software names of AutoCAD, Revit, and SketchUp, and concatenates them with the task window identifier to generate software task identification tags.

[0015] The task switching submodule, based on the software task identification tag, calls the timestamp and foreground window switching record, matches the window handle and software identifier, extracts the switching time and compares it with the software usage sequence, and generates window task switching segment information.

[0016] The operation sequence construction submodule combines task segments in chronological order according to the window task switching segment information, calculates the time difference between adjacent segments, determines whether it is lower than the minimum interval threshold, merges them into continuous operation segments, and generates continuous design operation segments.

[0017] As a further aspect of the present invention, the task trajectory generation module includes:

[0018] Based on the continuous design operation segment, the path recognition submodule calls the data sent by the user monitoring plugin, extracts the drawing path and task call information, identifies and numbers duplicate paths, records the number sequence according to the call order, and generates a duplicate path identification sequence.

[0019] The behavior splicing submodule splices the operation behaviors into a structural chain according to the path number order based on the repeated path identifier sequence, filters the connection points between the differentiated task numbers, extracts the corresponding behavior fragments, and obtains the structured behavior sequence.

[0020] The trajectory extraction submodule calls the structured behavior sequence, and based on the path field and task number, excludes behavior segments that do not belong to the task path to obtain the design task trajectory segment.

[0021] As a further aspect of the present invention, the project identifier collection module includes:

[0022] The task feedback receiving submodule, based on the designed task trajectory fragment, calls the design server interface to receive task feedback information from the source path, extracts the path field and associated task content from the feedback data, judges the path and filters out fields with no response, and obtains the task path feedback set.

[0023] The project number recognition submodule calls the task path feedback set, extracts the project number field embedded in the drawing path, connects the project information source data, locates the project number position according to the field structure, completes field comparison, and obtains the project number list;

[0024] The attribution content determination submodule compares the project type value corresponding to the number with the design stage value based on the project number list, and combines the behavior trigger time in the drawing annotation content with the comparison of the timestamp range in the field to classify and determine the attribution content of the professional task.

[0025] As a further aspect of the present invention, the personnel time consumption verification module includes:

[0026] The behavior writing submodule, based on the professional task attribution content, writes the behavior records of the responsible persons corresponding to each task into the behavior database, extracts the start time and end time fields of each attribution behavior, generates time period records, and obtains the task behavior time period set.

[0027] The time calculation submodule calls the task behavior time period set, merges the time periods that overlap and are continuous in the differentiated attribution behaviors of the same person, retains the start and end time of the merged segment, and generates the cumulative behavior time value.

[0028] The duration verification submodule compares the cumulative behavior time value with the time period field in the user's work hour record data to see if there is an overlap relationship between the start and end time intervals of the two datasets, and filters out fully verifiable time periods to obtain the project work duration distribution.

[0029] As a further aspect of the present invention, the system further includes:

[0030] The error offset tracking module combines the project's work duration distribution, compares the time periods reported in the report with those manually submitted, extracts and classifies the start and end time differences, cross-analyzes blank time and interrupted records, identifies offset record segments, and calculates and obtains the task execution time offset rate.

[0031] As a further aspect of the present invention, the task execution time offset rate includes the start and end time difference, blank time segments, and operation interruption records.

[0032] As a further aspect of the present invention, the error offset tracking module includes:

[0033] The time difference extraction submodule extracts the task time period recorded in the BI report and the user-manually declared time period based on the project's work duration distribution. It compares the start and end values ​​of the two time fields according to the task number, calculates the difference field, and then classifies the difference field according to the task sequence number to obtain the task time difference sequence.

[0034] The blank screening submodule calls the task time difference sequence, compares it with the operation time period of the corresponding task in the behavior database, detects blank time segments and operation interruption records within the time period, screens behavior points that are not bound to the declaration record within the time period, and obtains a set of non-declaration behavior segments.

[0035] The offset rate identification submodule calculates the time length of each segment based on the set of non-declared behavior segments and compares it with the corresponding item in the task time difference sequence. Records with offset degrees exceeding the declaration segment length threshold are marked as deviated segments, and the task execution time offset rate is obtained.

[0036] The beneficial effects of the technical solutions provided by the embodiments of the present invention include at least the following:

[0037] By extracting task windows and operation path sequences from design software, the task behavior chain is reconstructed and irrelevant operations are eliminated to form a clear task execution structure. Combined with task attribution information, continuous operation time periods are aggregated to establish a precise mapping relationship between behavioral data and project content. Effective working hours are matched with responsible personnel and then collected and compared to identify time offset segments between behavioral records and reported data. The offset rate is quantified and the rationality of working hour reports is determined, thereby achieving dynamic verification and accuracy improvement of the relationship between working hour distribution and task correspondence. Attached Figure Description

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

[0039] Figure 1 This is a schematic diagram of the process of the present invention;

[0040] Figure 2 This is a schematic diagram of the system framework of the present invention;

[0041] Figure 3 This is a flowchart of the page behavior recording module in this invention;

[0042] Figure 4 This is a flowchart of the task trajectory generation module in this invention;

[0043] Figure 5 This is a flowchart of the project identifier collection module in this invention;

[0044] Figure 6 This is a flowchart of the personnel time verification module in this invention;

[0045] Figure 7 This is a flowchart of the error offset tracking module in this invention. Detailed Implementation

[0046] The technical solution of the present invention will now be described with reference to the accompanying drawings.

[0047] In embodiments of the present invention, words such as "exemplarily," "for example," etc., are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" in the present invention should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the word "exemplary" is intended to present the concept in a concrete manner. Furthermore, in embodiments of the present invention, the meaning expressed by "and / or" can be both, or either one.

[0048] In the embodiments of this invention, the terms "image" and "picture" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction between them, their intended meanings are consistent. Similarly, the terms "of," "corresponding (relevant)," and "corresponding" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction between them, their intended meanings are consistent.

[0049] In this embodiment of the invention, sometimes a subscript such as W1 may be written in a non-subscript form such as W1. When the difference is not emphasized, the meaning they express is the same.

[0050] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0051] This invention provides a project time statistical analysis system for monitoring and analyzing architectural design application behaviors using algorithms, such as... Figure 1-2 The diagram shown illustrates a project time statistics analysis system for architectural design application behavior monitoring and algorithm analysis. This system includes:

[0052] The page behavior recording module obtains the front-end page behavior records of users when operating design software including AutoCAD, Revit, and SketchUp. It records the user's action of opening the design software, extracts the design software name and task window identifier and combines them, reads the task window switching event and corresponds it with the timing of the design software usage, segments the operations between tasks and performs timeline serialization processing, constructs a continuous task segment operation flow, and obtains continuous design operation segments.

[0053] The task trajectory generation module receives data from the user monitoring plugin based on continuous design operation segments, identifies drawing file paths and task call content, combines and splices repeatedly called path files in the design task, organizes behavior segments into a continuous structure according to the call order, removes irrelevant segments in the behavior that do not belong to the scope of the project task, and obtains design task trajectory segments.

[0054] The project identification collection module is based on the design task trajectory fragments. It calls the design server interface to receive task feedback information from the source path, extracts the project number embedded in the drawing path, connects the project information source data, compares the project type with the design stage value, and completes the classification operation by comparing the behavior trigger time with the drawing annotation content to obtain the professional task attribution content.

[0055] The personnel time consumption verification module writes the behavior records of the person in charge of the task into the behavior database according to the content of the professional task, extracts the continuous time value of the task for each assigned behavior, merges the task time segments in the behavior database, compares it with the user's work hour record data, identifies and binds verifiable time segments, and obtains the project work time distribution.

[0056] The error offset tracking module combines the project work duration distribution to extract and compare the task time period presented in the BI report with the user-manually reported time period. It extracts the start and end time difference field and divides them in parallel. It cross-screens blank time slices and operation interruption records in the behavior records to identify record segments that are significantly offset from the reported content and obtain the task execution time offset rate.

[0057] The continuous design operation segment includes the design software name, task window identifier, and window switching sequence. The design task trajectory segment includes the drawing file path, task call order, and irrelevant behavior stripping results. The professional task attribution content includes the project number field, project type identifier, design stage classification, and drawing annotation information. The project work duration distribution includes the assigned task time, merged task time period, and work hour comparison data. The task execution time offset rate includes the start and end time difference, blank time segments, and operation interruption records.

[0058] Specifically, such as Figure 2 , 3 As shown, the page behavior recording module includes:

[0059] The software identification submodule obtains the user's operation records when opening the design software, extracts the process startup event, filters the software names of AutoCAD, Revit, and SketchUp, and concatenates them with the task window identifier to generate software task identification tags.

[0060] The system first extracts all process startup events from the user terminal's system-level event log. Each event record contains information such as startup time, process ID, process name, startup path, and process status. The system iterates through these event records, comparing the process name field with a pre-defined software identification list. This list is fixed with the process names of three design software programs: "AutoCAD," "Revit," and "SketchUp." The system uses exact matching logic and does not accept fuzzy matching. For example, "AutoCAD2023" and "AutoCAD" will be considered inconsistent. Only when the process name is entirely "AutoCAD" will it be confirmed. After a successful match, the system immediately retrieves the handle of the active window generated by the corresponding process ID during its operation and calls the window management interface to extract the window title information. The window title often contains a brief name of the current project, such as "City Square Modeling - AutoCAD." The text is segmented and extracted using spaces or hyphens as delimiters. The first segment, "City Square Modeling," is taken as the project identifier field. This field is then combined with the process name to generate task tags. The tag format is "Software Name_Project Identifier," and the combined result is, for example, "AutoCAD_City Square Modeling." The system writes this result as a unique task identifier into the identification record table. This process is applicable to parallel identification operations of multiple software programs. If a user launches multiple design tools at the same time, the system will identify each process according to the launch order and generate a tag for each task window. In the example, if the system detects that the user launches Revit and SketchUp consecutively within a 20-second interval, with window titles "Cultural Center Design - Revit" and "Shop Exterior Sketch - SketchUp" respectively, the system will identify and generate two independent tags, "Revit_Cultural Center Design" and "SketchUp_Shop Exterior Sketch," to ensure accurate classification of different software tasks in the future.

[0061] The task switching submodule is based on software task identification tags, calls timestamps and foreground window switching records, matches window handles and software identifiers, extracts switching time and compares it with software usage time sequence to generate window task switching segment information;

[0062] First, the system retrieves the window focus switching log. Each record in this log contains the switching time, the window handle before the switch, and the window handle after the switch. The system reads each record sequentially, querying the process name and title text corresponding to the window based on the window handle after the switch. After obtaining complete window information, the system determines the current window task based on the previously generated task identification tag. The determination method is to parse the window title into the format "software name_project name" and then perform an exact match with the identification tag. For example, if the window title after the switch is "Residential Building Modeling - Revit", the corresponding tag should be "Revit_Residential Building Modeling". If the match is successful, the time point is recorded as the task active start time. Then, the system continues to search for the time when the window was switched out of focus as the task end time. If the task window is in between... If a window regains focus within a short period, such as 10 seconds, and is switched back, the system records this as the start time of the second active window. The start and end times of each segment are stored in the segment record table. The entire process requires maintaining a mapping table between window handles and task labels to ensure that each window switch accurately corresponds to a specific task. If multiple different task labels are switched alternately, the system will accurately distinguish them based on the actual changes in the window title. For example, if a user switches between "SketchUp_Commercial Street Scheme" and "AutoCAD_Underground Pipeline Layout" multiple times, the system will create multiple active task segments for each of them to ensure that the task segment division has clear boundaries and does not overlap. Each task segment will contain four types of basic data: start time, end time, task label, and corresponding window handle.

[0063] The operation sequence construction submodule combines task segments according to the window task switching section information, calculates the time difference between adjacent segments, determines whether it is lower than the minimum interval threshold, merges them into continuous operation segments, and generates continuous design operation segments.

[0064] First, all segments are sorted in ascending order by start time to construct a complete task time sequence. Then, the system processes each pair of adjacent task segments sequentially, calculating the time difference between the start time of the current segment and the end time of the previous segment. This difference is then compared with a preset minimum interval threshold. This minimum interval threshold is set based on the analysis of a large amount of user behavior data. Statistical analysis of task switching interval data from 50 designers revealed that over 70% of task intervals are concentrated between 2 and 3 minutes. To ensure the accuracy of operation continuity identification, the system sets the minimum interval threshold to 150 seconds. This value supports dynamic adjustment and can be adjusted to 120 seconds, 180 seconds, etc., based on user behavior models. In actual deployment, 150 seconds is the generally recommended value. Based on this, the system merges adjacent task segments into a single continuous operation segment when the interval between them is less than 150 seconds. If the interval is greater than or equal to 150 seconds, they are considered two independent task segments. For example, if a user completes a SketchUp task segment at 12:20:10 and the next Revit task starts at 12:22:00, the interval is only 110 seconds, less than the threshold, so they are merged into a single continuous segment of "SketchUp + Revit," with the start and end times recorded after merging from 12:15:40 to 12:29:10. Conversely, if another task starts at 12:34:40, 330 seconds after the previous segment ends, the system treats this segment as a new operation segment and records it separately. After traversing the entire task segment list, the system outputs the final continuous operation segments in chronological order. Each segment includes the start time, end time, total operation duration, and a list of covered task tags to support subsequent design behavior analysis.

[0065] Specifically, such as Figure 2 , 4 As shown, the task trajectory generation module includes:

[0066] The path recognition submodule is based on continuous design operation segments. It calls the data sent by the user monitoring plugin, extracts the drawing path and task call information, identifies and numbers duplicate paths, records the number sequence according to the call order, and generates a duplicate path identification sequence.

[0067] First, the system activates the data channel of the locally running user monitoring plugin and reads the task behavior data reported by the plugin one by one. This data includes fields such as drawing file access paths, user click behaviors, internal function call records of design tools, and task scheduling status. The system extracts the drawing path field from the data packet and creates a temporary path list. Each record in the list is the complete path of a drawing file that the user opened or operated on at a certain point in time. The system reads the path data in the list sequentially and performs a complete comparison in string form to determine if there are duplicate paths. The judgment process uses a double-layer traversal method: the outer layer traverses the current path item, and the inner layer compares each character with the registered path items. If the characters are completely identical and the length is the same, it is considered a duplicate call to the same drawing path. Subsequently, the system assigns a unique number to each path item that appears for the first time, starting from 1 and incrementing the number. The numbering method is as follows: if the current path does not exist in the numbering registration table, an integer equal to the current maximum number plus 1 is assigned as the path's number. For example, the path "D1 Plan View" is numbered 1 when it first appears, and reuses number 1 when it appears again. If a new path "D2 Section View" appears later, it is numbered 2, and so on. Finally, the numbering sequence is output according to the path calling order. For example, if the consecutive access order is "D1 Plan View", "D2 Section View", "D1 Plan View", "D3 Construction View", then the numbering sequence is 1, 2, 1, 3. This numbering sequence is recorded by the system as a repeating path identification sequence, providing a path-dimensional behavior chain reference in subsequent behavior organization and judgment. The entire numbering process is unique within the same task and is not reset. Even if the path switches multiple times in the task segment, the number will not be updated to ensure that the numbering sequence has accurate tracking ability in subsequent analysis.

[0068] The behavior splicing submodule splices the operation behaviors into a structural chain according to the path number sequence based on the repeating path identifier sequence, filters the connection points between the differentiated task numbers, extracts the corresponding behavior fragments, and obtains the structured behavior sequence.

[0069] The system sequentially reads the operation segments corresponding to each number, based on the number sequence. Each operation segment consists of a set of operations performed by the user within a specific path file, including basic actions such as drawing graphics, calling commands, and interface operations. The system arranges the operation segments sequentially using the path number as an index and adds logical connections between the operation data, constructing a path number-driven structural chain. For example, if the number sequence is 1, 2, 1, 3, the structural chain would be composed of "path 1 → path 2 → path 1 → path 3". The system connects the operation segments corresponding to each number and records the connection positions. The system then filters the connection points in the structural chain, determining whether the path numbers before and after the connection are inconsistent. If the connection point is a cross-path connection such as between path 1 and path 2, path 2 and path 1, or path 1 and path 3, it is marked as a differentiated task connection point. The filtering logic uses an inequality judgment method; if the current number is different from the previous number, it is considered a valid connection point. The system then uses these connection points as boundary points to extract the complete behavior segment covered by each connection point from the source data. It determines whether the behavior segment meets the continuity condition, i.e., the time interval between operations must not exceed a preset threshold. The system sets this threshold to 300 seconds, which is derived from the average interruption time statistics during the design process. The system collected the first operation time after path switching from 120 designers in a real work environment and calculated the average value to be 273 seconds. The system then adjusted the threshold upward to 300 seconds as the standard. If the time interval between the operation segments on both sides of the connection point is within 300 seconds, the behavior is considered continuous and extracted completely. If it exceeds 300 seconds, the behavior segment of that connection point is removed and no structural chain is constructed. Finally, the system outputs a structural chain assembled in the order of path number. Each chain contains fields such as path number, start and end time, operation set, connection position, and whether it is a differential connection, forming the basic dataset of structured behavior sequences.

[0070] The trajectory extraction submodule calls the structured behavior sequence, and based on the path field and task number, excludes behavior segments that do not belong to the task path to obtain the design task trajectory segments;

[0071] After reading each behavior segment's data, the system first retrieves the path number of the current operation from its path field and simultaneously reads its task number field. Then, the system matches and judges the behavior segment's path number against a list of path numbers called by the task registered in the task record. This list is generated by the path recognition module during task identification and records all path numbers actually called within the current task. For example, if a task's path number set is {2, 3, 4}, the system compares the behavior segment's path number with this set during trajectory extraction. If the number is in the set, it is retained; otherwise, it is excluded. This judgment logic uses an inclusion-based method to determine if the path number exists in the set. If the path number is 1 and there is no path number 1 in the task path set, it is determined to be a behavior that does not belong to the current task, and a removal operation is performed. In addition, the system also judges the task number field; if the behavior segment's task... If the number does not match the current task number, it will be excluded even if the path number matches. For example, if the task number of behavior segment is A, but the current task number is B, then the behavior segment will be excluded to ensure the consistency of the trajectory extraction task. Under the above double filtering, the system will finally retain all behavior segments that meet the condition that the path number and task number are consistent, and output them in chronological order to form task behavior trajectory fragments. The fragments record fields such as path number, operation content, operation start and end time, and user identifier. In the actual example, if the user accesses path numbers 2, 3, and 4 under task number T1, the behavior segment will record the drawing operation of path 3, the parameter adjustment operation of path 2, and the layer management operation of path 4 in sequence. The system will assemble these three operations into the design task trajectory fragment of task T1 as the basic data for subsequent design behavior visualization and behavior chain analysis.

[0072] Specifically, such as Figure 2 , 5 As shown, the project identifier collection module includes:

[0073] The task feedback receiving submodule, based on the design task trajectory fragment, calls the design server interface to receive task feedback information from the source path, extracts the path field and associated task content from the feedback data, judges the path and filters out fields with no response, and obtains the task path feedback set.

[0074] First, the system reads the path number, task number, and start and end times of each operation from the trajectory segment as parameters to construct the feedback request body. When the request is initiated, the system organizes the path field, task ID, and timestamp range in a JSON structure and accesses the task feedback database via an interface. The system receives the feedback dataset in the interface response. Each feedback record contains the following fields: path string, task number, feedback type, processing status, feedback time, and specific content. The system processes the feedback data sequentially. First, it extracts the path field and compares it with the path list in the original trajectory segment to confirm that it belongs to the operation path within the trajectory task. Then, it checks whether the processing status field of the feedback record is "processed," "read," or "valid." If the field is "no response," "no feedback," or empty, the system determines that the feedback is invalid and excludes its corresponding path from the valid set. The operation is executed through logical comparison. During rejection, the original path and the reason for rejection are recorded to form an error log. Then, a path standardization operation is performed on the remaining paths, that is, redundant spaces, extension differences, and capitalization differences are removed from the paths to ensure that the same drawing path is not recognized as multiple paths due to format issues. In the actual processing example, the system received 12 feedback data, of which 8 were in the status of "processed" or "read", 3 were in the status of "no response", and 1 feedback content was empty. Finally, the system judged the feedback records corresponding to the paths numbered 2, 5, and 7 as invalid feedback and rejected them. The remaining paths were rearranged in chronological order and summarized into a task path feedback set. The feedback set records the following fields: path number, task ID, feedback time, processing status, feedback summary, feedback content tag, etc., providing a basis for mapping paths and feedback content for subsequent project number parsing.

[0075] The project number recognition submodule calls the task path feedback set, extracts the project number field embedded in the drawing path, connects the project information source data, locates the project number position based on the field structure, completes field comparison, and obtains the project number list;

[0076] Each feedback path is parsed individually. String splitting is performed on the feedback path field. Based on the path naming convention, the embedded segment for the project number is identified. The system typically sets the starting position for project number extraction to the second or third segment of the path string, using "-" or "_" as field separators. For example, in the path string "Scheme Design-3205-Drawing 1", the system identifies the second segment "3205" as a candidate field for the number. This field is then compared precisely with the project master data table within the system, using the project number column as the comparison field. If the extracted number field matches any number in the project master data table exactly, the system records this number as a valid identification number and adds it to the project number list. If the number does not match the data table, or if there are abnormal field lengths (e.g., less than 4 digits or more than 8 digits), the system marks the path as "number". "Parsing failure" entries are not included in the project number list. During path parsing, a number recognition threshold is set: the positional offset of the number field must not exceed the first four segments of the path structure. If the number field appears in the fifth segment or later, it is marked as structural out-of-bounds and removed. This threshold is based on statistics from actual project path naming conventions, where 90% of valid number fields are located between the second and fourth segments. The system accordingly sets the field position threshold at the first four segments. In one actual recognition task, 10 path feedback records were processed. The successfully recognized numbers were "2103", "4211", and "3817". The number field "0812" in the path "Drawing_D-0812" was excluded because it was located in the fifth segment. The final generated project number list consisted of 2103, 4211, and 3817, each of which was matched with the project master data table and confirmed as valid.

[0077] The attribution content determination submodule compares the project type value corresponding to the number with the design stage value based on the project number list, and combines the behavior trigger time in the drawing annotation content with the comparison of the timestamp range in the field to classify and determine the attribution content of the professional task;

[0078] Based on each project number in the list, the system first reads the corresponding project type and design stage fields from the project master data table. For example, project number 2103 corresponds to the "Residential" type field and the "Preliminary Design" stage field. Then, the system calls the drawing annotation dataset, extracts the trigger time field and related task number field from the annotation behavior, and performs grouping and mapping by project number. The system determines whether an annotation behavior should be assigned to a corresponding project number, requiring three conditions to be met simultaneously: First, the task number of the behavior must have a clear matching relationship with the project number; second, the annotation time must fall within the allowed time range; and third, the project type field and design stage field must meet valid matching rules. Matching rules include identical task type values, consistent stage values, or adjacent stages. For example, the "Preliminary Design" stage and the "Preliminary Design" stage can be considered adjacent stages and are allowed to be assigned. However, if it is between "Construction Drawings" and "Schematic Design," they are considered different stages and are not categorized. Regarding time judgment, the system sets the threshold for timestamp comparison to ±1 day. That is, if the task record time is 08:00, the annotation trigger time must be between 08:00 of the previous day and 08:00 of the next day. This threshold is set based on the analysis of peak time periods in the feedback set of design projects. The peaks are mainly distributed within 24 hours before and after the task processing node, which is in line with the rhythm of engineering collaboration. If the annotation behavior time exceeds this range, it will be excluded even if the type and stage match. In one processing task, number 2103 corresponds to 4 annotation behaviors, of which 3 times fall between 08:00 and 07:30 of the next day and the stage matches "preliminary expansion" and the type matches "residential", which are judged as valid attribution behaviors. Number 4211 is excluded because one of its annotation behaviors is at 10:45 of the next day. Number 3817 has no matching stage field behavior. Finally, the system outputs a total of 7 valid attribution behavior entries, constructing a professional task attribution content structure set.

[0079] Specifically, such as Figure 2 , 6 As shown, the personnel time consumption verification module includes:

[0080] The behavior writing submodule, based on the professional task attribution content, writes the behavior records of the responsible person for each task into the behavior database, extracts the start time and end time fields of each attribution behavior, generates time period records, and obtains the task behavior time period set;

[0081] First, the system reads key information from the assigned data, including the responsible person field, task number field, behavior type field, start time, and end time fields. Before writing, the system verifies that the behavior time field format conforms to the "hour:minute:second" structure. If the field is missing or the format is abnormal, the record is not entered and is marked as "time field abnormal" in the log table. For other records, a new behavior entry is created in the behavior database. The system uses the assigned task number as the primary key index and writes it to the user behavior record table. At the same time, a partition is created under the responsible person dimension to ensure that the behavior records of each designer are clearly assigned. Then, the start time and end time fields are extracted from the assigned behavior and uniformly converted into a timestamp format for subsequent calculations. For example, "08:15:00" is converted to a timestamp of 29500 (with the starting point of the current day at 00:00 in seconds). The system calculates the duration of a single behavior segment based on the start and end times, stores it in seconds, and records three fields in the dataset: "behavior start time", "behavior end time", and "duration". These fields serve as the core structure for building the time period set. In a typical processing task, a total of 36 behaviors were processed. Two records were removed due to missing end time fields, resulting in 34 successfully written behavior records. The generated task behavior time period set is categorized according to the responsible person, ultimately obtaining a time period list corresponding to 6 designers. Each time period entry clearly identifies its responsible person, task number, operation start and end times, and behavior duration information.

[0082] The time calculation submodule calls the task behavior time period set, merges the time periods that overlap and are consecutive in the differentiated attribution behaviors of the same person, retains the start and end times of the merged segment, and generates the cumulative behavior time value;

[0083] Initial grouping is performed based on the responsible person field to ensure that the processing time of different personnel does not interfere with each other. Within each group, the system sorts the data in ascending order by the start time field. Then, the sorted time segment sequences are processed segment by segment for cross-checking and continuity judgment. The cross-checking criterion is: if the start time of the current time segment is less than the end time of the previous time segment, and the end time is later than the end time of the previous time segment, the two segments are considered overlapping and are merged. The continuity judgment criterion is: if the interval between the start time of the current time segment and the end time of the previous segment does not exceed 60 seconds, it is considered a continuous segment and is also merged. This 60-second time interval threshold is a standard set by the system based on statistical analysis of standard operational behavior intervals in the industry. After analyzing 1800 real operational behavior data points, it was found that over 98% of task behavior intervals were less than or equal to 1 minute; therefore, 60 seconds was used as the judgment threshold. When performing a merge operation, the system retains the earliest start time and the latest end time after the merge, calculates the duration of the merged behavior within this range, and records it in the newly generated merged behavior entry. After merging, the system iterates through the next time period again, repeating the above judgment logic until all time periods of the current responsible person have been traversed. In one sample, the responsible person had a total of 7 time records. Among them, the second segment 08:45:00–09:10:00 and the third segment 09:10:30–09:40:00 were 30 seconds apart, which met the continuous condition and were merged into 08:45:00–09:40:00. Finally, the 7 original time segments of the responsible person were merged into 4 continuous time periods. The cumulative behavior time value is the sum of the durations of all segments after merging, and is recorded uniformly in minutes. The record also includes a "merging times" field to count the frequency of merging in the later stages.

[0084] The duration verification submodule compares the cumulative value of behavior time with the time period field in the user's work hour record data to see if there is an overlap relationship between the start and end time intervals of the two datasets, and filters out fully verifiable time periods to obtain the project work duration distribution.

[0085] The system uses user work time records as a comparison. Each entry in these records includes the responsible person ID, work start time, work end time, project number, and attendance tag. The system performs a join operation based on the responsible person field. The core of the comparison is whether the two time period datasets have a complete overlap relationship. The logic for determining the overlap relationship is as follows: if the start time of a behavior time period is greater than or equal to the start time of a certain work period, and the end time of the behavior is less than or equal to the end time of the work period, then the behavior time period is considered to be completely covered, which is a valid match. If there is only partial overlap or there is an extension of the time period before or after, it is considered an incomplete verification and is discarded. This judgment requires time accuracy at the minute level, that is, the maximum allowable error is ±59 seconds. If it exceeds 1 minute, it is considered an offset segment and is not confirmed. This tolerance setting is based on the allowable time fluctuation range when the system compares attendance records. Analysis revealed that designers manually clocked in for 20-40 seconds. For error, the system ultimately sets an accuracy threshold of 60 seconds for a match; otherwise, it is not counted as valid time. In one comparison, the responsible person has a total of 3 cumulative behavior time periods: 08:05–09:00, 09:10–10:15, and 10:30–11:20. Their work time record is 08:00–12:00. Therefore, all behavior segments fall within this work time period and are marked as "completely covered." The system records the verification status as "confirmable," and the cumulative working time is 195 minutes. If another responsible person's behavior segment is 13:00–13:30, while their working time period for the day is 13:10–17:00, then because the first part of the behavior segment is not covered for more than 10 minutes, this segment is marked as "partially covered" and removed. Finally, the system generates a project working time distribution result table, which records the effective working time, the number of successfully verified segments, the number of unverified segments, and the project number of each responsible person.

[0086] Specifically, such as Figure 2 , 7 As shown, the error offset tracking module includes:

[0087] The time difference extraction submodule extracts the task time period recorded in the BI report and the user-manually declared time period based on the project work duration distribution. It compares the start and end values ​​of the two time fields according to the task number, calculates the difference field, and then classifies the difference field according to the task sequence number to obtain the task time difference sequence.

[0088] First, the system retrieves the manual reporting time periods for each task from historical reports in the BI system. Simultaneously, it extracts the system-recorded time periods for actual task execution from the behavior database. Both datasets are categorized and organized by task number. The system compares the start and end time fields of each task number item with the two time period datasets. The comparison rule is as follows: if the system-recorded start time is earlier than the manual reporting time, the difference before calculation is the time difference between the two; if the system-recorded end time is later than the manual reporting end time, the difference after calculation is the corresponding end time difference. Both differences are calculated in minutes and recorded in the difference field. If the time periods are completely identical, the difference is recorded as 0. Subsequently, this difference field is bound to the task number to construct a difference record item. During actual processing, the system discovered... Some tasks involve reverse time reporting, meaning the user manually reports a time period earlier than the system's recorded time period. In such cases, the system also records the difference but adds a "direction abnormality" flag. In the example, the system recorded the time period for task T001 as 08:00–10:00, while the user manually reported it as 08:15–09:45. The system calculates the difference as 15 minutes before and 15 minutes after, for a total difference of 30 minutes. The difference item is recorded as "T001_30". After completing the difference field construction, the system sorts all difference record items in ascending order by task number and assigns them sequential numbers for classification and statistics, ultimately forming a task time difference sequence. Each record includes fields such as task number, before difference, after difference, total difference, difference direction, and difference sequence number.

[0089] The blank screening submodule calls the task time difference sequence, compares it with the operation time period of the corresponding task in the behavior database, detects blank time segments and operation interruption records within the time period, screens behavior points that are not bound to the declaration record within the time period, and obtains a set of non-declaration behavior segments.

[0090] The system reads the task number corresponding to each difference record item by item and retrieves the set of operation time periods for that task from the behavior database. It constructs a time interval sequence for all operation records based on start and end times. Within each difference time interval, the system performs a blank segment detection operation. This is done by iterating through the set of task operation behaviors, comparing the start and end times of each operation behavior with the difference time interval, and determining if there are any segments where the time period is completely uncovered by any operation behavior. If a time interval is found between two consecutive operation behaviors, and this interval is greater than the system's set operation interruption judgment threshold, then a blank segment is considered to exist. This judgment threshold is set to 120 seconds by default. This threshold is derived from the average click interval statistics of design-related task operation behaviors. According to the analysis of long-term usage data collected by the project operation team, if the user operation interval exceeds 2 minutes, it can be initially judged as non-continuous behavior or... During idle periods, the system sets the screening threshold to 120 seconds. During the actual screening process, the time difference period for task T001 is 08:00–08:15, and the operation behavior records are 08:02–08:06 and 08:08–08:10. The system then marks the three time periods of 08:00–08:02, 08:06–08:08, and 08:10–08:15 as blank segments. The system further determines whether these segments are bound to the user's manually declared data. The system matches the task number and operator field of the behavior records with the work hour declaration data. If no match is found, it is marked as a "non-declaration behavior point". Finally, the system organizes and outputs all non-declaration bound blank behavior segments into a non-declaration behavior segment set. The recorded information includes task number, start and end time of time segment, segment length, existence of behavior data, and whether it is associated with declaration records.

[0091] The offset rate identification submodule calculates the time length of each segment based on the set of non-declared behavior segments and compares it with the corresponding item in the task time difference sequence. Records with offset exceeding the threshold of the declared segment length are marked as deviated segments, and the task execution time offset rate is obtained.

[0092] For each time period in the set of non-reported behavior segments, the system sequentially calculates its duration in minutes and associates it with the corresponding total difference field in the task time difference sequence by task number. Then, it calculates the ratio of the duration of each non-reported behavior segment to the total difference duration of that task. The calculation method is to divide the current segment length by the total difference duration to obtain the single segment offset ratio, and then sum the offset ratios of all segments to obtain the total offset percentage. The system then judges the offset ratio. If the ratio is greater than the offset judgment threshold, the behavior segment is marked as a deviation segment. This offset judgment threshold is set to 0.5, based on the company's operational management system, which clearly states that if more than 50% of the task time periods contain unreported behavior, it is considered a deviation. This value is fixed. The system sets a fixed policy value and does not accept user-defined values. For example, task T001 has a total duration of 30 minutes and contains three non-reported behavior segments with lengths of 4 minutes, 5 minutes, and 9 minutes, respectively. The system calculates the offset rates as 0.133, 0.167, and 0.3, respectively. Segment 3 is not marked separately because its offset rate of 0.3 is less than 0.5. However, the sum of the three is 0.6, which exceeds the threshold. The system marks task T001 as "deviation exists" and segments 3 as "cumulative deviation segment". The system finally outputs a list of task execution time offset rates, where each record includes the task number, number of offset segments, cumulative offset minutes, offset rate, whether it exceeds the threshold, and whether it is a serious deviation segment, for subsequent quality checks and attendance audits.

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

Claims

1. A project man-hour statistical analysis system for architectural design application behavior monitoring and algorithm analysis, characterized in that, The system comprises: The page behavior recording module obtains the foreground operation behavior of the user during the use of the design software, records the software starting action, extracts the software name and task window identifier, identifies the window switching event and corresponds to the operation time sequence, segments and time line serializes the task operation, extracts the continuous design operation paragraph; The task trajectory generation module receives the monitoring plug-in data based on the continuous design operation paragraph, identifies the drawing path and task calling content, splices the repeated calling path file, peels off the behavior segment irrelevant to the task, and generates the design task trajectory segment; The project identifier collection module calls the design server interface through the design task trajectory segment, extracts the project number in the drawing path, connects the project information source, compares the project type and design stage, combines the behavior time and drawing annotation content to complete the classification, and obtains the professional task attribution content; The personnel time consumption verification module writes the responsible person behavior into the database according to the professional task attribution content, extracts the continuous time value of each task and combines and calculates, compares with the user work time record, identifies the verifiable time section, and obtains the project work time length distribution.

2. The project man-hour statistical analysis system for building design application behavior monitoring and algorithm analysis according to claim 1, characterized in that: The continuous design operation paragraph comprises a design software name, a task window identifier, and a window switching time sequence, the design task trajectory segment comprises a drawing file path, a task calling sequence, and a irrelevant behavior peeling result, the professional task attribution content comprises a project number field, a project type identifier, a design stage classification, and drawing annotation information, and the project work time length distribution comprises attribution task time, combined task period, and work time comparison data.

3. The project man-hour statistical analysis system for building design application behavior monitoring and algorithm analysis according to claim 1, characterized in that: The behavior segment irrelevant to the task refers to non-design operation record without project drawing editing, viewing, and task calling path; The verifiable time section refers to the continuous working time section that the behavior record is consistent with the user work time declaration and can be cross-verified through operation data.

4. The project man-hour statistical analysis system for architectural design application behavior monitoring and algorithm analysis according to claim 1, characterized in that, The page behavior recording module comprises: The software identification submodule obtains the operation record of the user starting the design software, extracts the process starting event, filters the design software name, splices the task window identifier, and generates the software task identification tag; The task switching submodule calls the timestamp and foreground window switching record based on the software task identification tag, matches the window handle and software identifier, extracts the switching time and compares with the software use time sequence, and generates the window task switching section information; The operation sequence construction submodule combines the task segments in time sequence according to the window task switching section information, calculates the time difference between adjacent segments, judges whether it is lower than the minimum interval threshold, merges into a continuous operation segment, and generates the continuous design operation paragraph.

5. The project man-hour statistical analysis system for architectural design application behavior monitoring and algorithm analysis according to claim 1, characterized in that, The task trajectory generation module comprises: The path identification submodule calls the data sent by the user monitoring plug-in based on the continuous design operation paragraph, extracts the drawing path and task calling information, identifies the repeated path and numbers, records the number sequence in the calling order, and generates the repeated path identifier sequence; The behavior splicing submodule splices the operation behavior into a structure chain in the path number order according to the repeated path identifier sequence, filters the connection points between the differentiated task numbers, extracts the corresponding behavior segment, and obtains the structured behavior sequence; The trajectory extraction submodule calls the structured behavior sequence, excludes behavior segments not belonging to the task path according to the path field and the task number, and obtains a design task trajectory segment.

6. The project man-hour statistical analysis system for architectural design application behavior monitoring and algorithm analysis according to claim 1, characterized in that, The project identifier collection module comprises: The task feedback receiving submodule receives task feedback information in the source path based on the design task trajectory segment, calls a design server interface, extracts a path field and associated task content in feedback data, judges the path, and screens out non-response fields to obtain a task path feedback set; The project number identification submodule calls the task path feedback set, extracts a project number field embedded in the path, connects project information source data, positions the project number according to the field structure, and completes field comparison to obtain a project number list; The attribution content determination submodule compares the project type value corresponding to the number with the design stage value according to the project number list, and classifies and judges the time stamp range in the field according to the behavior triggering time in the drawing annotation content to obtain professional task attribution content.

7. The project man-hour statistical analysis system for building design application behavior monitoring and algorithm analysis according to claim 1, characterized in that, The personnel time consumption verification module comprises: The behavior writing submodule writes the responsible person behavior record corresponding to each task into the behavior database based on the professional task attribution content, extracts the start time and end time fields of each attribution behavior, and generates a time period record to obtain a task behavior time period set; The time calculation submodule calls the task behavior time period set, combines the time periods in which the same responsible person exists in different attribution behaviors, retains the start and end times of the combined period, and generates a behavior time cumulative value; The duration verification submodule compares the time period field in the user work time record data according to the behavior time cumulative value, compares whether there is an overlapping relationship between the start and end intervals in the two data sets, and screens the completely verifiable time period to obtain a project work duration distribution.

8. The project man-hour statistical analysis system for building design application behavior monitoring and algorithm analysis according to claim 1, characterized in that, The system further comprises: The error offset tracking module compares the time period of the report and the manual declaration, extracts the start and end time difference, and classifies, cross-analyzes the blank time and the interruption record, identifies the offset record, and calculates the task execution time offset rate.

9. The project man-hour statistical analysis system for building design application behavior monitoring and algorithm analysis according to claim 8, characterized in that: The task execution time offset rate comprises a start and end time difference, a blank time segment, and an operation interruption record.

10. The project man-hour statistical analysis system for building design application behavior monitoring and algorithm analysis according to claim 8, characterized in that, The error offset tracking module comprises: The time difference extraction submodule extracts the task time period of the BI report record and the user manual declaration time period based on the project work duration distribution, compares the start and end values of the two time fields according to the task number, calculates the difference field, classifies the difference field according to the task sequence number, and obtains a task time difference sequence; The blank screening submodule calls the task time difference sequence, compares the operation time period of the corresponding task in the behavior database, detects the blank time segment and the operation interruption record in the time period, screens the behavior points without bound declaration records in the time period, and obtains a non-declaration behavior segment set; The deviation rate identification submodule calculates the time length of each segment according to the non-declaration behavior segment set, and calculates the ratio of the corresponding item in the task time difference sequence, marks the record whose deviation degree exceeds the declaration segment length threshold as a deviated paragraph, and obtains the task execution time deviation rate.

Images