Information sharing-based construction site laboratory digital management method and system

Abstract

This invention provides a digital management method and system for construction site laboratories based on information sharing. First, it collects information sharing needs from multiple stakeholders, including quality supervision agencies, project owners, graded testing agencies, and the construction site laboratories themselves, regarding business processing, supervision and guidance, and collaborative management. Next, it uses the .NET framework to build a multi-stakeholder adaptation module, selecting and combining functional modules based on the collected needs. Then, it sets flow nodes according to the type of sharing needs, associating entity operation permissions to dynamically configure the information sharing approval process. Finally, it uses a front-end tool with table editing capabilities to integrate shared information items according to business scenarios and associate flow nodes, generating scenario-based shared information templates. Finally, it executes targeted information sharing among multiple stakeholders based on these scenario-based shared information templates, collecting feedback to optimize the combination of adaptation module functions and the configuration of the information sharing approval process, achieving efficient digital management of construction site laboratories.

Description

Technical Field

[0001] This invention relates to the field of construction site laboratory management technology, and more specifically, to a digital management method and system for construction site laboratories based on information sharing. Background Technology

[0002] The management of construction site laboratories involves multiple stakeholders, including quality supervision agencies, project owners, accredited testing institutions, and the laboratories themselves. These stakeholders all have a need for information sharing in areas such as business processing, supervision and guidance, and collaborative management. However, traditional construction site laboratory management models have many drawbacks.

[0003] On the one hand, poor information flow among various stakeholders and the lack of a unified information sharing platform and standards lead to untimely and inaccurate information transmission, easily resulting in information silos. For example, quality supervision agencies struggle to obtain timely testing data and operational progress from on-site laboratories, hindering effective supervision and guidance; project owners also lack comprehensive information about the laboratories' operational status, impacting the overall project progress. On the other hand, existing information sharing methods often lack flexibility and specificity, failing to dynamically adjust to the needs and business scenarios of different stakeholders. Unclear operational permissions and approval processes among different stakeholders during information sharing can easily lead to management chaos and security risks. Summary of the Invention

[0004] In view of the aforementioned problems, and in conjunction with the first aspect of the present invention, embodiments of the present invention provide a digital management method for construction site laboratories based on information sharing, the method comprising:

[0005] The information sharing needs of multiple entities for construction site laboratories are collected. These entities include quality supervision agencies, project owners, grade testing agencies, and the construction site laboratories themselves. The information sharing needs cover business processing needs, supervision and guidance needs, and collaborative management needs.

[0006] A multi-agent adaptation module is built using the .NET development framework. Based on the collected information sharing requirements, functional modules are selected and combined from the .NET development framework to complete the construction of the multi-agent adaptation module.

[0007] Based on the multi-subject adaptation module, flow nodes are set according to the sharing requirement type, and corresponding subject operation permissions are associated with each flow node to dynamically configure the information sharing approval process.

[0008] Using a front-end tool with table editing capabilities, shared information items are integrated according to business scenarios, and the shared information items are associated with the corresponding flow nodes in the information sharing approval process to generate scenario-based shared information templates.

[0009] Based on the scenario-based shared information template, targeted information sharing among multiple entities is performed, shared feedback information submitted by multiple entities is collected, and the functional combination of the multi-entity adaptation module and the configuration of the information sharing approval process are optimized according to the shared feedback information.

[0010] Furthermore, embodiments of the present invention also provide a digital management system for construction site laboratories based on information sharing, characterized in that it includes:

[0011] A processor; a machine-readable storage medium for storing machine-executable instructions of the processor; wherein the processor is configured to execute the above-described information-sharing-based digital management method for construction site laboratories by executing the machine-executable instructions.

[0012] In another aspect, embodiments of the present invention also provide a computer program product, the computer program product including machine-executable instructions, the machine-executable instructions being stored in a computer-readable storage medium, the processor of the information-sharing-based construction site laboratory digital management system reading the machine-executable instructions from the computer-readable storage medium, the processor executing the machine-executable instructions, causing the information-sharing-based construction site laboratory digital management system to execute the aforementioned information-sharing-based construction site laboratory digital management method.

[0013] Based on the above, by collecting information sharing needs from multiple stakeholders for construction site laboratories, a multi-stakeholder adaptation module was built using the .NET framework. Functional modules were flexibly selected and combined according to the collected needs, enabling rapid response to changes in management requirements across different construction site laboratories and at different stages. This enhanced the system's versatility and scalability, and reduced the cost of system upgrades and adjustments. By setting flow nodes according to the type of sharing needs and associating them with stakeholder operation permissions, and dynamically configuring the information sharing approval process, the security and standardization of information flow among multiple stakeholders were ensured. Each flow node has clearly defined operation permissions, preventing unauthorized access and tampering of information. Simultaneously, the dynamic approval process configuration can be flexibly adjusted according to actual conditions, improving approval efficiency and reducing information sharing waiting time. Scenario-based shared information templates were generated, precisely associating shared information items with flow nodes, making information sharing more aligned with actual business scenarios. Information sharing needs in different business scenarios can be met through corresponding templates, facilitating operation and use by multiple entities, improving the accuracy and practicality of information sharing. Targeted information sharing is executed based on scenario-based shared information templates, and feedback information is collected to optimize and adapt module function combinations and approval process configurations. By continuously collecting feedback from multiple entities during use, problems and shortcomings of the system can be identified in a timely manner, and targeted optimizations and improvements can be made. This enables the entire digital management system to continuously improve itself with the development of business and changes in needs, always maintaining efficient and stable operation, and effectively improving the overall efficiency and adaptability of digital management in construction site laboratories. Attached Figure Description

[0014] Figure 1 This is a schematic diagram of the execution flow of the digital management method for construction site laboratories based on information sharing provided in an embodiment of the present invention.

[0015] Figure 2 This is a schematic diagram of exemplary hardware and software components of the digital management system for construction site laboratories based on information sharing provided in an embodiment of the present invention. Detailed Implementation

[0016] The present invention will now be described in detail with reference to the accompanying drawings. Figure 1 This is a flowchart illustrating a digital management method for construction site laboratories based on information sharing, provided in one embodiment of the present invention. The following is a detailed description of this digital management method for construction site laboratories based on information sharing.

[0017] Step S110: Collect information sharing needs from multiple entities for the construction site laboratory. These entities include quality supervision agencies, project owners, grade testing agencies, and the construction site laboratory itself. The information sharing needs cover business processing needs, supervision and guidance needs, and collaborative management needs.

[0018] In this embodiment, the management of a construction site laboratory for a highway construction project is used as the application scenario. First, the information sharing needs assessment was initiated, and a dedicated needs research team was formed to communicate with the project's quality supervision agency, project owner, accredited testing agency, and the construction site laboratory itself. For the quality supervision agency, special seminars were held to understand their supervisory and guidance needs during the inspection of the construction site laboratory, including the types of test data they require in real time, report review progress, and early warnings of violations. For the project owner, questionnaires and on-site interviews were used to collect their business processing needs, such as the timeliness of the construction site laboratory's test results and their alignment with the project schedule. For the accredited testing agency, as the parent organization, the focus was on communicating their collaborative management needs regarding the personnel qualification management, equipment calibration, and the standardization of testing methods in the construction site laboratory. The construction site laboratory itself outlined its business processing needs in daily testing operations, including information entry, report generation, and internal review. The research team compiled and organized the various needs collected, forming a detailed list covering different types of needs from various stakeholders. For example, the supervision and guidance needs of quality supervision agencies include monthly statistical analysis reports on test data and tracking of non-conformities; the business processing needs of project owners include real-time push notifications of raw material entry test results and approval processes for mix design schemes.

[0019] Step S120: Build a multi-subject adaptation module using the .NET development framework. Based on the collected information sharing requirements, select and combine functional modules from the .NET development framework to complete the construction of the multi-subject adaptation module.

[0020] In the aforementioned highway construction project scenario, based on the multi-entity information sharing requirements collected in step S110, a multi-entity adaptation module was built. First, the .NET development framework was comprehensively reviewed to identify the functional modules available to meet the needs of each entity. Then, appropriate functional modules were selected and combined according to the specific needs of different entities. For example, for the information collection needs of the construction site laboratory, the data entry module and form management module were selected; for the supervision and statistical needs of the quality supervision agency, the data statistical analysis module and report generation module were selected. During the selection process, the compatibility and interface matching between modules were fully considered to ensure that the combined modules could work collaboratively.

[0021] Step S121: Analyze the collected multi-subject information sharing requirements and break down the core functional requirements of each subject. The core functional requirements are based on the subject's role in the management of the construction site laboratory and cover information collection, information query, process approval, report generation and supervision statistics.

[0022] This embodiment provides an in-depth analysis of the multi-entity information sharing requirements collected in step S110. For the construction site laboratory itself, its core functional requirements include the collection of daily test data, such as the input of physical and mechanical property test data for raw materials like cement and steel bars; the ability to query historical test records and reports at any time; the approval process for internal circulation of test reports; and the report generation function for automatically generating standardized test reports based on test data. The core functional requirements of the quality supervision agency focus on the supervision and statistics of the overall work of the construction site laboratory, including the number of various types of test projects conducted and the statistics of non-compliance rates. The core functional requirements of the project owner mainly involve the querying of key test results and the approval of related processes, such as the querying and approval of bridge concrete strength test reports. The core functional requirements of the graded testing agency include the querying of information on the qualifications of personnel in the construction site laboratory and the supervision and statistics of the calibration status of testing equipment. Through the above analysis, the specific functional requirements of each entity in information sharing are clarified.

[0023] Step S122: Based on the component-based architecture design of the .NET development framework, extract the preset basic functional modules from the .NET development framework. The basic functional modules include a data storage module, an information transmission module, an access control module, a process engine module, and a template generation module.

[0024] In this highway construction project, a component-based architecture based on the .NET development framework was used to extract pre-defined basic functional modules. The data storage module stores various test data, entity information, approval records, etc., from the site laboratory, using a relational database to organize the data, ensuring structured storage and efficient retrieval. The information transmission module is responsible for real-time information transfer between multiple entities, using an HTTP-based interface for data interaction to ensure the stability and security of information transmission. The access control module strictly limits the operational scope of different entities based on their roles and permissions; for example, site laboratory personnel can only access data related to their own business, while quality supervision personnel can view all site laboratory supervision data. The workflow engine module drives the flow of information sharing and approval processes, automatically advancing approval nodes according to pre-defined rules. The template generation module creates various scenario-based shared information templates, such as raw material testing report templates and mix design templates.

[0025] Step S123: Match the core functional requirements of each subject with the basic functional modules, determine the basic functional module combination method corresponding to each core functional requirement, and obtain the matched basic functional module combination method. The basic functional module combination method is based on the interface compatibility definition of the functional modules.

[0026] For the core functional requirements of each entity analyzed in step S121, they are matched with the basic functional modules extracted in step S122. For example, the information collection function requirement of the construction site laboratory is matched with the data storage module and the information transmission module. The data storage module is used to store the collected data, and the information transmission module is used to upload the data to the system. The information query function requirement is mainly matched with the data storage module and the access control module. The access control module ensures that the query operation is performed within the authorized scope, and the data storage module provides the data source for the query. For the project owner's process approval requirement, the process engine module and the access control module are matched. The process engine module controls the progress of the approval process, and the access control module ensures that the owner has the approval authority. Through the above matching, the combination of basic functional modules required for each core functional requirement is determined. For example, the information collection function is implemented by combining the data storage module and the information transmission module, and the process approval function is implemented by combining the process engine module and the access control module, etc.

