A digital collaborative management system and method for the entire process of highway construction

Abstract

This invention discloses a full-process digital collaborative management system and method for highways, specifically relating to the field of highway data management technology, to address the problem of identifying anomalies in multi-role collaborative conflict identification. By constructing a task-driven graph and a multi-role scheduling model, this invention achieves dynamic linkage management of task status and role behavior throughout the entire highway design process. It extracts access behavior, task records, and data version status, calculates role collaborative offsets, identifies and controls write permissions for task conflict nodes, constructs priority factors based on stage indexes, data dependencies, and time urgency, generates scores using a nonlinear model, drives the automatic reconstruction of scheduling order and data ownership, synchronously updates role permissions and collaborative views, forming a closed loop of data access control based on task status evolution, and constructs a three-dimensional responsibility chain through full-process behavior tracking, achieving traceable management of collaborative operations and improving the intelligence of collaborative scheduling and the accuracy of data management.

Description

Technical Field

[0001] This invention relates to the field of highway data management technology, and more specifically, to a full-process digital collaborative management system and method for highways. Background Technology

[0002] Currently, the highway engineering design field is accelerating its digital and collaborative transformation, with the design process increasingly exhibiting complex characteristics of multiple roles, disciplines, and parallel tasks. With the widespread application of cloud computing, BIM, CIM, and distributed deployment technologies, design platforms are gradually evolving from local area networks (LANs) to enterprise private clouds or hybrid cloud architectures. This allows internal designers, on-site representatives, external experts, and collaborating units to access resources remotely and collaborate on tasks via the internet, promoting the implementation of the concept of end-to-end digital collaboration. Against this backdrop, design platforms not only need to support multi-terminal access and remote task processing, but also need to provide effective management of data access and secure isolation between tasks in situations involving concurrent tasks, interdisciplinary collaboration, and dynamic process changes.

[0003] Existing technologies have shortcomings: When facing multi-role access conflicts in remote collaboration scenarios, they lack dynamic response and behavior recognition mechanisms, relying primarily on permission configuration and preset access boundaries, which struggles to adapt to permission boundary drift caused by real-time changes in task status. Common technical challenges in practice include: when multiple users with different roles perform viewing, editing, or review operations on the same design data on the platform, it's impossible to determine the appropriateness of the operation based on the current task context; especially when multiple remote users simultaneously access historical drawings, cross-stage documents, or data being modified, the platform's lack of access conflict recognition and task mutual exclusion control mechanisms leads to serious problems such as version overwriting, data distortion, and broken chains of responsibility. These system gray areas—where permissions are reasonable but actions are inappropriate, and roles are legitimate but tasks conflict—severely impact the security, controllability, and task collaboration of the collaborative platform in remote environments. Summary of the Invention

[0004] In order to overcome the above-mentioned defects of the prior art, the present invention provides a full-process digital collaborative management system and method for highways, so as to solve the problem of abnormal identification of multi-role collaborative conflicts in the above-mentioned background art.

[0005] To achieve the above objectives, the present invention provides the following technical solution:

[0006] A digital collaborative management method for the entire process of highway construction includes the following steps:

[0007] Based on the phased process, professional structure and time decomposition information of highway engineering design tasks, a task-driven graph is constructed, and a multi-role task scheduling model is generated according to the node status and role correspondence in the task-driven graph.

[0008] By combining user access behavior, task execution records, and the real-time data version status of the design platform, the state difference between the access operation and the current task node is extracted, and a role collaboration offset index is constructed.

[0009] When the role collaboration offset index exceeds the set tolerance range, the task mutual exclusion control mechanism is automatically triggered, the write permissions of conflicting data nodes are suspended, and a collaboration conflict prompt is generated for all involved roles.

[0010] Based on the phase relationships, data dependency paths, and submission sequences involved in the conflicting task nodes, the execution priority of the conflicting tasks is evaluated, and the task scheduling order and data ownership are automatically reconstructed based on the evaluation results.

[0011] The scheduling results are updated to the task-driven graph, and the platform synchronously refreshes the current permissions, collaboration view and operable data range of each role, forming a data access control closed loop based on the dynamic evolution of task status;

[0012] The system tracks the entire process of task conflict identification, collaborative scheduling, permission reconstruction, and data synchronization, constructs a three-dimensional responsibility chain structure of roles, data, and tasks, and manages the collaborative behavior throughout the entire process.

[0013] In a preferred embodiment, based on the phased process, professional structure, and time decomposition information of highway engineering design tasks, a task-driven graph is constructed, and a multi-role task scheduling model is generated according to the correspondence between node status and role in the task-driven graph. The specific process is as follows:

[0014] Extract the phase division information, professional participation relationships and corresponding time plans of highway engineering design projects, and construct a set of task nodes according to phase nodes, professional intersections and time sequence.

[0015] Set a node status label for each task node, including stage type, execution status, submission deadline, and associated data identifier;

[0016] Based on the status label of each task node and its corresponding design specialty, role category, and responsibility boundaries, a role mapping table is generated, and a mapping relationship is established between each role and its corresponding task node.

[0017] Based on the node set and role mapping table, a task-driven graph is constructed, and the stage dependencies and data interaction paths between task nodes are set in the task-driven graph.

[0018] A multi-role task scheduling model is generated based on the state sequence and role relationship of each node in the task-driven graph.

[0019] In a preferred embodiment, the multi-role task scheduling model is used to determine the data access timing relationship and role participation order between different task nodes, and after the conflict task is identified, it serves as the basis for scheduling priority evaluation and access permission reconstruction, controlling the write permissions and submission windows of each role on the data node.

[0020] In a preferred embodiment, by combining user access behavior, task execution records, and the real-time data version status of the design platform, the state difference between the access operation and the current task node is extracted, and a role collaboration offset index is constructed. The specific process is as follows:

[0021] Collect current user access behavior data, including login time, operating terminal, access path, data operation type and access target identifier;

[0022] Extract the user's historical task execution records, including completed task nodes, operation timestamps, role identity, and submitted data version number;

[0023] Obtain the latest version status information of the corresponding data node in the design platform, including the current version number, lock status, data ownership role, and recent operation records;

[0024] Match the data node currently accessed by the user with the corresponding task node in its task record, and calculate the degree of difference in state in terms of task stage, data version and time sequence;

[0025] Based on state differences and access behavior characteristics, a role collaboration offset index is constructed. The role collaboration offset index is used to measure the degree of offset between the current user's operation behavior and its task boundary.

[0026] In a preferred embodiment, a role collaboration offset index is constructed based on state difference and access behavior characteristics, as follows:

[0027] The data node currently accessed by the user is compared with its bound task node, and the state difference is calculated respectively. The state difference includes task stage offset value, data version offset value and time sequence offset value.