[0027] Step S1231: Analyze the component-based architecture implementation logic of the .NET development framework, and define the implementation mechanism of the component-based architecture in the .NET development framework. The implementation mechanism includes module encapsulation standards, interface definition specifications, and dependency management methods.

[0028] In this embodiment, the component-based architecture implementation logic of the .NET development framework is analyzed. The module encapsulation standard specifies the encapsulation format for each functional module, encapsulating the module's functional implementation code, configuration files, etc., into independent components, giving them good independence and portability. The interface definition specification clarifies the interface format, parameter requirements, and return value types for data interaction between modules. For example, the data storage module provides interfaces for data insertion, querying, updating, and deleting, each with specific input parameters and output data formats. The dependency management method is used to manage the dependencies between modules. When one module needs to call the functionality of another module, the required module is loaded through the dependency management mechanism, ensuring collaborative work between modules.

[0029] Step S1232: Traverse the module library of the .NET development framework, filter the preset basic function modules according to function type, and verify the integrity and availability of each module during the filtering process. The integrity refers to the module having complete function implementation code, and the availability refers to the module being able to run normally in the .NET development framework.

[0030] The module library of the .NET development framework is traversed, and basic functional modules are filtered according to their functional type, such as data processing, workflow control, and access control. During the filtering process, each module undergoes a completeness check to ensure it contains complete functional implementation code, configuration files, and necessary documentation. Simultaneously, usability testing is performed by deploying the modules to a test environment and simulating real-world business scenarios to check if the modules can respond correctly and perform their expected functions. For example, when testing the data storage module, data insertion and query operations are attempted to verify that data can be stored and retrieved correctly; when testing the workflow engine module, a simple approval workflow is configured to check if the workflow flows according to preset rules. Incomplete or unusable modules are promptly repaired or replaced.

[0031] Step S1233: Organize functional description documents for the selected basic functional modules. The functional description documents record in detail the function, input parameters, output results, calling method and interface specifications of each module. The interface specifications are formulated based on the standard interface specifications of the .NET development framework.

[0032] For the basic functional modules selected in step S1232, compile functional description documents. Taking the data storage module as an example, its function is described as achieving persistent storage of various test data; input parameters include data entity objects, such as raw material test data objects, containing attributes such as material name, test items, and test values; output results are indicators of whether the data operation was successful and related error messages; the calling method is through the API interface provided by the module; the interface specifications strictly follow the standard interface specifications of the .NET development framework, including interface name, parameter types, return value types, etc. By compiling the above functional description documents, developers can understand the function and usage of each module.

[0033] Steps S1234: Compare the organized basic functional module function description documents with the core functional requirements of each entity one by one. During the comparison process, pay attention to the degree of functional matching between the implementation requirements of the core functional requirements and the functions of the basic functional modules.

[0034] The functional description documents of the basic functional modules compiled in step S1233 are compared one by one with the core functional requirements of each subject parsed in step S121. For example, the core functional requirement of information collection in the construction site laboratory is compared with the functional description document of the data storage module to check whether the data storage module can meet the data storage requirements of information collection, including data type support and storage capacity; the core functional requirement of supervision and statistics in the quality supervision agency is compared with the functional description document of the data statistical analysis module to check whether the module can provide the required statistical analysis methods and report generation functions. During the comparison process, the degree of matching between each core functional requirement and the basic functional module is recorded in detail.

[0035] Step S1235: For the core functional requirements that can be met by a single basic functional module, determine that the basic functional module as the unique combination unit, and the combination method is to call the module separately.

[0036] During the comparison process, it was found that certain core functional requirements could be met by a single basic functional module. For example, the core functional requirement of information querying in the construction site laboratory can be achieved through the query interface provided by the data storage module, without the cooperation of other modules. In this case, the data storage module was determined to be the only unit for combining this core functional requirement, and the combination method is to call this module independently. In the system implementation, logic is configured to call the query interface of the data storage module independently for this core functional requirement, ensuring that users can directly obtain the required query information through this module.

[0037] Step S1236: For core functional requirements that require the collaborative implementation of multiple basic functional modules, analyze the functional complementarity and interface compatibility of each basic functional module.

[0038] For some more complex core functionalities, such as the test report generation function in a construction site laboratory, multiple basic functional modules need to work together. In this case, it's crucial to analyze the functional complementarity and interface compatibility of these modules. The report generation function requires a data storage module to provide test data, a template generation module to provide report templates, and an information transmission module to transmit the generated report to the relevant parties. This involves analyzing whether the data storage module can provide the required data format and content for report generation, whether the template generation module can dynamically populate the template based on the data, and whether the information transmission module can correctly transmit the generated report file. Simultaneously, it's essential to check the compatibility of the interfaces between modules, whether the output data format of the data storage module matches the input requirements of the template generation module, and whether the report file format generated by the template generation module conforms to the transmission standards of the information transmission module.

[0039] Step S1237: Based on functional complementarity and interface compatibility, determine the combination order and interaction relationship of multiple basic functional modules. The combination order is set according to the logical order of function implementation, and the interaction relationship is defined based on the input and output parameters of the modules.

[0040] After determining that multiple basic functional modules need to collaborate to achieve the core functional requirements, the combination order and interaction relationships are determined based on functional complementarity and interface compatibility. Taking the test report generation function as an example, the combination order is set as follows: first, the data storage module is called to obtain the test data; then, the data is passed to the template generation module to generate the report; finally, the information transmission module is called to send the report to the relevant parties. Regarding the interaction relationships, the output parameter of the data storage module is the test data set, which serves as the input parameter for the template generation module; the output parameter of the template generation module is the generated report file, which serves as the input parameter for the information transmission module. Through the above combination order and interaction relationships, it is ensured that the modules can smoothly transfer data and call functions to each other, jointly achieving the core functional requirements.

[0041] Step S1238: Configure a unified call entry point for the combined multiple basic functional modules. The call entry point provides a simple operation interface for the main body and triggers the collaborative operation mechanism of the combined modules through the unified call entry point.

[0042] A unified entry point is configured for the combined basic functional modules to facilitate main operations. For example, in the operation interface of the construction site laboratory, a "Generate Test Report" button is set as the unified entry point. When the user clicks this button, the system automatically triggers the collaborative operation mechanism of the data storage module, template generation module, and information transmission module. Users do not need to operate each module separately; they can complete the generation and sending of test reports through this unified entry point, improving the convenience and efficiency of operation.

[0043] Step S1239: Test the combination of the determined basic functional modules. The test content includes the functional implementation effect, running efficiency and stability of the combined modules. The test scenario simulates the business scenario in which the main body actually uses the core functional requirements.

[0044] The determined combination of basic functional modules was tested. Taking the module combination for generating test reports as an example, a scenario was simulated where laboratory personnel at a construction site generate concrete compressive strength test reports in actual business operations. The functionality was tested to ensure it was effective, checking whether the generated reports contained all necessary test data and information, and whether the format conformed to specifications. Operational efficiency was tested by recording the time required from clicking the generate button to report generation completion. Stability was tested by repeatedly performing report generation operations and observing whether the system crashed, displayed data errors, or exhibited other anomalies. These tests verified the feasibility and reliability of the module combination method.

[0045] Step S12310: Based on the test results, adjust the combination method of the basic functional modules, optimize the combination order and interaction relationship; for functional modules that fail to achieve the core functional requirements in the test, or cause errors when interacting with other modules, remove them from the current combination, and select other basic functional modules with matching functional descriptions from the module library of the .NET development framework for replacement and retesting.

[0046] Based on the test results of step S1239, adjust the combination method of the basic functional modules. If the test reveals that a certain module frequently experiences data transmission errors when interacting with other modules, the cause may be interface incompatibility. In this case, consider selecting another module with similar functionality but more compatible interfaces from the .NET framework module library for replacement. After replacement, retest until the combined modules can stably and efficiently achieve the core functional requirements. For example, if the original data storage module is inefficient when querying large amounts of data, replace it with a higher-performance data storage module and retest the efficiency of the report generation function.

[0047] Step S124: For the matched basic functional module combination, configure the interaction interface parameters between the modules and set them based on the standard interface specifications of the .NET development framework. The interaction interface parameters are set according to the data transmission requirements between different basic functional modules.

[0048] After determining the combination of basic functional modules, configure the interaction interface parameters between modules. For example, when the data storage module interacts with the template generation module, the data storage module needs to transmit experimental data to the template generation module. In this case, configure the data transmission format to JSON, including fields such as the experimental project name, detection value, and standard value. Simultaneously, set parameters such as the data transmission timeout and number of retries to ensure the reliability of data transmission. The configuration of the above interaction interface parameters strictly adheres to the standard interface specifications of the .NET development framework, ensuring that the modules can correctly and efficiently exchange data.

[0049] Step S125: Based on the multi-subject information sharing requirements, identify functional requirements involving interaction or collaboration between two or more subjects, define them as cross-subject collaborative functional requirements, and select corresponding collaborative functional modules based on the collaborative functional requirements. The collaborative functional requirements include cross-subject information flow, joint approval, and collaborative supervision.

[0050] Based on the multi-entity information sharing needs collected in step S110, cross-entity collaborative function requirements are identified. For example, in this highway construction project, raw material testing reports require review by multiple entities, including on-site laboratory review, project owner approval, and quality supervision agency review. This falls under the category of cross-entity joint approval function requirements. To address such requirements, a collaborative function module, such as a cross-entity process collaboration module, is selected from the .NET development framework. This module supports collaborative operations by multiple entities in the approval process, enabling the flow and processing of information between different entities.

[0051] Step S126: Integrate the selected collaborative function modules with the basic function modules of each subject, and construct the initial architecture of the multi-subject adaptation module based on the integrated function module set. In the initial architecture, define the hierarchical relationship and data interface specifications of each function module according to the calling dependency relationship and data processing order between modules.

[0052] The selected collaborative functional modules are integrated with the basic functional modules of each entity. For example, the cross-entity process collaboration module can be integrated with the process approval module of the construction site laboratory and the access control module of the project owner. When constructing the initial architecture, based on the calling dependencies between modules (e.g., the cross-entity process collaboration module needs to call the process engine module to drive the approval process), the hierarchical relationship between modules is defined, with the process engine module as the underlying support module and the cross-entity process collaboration module as the upper-level application module. Simultaneously, the data interface specifications between modules are clearly defined, such as the interface format and content requirements for the cross-entity process collaboration module to pass approval process parameters to the process engine module.

[0053] Step S127: Adjust the resource allocation ratio of the functional modules in the initial architecture according to the priority of the information sharing needs of each subject. The resource allocation ratio is determined based on the resource load stress test results of each functional module under simulated concurrent call scenarios.

[0054] Based on the priority of information sharing needs among various stakeholders, the resource allocation ratios of functional modules in the initial architecture are adjusted. For example, the supervision and guidance needs of quality inspection agencies have a higher priority, requiring more computing and storage resources for their corresponding supervision statistics and data query modules. By simulating concurrent call scenarios, such as multiple stakeholders simultaneously performing data queries and report generation operations, the resource load of each functional module is tested. Based on the test results, for modules with high resource loads, their resource allocation ratios are appropriately increased to ensure stable system operation under high concurrency.