[0028] The task stage offset value is determined by comparing the stage difference level between the design stage of the currently accessed node and the node stage in the task record, and is quantitatively mapped using a preset stage level table.

[0029] The data version offset value is calculated by comparing the version identifier of the accessed data with the version identifier of the corresponding data in the task record to perform a sequence difference. If the version numbers are the same, it is recorded as zero. If the version numbers are different, the offset level is set according to the order of magnitude of the difference and a linear increment rule.

[0030] The time sequence offset value is calculated based on the time difference between the access time and the task binding time. A sliding time window is used to set the time tolerance range. If the access time exceeds the task end time and the historical task node is still accessed, it is set as a high-risk reverse order offset.

[0031] The task phase offset, data version offset, and time sequence offset are input into the rule-based comprehensive scoring function, and after normalization, a weighted summation is performed. The output result is used as the role collaboration offset index.

[0032] In a preferred embodiment, when the role collaboration offset index exceeds the set tolerance range, the task mutual exclusion control mechanism is automatically triggered, suspending the write permissions of the conflicting data nodes and generating collaboration conflict prompts to the involved roles. The specific process is as follows:

[0033] Identify the data node currently accessed by the user and retrieve the set of all associated nodes in the task-driven graph that have a dependency or version reference relationship with that node;

[0034] Find other user roles in the set of associated nodes that have overlapping task boundaries with the current access behavior, and construct an access conflict role group;

[0035] Perform permission adjustment operations on each user in the conflict role group, suspend write permissions to the current data node and directly related nodes, and retain read-only permissions for comparison and reference.

[0036] Generate a conflict alert message on the platform collaboration interface and push a collaboration anomaly notification to the conflict role group, indicating that the current data node is in a mutual exclusion control state.

[0037] The system synchronizes the mutual exclusion control status of tasks, marks the current node as a conflict-frozen state, and sets the conditions for releasing the mutual exclusion.

[0038] In a preferred embodiment, the priority of conflicting tasks is evaluated based on the stage relationships, data dependency paths, and submission sequences involved in the conflicting task nodes, and the task scheduling order and data ownership are automatically reconstructed based on the evaluation results. The specific steps are as follows:

[0039] Extract the task number corresponding to the data node that is currently in a mutually exclusive state, and retrieve the task path in the task-driven graph that has a stage relationship with the task. Obtain the stage position index value and construct the stage priority factor based on the stage position index value.

[0040] Analyze the data dependency paths between the task and the conflicting task, identify the position in the data link, and construct a data dependency urgency factor;

[0041] Perform time-series analysis on the submission behavior of conflicting tasks, extract submission time, modification frequency and current progress status, and calculate time priority factor;

[0042] The phase priority factor, data dependency urgency factor and time priority factor are nonlinearly combined and mapped to generate a comprehensive priority score for conflict tasks.

[0043] Tasks are sorted based on their conflict priority scores, and the task scheduling order and data ownership are automatically reconstructed accordingly, updating the scheduling paths and node status in the task-driven graph.

[0044] In a preferred embodiment, the stage priority factor, data dependency urgency factor, and time priority factor are non-linearly combined and mapped to generate a comprehensive priority score for conflicting tasks. The specific steps are as follows:

[0045] Extract the design phase number to which the conflicting task belongs, and use the phase number as the base of the exponential function to generate the phase priority factor;

[0046] Based on the data path depth and the number of references that the conflict task depends on, the square of the path depth is calculated as a measure of dependency strength. The logarithm of the square value divided by the number of references is used as the data dependency urgency factor.

[0047] Calculate the time difference between the current time and the recommended completion time of the conflicting task, and substitute the difference as an independent variable into the inverse proportional function. The resulting value is used as the time priority factor.

[0048] The phase priority factor, data dependency urgency factor, and time priority factor are taken as inputs and substituted into a pre-defined three-layer activation function combination model to output a comprehensive priority score for conflicting tasks, which is then used to sort and generate a new round of scheduling order.

[0049] In a preferred embodiment, the entire process of task conflict identification, collaborative scheduling, permission refactoring, and data synchronization is traced, a three-dimensional responsibility chain structure of roles, data, and tasks is constructed, and the collaborative behavior throughout the entire process is traceable and managed. The specific steps are as follows:

[0050] Obtain operation behavior logs generated by the platform during conflict identification, permission reconstruction and task scheduling, including execution metadata such as user identity information, operation timestamp, task node identifier, operation type and scope of impact;

[0051] The acquired behavior logs are categorized according to task nodes, and a triplet mapping relationship is established based on the binding relationship between roles and tasks, data access paths, and submission records to construct a three-dimensional responsibility chain structure of roles, data, and tasks.

[0052] Each operation record is uniquely identified and encoded, and the operation action is bound to its corresponding task version and data snapshot in the platform log structure;

[0053] The platform task view integrates a responsibility chain traceability interface. When data conflicts, misoperations, or version rollback requests occur, the responsibility chain path of the corresponding node is invoked to display the operation evolution path and responsible role of the task node.

[0054] A full-process digital collaborative management system for highways, used to implement the aforementioned full-process digital collaborative management method for highways, includes:

[0055] The highway phase task allocation module constructs a task-driven graph based on the phase process, professional structure, and time decomposition information of highway engineering design tasks, and generates a multi-role task scheduling model according to the node status and role correspondence in the task-driven graph.

[0056] The collaborative analysis module is used to combine user access behavior, task execution records and the real-time data version status of the design platform to extract the state difference between the access operation and the current task node, and construct the role collaboration offset index.

[0057] The conflict detection module is used to automatically trigger the task mutual exclusion control mechanism when the role collaboration offset index exceeds the set tolerance range, suspend the write permissions of the conflicting data nodes, and generate collaboration conflict prompts to the relevant roles.

[0058] The data evaluation module is used to evaluate the priority of conflicting tasks based on the stage relationships, data dependency paths and submission times of the conflicting task nodes, and automatically reconstruct the task scheduling order and data ownership based on the evaluation results.

[0059] The data access control module is used to update the scheduling results to the task-driven graph. The platform synchronously refreshes the current permissions, collaborative view and operable data range of each role, forming a data access control closed loop based on the dynamic evolution of task status.

[0060] The traceability management module leaves a record of the entire process of task conflict identification, collaborative scheduling, permission reconstruction, and data synchronization, constructs a three-dimensional responsibility chain structure of roles, data, and tasks, and performs traceability management of the entire collaborative process.

[0061] The technical effects and advantages of this invention are as follows:

[0062] This invention achieves task status awareness and role collaborative management throughout the entire highway engineering design process by constructing a task-driven graph and a multi-role scheduling model. Based on ternary heterogeneous data of user access behavior, task records, and platform version status, it extracts status differences and calculates role collaborative offsets, identifies task boundary overlaps and collaborative offset risks among multiple roles, and automatically triggers a mutual exclusion control mechanism to effectively block unauthorized write operations to conflicting data nodes. After conflict identification, it constructs phase priority factors, data dependency urgency factors, and time priority factors, and generates a comprehensive priority score for conflicting tasks through a nonlinear combination mapping method. The score results drive scheduling reconstruction and data ownership adjustment, forming a dynamic collaborative scheduling strategy with task-driven attributes.

[0063] A closed-loop data access control mechanism is proposed under the task state evolution. The platform automatically refreshes role permissions, collaborative views, and data operation scope based on the latest scheduling results, realizing real-time linkage between role behavior and task status. At the same time, the entire process of conflict identification, permission adjustment, and data synchronization is recorded in a structured manner, constructing a three-dimensional responsibility chain structure of roles, tasks, and data. This supports complete traceability and responsibility positioning of historical collaborative behaviors, effectively addressing data conflict issues under multi-disciplinary and multi-stage parallel operation, significantly improving the behavioral standardization and data consistency of design collaboration, and enhancing the intelligence and controllability of digital management of the entire engineering process. Attached Figure Description

[0064] Figure 1 This is a flowchart of a full-process digital collaborative management method for highways according to the present invention.

[0065] Figure 2 This is a schematic diagram of the structure of a full-process digital collaborative management system for highways according to the present invention. Detailed Implementation

[0066] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0067] Example 1: As Figure 1 As shown, a full-process digital collaborative management method for highways includes the following steps:

[0068] Based on the phased process, professional structure and time decomposition information of highway engineering design tasks, a task-driven graph is constructed, and a multi-role task scheduling model is generated according to the node status and role correspondence in the task-driven graph.

[0069] By combining user access behavior, task execution records, and the real-time data version status of the design platform, the state difference between the access operation and the current task node is extracted, and a role collaboration offset index is constructed.

[0070] When the role collaboration offset index exceeds the set tolerance range, the task mutual exclusion control mechanism is automatically triggered, the write permissions of conflicting data nodes are suspended, and a collaboration conflict prompt is generated for all involved roles.

[0071] Based on the phase relationships, data dependency paths, and submission sequences involved in the conflicting task nodes, the execution priority of the conflicting tasks is evaluated, and the task scheduling order and data ownership are automatically reconstructed based on the evaluation results.

[0072] The scheduling results are updated to the task-driven graph, and the platform synchronously refreshes the current permissions, collaboration view and operable data range of each role, forming a data access control closed loop based on the dynamic evolution of task status;

[0073] The system tracks the entire process of task conflict identification, collaborative scheduling, permission reconstruction, and data synchronization, constructs a three-dimensional responsibility chain structure of roles, data, and tasks, and manages the collaborative behavior throughout the entire process.

[0074] Step 1: Based on the phased process, professional structure, and time decomposition information of highway engineering design tasks, construct a task-driven graph, and generate a multi-role task scheduling model according to the node status and role correspondence in the task-driven graph, including the following steps:

[0075] Extract the phase division information, professional participation relationships, and corresponding time plan information of the target highway engineering project. The phase division information includes the typical phases covered by the project design, such as feasibility study, preliminary design, construction drawing design, and handover design; the professional participation relationships include the professional categories involved in each design phase, such as route, bridge, tunnel, traffic, structure, and electrical; the time plan information includes the planned start and end times of each phase and key milestones.

[0076] Subsequently, a task node set is constructed by dividing the information into stages, identifying the intersections of different professions in the professional participation relationships, and determining the time sequence in the time plan information. Each task node represents a specific design task unit and is uniquely identified in the set.

[0077] For each task node, a node status label is set. The node status label includes a stage type label (used to identify which design stage the task node belongs to), an execution status label (such as pending, in progress, or completed), a submission deadline label (indicating the latest submission time for this task node), and an associated data identifier (a unique number used to bind the design data file or model data involved in this task node).

[0078] Based on the task node set and status label information, a role mapping table is generated according to the professional role categories assigned to each stage of the design task and their corresponding responsibility boundaries. Role categories include, but are not limited to, design lead, professional designer, checker, and reviewer, and the corresponding responsibility boundaries are set according to project management regulations.

[0079] The above role mapping table is bound to the task node set to establish the mapping relationship between task nodes and each role, thereby determining the participation rights and responsibilities of each role in different task nodes.

[0080] Furthermore, a task-driven graph is constructed based on the task node set and role mapping relationship. The task-driven graph represents the stage dependencies and data interaction paths between tasks in a graph structure. Each node in the graph corresponds to a task node, and each edge represents the stage relationship or data reference relationship between tasks. The task-driven graph records the predecessor and successor tasks of each task node, as well as the input and output dependency paths between data, to support subsequent process collaborative control.

[0081] Finally, based on the status label sequence of each task node in the constructed task-driven graph and the corresponding role mapping relationship, a multi-role task scheduling model is generated. This multi-role task scheduling model is used to define the task participation order, data access permission control boundaries, and submission time windows of each role in the project progress process. The task scheduling model defines the following:

[0082] Data access timing: Clarify the order in which each role reads and writes design data to prevent data version confusion or duplicate submission conflicts.

[0083] Role participation order: Based on the stage dependencies between task nodes in the graph, determine the specific timing for each role to participate in the task progress, and set whether it has submission or approval permissions.

[0084] Access control strategy: The scheduling model clearly defines the access permissions of each role on the corresponding task node, including whether they have the right to modify, whether they are allowed to submit versions, and whether approval is required.

[0085] Submission window settings: Based on the time constraints in the task-driven graph, combined with the submission time limit of task nodes and the progress of related stages, set the allowed time period for role data submission, and establish a warning mechanism for early or late submission behavior.

[0086] This multi-role task scheduling model serves as the basis for determining access permissions, handling conflicting tasks, and automatically reconstructing the scheduling order during subsequent collaboration. In particular, after task conflict identification occurs, the model can be used to quickly determine whether the involved role has data modification permissions at the current stage, whether its task order is prioritized, and whether its submission time is valid. This provides support for subsequent data mutual exclusion control mechanisms and access permission adjustment strategies, ensuring the stable progress of the design process under multi-role collaboration.

[0087] Through the above process, while ensuring multi-stage and multi-professional collaboration in design tasks, a task-driven mechanism with clear roles, clear timelines, and precise access control has been established, significantly improving the informatization and automation level of highway engineering design management.