[0055] Step S128: Conduct module compatibility testing on the initial architecture, simulate the concurrent call scenario where multiple entities operate the corresponding functional modules simultaneously, test the running stability of each functional module, and perform the following operations according to the compatibility test results: adjust the parameters and call logic of the interaction interfaces between functional modules; reallocate the computing and storage resource quotas according to the resource utilization rates of each module during the test; remove the connections between modules that are not called or conflict during the test; create new interfaces for cross-module interactions discovered during the test to obtain a shared support architecture.

[0056] Conduct module compatibility testing on the initial architecture and simulate the concurrent scenario of multiple entities operating simultaneously. For example, laboratory personnel at the construction site enter test data, the project owner approves reports simultaneously, and the quality supervision agency queries supervision data. During the test, monitor the running status of each functional module and check for compatibility issues such as data conflicts and interface call failures. According to the test results, adjust the parameters of the interaction interfaces between functional modules, such as increasing the buffer size for data transmission to solve the problem of data loss; reallocate resource quotas, such as increasing the memory allocation of modules that often experience resource shortages; remove the connections between modules that are not called to reduce system resource waste; create new interfaces for necessary cross-module interactions, such as creating a new data transmission interface between the data statistical analysis module and the report generation module to meet the requirements of the supervision and statistics function. After these operations, obtain the final shared support architecture.

[0057] Step S130: Based on the multi-entity adaptation module, set up transfer nodes according to the types of sharing requirements, and associate corresponding entity operation permissions with each transfer node to dynamically configure the information sharing approval process.

[0058] In the above highway construction project, based on the established multi-entity adaptation module, start dynamically configuring the information sharing approval process. According to different types of sharing requirements, such as business processing, supervision and guidance, and collaborative management, set the corresponding transfer nodes respectively. For example, in the approval process of the raw material inspection report in the business processing type of requirement, set transfer nodes such as information submission, internal review, result confirmation, and information release. At the same time, associate corresponding entity operation permissions with each transfer node, such as associating the operation permission of the laboratory testing personnel at the construction site with the information submission node, and associating the operation permission of the technical person in charge of the laboratory at the construction site with the internal review node. Through the above configuration, realize the dynamic management of the information sharing approval process.

[0059] Step S131: Classify the information sharing needs of multiple entities into business processing needs, supervision and guidance needs, and collaborative management needs. Among them, business processing needs originate from the testing and inspection business processes of the construction site laboratory; supervision and guidance needs originate from the supervision and inspection processes of quality supervision agencies or project owners; and collaborative management needs originate from management processes that require the joint participation of multiple entities.

[0060] In this embodiment, the information sharing needs of multiple entities are categorized. Business processing needs include daily data entry, report generation, and internal review for on-site laboratories, which directly originate from various stages of the testing and inspection business process. Supervision and guidance needs, such as the supervision and inspection of the testing process by quality supervision agencies and the review and approval of test results by project owners, stem from the supervision and inspection processes of relevant entities. Collaborative management needs, such as the management of equipment calibration by accredited testing institutions and the joint review of major testing plans by multiple entities, require the joint participation of multiple entities.

[0061] Step S132: For business processing requirements, arrange the basic workflow nodes of the information sharing approval process according to the business process sequence of the construction site laboratory. The basic workflow nodes include information submission node, internal review node, result confirmation node and information release node.

[0062] For business processing needs, basic workflow nodes are set according to the business process of the construction site laboratory. Taking cement physical performance testing as an example, firstly, the testing personnel enter the cement test data at the information submission node, including fineness, setting time, compressive strength, etc.; then it flows to the internal review node, where the laboratory technical head reviews the accuracy and completeness of the test data; after the review is passed, it enters the result confirmation node, where the laboratory director makes the final confirmation of the test results; after confirmation, the test report is released to relevant parties, such as project owners and construction units, at the information release node.

[0063] Step S133: For supervision and guidance requirements, add a supervision and review node and a feedback node to the basic circulation node. The supervision and review node is operated by the quality supervision agency or the project owner, and the feedback node is used by the site laboratory to receive supervision opinions.

[0064] For supervisory and guidance requirements, a supervisory review node and a feedback node are added to the basic workflow nodes. For example, when a quality supervision agency conducts a supervisory review of the monthly quality report of a construction site laboratory, the report, after passing through the information submission, internal review, and result confirmation nodes within the construction site laboratory, flows to the supervisory review node, where personnel from the quality supervision agency review the report content. If problems are found during the review, supervisory opinions are fed back to the construction site laboratory through the feedback node, and the construction site laboratory resubmits the report for review after making corrections based on the opinions.

[0065] Step S134: For collaborative management requirements, integrate the approval nodes corresponding to each entity, and set up joint approval nodes and collaborative confirmation nodes. The joint approval node requires multiple entities to perform operation confirmation simultaneously, and the collaborative confirmation node is used to summarize the approval opinions of each entity.

[0066] For collaborative management needs, such as the approval of concrete mix design schemes for major bridge projects, it is necessary to integrate the approval processes of multiple entities, including grade testing institutions, project owners, and quality supervision agencies. A joint approval node is established, requiring all three entities to simultaneously approve the mix design scheme. Only after all entities have approved it can the scheme proceed to the next step. Simultaneously, a collaborative confirmation node is established to summarize the approval opinions of all entities. If differing opinions exist, negotiation and final confirmation are conducted at this node.

[0067] Step S135: Assign corresponding subject operation permissions to each flow node. The subject operation permissions are defined based on node functions and subject roles. Assign information submission nodes and internal review nodes to relevant personnel in the construction site laboratory, assign supervision and review nodes to quality supervision agencies and project owners, and assign joint approval nodes to all subjects participating in collaborative management.

[0068] Each workflow node is assigned specific operational permissions. Operational permissions for information submission and internal review nodes are assigned to relevant personnel in the site laboratory; for example, information submission is handled by testing personnel, and internal review by the technical lead. Operational permissions for oversight and review nodes are assigned to relevant personnel from the quality supervision agency and the project owner. Operational permissions for joint approval nodes are assigned to all entities involved in collaborative management, such as the technical lead of the testing agency, engineering management personnel from the project owner, and oversight engineers from the quality supervision agency. This permission allocation ensures that each node's operation is completed by the corresponding entity, guaranteeing the standardization and security of the approval process.

[0069] Step S136: Configure operation time limit requirements for each circulation node. The operation time limit requirements are set through the following steps: allocate a basic time limit range according to the sharing demand type to which the circulation node belongs; then, according to the preset node importance classification rules, assign specific duration values ​​to nodes of different importance levels within the basic time limit range.

[0070] Configure operation time limits for each workflow node. For example, the basic time limit range for business processing requirements is set to 1 to 3 working days, for supervision and guidance requirements to 3 to 5 working days, and for collaborative management requirements to 5 to 7 working days. Preset node importance classification rules, dividing nodes into three levels: important, relatively important, and general. For internal review nodes within business processing requirements, due to their important level, they are assigned a specific duration of 2 working days within the basic time limit range of 1 to 3 working days; information submission nodes, with a general importance level, are assigned a duration of 1 working day.

[0071] Step S137: Set the jump rules for the flow nodes. The jump rules are defined based on the node operation results. If the operation result is passed, jump to the next flow node. If the operation result is rejected, jump to the previous related flow node. The jump rules are designed according to the business logic progression order.

[0072] Define the jump rules for workflow nodes. Taking the raw material testing report approval process as an example, if the information submission node operation result is "pass," jump to the internal review node; if the internal review node operation result is "pass," jump to the result confirmation node; if the result confirmation node operation result is "pass," jump to the information release node. If the internal review node operation result is "reject," jump back to the information submission node, where the testing personnel must revise and resubmit. The jump rules are designed strictly according to the business logic progression sequence to ensure a smooth approval process.

[0073] Step S138: Enter the configured flow nodes, subject operation permissions, operation time limit requirements and jump rules into the process engine module of the multi-subject adaptation module. The process engine module completes the rule storage based on the process configuration interface of the NET development framework.

[0074] The configured workflow nodes, subject operation permissions, operation time limits, and jump rules are entered into the workflow engine module of the multi-subject adaptation module. The workflow engine module stores these rules in the system database through the workflow configuration interface of the .NET development framework. For example, the information of each node in the raw material testing report approval process, permission configuration, time limit requirements, and jump rules are stored in a structured data format so that the workflow engine module can read and execute these rules at runtime.

[0075] Step S139: Generate an initial approval process through the process engine module. In the initial approval process, define the operating subject, operation content and time requirements of each node. The operation content is matched according to the node function.

[0076] The workflow engine module generates an initial approval process based on the entered rules. This initial approval process clearly defines the operating entity for each node, such as the testing personnel for the information submission node; the operation content, such as entering raw material testing data for the information submission node; and the time requirement, such as the information submission node needing to be completed within one business day. The operation content and node function strictly correspond and match, ensuring that the operation at each node meets business requirements.

[0077] Step S1310: Associate the initial approval process with the corresponding requirement type and store it. Establish a mapping relationship between requirement type identifier and approval process identifier in the system configuration. When the information sharing requirement of the preset type is triggered, call the approval process pointed to by the corresponding approval process identifier according to the mapping relationship.

[0078] The initial approval process is associated with its corresponding requirement type for storage; for example, the raw material testing report approval process is associated with a business processing requirement. In the system configuration, a unique requirement type identifier is assigned to each business processing requirement, and a unique approval process identifier is assigned to each raw material testing report approval process, establishing a mapping relationship between the two. When site laboratory personnel trigger a requirement to share raw material testing report information, the system looks up the corresponding approval process identifier based on the requirement type identifier, and then invokes the raw material testing report approval process.

[0079] Step S140: Using a front-end tool with table editing capabilities, integrate shared information items according to business scenarios, and associate the shared information items with the corresponding flow nodes in the information sharing approval process to generate scenario-based shared information templates.

[0080] In this highway construction project, tools with front-end spreadsheet editing capabilities, such as online spreadsheet tools similar to Excel, were used to integrate shared information items according to business scenarios. Taking the raw material testing scenario as an example, shared information items such as raw material name, specifications, manufacturer, testing items, testing standards, and testing results were integrated. These information items were then associated with corresponding workflow nodes in the information sharing approval process. For example, testing items and testing results were linked to internal review nodes, allowing reviewers to focus on these key information during the review process. Through these operations, a scenario-based shared information template for the raw material testing scenario was generated.

[0081] Step S141: Divide the core business scenarios of the construction site laboratory. The core business scenarios include raw material testing scenario, mix design scenario, physical quality testing scenario, equipment calibration scenario, and test report review scenario.

[0082] The core business scenarios of the construction site laboratory can be divided into the following: Raw material testing scenario, which covers the testing of various performance indicators of raw materials such as cement, steel bars, and sand used in the project; Mix design scenario, which involves the mix design and optimization of mixtures such as concrete and asphalt; Physical quality testing scenario, which includes the testing of quality indicators such as strength, thickness, and flatness of the constructed engineering structure; Equipment calibration scenario, which mainly involves the periodic calibration and maintenance records of various testing equipment in the laboratory; and Test report review scenario, which involves the preparation, review, and issuance of various test reports.

[0083] Step S142: For each core business scenario, extract the information items that multiple entities need to share under that core business scenario. The information items are defined based on the business process of the scenario and the information needs of each entity. Among them, the information items of the raw material testing scenario include basic information of raw materials, sample preparation information, testing data information, testing result information, and non-conformance handling information.