[0088] Step 2: Combining user access behavior, task execution records, and the real-time data version status of the design platform, extract the state difference between the access operation and the current task node, and construct a role collaboration offset index, including the following steps:

[0089] To construct the role-based collaborative offset metric, user access behavior data is first collected, including login time, operating terminal, access path, data operation type and access target identifier, specific data operation type, and the identifier of the data node operated on. Then, the user's task execution records in the current project are extracted from the historical database, including the task node number completed by the user, the timestamp of each operation, the role identity category corresponding to the task node, and the version number of the data submitted by the user. At the same time, the version status information of the data node corresponding to the current access target in the platform is extracted, including the current version number of the data node, whether it is in a write-locked state, the data ownership role information, and the most recent operation record of the data node.

[0090] After data preparation is complete, the data node currently operated by the user is matched with the nodes involved in its task execution record. The state difference degree in three dimensions is calculated on the matching results, including task stage difference degree, data version difference degree, and time sequence difference degree. The task stage difference degree is evaluated by judging whether the task stage currently accessed by the user is earlier than, equal to, or later than the stage boundary set in its task record. For example, if it is later, it is considered a stage out of bounds. The data version difference degree is judged based on the number interval between the data version number currently accessed by the user and its historical submission version number. The time sequence difference degree is obtained by calculating the number of days between the user's most recent operation time and the current access time.

[0091] Specifically, the task stage offset value is determined by identifying the design stage of the currently accessed data node and comparing it with the corresponding node's design stage in the task record. Based on a preset stage level table, such as preliminary design, construction drawing design, specialized design, and post-construction evaluation, the interval between adjacent levels is set to 1, and the interval across two levels is set to 2, and so on, mapping to an integer offset level. If the currently accessed node is in the same stage as the bound task node, the offset value is 0.

[0092] The data version offset is determined by comparing the version identifier of the currently accessed data node with the identifier of the historically submitted version in the task record. If the two version identifiers match, the offset is set to 0; if they do not match, the offset level is set according to the magnitude of the difference in their numbers. For example, a difference of 1 level in version numbers indicates a minor offset, a difference of 2 levels or more indicates a moderate or severe offset, and the offset increases proportionally, with a fixed offset unit added for each level of difference. This unit can be set during system initialization and adjusted through platform policies.

[0093] The time sequence offset value is calculated by comparing the time of the current access behavior with the end time of the task bound in the task record. An acceptable time tolerance range is defined based on a sliding time window mechanism. For example, access within 24 hours after the task ends is considered reasonable access; access exceeding this time window is judged as reverse-order offset behavior, and the degree of offset is quantified based on the length of the time exceeding the limit. If the access behavior occurs before the task phase, it is considered premature intervention access and is set as a high-risk offset.

[0094] By combining the above three difference factors with the user's current access behavior characteristics, such as whether it is a submission operation and whether the access path is within its task path, a role collaboration offset index is generated using a rule-based non-linear combination method. That is, the three offset dimensions are normalized to quantitative values ​​under the same scoring scale, for example, normalized to the interval of 0 to 1, and the three normalized offset values ​​are input into a preset rule combination function for weighted summation. If the stage difference is out of bounds, the data version difference is greater than the set version interval, the time sequence difference is greater than the set time threshold, and the current behavior is a write operation, the role collaboration offset index is evaluated as a severe offset; if the difference is small or the access behavior is a read-only operation, it is evaluated as a mild offset or normal. The final output collaboration offset result is used to indicate whether the current user's behavior deviates from the task boundary they should participate in, and serves as the input basis for subsequent task mutual exclusion control mechanisms and scheduling priority judgments.

[0095] Step 3: When the role collaboration offset index exceeds the set tolerance range, the task mutual exclusion control mechanism is automatically triggered, suspending the write permissions of conflicting data nodes and generating collaboration conflict prompts to all involved roles, including the following steps:

[0096] When the role collaboration offset metric calculated by the platform exceeds the preset tolerance threshold, the task mutual exclusion control mechanism is automatically triggered to ensure the write consistency of the current data node in the collaborative environment and the mutual exclusion control of multi-role operations. The tolerance threshold is set according to actual needs, that is, the tolerance threshold may be different at different times.

[0097] Identify the identifier of the data node accessed by the current user, and based on the identifier, retrieve all nodes in the task-driven graph that have direct or indirect data references, version inheritance, parameter dependencies or stage continuity relationships with it, forming a set of associated nodes. This set of associated nodes includes not only the data entities directly operated by the current task node, but also its historical version reference chain and task dependency nodes in subsequent stages.

[0098] The system queries the current task graph to find all currently online users or those with write permissions, and determines whether their operation nodes overlap with the aforementioned set of related nodes. If so, they are added to the access conflict role group, which includes all user roles with write permissions to the current data node and its dependent paths, for subsequent access control operations. For each user in the access conflict role group, an access adjustment instruction is executed: the user's write permissions to the current data node and all its directly related nodes are suspended, while their read-only permissions to that node are maintained. This allows the user to view the latest task status and data version, but not to modify or submit it. This access adjustment is dynamically issued through the platform's access mapping table and data access interface, achieving real-time access control.

[0099] After performing the permission adjustment operation, the platform generates a conflict notification message on the collaborative operation interface and writes the current conflict node identifier, associated role, conflict occurrence time, and mutual exclusion control reason into the collaborative event log. Simultaneously, it pushes a collaborative anomaly notification to each user in the conflict role group through the system's notification mechanism. The notification includes: the node's current status, conflict type, scope of impact, and resolution conditions, ensuring all relevant roles are synchronously aware of the current mutual exclusion status. The current data node's status is marked as conflict frozen, and the task mutual exclusion control trigger event is recorded. This status mark is written to the node status attribute of the task-driven graph to restrict other modules' scheduling or operation of the frozen node. Furthermore, mutual exclusion resolution conditions are set in the system, including but not limited to conditions such as conflicting users completing comparison confirmation, system administrator intervention to unlock, and collaborative offset recovery to the tolerance range. Once any condition is met, the system can automatically or manually perform the unlock operation, restoring the data node's normal write permissions and resolving the conflict notification.

[0100] Through the above control mechanism, dynamic mutual exclusion control of critical data nodes is realized when the collaborative offset of roles exceeds the limit, avoiding write conflicts between multiple roles during task overlap, and effectively enhancing the security and consistency of collaborative operations in the design process.

[0101] To address the task execution conflict caused by multiple roles initiating conflicting write operations on the same data node, the system further prioritizes conflicting tasks after the task mutual exclusion control mechanism is triggered, and reconstructs the task scheduling order and data ownership accordingly, so as to achieve coordinated and orderly progress of tasks and clear sovereignty over critical data.