[0084] For each core business scenario, shared information items are extracted. Taking the mix design scenario as an example, the information items that multiple entities need to share include design basis, raw material performance parameters, mix design calculation process, trial mixing results, and adjustment plans. These information items are defined based on the business process of mix design, such as raw material inspection, mix design calculation, trial mixing verification, and the information needs of various entities, including the project owner's concern for the rationality of the mix design and the quality supervision agency's supervision of the compliance of the design process.

[0085] Step S143: Based on the business process, sort out the generation order and dependency relationship of information items in each business scenario. The generation order and dependency relationship are defined according to the information transmission and processing logic in the business process.

[0086] Based on the business process, the generation order and dependencies of information items are analyzed. Taking the physical quality inspection scenario as an example, the business process is on-site sampling, sample delivery, laboratory testing, data processing, and result determination. The corresponding generation order of information items is: basic sample information (generated in the on-site sampling stage), sample delivery information (generated in the sample delivery stage), raw testing data information (generated in the laboratory testing stage), data processing result information (generated in the data processing stage), and quality determination result information (generated in the result determination stage). In terms of dependencies, raw testing data information depends on sample delivery information, data processing result information depends on raw testing data information, and quality determination result information depends on data processing result information.

[0087] Step S144: Launch the table tool with table editing function on the front end, design the table structure of the template based on the logical relationship of the information items, and set the input position, data type and display format of the information items in the table structure. The data types include text, numeric, date and attachment types, and the display format is designed according to the display requirements of the information items.

[0088] Launch the front-end spreadsheet tool and design the template's table structure based on the logical relationships between information items. Taking equipment calibration as an example, the columns of the table structure correspond to information items such as equipment name, model and specifications, calibration date, calibration organization, calibration result, and next calibration date. Set the equipment name as text type and enter it in the first column of the table; the calibration date as date type and enter it in the third column, displaying the format as year-month-day; the calibration result as text type, with options such as "qualified," "unqualified," and "restricted use"; the calibration certificate is set as an attachment-type information item in the last column of the table, supporting file upload.

[0089] Step S145: Configure input verification rules for each information item in the table tool. The input verification rules are defined according to the data type, business rules and format requirements of the information item. Among them, text information items are limited according to the character length specification, and numerical information items are specified according to the data format standard. The verification rules take effect automatically when the information is entered.

[0090] Configure data entry validation rules for each information item in the spreadsheet tool. For text-based raw material name information items, set the character length limit to between 1 and 50 characters; for numerical concrete compressive strength test value information items, set the data format to numbers with two decimal places, and the value range to 95% to 115% of the design strength grade. When the user enters information, the validation rules automatically take effect. If the entered raw material name exceeds 50 characters, or the compressive strength test value exceeds the set range, the system will display a prompt message requiring the user to re-enter the information.

[0091] Step S146: Extract the information sharing approval process nodes corresponding to the business scenario, associate each approval process node with the relevant information items in the template to obtain the association relationship. The association relationship is defined based on the operation content of the node. Among them, the internal audit node is associated with the detection data information and the detection result information, and the supervision audit node is associated with the detection result information and the non-compliance handling information.

[0092] Extract the information sharing approval process nodes corresponding to the business scenario and associate them with the information items in the template. Taking the test report review scenario as an example, its approval process nodes include the report preparation node, internal review node, owner approval node, and quality supervision filing node. Associate the report preparation node with the basic report information and test data information; associate the internal review node with the test data information and test result information; associate the owner approval node with the test result information and conclusion recommendation information; and associate the quality supervision filing node with all information items in the entire report.

[0093] Step S1461: Retrieve the information sharing approval process corresponding to the business scenario from the process engine module of the multi-subject adaptation module, parse the complete structure of the approval process, define the name, operating subject and operation content of all flow nodes, and the operation content describes in detail the information to be processed and the operation to be performed by the flow node.

[0094] The information-sharing approval process corresponding to the test report review scenario is retrieved from the process engine module of the multi-entity adaptation module, and its complete structure is analyzed. This approval process includes a report preparation node, an internal review node, an owner approval node, and a quality supervision filing node. The operator of the report preparation node is the testing personnel, whose task is to enter the basic information, test data, and results of the test report. The operator of the internal review node is the technical head, whose task is to review the accuracy of the test data and the standardization of the report. The operator of the owner approval node is the project owner representative, whose task is to review whether the report conclusions meet the engineering requirements. The operator of the quality supervision filing node is the personnel of the quality supervision agency, whose task is to register the report.

[0095] Step S1462: Return the scenario-based shared information template for this business scenario, and parse the name, data type and purpose of all information items in the scenario-based shared information template. The purpose is defined based on the role of the information item in the business process, including recording data, supporting approval and generating reports.

[0096] Returning to the scenario-based shared information template for the test report review, we parse the information items. These items include: Report Number (text type, used to uniquely identify the report), Project Name (text type, recording the project it belongs to), Test Items (text type, recording the specific items being tested), Test Data (numerical type, used to record the raw data from the test), Test Results (text type, recording the judgment results on the test data), and Review Comments (text type, supporting the approval process). The test data is used to record data, and the review comments are used to support the approval process. All information items work together to generate a complete test report.

[0097] Step S1463: Compare the operation content of each flow node with the purpose of the information items in the template, identify the information items involved in the operation content, and use the information items involved as the information items that the flow node needs to process or refer to.

[0098] The operation content of each flow node is compared with the purpose of the information items. The operation content of the internal audit node is to audit the accuracy of the test data and the standardization of the report. It is related to the purpose of the test data (used for recording data) and the basic information of the report (used for generating the report) in the template. Therefore, the test data and the basic information of the report are identified as the information items that need to be processed or referenced by this node.

[0099] Step S1464: Establish a list of associated information items for each flow node. The list of associated information items records the names, data types, and positions of all information items corresponding to the flow node in the scenario-based shared information template.

[0100] Create a list of associated information items for each internal audit node. The list records information items named "Detection Data" and "Basic Report Information," with data types of numeric and text, respectively. These items are located in column 3 and column 1 of the table template. This list clarifies the information items that need to be monitored at each node.

[0101] Step S1465: Add an association identifier field to the configuration file of the scenario-based shared information template. The association identifier field corresponds to each information item, and the field content is the name of the flow node associated with the information item and the operation requirements. The operation requirements include viewing, editing, and confirming.

[0102] In the configuration file of the scenario-based shared information template, add an association identifier field for the test data information item. The field content is "Internal review node - view, edit; owner approval node - view", which means that the test data information item can be viewed and edited in the internal review node, and can only be viewed in the owner approval node.

[0103] Step S1466: Configure the operation permissions of the transfer node for the associated information items. The operation permissions are determined based on the role and permission scope of the transfer node's operation subject and the preset security level or sensitivity level of the associated information items.

[0104] Configure the internal review node's access permissions for test data information items. The technical lead is the primary user of the internal review node, and their role permissions include the right to review the test data. The default security level for the test data information items is "normal," therefore, the technical lead is granted viewing and editing permissions for the test data information items.

[0105] Step S1467: Establish an index table of associations, in which the names of the transfer nodes, the list of associated information items, operation permissions, and configuration time are recorded.

[0106] An index table is established to establish relationships, with each row recording: the name of the flow node "Internal Audit Node", the list of associated information items "Detection Data, Report Basic Information", the operation permissions "View, Edit", and the configuration time "Current System Time". This index table allows the system to quickly query the relationships between each node and information item.

[0107] Step S1468: Deploy the association verification function in the multi-subject adaptation module. The association verification function runs automatically when the template is called and the approval process is advanced to verify whether the association between the flow node and the information item is valid. Valid association means that the node operation can normally obtain and process the corresponding information item.

[0108] Deploy the association verification function in the multi-entity adaptation module. When the template for the test report review scenario is called, the association verification function automatically checks whether the internal review node can normally obtain the test data and basic report information; when the approval process progresses to the internal review node, it verifies again whether the node's operation permissions for the associated information items are valid. If it is found that the node cannot obtain the information items or the operation permissions do not match, the association is determined to be invalid and an error message is issued.

[0109] Step S1469: Based on the results of the association verification function, correct invalid associations. Invalid associations include missing information items and mismatched operation permissions. Correction methods include re-associating information items and adjusting operation permissions.

[0110] If the association verification function finds that a certain information item associated with an internal audit node is missing, such as the "Testing Method" information item being deleted from the template, then the "Testing Standard" information item will be reassigned to that node as a replacement. If an operation permission mismatch is found, such as granting the technical manager editing permission for the "Owner's Opinion" information item, but the preset confidentiality level of this information item is confidential and the technical manager does not have this permission, then the operation permission will be adjusted to viewing permission.

[0111] Step S14610: Synchronize the corrected association relationships, association identifier fields, and index table to the template management module and the process engine module, so that the association between the scenario-based shared information template and the information sharing approval process node remains effective in subsequent use.

[0112] The revised relationships, association identifier fields, and index tables are synchronized to the template management module and the process engine module. The template management module updates the stored scenario-based shared information template configurations, and the process engine module updates the association rules between approval process nodes and information items to ensure that the association between scenario-based shared information templates and approval process nodes remains effective during subsequent template calls and approval process progression.

[0113] Step S147: Set the approval node identifier in the template. The approval node identifier is marked in the corresponding position of the associated information item. The identifier content includes the node name and the operating subject.

[0114] In the scenario-based shared information template, next to the table cell containing the detection data information item associated with the internal review node, an approval node identifier is set with the content "Internal Review Node - Technical Leader" so that users can clearly understand the associated node and operating entity of this information item in the approval process.

[0115] Step S148: For shared information items across business scenarios, set information association identifiers in the template, wherein the information association identifiers link the same information items in different business scenario templates.

[0116] For shared information items across business scenarios, such as "project name" which exists in both the raw material inspection scenario and the physical quality inspection scenario templates, an information association identifier is set for this information item in the template. This identifier links the "project name" information item in the two scenario templates, enabling information sharing and synchronous updates.

[0117] Step S149: Using the template saving function of the table tool, save the designed table structure, input verification rules, approval node associations and information association identifiers to generate the initial shared information template for this business scenario.

[0118] After completing the template design, use the template saving function of the spreadsheet tool to save the designed table structure, data entry validation rules, approval node associations, and information association identifiers, generating an initial shared information template for the raw material inspection scenario. Upon saving, the system automatically assigns a unique template identifier for subsequent retrieval and management.

[0119] Step S1410: Import the initial shared information template into the template management module of the multi-subject adaptation module. The template management module stores the complete structure and configuration information of the template, and establishes an association mapping between the template and business scenarios and approval processes.

[0120] The initial shared information template is imported into the template management module of the multi-entity adaptation module. The template management module stores the complete structure and configuration information of the template in the database and establishes an association mapping between the template and the raw material testing business scenario and the raw material testing report approval process, enabling the system to quickly call the corresponding template according to the business scenario and approval process.

[0121] Step S150: Based on the scenario-based shared information template, perform targeted information sharing among multiple entities, collect shared feedback information submitted by multiple entities, and optimize the functional combination of the multi-entity adaptation module and the configuration of the information sharing approval process according to the shared feedback information.

[0122] In this highway construction project, targeted information sharing among multiple entities is implemented based on generated scenario-based shared information templates. For example, after the site laboratory uses the raw material testing scenario template to enter cement testing information, it is pushed to the project owner and quality supervision agency through the system. After reviewing the shared information, the project owner and quality supervision agency submit feedback information through the system, such as evaluations of the information's completeness and usability, and suggestions for optimization. The system collects this feedback information to optimize the functional combination of multi-entity adaptation modules and the configuration of the information sharing approval process.