[0102] Step 4: Based on the phase relationships, data dependency paths, and submission sequences of the conflicting task nodes, evaluate the execution priority of the conflicting tasks, and automatically reconstruct the task scheduling order and data ownership based on the evaluation results, including the following steps:

[0103] The stage priority factor is obtained as follows:

[0104] First, extract the task ID bound to the data node currently in a mutual exclusion control state. Then, search the task-driven graph for all task paths that have a logical relationship with the task before and after a stage. The position of each task in the stage flow is identified by the stage index number, with smaller index numbers indicating earlier stages. Use the stage index number as the base of an exponential function to obtain the stage position index value. Construct a stage priority factor according to the task's hierarchy. The stage priority factor represents the importance of the task in the overall flow and is used to measure its impact on subsequent nodes in the current flow.

[0105] The design phase list generally includes the following pre-defined phases: schematic design phase, preliminary design phase, technical design phase, construction drawing design phase, and as-built drawing preparation phase. Each phase is assigned a unique index number according to its chronological order. For example: schematic design phase: phase index number 1; preliminary design phase: phase index number 2; technical design phase: phase index number 3; construction drawing design phase: phase index number 4; as-built drawing preparation phase: phase index number 5.

[0106] By finding the stage attribute field of the conflicting task in the task-driven graph, the stage in which it belongs is identified, and the index number of the stage in the stage list is extracted as the stage number. For example, if the current task is "construction drawing design stage", then its stage index number is 4.

[0107] The index number is input into a preset exponential function rule to generate a stage priority factor. This exponential function uses the stage index number as the base and incorporates a decay coefficient less than 1 as the exponent. For example, the decay coefficient can be set to 0.5, indicating that the priority factor increases at a relatively moderate rate as the stage progresses. The stage priority factor is a function value that increases with the stage index number. This value measures the strength of the current stage's impact on subsequent tasks throughout the design process. If the stage index number is 2, the generated stage priority factor is a moderately low value; if the stage index number is 5, the generated priority factor is significantly higher, indicating that the task is more sensitive to the dependence on subsequent tasks and the timeliness of completion.

[0108] The data dependency urgency factor is obtained as follows:

[0109] Analyze all data reference relationships between the current task and other conflicting tasks to identify its position in the data dependency chain between tasks. The closer the dependency position is to the data source node or branch node, the stronger the dependency relationship and the higher its importance. Calculate the depth value of the task path (i.e., the depth level of the task node in the data dependency chain) and square the path depth to form a path strength metric. At the same time, count the number of times the data of this task node is referenced by other task nodes, and take the logarithm of the reference count as the reference breadth metric.

[0110] Using the squared value of path depth as a baseline and the number of citations as an influencing factor, a data dependency urgency factor is constructed. The calculation method is as follows: The system uses the squared value of path depth as the dependency strength and performs a logarithmic hierarchical mapping on the order of magnitude in combination with the number of citations. As the number of citations increases, more fine-grained mapping control is performed on the dependency strength value, thereby outputting the final dependency urgency factor value;

[0111] For example, if the path depth is 5, the squared result is 25; and the number of references is 10, then the system performs a non-linear mapping of 25 in increments of 10, so that the output can simultaneously reflect the high risk brought by deep paths and the data consistency pressure brought by frequent references.

[0112] The priority factor is obtained as follows:

[0113] First, obtain the current time of the task node that is currently in conflict. This time can be automatically recorded by the platform server system time, indicating the time when the task is currently being accessed or attempted to be submitted. Then, retrieve the recommended completion time bound to the task node. This time is the suggested delivery time set by the task scheduling model in the initial scheduling, which is usually generated by the project plan.

[0114] Compare the current time with the recommended completion time and calculate the time difference between the two. If the current time is earlier than the recommended completion time, the time difference is positive, indicating that it is still within the controllable time limit; if the current time is later than the recommended completion time, the time difference is negative, indicating that a delay has occurred.

[0115] This time difference will be used as the independent variable in the inverse proportional function mapping rule to generate the time priority factor. The preset form of the inverse proportional function is as follows:

[0116] The smaller the time difference (i.e., the closer the task is to or beyond the recommended time), the larger the generated priority factor; the larger the time difference (i.e., there is still plenty of time before the recommended completion time), the smaller the generated priority factor.

[0117] For example, under system settings, if the current time is only 1 hour away from the recommended completion time, it will be mapped to a higher priority value, such as 0.9; if there are still 48 hours left, the system may map it to a lower priority value, such as 0.1. This inverse proportional function supports dynamic changes to ensure that task scheduling responds sensitively to time urgency.

[0118] The process of performing a non-linear mapping between stage priority factors, data dependency urgency factors, and time priority factors to generate a unified comprehensive priority score for conflict tasks is as follows:

[0119] The stage priority factor, data dependency urgency factor, and time priority factor are input into the first-layer mapping structure of the evaluation model in vector form. The first-layer structure uses the hyperbolic tangent function to perform nonlinear scaling mapping. For example, by setting a threshold range, low values ​​are compressed and high values ​​are expanded to enhance the discriminativeness of task features. That is, for any input factor value, it is first standardized and then transformed by the hyperbolic tangent function, that is, the standardized factor input is mapped to the range of negative one to positive one. Factor values ​​close to zero are compressed and factors close to extreme values ​​are expanded, reflecting the importance of highly differentiated tasks.

[0120] Upon entering the second layer, the system introduces an exponential growth function to construct the cross-influence relationship between factors. For example, when both the data dependency urgency factor and the time priority factor are high, the activation value increases non-linearly, indicating that tasks with extremely high conflict sensitivity should be prioritized. When both input factors are above a certain set threshold, the system multiplies them as an intermediate variable and inputs this variable into the exponential growth function for enhancement. That is, the larger the value, the more significant the increase in output, thus reflecting the coupling urgency between factors. For example, in scenarios where both the stage priority factor and the data dependency urgency factor are high, this function can significantly increase the overall score, prioritizing the handling of such risky tasks.

[0121] The comprehensive output after the first two transformations is mapped to a specified scoring range (e.g., 0 to 1) to achieve unified standardization and comparability control of the scoring results. Here, a sigmoid function is introduced as a convergence function. By setting the inflection point and slope parameters, the output value is converged to between zero and one. When the value is small, the output of this function increases slowly, changes rapidly when it approaches the inflection point, and eventually tends to saturate, thereby limiting the occurrence of extreme scoring values ​​and maintaining the controllability of the scoring. Finally, the comprehensive priority score of the conflict task is output.