[0123] Step S151: Based on the current business operations of the on-site laboratory, determine the target business scenario being executed. The target business scenario is defined based on the actual testing and inspection work being carried out, and multiple parallel target business scenarios may exist simultaneously.

[0124] Based on the actual operations of the site laboratory, the target business scenarios currently being implemented are determined. For example, at a certain stage, the site laboratory simultaneously conducts cement raw material testing, concrete mix design, and roadbed compaction testing. Therefore, the target business scenarios include raw material testing, mix design, and physical quality testing.

[0125] Step S152: Call the scenario-based shared information template corresponding to the target business scenario from the template management module of the multi-subject adaptation module. During the call, execute the template validity verification program. The template validity verification program checks in sequence: whether the structured configuration file of the scenario-based shared information template is complete and parsable; whether all required information items in the scenario-based shared information template have been defined; whether the approval process identifier associated with the scenario-based shared information template exists and is valid. Only when all the above checks pass, the scenario-based shared information template is determined to be valid.

[0126] The template management module retrieves the scenario-based shared information template corresponding to the raw material testing scenario. During the retrieval process, a template validity verification procedure is executed. First, it checks whether the template's structured configuration file is complete, including whether the table structure definition, validation rule configuration, etc., are complete and can be parsed by the system. Then, it checks whether all required information items in the template, such as raw material name, testing items, and testing results, are defined. Finally, it checks whether the raw material testing report approval process identifier associated with the template exists and is valid in the process engine module. Only when all checks pass is the template deemed valid and allowed to be used.

[0127] Step S153: Enter the corresponding business information based on the scenario-based shared information template. During the entry process, the entry verification rules of the scenario-based shared information template automatically standardize the entered information so that the entered information meets the preset format and requirements.

[0128] On-site laboratory testing personnel input cement testing information based on a valid, scenario-based shared information template for raw material testing. During the input process, the template's input verification rules automatically take effect. For example, when inputting cement compressive strength test values, the system automatically checks whether the data is numerical and within a reasonable range. If non-numerical data or data outside the range is entered, the system prompts an error and requires re-entry, ensuring that the input information conforms to the preset format and requirements.

[0129] Step S154: After the business information is entered, the information sharing approval process associated with the scenario-based shared information template is triggered. The information sharing approval process proceeds sequentially according to the preset flow nodes. The subject corresponding to each flow node receives the relevant information and performs the corresponding operation.

[0130] After the business information is entered, the testing personnel click the submit button, triggering the raw material testing report approval process. This raw material testing report approval process proceeds sequentially according to the preset information submission node, internal review node, result confirmation node, and information release node. After the information submission node is completed, the system automatically transfers the information to the internal review node. The technical manager receives the review notification, views and reviews the testing information, and after the review is passed, it flows to the result confirmation node, where the laboratory director confirms it. After confirmation that there are no errors, it flows to the information release node.

[0131] Step S155: Through the information transmission module of the multi-subject adaptation module, the operation results of each flow node are synchronized to the relevant subject, wherein the synchronization information includes operation status, operation opinion and operation time.

[0132] During the approval process, the information transmission module synchronizes the operation results of each workflow node to the relevant entities. For example, after the technical head of the internal review node approves the operation, the information transmission module synchronizes the operation status "approved," the operation comment "data accurate and compliant with specifications," and the operation time "current system time" to the testing personnel and the laboratory director, the entity responsible for the next result confirmation node.

[0133] Step S156: When the information sharing approval process progresses to the information release node, the complete shared information is pushed to the target audience through the information transmission module according to the preset list of shared objects. The list of shared objects is based on the definition of information sharing needs of multiple entities, and determines the receiving entity corresponding to each shared information.

[0134] When the approval process reaches the information release stage, the information transmission module pushes the complete cement test report to the project owner and the quality supervision agency according to the preset sharing object list. The sharing object list is defined based on the information sharing needs of multiple entities, specifying that the recipients of this type of raw material test report are the project owner's engineering management department and the supervision department of the quality supervision agency.

[0135] Step S157: The receiving subject obtains the shared information pushed to the target through the information query function of the multi-subject adaptation module. During the query process, the operation permission of the receiving subject is verified. The operation permission verification is performed based on the preset subject operation permission configuration.

[0136] Project owners and quality supervision agencies can obtain the pushed cement test reports through the information query function of the multi-entity adaptation module. During the query process, the system verifies the operating permissions of the receiving entity. For example, personnel from the project owner's engineering management department have the permission to view the report, while personnel from other departments do not. The permission verification is performed based on the preset entity operating permission configuration to ensure secure access to information.

[0137] Step S158: After obtaining the shared information, the receiving subject enters the shared feedback information through the feedback input interface of the multi-subject adaptation module. The feedback input interface provides a structured form for the subject to fill in the information completeness evaluation, information usability evaluation, process convenience evaluation, and optimization suggestions.

[0138] After obtaining the shared information, project owners and quality supervision agencies enter the shared feedback information through the system's feedback entry interface. The feedback entry interface provides a structured form, including text boxes for information completeness evaluation (e.g., "complete", "mostly complete", "incomplete"), information usability evaluation (e.g., "high", "medium", "low"), process convenience evaluation (e.g., "convenient", "average", "cumbersome"), and optimization suggestion text boxes. The recipients fill in the form according to the actual situation.

[0139] Step S159: The feedback collection module of the multi-subject adaptation module collects the shared feedback information submitted by all receiving subjects in real time, and records the feedback subject identifier, feedback time and feedback content during the collection process.

[0140] The feedback collection module collects shared feedback information submitted by project owners and quality supervision agencies in real time. During the collection process, it records the feedback subject identifier, such as "Project Owner - Engineering Management Department - Zhang San" or "Quality Supervision Agency - Supervision Section - Li Si"; the feedback time, such as "Year-Month-Day Hour:Minute:Second"; and the feedback content, such as information completeness evaluation "Complete", information usability evaluation "High", process convenience evaluation "Convenient", and optimization suggestion "Suggestion to add testing equipment information".

[0141] Step S1510: Through the feedback collection module, the collected shared feedback information is classified and stored according to the target business scenario and feedback type, and the relationship between feedback information and shared information and approval process is established.

[0142] The feedback collection module categorizes and stores the collected shared feedback information according to the target business scenario (such as raw material testing scenario) and feedback type (such as information integrity evaluation, information usability evaluation, etc.). At the same time, it establishes a correlation between feedback information and corresponding cement testing shared information and raw material testing report approval processes, so that each piece of feedback information can be traced back to the relevant shared information and approval processes.

[0143] For example, step S15101: Extract all collected shared feedback information from the feedback collection module, and parse the metadata of each piece of feedback information. The metadata includes the feedback subject identifier, feedback time, target business scenario identifier, shared information identifier, and approval process identifier.

[0144] Extract all shared feedback information from the feedback collection module and parse the metadata of each piece of information. For example, the metadata of a piece of feedback information is: feedback subject identifier "Project Owner-Engineering Management Department-Zhang San", feedback time "2024-05-20 10:30:00", target business scenario identifier "Raw Material Testing Scenario", shared information identifier "Cement Testing Report-20240520001", and approval process identifier "Raw Material Testing Report Approval Process-001".

[0145] Step S15102: Perform preliminary classification of shared feedback information according to the target business scenario identifier, group feedback information corresponding to the same target business scenario identifier into one category, and form a set of feedback information based on business scenario.

[0146] The shared feedback information is initially categorized according to the target business scenario identifier. All feedback information identified as "raw material testing scenario" is grouped into one category to form the raw material testing scenario feedback information set; feedback information identified as "mixing ratio design scenario" is grouped into another category to form the mixing ratio design scenario feedback information set.

[0147] Step S15103: In the feedback information set of each business scenario, perform secondary classification according to feedback type. The feedback type includes information integrity evaluation, information usability evaluation, process convenience evaluation, and optimization suggestions.

[0148] In the feedback information set of raw material testing scenarios, secondary classification is performed according to feedback type. Feedback information evaluated as "complete," "mostly complete," and "incomplete" is categorized separately; feedback information evaluated as "high," "medium," and "low" in terms of information usability is categorized separately; process convenience evaluation and optimization suggestions are also categorized according to their respective types.

[0149] Step S15104: Assign a unique classification identifier to each subset of categorized feedback information. The classification identifier is a combination of a business scenario identifier and a feedback type identifier.

[0150] Assign a unique category identifier to each subset of categorized feedback information. For example, the subset of feedback information evaluated as "complete" in the raw material testing scenario is categorized as "Raw Material Testing Scenario - Information Completeness Evaluation - Complete"; the subset of feedback information providing optimization suggestions in the mix design scenario is categorized as "Mix Design Scenario - Optimization Suggestions".

[0151] Step S15105: Extract the shared information identifier and approval process identifier corresponding to each feedback message, and find the corresponding shared information content and approval process configuration information based on these two identifiers. The shared information content includes the entered business information and shared template structure, and the approval process configuration information includes the flow node and operation time limit.

[0152] Extract the shared information identifier and approval process identifier corresponding to each feedback message. Based on the shared information identifier "Cement Testing Report-20240520001", find the corresponding shared information content, including the entered cement testing business information (such as test values, standard values, etc.) and shared template structure (such as table column definitions, verification rules, etc.). Based on the approval process identifier "Raw Material Testing Report Approval Process-001", find the corresponding approval process configuration information, including the flow nodes (information submission, internal review, etc.) and operation time limits (information submission node 1 working day, etc.).

[0153] Step S15106: Establish a relationship table between feedback information, shared information, and approval process. The relationship table records the feedback information identifier, shared information identifier, core content of shared information, approval process identifier, core configuration of approval process, and associated time. Among them, the core content of shared information is extracted from the shared information according to preset rules, which includes a combination of fields containing business entity identifier, key data items, and final conclusion. The core configuration of approval process is extracted from the approval process configuration information according to preset rules, which includes a combination of fields containing process start conditions, core flow node sequence, and end conditions.

[0154] Establish a relationship table, with one record as follows: Feedback information identifier "FK20240520001", shared information identifier "Cement Test Report-20240520001", shared information core content "Business entity identifier: Cement; Key data item: Compressive strength 32.5MPa; Final conclusion: Qualified", approval process identifier "Raw material test report approval process-001", approval process core configuration "Process start condition: Test data entry completed; Core flow node sequence: Information submission → Internal review → Result confirmation → Information release; End condition: Information release completed", and associated time "2024-05-20 10:35:00".

[0155] Step S15107: Using the database storage function of the multi-subject adaptation module, the categorized feedback information subset, category identifier and association table are stored according to a preset storage structure. The storage structure is defined based on data query efficiency and storage security, and the storage area is divided according to business scenarios using a partitioned storage method.

[0156] Utilizing the database storage function of the multi-subject adaptation module, the categorized subset of feedback information, category identifiers, and relationship tables are stored in the database. A partitioned storage approach is adopted, storing feedback information from raw material testing scenarios in one partition and those from mix design scenarios in another partition to improve data retrieval efficiency. Simultaneously, the stored data is encrypted to ensure storage security.

[0157] Step S15108: Configure a data backup strategy to periodically back up the stored feedback information, classification identifiers, and relationship tables. The backup frequency is determined based on the update speed of the feedback information.