[0122] For example, suppose a conflict task A has a phase priority factor of 5, a data dependency urgency factor of 8, and a time priority factor of 7. First, the three factor values ​​are standardized and mapped to the interval [-1,1]. Let the standardized values ​​be 0.2, 0.6, and 0.5 respectively. After entering the first layer of hyperbolic tangent function (tanh) mapping, 0.2 is compressed to about 0.197, 0.6 is expanded to about 0.537, and 0.5 is expanded to about 0.462, thus improving the discriminative power of the high-value factors. Entering the second-level exponential growth function processing stage, the system detects that both the data dependency factor and the time priority factor exceed the preset threshold (e.g., 0.4). Therefore, it calculates their product 0.537 × 0.462 ≈ 0.248 and substitutes this value into the exponential growth function exp(x), obtaining an enhanced output of approximately 1.281, further highlighting the impact of urgency coupling in the conflict. Finally, it enters the third-level Sigmoid function processing stage. By setting the inflection point to 1.0 and the slope parameter to 10, the aforementioned value is input into sigmoid(10 × (1.281 – 1.0)) ≈ 0.57, resulting in a final comprehensive priority score of 0.57 for the conflict task. This score serves as the ranking basis for adjusting the task scheduling order. The comprehensive priority score for the conflict task reflects both the relative importance of the original factors and the urgency of coupling between factors, and maintains the stability and comparability of the score through a convergence function.

[0123] It should be noted that each activation function has independent training parameters, including weight scaling coefficients and offsets. This parameter set is obtained through supervised training using historical collaborative task data collected in the early stages of the project. The training samples include labels such as task priority annotations, conflict resolution history records, and task completion delay values. The system can adopt an iterative training method based on error minimization strategy to gradually optimize the boundary points and response thresholds in each activation function.

[0124] Step 5: Update the scheduling results to the task-driven graph. The platform synchronously refreshes the current permissions, collaboration view, and operable data range of each role, forming a data access control closed loop based on the dynamic evolution of task status. This includes the following steps:

[0125] After prioritizing and ranking conflicting tasks, the task-driven graph is reconstructed based on the latest generated task scheduling order. This reconstruction process includes synchronizing and adjusting the stage connections, dependency paths, and execution order between task nodes, and assigning a currently valid scheduling status label to each task node. The scheduling status labels include four states: pending, executing, paused, and completed. Subsequent processing of access control is then performed based on this status.

[0126] Based on the updated task-driven graph, the corresponding role binding relationships of each task node are parsed, and the data access permissions of each role at the current stage are dynamically refreshed. Specifically, this includes: reallocating the set of nodes with write permissions, adjusting the read boundaries of visible nodes, and restricting access channels for roles with mutually exclusive tasks on conflicting paths. For refreshing write permissions, editing capabilities are only enabled when a node is in an executing state and the role matches the task's responsibility role; otherwise, the node will be presented in a read-only or hidden state in the role's collaboration view.

[0127] After the permissions are refreshed, the collaboration view content loaded by each user in the platform is refreshed synchronously. The collaboration view is used to display the design data, collaboration nodes, and deliverable paths that the user can operate on in the current task stage. Based on the task status and its updated scheduling index, the display priority and interactive response range of elements in the view are adjusted, while blocking node entry points in conflict states to ensure consistency and integrity of data access boundaries during multi-role collaboration. While completing the permission and collaboration view updates, the scope of operable data is confirmed in a closed loop and updated to disk. A data operation whitelist table is generated in the background, which includes the current role, task stage, data node identifier, and its operation permission level, as the basis for subsequent access control. When any user attempts to access a data node not in the whitelist, their request will be directly blocked and an access violation prompt will be generated, ensuring that permission scheduling and task scheduling are fully linked.

[0128] Through the above steps, a closed loop of data access control driven by the dynamic evolution of task status is formed, realizing a complete mechanism for scheduling updates, permission refreshes, and synchronous adjustment of data operation boundaries, ensuring the consistency of role behavior and task execution status and the standardization of permissions in collaborative scenarios.

[0129] Step 6 involves recording the entire process of task conflict identification, collaborative scheduling, permission refactoring, and data synchronization, constructing a three-dimensional responsibility chain structure for roles, data, and tasks, and managing the traceability of collaborative behavior throughout the process, including the following steps:

[0130] First, acquire the operation behavior logs generated by the platform during the process of conflict task identification, permission adjustment, and scheduling refactoring. These logs contain user identity information (such as user account, role category, and affiliated unit) at the time of each action, the timestamp of the action, the task node identifier associated with the action, the specific action type (such as write control, scheduling order change, or version locking), and the execution metadata such as the scope of permissions and data affected by the action. This metadata constitutes the basic recording unit for each action.

[0131] All acquired behavior log records are categorized according to the task nodes corresponding to the operations. Multiple behaviors under the same task node are grouped into one operation unit set. Based on this, combined with the pre-set binding mapping relationship between roles and tasks in the task-driven graph, the data node paths accessed by the role in historical submissions, and the data version records generated by its submission operations, a triplet structure containing three elements is established for each operation behavior. This triplet consists of role (role identifier), data (data node), and task (task node number) identifier. The three together constitute the responsibility path of the behavior in the collaborative environment. This type of triplet structure is iteratively generated in all task nodes, thereby constructing a three-dimensional responsibility chain structure woven from the three dimensions of role, data, and task globally, which is used to reflect the role responsibility and task flow position behind all key behaviors in the system.

[0132] Each operation log entry is further assigned a unique identifier code. This code is generated using a combination of timestamp and behavior fingerprint. The timestamp represents the precise time the action occurred, and the behavior fingerprint is constructed from the user identifier, operation type, and task number through a hash mapping. During the recording process, this behavior identifier code is bound to the corresponding data snapshot and task version in the platform database. This ensures that any operation can be mapped to the data state before and after modification, thus forming a complete version slicing and behavior trajectory binding system.

[0133] An accountability chain traceability interface is embedded in the graphical task view interface of the task management platform. When project managers or platform users face collaboration conflicts, version anomalies, misoperations, or task version rollback requests, they can click on the corresponding task node through this interface to invoke its corresponding three-dimensional accountability chain structure. This will automatically parse the historical operation evolution path, including the responsible roles, task node stages, and version status changes for each modification, and gradually unfold it in a timeline format on the interface. This helps managers quickly locate the attribution of responsibility and the branch of task evolution, providing effective data support and evidence chain for subsequent task adjustments, responsibility confirmation, and anomaly handling.

[0134] Through the above implementation methods, the entire process of digital collaborative management of the entire highway engineering process, including conflict behavior, permission changes and task scheduling, is recorded and responsibility is mapped. This can play a key role in scenarios such as problem tracing, task auditing and platform supervision, and ensure the stability, transparency and controllability of the collaborative system.

[0135] It should be noted that the thresholds involved in the embodiments can be determined according to specific scenarios and needs.

[0136] This invention achieves task status awareness and role collaborative management throughout the entire highway engineering design process by constructing a task-driven graph and a multi-role scheduling model. Based on ternary heterogeneous data of user access behavior, task records, and platform version status, it extracts status differences and calculates role collaborative offsets, identifies task boundary overlaps and collaborative offset risks among multiple roles, and automatically triggers a mutual exclusion control mechanism to effectively block unauthorized write operations to conflicting data nodes. After conflict identification, it constructs phase priority factors, data dependency urgency factors, and time priority factors, and generates a comprehensive priority score for conflicting tasks through a nonlinear combination mapping method. The score results drive scheduling reconstruction and data ownership adjustment, forming a dynamic collaborative scheduling strategy with task-driven attributes.

[0137] A closed-loop data access control mechanism is proposed under the task state evolution. The platform automatically refreshes role permissions, collaborative views, and data operation scope based on the latest scheduling results, realizing real-time linkage between role behavior and task status. At the same time, the entire process of conflict identification, permission adjustment, and data synchronization is recorded in a structured manner, constructing a three-dimensional responsibility chain structure of roles, tasks, and data. This supports complete traceability and responsibility positioning of historical collaborative behaviors, effectively addressing data conflict issues under multi-disciplinary and multi-stage parallel operation, significantly improving the behavioral standardization and data consistency of design collaboration, and enhancing the intelligence and controllability of digital management of the entire engineering process.

[0138] Example 2: A full-process digital collaborative management system for highways, such as... Figure 2 As shown, it specifically includes:

[0139] The highway phase task allocation module constructs a task-driven graph based on the phase process, professional structure, and time decomposition information of highway engineering design tasks, and generates a multi-role task scheduling model according to the node status and role correspondence in the task-driven graph.

[0140] The collaborative analysis module is used to combine user access behavior, task execution records and the real-time data version status of the design platform to extract the state difference between the access operation and the current task node, and construct the role collaboration offset index.

[0141] The conflict detection module is used to automatically trigger the task mutual exclusion control mechanism when the role collaboration offset index exceeds the set tolerance range, suspend the write permissions of the conflicting data nodes, and generate collaboration conflict prompts to the relevant roles.

[0142] The data evaluation module is used to evaluate the priority of conflicting tasks based on the stage relationships, data dependency paths and submission times of the conflicting task nodes, and automatically reconstruct the task scheduling order and data ownership based on the evaluation results.

[0143] The data access control module is used to update the scheduling results to the task-driven graph. The platform synchronously refreshes the current permissions, collaborative view and operable data range of each role, forming a data access control closed loop based on the dynamic evolution of task status.

[0144] The traceability management module leaves a record of the entire process of task conflict identification, collaborative scheduling, permission reconstruction, and data synchronization, constructs a three-dimensional responsibility chain structure of roles, data, and tasks, and performs traceability management of the entire collaborative process.

[0145] The above formulas are all dimensionless calculations. Dimensionless calculations can be performed using various methods such as standardization, which will not be elaborated here. The formulas are derived from software simulations based on a large amount of collected data, and the preset parameters in the formulas can be set by those skilled in the art according to the actual situation.

[0146] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, ATA hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. The semiconductor medium can be a solid-state ATA hard disk.

[0147] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0148] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0149] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and 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 through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0150] 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; 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, depending on actual needs.

[0151] In addition, the functional units in the various embodiments of this application 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.

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

Claims

1. A method for end-to-end digital collaborative management of highways, characterized in that, Includes the following steps: Based on the phased process, professional structure and time decomposition information of highway engineering design tasks, a task-driven graph is constructed, and a multi-role task scheduling model is generated according to the node status and role correspondence in the task-driven graph. By combining user access behavior, task execution records, and the real-time data version status of the design platform, the state difference between the access operation and the current task node is extracted, and a role collaboration offset index is constructed. When the role collaboration offset index exceeds the set tolerance range, the task mutual exclusion control mechanism is automatically triggered, the write permissions of conflicting data nodes are suspended, and a collaboration conflict prompt is generated for all involved roles. Based on the phase relationships, data dependency paths, and submission sequences involved in the conflicting task nodes, the execution priority of the conflicting tasks is evaluated, and the task scheduling order and data ownership are automatically reconstructed based on the evaluation results. The scheduling results are updated to the task-driven graph, and the platform synchronously refreshes the current permissions, collaboration view and operable data range of each role, forming a data access control closed loop based on the dynamic evolution of task status; The entire process of task conflict identification, collaborative scheduling, permission reconstruction, and data synchronization is traced, a three-dimensional responsibility chain structure of roles, data, and tasks is constructed, and the collaborative behavior throughout the entire process is traceable and managed. The entire process of task conflict identification, collaborative scheduling, permission refactoring, and data synchronization is traced, a three-dimensional responsibility chain structure of roles, data, and tasks is constructed, and the collaborative behavior throughout the entire process is traceable and managed. The specific steps are as follows: Obtain operation behavior logs generated by the platform during conflict identification, permission reconstruction and task scheduling, including user identity information, operation timestamp, task node identifier, operation type and scope of impact execution metadata; The acquired behavior logs are categorized according to task nodes, and a triplet mapping relationship is established based on the binding relationship between roles and tasks, data access paths, and submission records to construct a three-dimensional responsibility chain structure of roles, data, and tasks. Each operation record is uniquely identified and encoded, and the operation action is bound to its corresponding task version and data snapshot in the platform log structure; The platform task view integrates a responsibility chain traceability interface. When data conflicts, misoperations, or version rollback requests occur, the responsibility chain path of the corresponding node is invoked to display the operation evolution path and responsible role of the task node.

2. The method for end-to-end digital collaborative management of highways according to claim 1, characterized in that: Based on the phased process, professional structure, and time decomposition information of highway engineering design tasks, a task-driven graph is constructed, and a multi-role task scheduling model is generated according to the correspondence between node status and role in the task-driven graph. The specific process is as follows: Extract the phase division information, professional participation relationships and corresponding time plans of highway engineering design projects, and construct a set of task nodes according to phase nodes, professional intersections and time sequence. Set a node status label for each task node, including stage type, execution status, submission deadline, and associated data identifier; Based on the status label of each task node and its corresponding design specialty, role category, and responsibility boundaries, a role mapping table is generated, and a mapping relationship is established between each role and its corresponding task node. Based on the node set and role mapping table, a task-driven graph is constructed, and the stage dependencies and data interaction paths between task nodes are set in the task-driven graph. A multi-role task scheduling model is generated based on the state sequence and role relationship of each node in the task-driven graph.