[0158] Configure a data backup strategy. Since feedback information is added and updated daily, set up an incremental backup to be performed every day at midnight, and a full backup to be performed every Sunday. Backup data is stored on a separate backup server to prevent data loss.

[0159] Step S15109: According to the preset data lifecycle management strategy, the stored feedback information is cleaned up periodically; the data lifecycle management strategy stipulates that: feedback information records whose storage time exceeds the preset period are filtered out, and it is checked whether they have been associated with queries or used for optimization analysis within the preset recent time period. For records that have exceeded the storage period and have not been accessed within the recent time period, they are migrated to the archive database or physically deleted, and the feedback information identifier, cleanup time and cleanup strategy terms are recorded in the operation log.

[0160] Based on the data lifecycle management strategy, the storage period for feedback information is set to 2 years. Feedback information records stored for more than 2 years are periodically filtered out and checked to see if they have been linked for queries or used for optimization analysis within the last 6 months. Records that have exceeded their storage period and have not been accessed within the last 6 months are migrated to the archive database. The feedback information identifier for cleanup is recorded in the operation log, such as "FK20220510001", the cleanup time "2024-05-10 02:00:00", and the policy terms for execution of the cleanup: "Storage period exceeds 2 years and no access records in the last 6 months".

[0161] Step S1511: Based on the shared feedback information corresponding to each target business scenario, focus on the content of functional modules involved in the information usability evaluation and optimization suggestions, and filter out the feedback information for functional deficiencies, functional redundancy and functional interaction problems.

[0162] Based on shared feedback from various target business scenarios, the focus is on the functional modules involved in the information usability evaluation and optimization suggestions. For example, in the feedback from the raw material testing scenario, the information usability evaluation was "medium," and the optimization suggestion mentioned "wanting to add a testing data trend analysis function," which is a function missing issue; another feedback message mentioned that "some report types in the report generation module have never been used," which is a function redundancy issue; and yet another feedback message pointed out that "data transmission between the data entry module and the data statistics module is sometimes delayed," which is a functional interaction issue. The feedback messages involving functional module issues mentioned above are then filtered out.

[0163] Step S1512: Classify and statistically analyze the filtered feedback information, and count the frequency of each functional problem and the number of subjects involved. The frequency and the number of subjects are counted according to the recorded content of the feedback information.

[0164] The filtered feedback information was categorized and statistically analyzed. Among the missing function issues, "add test data trend analysis function" appeared 3 times, involving 2 entities: project owner and quality supervision agency; among the redundant function issues, "some report types in the report generation module are not used" appeared 2 times, involving 1 entity: construction site laboratory; among the interaction function issues, "data transmission delay between data entry and statistics module" appeared 4 times, involving 2 entities: construction site laboratory and project owner.

[0165] Step S1513: For feedback information on missing functions, analyze the core requirements corresponding to the missing functions. The core requirements are defined based on the consistency of feedback content and information sharing requirements of multiple subjects, and determine the types of functional modules that need to be added.

[0166] Regarding the feedback regarding the missing functionality of "adding a trend analysis function for testing data," the core requirement is the ability to perform trend analysis on multiple tests of the same type of raw materials to better understand quality changes. Considering the need for information sharing among multiple stakeholders—both the project owner and the quality supervision agency share this requirement—it was determined that a new module for trend analysis of testing data is necessary.

[0167] Step S1514: Based on the component-based architecture design of the .NET development framework, select or customize new functional modules from the .NET development framework.

[0168] Based on the component-based architecture design of the .NET development framework, check if there is an existing data analysis module in the framework. If so, adjust its functionality to meet the needs of data trend analysis; if not, custom-develop a data trend analysis module with functions such as data import, trend chart generation, and data comparison analysis.

[0169] Step S1515: Integrate the newly added functional module into the existing architecture of the multi-subject adaptation module, and configure the interaction interface between the newly added functional module and the existing module.

[0170] The newly added detection data trend analysis module will be integrated into the existing architecture of the multi-entity adaptation module. The interaction interface between this module and the data storage module will be configured to acquire detection data; the interaction interface with the information transmission module will be configured to transmit analysis results to relevant entities; and the interaction interface with the access control module will be configured to implement access control for different entities.

[0171] Step S1516: For functional redundancy feedback information, identify redundant modules that are not fully used in the existing functional module combination. The determination of insufficient use must meet the following conditions at the same time: the call frequency of the redundant module is lower than the preset frequency threshold, and business analysis confirms that its function can be completely replaced by other modules or there is no corresponding business demand.

[0172] Regarding the redundant feedback message "Some report types in the report generation module are not used," we checked the call frequency of various reports in the report generation module. A frequency threshold of once per month was set, and it was found that the "Annual Testing Equipment Usage Statistics Report" was called once per quarter, which is below the threshold. Business analysis revealed that the function of this report can be completely replaced by the equipment usage record statistics function in the equipment management module; therefore, the module corresponding to this report type was determined to be redundant.

[0173] Step S1517: Disconnect the redundant module from the existing architecture while retaining the backup data of the redundant module. During the disconnection process, operate according to the preset module isolation mechanism.

[0174] Disconnect the "Annual Testing Equipment Usage Statistics Report" module from the existing architecture. During the disconnection process, according to the preset module isolation mechanism, stop the module's service and remove its interface call relationships with other modules. At the same time, save the backup data of this module in case it needs to be restored later.

[0175] Step S1518: For feedback information regarding functional interaction issues, analyze the unreasonable aspects of the interaction logic between modules, and adjust the interaction logic and interface parameters between modules based on the analysis results. The unreasonable aspects include incorrect interaction order, data transmission delay, and parameter mismatch.

[0176] Regarding the functional interaction issue of "sometimes delay in data transmission between the data entry module and the data statistics module," analysis revealed that insufficient bandwidth settings for the data transmission interface caused delays during large-scale data transmission. Based on this, the bandwidth parameters of the data transmission interface were adjusted to improve the data transmission rate; simultaneously, the interaction logic was optimized by adopting an asynchronous transmission method to avoid impacting other operations due to data transmission consuming system resources.

[0177] Step S1519: Conduct functional tests on the optimized functional module combination. Based on the functional test results, further fine-tune the functional module combination and interaction configuration. The test scenario simulates the actual business scenario in which multiple entities use related functional modules at the same time. The test content includes the functional implementation effect, the smoothness of module interaction, and the stability of operation.

[0178] Functional testing was conducted on the optimized combination of functional modules. A multi-entity simultaneous operation scenario was simulated, involving laboratory personnel at the construction site entering data, project owners viewing test data trend analysis results, and quality supervision agencies conducting monitoring and statistics. The functionality of the newly added test data trend analysis module was tested, checking the accuracy of the generated trend charts; the smoothness of interaction between the data entry and data statistics modules was tested, observing any data transmission delays; and the overall system's stability under multi-entity concurrent operation was tested, checking for crashes or data errors. Based on the test results, further fine-tuning of the functional module combination and interaction configuration was performed, such as adjusting the chart display parameters of the trend analysis module and optimizing the timeout settings of the data transmission interface.

[0179] Step S1520: Extract feedback content related to the approval process from the shared feedback information, extract process convenience evaluation and optimization suggestions, and filter out feedback information that addresses redundancy in process nodes, unreasonable operation time limits, and cumbersome jump rules.

[0180] Extract content related to the approval process from shared feedback information, such as a process convenience rating of "cumbersome," and optimization suggestions like "reduce approval nodes," "operation time limits for some nodes are too short," and "complex jump rules." Filter out feedback information addressing redundant process nodes, unreasonable operation time limits, and cumbersome jump rules, such as "the result confirmation node in the raw material testing report approval process can be merged with the internal review node," "the 3-working-day operation time limit for the supervision and review node is too short," and "after rejection, it is necessary to start again from the information submission node, and the jump rules are cumbersome."

[0181] Step S1521: Classify the filtered feedback information according to the approval process type to obtain classified feedback information, which corresponds to business processing, supervision and guidance, and collaborative management approval processes.

[0182] The filtered feedback information was categorized according to the approval process type. Feedback information for the approval process of raw material testing reports (business processing type) was grouped into one category; feedback information for the approval process of supervision and inspection reports (supervision and guidance type) was grouped into another category; and feedback information for the joint review process (collaborative management type) was grouped into a third category.

[0183] Step S1522: For feedback information marked as redundant process nodes, perform process node necessity analysis: traverse each flow node of the corresponding approval process and check the operation content of the flow node; if the operation of the flow node does not generate any new approval status, business data or form content, and its logical function is completely contained in the operation of its adjacent upstream or downstream nodes, then the flow node is determined to be a redundant node and removed from the node sequence of the approval process.

[0184] In response to feedback that "the result confirmation node can be merged with the internal review node" in the raw material testing report approval process, a necessity analysis of the process nodes was performed. The flow nodes of this approval process were traversed. The operation of the result confirmation node was examined; its function is simply the laboratory director's final confirmation of the test results, without generating new approval status or business data. Its logical function (confirming the test results) is entirely contained within the operation of the internal review node (the technical lead reviews the test data and results). Therefore, the result confirmation node was determined to be a redundant node and removed from the node sequence of the approval process.

[0185] Step S1523: In response to feedback that the operation time limit is unreasonable, adjust the operation time limit requirements of the nodes. Specifically, collect historical process data, calculate the average processing time and standard deviation of each node, and use them as the adjustment benchmark. For nodes with unreasonable time limits indicated in the feedback, if their historical average processing time consistently exceeds the current configured time limit, extend their time limit by a preset ratio. If their historical average processing time is lower than the current configured time limit, shorten it by referring to the average time of similar nodes. Based on the preset critical path rules of the process, assign higher time limit adjustment priority to nodes on the critical path.

[0186] In response to feedback that the 3-working-day processing time for the supervisory and review node was too short, historical process data for this node was collected, and the average processing time was calculated to be 4 working days with a standard deviation of 1 working day. Since the historical average processing time consistently exceeded the currently configured 3-working-day time limit, the time limit was extended by a preset 20%, adjusted to 3.6 working days, rounded up to 4 working days. Simultaneously, this node is located on the critical path of the supervisory and guidance approval process, and is given a higher adjustment priority, completing the time limit adjustment first.

[0187] Step S1524: For feedback information marked as having cumbersome jump rules, re-examine the jump conditions of the corresponding approval process. Merge multiple conditions that lead to the same jump result. Analyze each jump step in the approval process. If the jump of this step does not change any business status or approval data, and the operation subject and operation content of its preceding and following nodes can be directly connected, then delete this jump step, directly associate the output of the preceding node with the subsequent node, and reconfigure the optimized jump rules into the jump process.

[0188] In response to feedback that "rejection requires restarting from the information submission node, making the jump rules cumbersome," the jump conditions for the raw material testing report approval process were re-examined. The original jump rules were: after rejection at the internal review node, the process jumps to the information submission node; after submission at the information submission node, it jumps back to the internal review node. Analysis revealed that this process, involving a jump to the information submission node after rejection and then submission to the internal review node, did not change the business status or approval data. Furthermore, the operators at both nodes were testing personnel and technical leaders, and the operations were directly interconnected. Therefore, the jump step at the information submission node was removed. Instead, after rejection at the internal review node, the process jumps directly to the modification interface at the information submission node. After modification, the process is directly submitted to the internal review node. The optimized jump rules were then reconfigured into the process.

[0189] Step S1525: Based on the optimized flow nodes, operation time limits and jump rules, update the approval process configuration information in the process engine module of the multi-subject adaptation module, and retain the backup of the original configuration during the update process.

[0190] Based on the optimized workflow nodes (removing the result confirmation node), operation time limits (adjusting the supervision and review node to 4 working days), and redirection rules (directly redirecting to the modification interface after rejection), the raw material testing report approval process configuration information in the workflow engine module of the multi-entity adaptation module was updated. During the update process, the original configuration information was backed up so that it could be restored in a timely manner in case of problems.

[0191] Step S1526: Simulate the optimized approval process and conduct process simulation tests. The simulation tests are based on typical cases in actual business scenarios to verify the smoothness of the approval process, the rationality of the time limit, and the effectiveness of the jump rules.

[0192] The optimized raw material testing report approval process was simulated using a real-world cement testing case study. Test personnel acted as testing staff, technical managers, and project owners, operating according to the optimized process to verify its smooth flow, the reasonableness of the 4-working-day timeframe for review nodes, and the effectiveness of the redirection rules after rejection.

[0193] Step S1527: Collect the problems discovered during the simulation test, and further adjust the approval process configuration for the problems until the process simulation test meets the business requirements. The problems include process lag, insufficient time limit adaptation, and deviation of jump logic.

[0194] During the process simulation testing, a slight lag was found when the optimized process transitioned from the internal review node to the information release node after submission. After identifying this issue, the parameter settings of the process engine module were further adjusted to optimize the response speed of node transitions. Testing was then conducted again until the process simulation test met business requirements.

[0195] Step S1528: Re-associate the optimized approval process with the corresponding demand type, update the association mapping relationship, and synchronize the optimized content of the approval process to all relevant entities through the notification function of the multi-entity adaptation module and offline notification.

[0196] The optimized raw material testing report approval process was re-linked with business processing requirements, and the mapping relationship between requirement type identifiers and approval process identifiers in the system configuration was updated. The approval process optimization notification was sent to all relevant entities through the notification function of the multi-entity adaptation module, including optimized nodes, time limits, and jump rules. Simultaneously, offline meetings were held to inform and train relevant personnel from each entity, ensuring they were aware of the optimized approval process.

[0197] In one exemplary embodiment, a digital management system for construction site laboratories based on information sharing is provided. This system can be a terminal, server, etc., and its internal structure diagram can be as follows: Figure 2 As shown, this information-sharing-based digital management system for construction site laboratories includes a processor, memory, input / output interfaces, a communication interface, a display unit, and input devices. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input devices are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, near-field communication, or other technologies. When the computer program is executed by the processor, it implements a digital management method for construction site laboratories based on information sharing. The display unit is used to create a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device can be a touch layer covering the display screen, or a button, trackball, or touchpad set on the shell of a construction site laboratory digital management system based on information sharing, or an external keyboard, touchpad, or mouse, etc.

[0198] It should be noted that, in order to simplify the description of the present invention and thus help to understand one or more embodiments of the invention, multiple features may sometimes be grouped into one embodiment, drawing or description thereof in the foregoing description of the embodiments of the present invention.

Claims

1. A digital management method for construction site laboratories based on information sharing, characterized in that, The method includes: The information sharing needs of multiple entities for construction site laboratories are collected. These entities include quality supervision agencies, project owners, grade testing agencies, and the construction site laboratories themselves. The information sharing needs cover business processing needs, supervision and guidance needs, and collaborative management needs. A multi-agent adaptation module is built using the .NET development framework. Based on the collected information sharing requirements, functional modules are selected and combined from the .NET development framework to complete the construction of the multi-agent adaptation module. Based on the multi-subject adaptation module, flow nodes are set according to the sharing requirement type, and corresponding subject operation permissions are associated with each flow node to dynamically configure the information sharing approval process. Using a front-end tool with table editing capabilities, shared information items are integrated according to business scenarios, and the shared information items are associated with the corresponding flow nodes in the information sharing approval process to generate scenario-based shared information templates. Based on the scenario-based shared information template, targeted information sharing among multiple entities is performed, shared feedback information submitted by multiple entities is collected, and the functional combination of the multi-entity adaptation module and the configuration of the information sharing approval process are optimized according to the shared feedback information. The method utilizes a front-end tool with table editing capabilities to integrate shared information items according to business scenarios, and associates these shared information items with corresponding workflow nodes in the information sharing approval process to generate scenario-based shared information templates, including: The core business scenarios of the construction site laboratory are divided into raw material testing scenarios, mix design scenarios, physical quality testing scenarios, equipment calibration scenarios, and test report review scenarios. For each core business scenario, information items that need to be shared by multiple entities under that core business scenario are extracted. The information items are defined based on the business process of the scenario and the information needs of each entity. Among them, the information items for the raw material testing scenario include basic information of raw materials, sample preparation information, testing data information, testing result information, and non-conformance handling information. Based on the business process, the generation order and dependency relationship of information items in each business scenario are sorted out. The generation order and dependency relationship are defined according to the information transmission and processing logic in the business process. Launch a table tool with table editing capabilities on the front end, design a table structure template based on the logical relationship of information items, and set the entry position, data type and display format of information items in the table structure. The data types include text, numeric, date and attachment types, and the display format is designed according to the display requirements of the information items. In the table tool, an input verification rule is configured for each information item. The input verification rule is defined according to the data type, business rules and format requirements of the information item. Among them, text information items are limited according to the character length specification, and numerical information items are specified according to the data format standard. The verification rule takes effect automatically when the information is entered. Extract the information sharing approval process nodes corresponding to the business scenario, associate each approval process node with the relevant information items in the template to obtain the association relationship. The association relationship is defined based on the operation content of the node. Among them, the internal audit node is associated with the detection data information and the detection result information, and the supervision audit node is associated with the detection result information and the non-compliance handling information. Set an approval node identifier in the template. The approval node identifier is marked in the corresponding position of the associated information item. The identifier content includes the node name and the operating subject. For shared information items across business scenarios, information association identifiers are set in the templates, and these information association identifiers link the same information items in different business scenario templates; Using the template saving function of the table tool, the designed table structure, input verification rules, approval node associations and information association identifiers are saved to generate the initial shared information template for this business scenario. The initial shared information template is imported into the template management module of the multi-subject adaptation module. The template management module stores the complete structure and configuration information of the template, and establishes an association mapping between the template and business scenarios and approval processes. The optimization of the functional combination of the multi-subject adaptation module based on the shared feedback information includes: Based on the shared feedback information corresponding to each target business scenario, we focus on the content of functional modules involved in the information usability evaluation and optimization suggestions, and filter out feedback information on functional deficiencies, functional redundancy and functional interaction issues. The filtered feedback information is categorized and statistically analyzed, and the frequency of each functional problem and the number of entities involved are counted. The frequency and number of entities are counted according to the recorded content of the feedback information. For feedback information regarding missing functions, analyze the core requirements corresponding to the missing functions. The core requirements are defined based on the consistency of feedback content and information sharing requirements among multiple stakeholders to determine the types of functional modules that need to be added. Based on the component-based architecture design of the .NET development framework, corresponding new functional modules are selected or customized from the .NET development framework; Integrate the newly added functional module into the existing architecture of the multi-subject adaptation module, and configure the interaction interface between the newly added functional module and the existing module; For feedback information on functional redundancy, identify redundant modules that are not fully used in the existing combination of functional modules. The determination of underutilization must meet the following conditions at the same time: the call frequency of the redundant module is lower than the preset frequency threshold, and business analysis confirms that its function can be completely replaced by other modules or there is no corresponding business demand. Disconnect the redundant module from the existing architecture while retaining the backup data of the redundant module. During the disconnection process, operate according to the preset module isolation mechanism. For feedback information regarding functional interaction issues, analyze the unreasonable aspects of the interaction logic between modules, and adjust the interaction logic and interface parameters between modules based on the analysis results. The unreasonable aspects include incorrect interaction order, data transmission delay, and parameter mismatch. Functional tests were conducted on the optimized combination of functional modules. Based on the results of the functional tests, the combination of functional modules and interaction configurations were further fine-tuned. The test scenarios simulated actual business scenarios in which multiple entities used related functional modules at the same time. The test content included the functional implementation effect, the smoothness of module interaction, and the stability of operation.

2. The digital management method for construction site laboratories based on information sharing according to claim 1, characterized in that, The construction of the multi-agent adaptation module using the .NET development framework involves selecting and combining functional modules from the .NET development framework based on the collected information sharing requirements to complete the construction of the multi-agent adaptation module, including: The collected information sharing needs of multiple entities were analyzed, and the core functional requirements of each entity were broken down. These core functional requirements are based on the roles of the entities in the management of the construction site laboratory and cover information collection, information query, process approval, report generation, and supervision and statistics. Based on the component-based architecture design of the .NET development framework, preset basic functional modules are extracted from the .NET development framework. The basic functional modules include a data storage module, an information transmission module, an access control module, a process engine module, and a template generation module. The core functional requirements of each subject are matched with the basic functional modules to determine the combination method of the basic functional modules corresponding to each core functional requirement, and the matching basic functional module combination is obtained. The basic functional module combination method is based on the interface compatibility definition of the functional modules. For the matched basic functional module combination, configure the interaction interface parameters between the modules and set them based on the standard interface specification of the .NET development framework. The interaction interface parameters are set according to the data transmission requirements between different basic functional modules. Based on the aforementioned multi-entity information sharing requirements, functional requirements involving interaction or collaboration between two or more entities are identified and defined as cross-entity collaborative functional requirements. Corresponding collaborative functional modules are selected based on these collaborative functional requirements, which include cross-entity information flow, joint approval, and collaborative supervision. The selected collaborative functional modules are combined with the basic functional modules of each subject and integrated. Based on the integrated functional module set, the initial architecture of the multi-subject adaptation module is constructed. In the initial architecture, the hierarchical relationship and data interface specifications of each functional module are defined according to the calling dependency relationship and data processing order between modules. Based on the priority of the information sharing needs of each entity, the resource allocation ratio of the functional modules in the initial architecture is adjusted. The resource allocation ratio is defined based on the resource load stress test results of each functional module under simulated concurrent call scenarios. The initial architecture is subjected to module compatibility testing, simulating concurrent call scenarios where multiple entities simultaneously operate on corresponding functional modules to test the operational stability of each functional module. Based on the compatibility test results, the following operations are performed: adjusting the parameters and calling logic of the interaction interfaces between functional modules; reallocating computing and storage resource quotas based on the resource utilization rate of each module during the test; removing inter-module connections that were not called or conflicted during the test; and creating new interfaces for cross-module interactions discovered during the test to obtain a shared support architecture.