3. The method for end-to-end digital collaborative management of highways according to claim 2, characterized in that: The multi-role task scheduling model is used to determine the data access timing relationship and role participation order between different task nodes. After the conflict task is identified, it serves as the basis for scheduling priority evaluation and access permission reconstruction, controlling the write permissions and submission windows of each role on the data node.

4. The method for full-process digital collaborative management of highways according to claim 3, characterized in that: By combining user access behavior, task execution records, and the real-time version status of the design platform, the state difference between the access operation and the current task node is extracted, and a role collaboration offset index is constructed. The specific process is as follows: Collect current user access behavior data, including login time, operating terminal, access path, data operation type and access target identifier; Extract the user's historical task execution records, including completed task nodes, operation timestamps, role identity, and submitted data version number; Obtain the latest version status information of the corresponding data node in the design platform, including the current version number, write lock status, data ownership role, and recent operation records; Match the data node currently accessed by the user with the corresponding task node in its task record, and calculate the degree of difference in state in terms of task stage, data version and time sequence; Based on state differences and access behavior characteristics, a role collaboration offset index is constructed. The role collaboration offset index is used to measure the degree of offset between the current user's operation behavior and its task boundary.

5. The method for end-to-end digital collaborative management of highways according to claim 4, characterized in that: The role collaboration offset index is constructed based on state differences and access behavior characteristics. The specific process is as follows: The data node currently accessed by the user is compared with its bound task node, and the state difference is calculated respectively. The state difference includes task stage offset value, data version offset value and time sequence offset value. The task stage offset value is determined by comparing the stage difference level between the design stage of the currently accessed node and the node stage in the task record, and is quantitatively mapped using a preset stage level table. The data version offset value is calculated by comparing the version identifier of the accessed data with the version identifier of the corresponding data in the task record to perform a sequence difference. If the version numbers are the same, it is recorded as zero. If the version numbers are different, the offset level is set according to the order of magnitude of the difference and a linear increment rule. The time sequence offset value is calculated based on the time difference between the access time and the task binding time. A sliding time window is used to set the time tolerance range. If the access time exceeds the task end time and the historical task node is still accessed, it is set as a high-risk reverse order offset. The task phase offset, data version offset, and time sequence offset are input into the rule-based comprehensive scoring function, and after normalization, a weighted summation is performed. The output result is used as the role collaboration offset index.

6. The method for end-to-end digital collaborative management of highways according to claim 5, characterized in that: When the role collaboration offset exceeds the set tolerance range, the task mutual exclusion control mechanism is automatically triggered, suspending the write permissions of conflicting data nodes and generating collaboration conflict prompts to all involved roles. The specific process is as follows: Identify the data node currently accessed by the user and retrieve the set of all associated nodes in the task-driven graph that have a dependency or version reference relationship with that data node; Find other user roles in the set of associated nodes that have overlapping task boundaries with the current access behavior, and construct an access conflict role group; Perform permission adjustment operations on each user in the access conflict role group, suspend write permissions to the current data node and directly related nodes, and retain read-only permissions for comparison and reference. Generate a conflict alert message on the platform collaboration interface and push a collaboration anomaly notification to the conflict role group, indicating that the current data node is in a mutual exclusion control state. The system synchronizes the mutual exclusion control status of tasks, marks the current node as a conflict-frozen state, and sets the conditions for releasing the mutual exclusion.

7. The method for end-to-end digital collaborative management of highways according to claim 6, characterized in that: Based on the phase relationships, data dependency paths, and submission sequences involved in the conflicting task nodes, the execution priority of the conflicting tasks is evaluated, and the task scheduling order and data ownership are automatically reconstructed based on the evaluation results. The specific steps are as follows: Extract the task number corresponding to the data node that is currently in a mutually exclusive state, and retrieve the task path in the task-driven graph that has a stage relationship with the task. Obtain the stage position index value and construct the stage priority factor based on the stage position index value. Analyze the data dependency paths between the task and the conflicting task, identify the position in the data link, and construct a data dependency urgency factor; Perform time-series analysis on the submission behavior of conflicting tasks, extract submission time, modification frequency and current progress status, and calculate time priority factor; The phase priority factor, data dependency urgency factor and time priority factor are non-linearly combined and mapped to generate a comprehensive priority score for conflict tasks. Tasks are sorted based on their conflict priority scores, and the task scheduling order and data ownership are automatically reconstructed accordingly, updating the scheduling paths and node status in the task-driven graph.

8. The method for end-to-end digital collaborative management of highways according to claim 7, characterized in that: The stage priority factor, data dependency urgency factor, and time priority factor are non-linearly combined and mapped to generate a comprehensive priority score for conflict tasks. The specific steps are as follows: Extract the design phase index number to which the conflicting task belongs, and use the phase index number as the base of the exponential function to generate the phase priority factor; Based on the data path depth and the number of references that the conflict task depends on, the square of the path depth is calculated as a measure of dependency strength. The logarithm of the square value divided by the number of references is used as the data dependency urgency factor. Calculate the time difference between the current time and the recommended completion time of the conflicting task, and substitute the difference as an independent variable into the inverse proportional function. The resulting value is used as the time priority factor. The phase priority factor, data dependency urgency factor, and time priority factor are taken as inputs and substituted into a pre-defined three-layer activation function combination model to output a comprehensive priority score for conflicting tasks, which is then used to sort and generate a new round of scheduling order.

9. A full-process digital collaborative management system for highways, used to implement the full-process digital collaborative management method for highways as described in any one of claims 1-8, characterized in that, include: The highway phase task allocation module constructs a task-driven graph based on the phase process, professional structure, and time decomposition information of highway engineering design tasks, and generates a multi-role task scheduling model according to the node status and role correspondence in the task-driven graph. The collaborative analysis module is used to combine user access behavior, task execution records and the real-time data version status of the design platform to extract the state difference between the access operation and the current task node, and construct the role collaboration offset index. The conflict detection module is used to automatically trigger the task mutual exclusion control mechanism when the role collaboration offset index exceeds the set tolerance range, suspend the write permissions of the conflicting data nodes, and generate collaboration conflict prompts to the relevant roles. The data evaluation module is used to evaluate the priority of conflicting tasks based on the stage relationships, data dependency paths and submission times of the conflicting task nodes, and automatically reconstruct the task scheduling order and data ownership based on the evaluation results. The data access control module is used to update the scheduling results to the task-driven graph. The platform synchronously refreshes the current permissions, collaborative view and operable data range of each role, forming a data access control closed loop based on the dynamic evolution of task status. The traceability management module leaves a record of the entire process of task conflict identification, collaborative scheduling, permission reconstruction, and data synchronization, constructs a three-dimensional responsibility chain structure of roles, data, and tasks, and performs traceability management of the entire collaborative process.

Images