3. The digital management method for construction site laboratories based on information sharing according to claim 1, characterized in that, The process of setting flow nodes according to the sharing requirement type based on the multi-subject adaptation module, and associating corresponding subject operation permissions with each flow node to dynamically configure the information sharing approval process includes: The information sharing needs of multiple stakeholders are categorized into three types: business processing needs, supervision and guidance needs, and collaborative management needs. Specifically, business processing needs originate from the testing and inspection processes of on-site laboratories; supervision and guidance needs originate from the supervision and inspection processes of quality supervision agencies or project owners; and collaborative management needs originate from management processes requiring the participation of multiple stakeholders. For business processing needs, the basic workflow nodes of the information sharing and approval process are set according to the business process sequence of the construction site laboratory. The basic workflow nodes include information submission node, internal review node, result confirmation node and information release node. To address supervision and guidance needs, a supervision and review node and a feedback node are added to the basic workflow nodes. The supervision and review node is operated by the quality supervision agency or the project owner, and the feedback node is used by the site laboratory to receive supervision opinions. For collaborative management needs, the approval nodes corresponding to various entities are integrated, and joint approval nodes and collaborative confirmation nodes are set. The joint approval node requires multiple entities to perform operation confirmation at the same time, and the collaborative confirmation node is used to summarize the approval opinions of various entities. Assign corresponding main operation permissions to each flow node. The main operation permissions are defined based on node functions and main roles. Information submission nodes and internal review nodes are assigned to relevant personnel in the construction site laboratory, supervision and review nodes are assigned to quality supervision agencies and project owners, and joint approval nodes are assigned to all entities participating in collaborative management. Each circulation node is configured with an operation time limit requirement, which is set through the following steps: based on the sharing demand type to which the circulation node belongs, a basic time limit range is allocated; then, based on the preset node importance classification rules, specific duration values ​​are assigned to nodes of different importance levels within the basic time limit range. Define the jump rules for the flow nodes. The jump rules are defined based on the node operation results. If the operation result is pass, jump to the next flow node. If the operation result is rejection, jump to the previous related flow node. The jump rules are designed according to the business logic progression order. The configured flow nodes, main operation permissions, operation time limit requirements and jump rules are entered into the process engine module of the multi-subject adaptation module. The process engine module completes the rule storage based on the process configuration interface of the .NET development framework. The process engine module generates an initial approval process, in which the operating subject, operation content and time requirements of each node are defined, and the operation content is matched according to the node function. The initial approval process is associated with the corresponding requirement type and stored. A mapping relationship between requirement type identifier and approval process identifier is established in the system configuration. When a preset type of information sharing requirement is triggered, the approval process pointed to by the corresponding approval process identifier is called according to the mapping relationship.

4. The digital management method for construction site laboratories based on information sharing according to claim 1, characterized in that, The process of performing targeted information sharing among multiple entities based on the scenario-based shared information template, and collecting shared feedback information submitted by multiple entities, includes: Based on the current operational status of the on-site laboratory, the target business scenarios being executed are determined. These target business scenarios are defined based on the actual testing and inspection work being carried out, and multiple parallel target business scenarios may exist simultaneously. The template management module of the multi-subject adaptation module calls the scenario-based shared information template corresponding to the target business scenario. During the calling process, a template validity verification program is executed. The template validity verification program checks in sequence: whether the structured configuration file of the scenario-based shared information template is complete and parsable; whether all required information items in the scenario-based shared information template have been defined; and whether the approval process identifier associated with the scenario-based shared information template exists and is valid. The scenario-based shared information template is determined to be valid only when all the above checks pass. Based on the scenario-based shared information template, the corresponding business information is entered. During the entry process, the entry verification rules of the scenario-based shared information template automatically standardize the entered information so that the entered information meets the preset format and requirements. After the business information is entered, the information sharing approval process associated with the scenario-based shared information template is triggered. The information sharing approval process proceeds sequentially according to the preset flow nodes. The subject corresponding to each flow node receives the relevant information and performs the corresponding operation. The information transmission module of the multi-subject adaptation module synchronizes the operation results of each flow node to the relevant subject. The synchronization information includes operation status, operation comments and operation time. When the information sharing approval process progresses to the information release node, the information transmission module pushes complete shared information in a targeted manner according to a preset list of shared objects. The list of shared objects is based on the definition of information sharing needs of multiple entities, and determines the receiving entity corresponding to each piece of shared information. The receiving subject obtains the targeted shared information through the information query function of the multi-subject adaptation module. During the query process, the operating permissions of the receiving subject are verified. The operation permission verification is performed based on the preset subject operation permission configuration. After obtaining the shared information, the receiving entity enters the shared feedback information through the feedback input interface of the multi-entity adaptation module. The feedback input interface provides a structured form for the entity to fill in the information completeness evaluation, information usability evaluation, process convenience evaluation, and optimization suggestions. The feedback collection module of the multi-subject adaptation module collects shared feedback information submitted by all receiving subjects in real time, and records the feedback subject identifier, feedback time and feedback content during the collection process. The feedback collection module categorizes and stores the collected shared feedback information according to the target business scenario and feedback type, and establishes the association between feedback information, shared information, and approval processes.

5. The digital management method for construction site laboratories based on information sharing according to claim 1, characterized in that, The step of optimizing the configuration of the information sharing approval process based on the shared feedback information includes: Extract feedback content related to the approval process from the shared feedback information, extract process convenience evaluation and optimization suggestions, and filter out feedback information that addresses redundancy in process nodes, unreasonable operation time limits, and cumbersome jump rules. The filtered feedback information is classified according to the approval process type to obtain classified feedback information, which corresponds to business processing, supervision and guidance, and collaborative management approval processes. For feedback information marked as redundant process nodes, perform a process node necessity analysis: traverse each flow node of the corresponding approval process and check the operation content of the flow node; if the operation of the flow node does not generate any new approval status, business data or form content, and its logical function is completely contained in the operation of its adjacent upstream or downstream nodes, then the flow node is determined to be a redundant node and removed from the node sequence of the approval process. In response to feedback regarding unreasonable operation time limits, the operation time limit requirements for nodes are adjusted. Specifically, historical process data is collected, and the average processing time and standard deviation of each node are calculated as the adjustment benchmark. For nodes with unreasonable time limits indicated in the feedback, if their historical average processing time consistently exceeds the current configured time limit, their time limit is extended by a preset ratio. If their historical average processing time is lower than the current configured time limit, it is shortened by referring to the average time of similar nodes. Based on the preset critical path rules of the process, nodes on the critical path are given a higher priority for time limit adjustment. For feedback messages marked as having cumbersome jump rules, the jump conditions of the corresponding approval process are re-examined. This will merge multiple conditions that result in the same jump result. Each jump step in the approval process is analyzed. If the jump step does not change any business status or approval data, and the operation subject and operation content of its preceding and following nodes can be directly connected, then the jump step is deleted, the output of the preceding node is directly associated with the subsequent node, and the optimized jump rules are reconfigured into the jump process. Based on the optimized flow nodes, operation time limits, and jump rules, update the approval process configuration information in the process engine module of the multi-subject adaptation module, and retain a backup of the original configuration during the update process; The optimized approval process is simulated and tested. The simulation test is based on typical cases in actual business scenarios to verify the smoothness of the approval process, the rationality of the time limit, and the effectiveness of the jump rules. Collect problems discovered during the simulation and testing process, and further adjust the approval process configuration based on the problems until the process simulation and testing meets the business requirements. The problems include process lag, insufficient time limit adaptation, and deviation of jump logic. The optimized approval process is re-associated with the corresponding demand type, the association mapping is updated, and the optimized content of the approval process is synchronized to all relevant entities through the notification function of the multi-entity adaptation module and offline notification.

6. The digital management method for construction site laboratories based on information sharing according to claim 2, characterized in that, The step of matching the core functional requirements of each entity with the basic functional modules to determine the combination of basic functional modules corresponding to each core functional requirement includes: The component-based architecture implementation logic of the .NET development framework is analyzed, and the implementation mechanism of the component-based architecture in the .NET development framework is defined. The implementation mechanism includes module encapsulation standards, interface definition specifications, and dependency management methods. The module library of the .NET development framework is traversed, and the preset basic functional modules are filtered according to the functional type. During the filtering process, the completeness and availability of each module are verified. The completeness refers to the module having complete functional implementation code, and the availability refers to the module being able to run normally in the .NET development framework. The selected basic functional modules are organized into functional description documents. The functional description documents record in detail the function, input parameters, output results, calling method and interface specifications of each module. The interface specifications are based on the standard interface specifications of the .NET development framework. The compiled basic functional module functional description documents are compared one by one with the core functional requirements of each subject. During the comparison process, attention is paid to the degree of functional matching between the implementation requirements of the core functional requirements and the basic functional modules. For core functional requirements that can be met by a single basic functional module, the basic functional module is identified as the unique combination unit, and the combination method is to call the module separately. For core functional requirements that require the collaborative implementation of multiple basic functional modules, analyze the functional complementarity and interface compatibility of each basic functional module. Based on functional complementarity and interface compatibility, the combination order and interaction relationship of multiple basic functional modules are determined. The combination order is set according to the logical order of function implementation, and the interaction relationship is defined based on the input and output parameters of the modules. A unified call entry point is configured for the multiple basic functional modules after combination. The call entry point provides a simple operation interface for the main body and triggers the collaborative operation mechanism of the combined modules through the unified call entry point. The test determines the combination of basic functional modules. The test content includes the functional implementation effect, operating efficiency and stability of the combined modules. The test scenario simulates the business scenario in which the subject actually uses the core functional requirements. Based on the test results, adjust the combination method of basic functional modules, optimize the combination order and interaction relationship; for functional modules that fail to achieve the core functional requirements in the test, or cause errors when interacting with other modules, remove them from the current combination, and select other basic functional modules with matching functional descriptions from the module library of the .NET development framework for replacement and retesting.

7. The digital management method for construction site laboratories based on information sharing according to claim 1, characterized in that, The step involves extracting the information sharing approval process nodes corresponding to the business scenario, and associating each approval process node with relevant information items in the template. The association relationship is defined based on the operation content of the node, including: The information sharing approval process corresponding to the business scenario is retrieved from the process engine module of the multi-subject adaptation module. The complete structure of the approval process is parsed, and the names, operating subjects and operation contents of all flow nodes are defined. The operation contents describe in detail the information to be processed and the operation to be performed by the flow node. Return the scenario-based shared information template for this business scenario, and parse the name, data type and purpose of all information items in the scenario-based shared information template. The purpose is defined based on the role of the information item in the business process, including recording data, supporting approval and generating reports. The operation content of each flow node is compared with the purpose of the information items in the template to identify the information items involved in the operation content. The information items involved are the information items that the flow node needs to process or refer to. A list of associated information items is established for each flow node. The list of associated information items records the names, data types, and positions of all information items corresponding to the flow node in the scenario-based shared information template. Add an association identifier field to the configuration file of the scenario-based shared information template. The association identifier field corresponds to each information item, and the field content is the name of the flow node associated with the information item and the operation requirements. The operation requirements include viewing, editing, and confirming. Configure the operation permissions of the circulation node for the associated information items. The operation permissions are determined based on the role and permission scope of the circulation node's operating subject and the preset security level or sensitivity level of the associated information items. An index table for establishing relationships is established, which records the names of the flow nodes, a list of associated information items, operation permissions, and configuration time. The association verification function is deployed in the multi-subject adaptation module. The association verification function runs automatically when the template is called and the approval process is advanced to verify whether the association between the flow node and the information item is effective. Effective association means that the node operation can normally obtain and process the corresponding information item. Based on the results of the association verification function, invalid associations are corrected. Invalid associations include missing information items and mismatched operation permissions. Correction methods include re-associating information items and adjusting operation permissions. The revised association relationships, association identifier fields, and index tables will be synchronized to the template management module and the process engine module, so that the association between the scenario-based shared information template and the information sharing approval process node will remain effective in subsequent use.

8. A digital management system for construction site laboratories based on information sharing, characterized in that: include: processor; A machine-readable storage medium for storing machine-executable instructions of the processor; The processor is configured to execute the digital management method for construction site laboratories based on information sharing as described in any one of claims 1 to 7 by executing the machine-executable instructions.

Images