Bridge engineering project demand analysis method and system

Abstract

This invention relates to the field of engineering project requirements analysis, specifically disclosing a method and system for requirements analysis of bridge engineering projects. The method includes the following steps: S1: Obtaining multimodal raw data of the bridge engineering project and processing the multimodal raw data to obtain semi-structured data; S2: Performing semantic extraction and entity alignment processing on the semi-structured data to obtain aligned data; S3: Based on the TOGAF architecture, mapping the aligned data to the strategy layer, business layer, and application layer to generate a TOGAF attribute graph, performing real-time conflict detection to obtain a conflict-free TOGAF attribute graph; S4: Visualizing the conflict-free TOGAF attribute graph and encapsulating it to obtain a standardized architecture asset package; S5: Constructing a bridge engineering project architecture asset library. This invention can, to a certain extent, solve the problems of data duplication, logical mutual exclusion, and weak cross-business domain abstraction capabilities in existing bridge engineering project requirements analysis.

Description

Technical Field

[0001] This application relates to the field of engineering project requirements analysis, specifically to a method and system for requirements analysis of bridge engineering projects. Background Technology

[0002] Currently, the requirements analysis phase of bridge engineering projects is still mainly driven by manual processes. Project managers and engineering teams combine actual needs with strategic opinions from corporate management to manually extract and break down project requirements. The sub-requirements and parameter requirements are then handed over to the R&D and design team for subsequent work. This model relies heavily on human experience and is difficult to meet the needs of digital engineering development.

[0003] Furthermore, professional entities in the field of bridge engineering exhibit the phenomenon of "different names for the same entity" in different data carriers, leading to duplicate, missing, or conflicting data entries. Moreover, requirement conflict detection can only achieve surface-level similarity comparison and cannot identify deep-seated logical mutual exclusion issues. Conflicts often only emerge in the downstream design stage, resulting in high design change costs.

[0004] Meanwhile, historical needs, decisions, and technical lessons learned in the field of bridge engineering projects are stored in an unstructured manner on shared drives, emails, instant messaging tools, and other media. During the new project requirements analysis phase, historical assets cannot be effectively accessed, and the work of extracting and dismantling requirements can only be repeated. The asset reuse rate is insufficient, which not only significantly increases project costs but also hinders organizational-level technical learning and experience accumulation.

[0005] Some solutions attempt to combine artificial intelligence models with knowledge bases for application in engineering project requirements analysis, which can realize an automated link from requirements identification and decomposition to parameter matching. However, such solutions are only oriented towards a single engineering business domain, and their knowledge bases only store static design formulas. They lack cross-business domain abstraction capabilities, have not established a standardized requirements traceability system, and cannot guarantee end-to-end consistency from business objectives to technical implementation. In addition, they often use hard-coded rule engines, which cannot automatically resolve semantic ambiguities and deep logical conflicts in requirements descriptions, and still require a lot of manual review intervention. Summary of the Invention

[0006] To address, to some extent, the problems of data duplication, logical inconsistencies, and weak cross-business domain abstraction capabilities in existing bridge engineering project requirements analysis, this invention proposes a bridge engineering project requirements analysis method, comprising the following steps: S1: Obtain multimodal raw data of bridge engineering projects, and process the multimodal raw data to obtain semi-structured data; S2: Perform semantic extraction and entity alignment processing on the semi-structured data to obtain aligned data; S3: Based on the TOGAF architecture, the aligned data is mapped to the strategy layer, business layer, and application layer to generate a TOGAF attribute graph. At the same time, based on the mutual exclusion constraint rules, the TOGAF attribute graph is subjected to real-time conflict detection. If a conflict is detected, a conflict prompt is generated and an alternative solution is provided until a conflict-free TOGAF attribute graph is obtained. S4: Visualize the conflict-free TOGAF attribute diagram, receive user fine-tuning operations and perform conflict detection again, and after confirming that there is no conflict, encapsulate the conflict-free TOGAF attribute diagram into a standardized architecture asset package. S5: Store the standardized architecture asset package in a graph database according to the three-layer classification labels of the TOGAF standard architecture to construct a bridge engineering project architecture asset library.

[0007] According to a preferred embodiment, processing the multimodal raw data includes: S11: Record the data lineage of the multimodal raw data, including file, project, version, and person in charge; S12: Preprocess the multimodal raw data, including image correction, character recognition, named entity recognition, and primitive vectorization parsing; S13: Extract the preprocessed multimodal raw data into "component number-geometry-material" triples to obtain semi-structured data.

[0008] According to a preferred embodiment, step S2 includes the following sub-steps: S21: Generate a logical list of requirement processing tasks that includes business scenario definition, goal setting, and architecture hierarchy construction; S22: Parse the text, image, and tabular data in the semi-structured data respectively, extract the business entities, attribute information, and relationships, and form a preliminary requirement description with logical steps; S23: Filter the semantic information in the preliminary requirements description; S24: Establish a unified semantic space for multimodal entities and merge entities with different names but the same meaning in different data carriers; S25: Clarify the dependencies, constraints, and relationships between the merged entities to form structured, aligned data; S26: Perform a consistency check on the alignment data.

[0009] According to a preferred embodiment, the mapping rules for the strategy layer, business layer, and application layer are as follows: business objects are mapped to business layer nodes, application services are mapped to application layer nodes, and strategic components are mapped to strategy layer nodes. URI, name, and priority core attributes are configured for each layer node, and traceTo or realize trace edges are established between each layer node.

[0010] According to a preferred embodiment, the business layer nodes include business services, business processes, business functions, business objects, business events, and business role nodes; the application layer nodes include application components, application interfaces, application functions, and data object nodes; and the strategy layer nodes include device and system software nodes.

[0011] According to a preferred embodiment, in step S3, the mutual exclusion constraint rule is a mutual exclusion triplet constructed from indicators extracted from bridge engineering specifications, and the mutual exclusion triplet is written to the graph database in batches in CSV format. The real-time collision detection includes the following sub-steps: S31: Initialize the TOGAF attribute graph and configure initial attributes for each node; S32: Update the TOGAF attribute graph in real time, analyze the dependency, constraint, and mutual exclusion relationships between the newly added nodes and existing nodes, and add corresponding edges; S33: Use a depth-first search algorithm to detect loops in the TOGAF attribute graph, and check whether there are mutually exclusive edges in the loops and attribute graph that satisfy the mutual exclusion constraint rules; S34: If a mutual exclusion edge is detected, mark the conflict, generate a conflict prompt containing the conflict requirement, conflict attribute, and conflict reason, and attach the alternative solution node.

[0012] According to a preferred embodiment, in step S4, the visualization is implemented using the TOGAFExplore front-end rendering tool, and the fine-tuning operations include adding or deleting nodes, adjusting coordinates, and changing attributes.

[0013] According to a preferred embodiment, when conducting a new bridge engineering project requirements analysis, matching architectural assets are retrieved from the architectural asset library and reused.

[0014] According to a preferred embodiment, retrieving and reusing matching architectural assets from the architectural asset repository includes the following sub-steps: S51: Receive natural language query requests for new bridge engineering projects; S52: Use the cosine similarity algorithm to retrieve the most relevant subgraph in the architecture asset library in the vector space; S53: Use a graph matching algorithm to filter out reusable architectural asset nodes and relationships from the most relevant subgraphs; S54: Call the reusable architecture asset nodes and relationships to the TOGAF attribute graph generation stage of the new bridge engineering project.

[0015] Accordingly, the present invention also proposes a bridge engineering project requirements analysis system for implementing the above method, comprising: The multimodal data processing module is used to acquire multimodal raw data of bridge engineering projects, preprocess the multimodal raw data to obtain semi-structured data, store the semi-structured data in the raw data lake and record the data lineage information; The semantic extraction and alignment module is used to perform semantic extraction and entity alignment processing on the semi-structured data, generate a requirement description with logical steps, and realize the merging of homonymous entities and output aligned data. The TOGAF graph generation and conflict detection module is used to map the aligned data into a three-layer architecture node and relationship based on the optimized TOGAF standard architecture, generate a TOGAF attribute graph, perform real-time conflict detection on the TOGAF attribute graph based on mutual exclusion constraint rules, generate conflict prompts and provide alternative solutions, and output a conflict-free TOGAF attribute graph. The visualization fine-tuning module is used to visualize the conflict-free TOGAF attribute diagram, receive user fine-tuning operations, and perform conflict detection again. After confirming that there are no conflicts, it is packaged into a standardized architecture asset package. The asset reuse module is used to store the standardized architecture asset package in a graph database according to three-level classification tags to build an architecture asset library, and to retrieve and reuse matching architecture assets when analyzing new project requirements.

[0016] This invention processes multimodal raw data to obtain semi-structured data, and performs semantic extraction and entity alignment to avoid data entry duplication or omission. Through the TOGAF architecture, the aligned data is mapped to the strategy layer, business layer, and application layer. Based on mutual exclusion rules, real-time conflict detection is performed on the TOGAF attribute graph to identify deep-seated logical mutual exclusion problems. Unified encapsulation and storage are then implemented for effective reuse. The core architecture of the strategy, business, and application layers is extracted, and the requirement entities from different business domains in bridge engineering are abstracted into standardized architectural nodes and relationships. Regardless of whether the requirement originates from design, construction, supervision, or other business stages, it falls within a unified architectural framework, breaking down information barriers between business domains and achieving efficient requirement analysis for bridge engineering projects. Attached Figure Description

[0017] Figure 1 This is a step diagram of a bridge engineering project requirements analysis method according to the present invention; Figure 2 This is a requirements analysis architecture diagram for bridge engineering projects according to the present invention; Figure 3 This is a diagram illustrating the composition of a bridge engineering project requirements analysis system according to the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the various embodiments of this application will be described in detail below with reference to the accompanying drawings. However, those skilled in the art will understand that many technical details have been presented in the various embodiments of this application to enable the reader to better understand this application. However, the technical solutions claimed in this application can be implemented even without these technical details and various changes and modifications based on the following embodiments.

[0019] In the following description, certain specific details are set forth for the purpose of illustrating various disclosed embodiments in order to provide a thorough understanding of the various disclosed embodiments. However, those skilled in the art will recognize that embodiments may be practiced without one or more of these specific details. In other instances, well-known apparatuses, structures, and techniques associated with this application may not have been shown or described in detail to avoid unnecessarily obscuring the description of the embodiments.

[0020] Unless the context requires otherwise, throughout the specification and claims, the word “comprising” and its variations, such as “including” and “having”, shall be understood to have an open, inclusive meaning, that is, to be interpreted as “including, but not limited to”.

[0021] The embodiments of this application will be described in detail below with reference to the accompanying drawings to provide a clearer understanding of the purpose, features, and advantages of this application. It should be understood that the embodiments shown in the drawings are not intended to limit the scope of this application, but are merely for illustrating the essential spirit of the technical solution of this application.

[0022] Throughout this specification, references to "an embodiment" or "an embodiment" indicate that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Therefore, the appearance of "in an embodiment" or "an embodiment" in various places throughout the specification does not necessarily refer to the same embodiment. Furthermore, a particular feature, structure, or characteristic may be combined in any manner in one or more embodiments.

[0023] To address, to some extent, the problems of data duplication, logical inconsistencies, and weak cross-business domain abstraction capabilities in existing bridge engineering project requirements analysis, this invention proposes a bridge engineering project requirements analysis method and a corresponding system, such as... Figure 1 As shown, the method includes the following steps: S1: Obtain multimodal raw data of bridge engineering projects, and process the multimodal raw data to obtain semi-structured data; S2: Perform semantic extraction and entity alignment processing on the semi-structured data to obtain aligned data; S3: Based on the TOGAF architecture, the aligned data is mapped to the strategy layer, business layer, and application layer to generate a TOGAF attribute graph. At the same time, based on the mutual exclusion constraint rules, the TOGAF attribute graph is subjected to real-time conflict detection. If a conflict is detected, a conflict prompt is generated and an alternative solution is provided until a conflict-free TOGAF attribute graph is obtained. S4: Visualize the conflict-free TOGAF attribute diagram, receive user fine-tuning operations and perform conflict detection again, and after confirming that there is no conflict, encapsulate the conflict-free TOGAF attribute diagram into a standardized architecture asset package. S5: Store the standardized architecture asset package in a graph database according to the three-layer classification labels of the TOGAF standard architecture to construct a bridge engineering project architecture asset library.

[0024] TOGAF is an enterprise architecture framework that provides a methodology for designing, planning, implementing, and managing enterprise information technology architectures, using standardized methods to analyze project business scenarios.

[0025] To enable the system to master TOGAF theory and bridge engineering knowledge, a domain-adjusted multimodal system and the Langgraph framework were added. By injecting bridge engineering project corpus covering BIM components, construction procedures, and bills of quantities, the system can accurately identify professional entities even under mixed text-and-table input conditions. At the same time, based on the Langgraph framework, a rigid mapping intelligent agent from entities to the TOGAF metamodel was constructed, so that each requirement item automatically falls into the Strategic, Business, and Application entity types at the moment of generation, and completes ID unification, attribute completion, and name confusion between entities.

[0026] By using intelligent agents, we can achieve highly efficient, accurate, and reusable digital requirements analysis. At the same time, since TOGAF theory is a complete and rich enterprise architecture theory, in order to make it more suitable for bridge requirements analysis and improve the accuracy of intelligent agents, TOGAF theory has been optimized by extracting only three entity types: Strategic, Business, and Application, making it more suitable for applications in the bridge engineering industry.

[0027] This invention processes multimodal raw data to obtain semi-structured data, and performs semantic extraction and entity alignment to avoid data entry duplication or omission. Through the TOGAF architecture, the aligned data is mapped to the strategy layer, business layer, and application layer. Based on mutual exclusion rules, real-time conflict detection is performed on the TOGAF attribute graph to identify deep-seated logical mutual exclusion problems. Unified encapsulation and storage are then implemented for effective reuse. The core architecture of the strategy, business, and application layers is extracted, and the requirement entities from different business domains in bridge engineering are abstracted into standardized architectural nodes and relationships. Regardless of whether the requirement originates from design, construction, supervision, or other business stages, it falls within a unified architectural framework, breaking down information barriers between business domains and achieving efficient requirement analysis for bridge engineering projects.

[0028] like Figure 2 As shown, the present invention provides a requirements analysis architecture for bridge engineering projects, including a multimodal data source layer, a semantic extraction and alignment layer, a knowledge graph display layer, and a TOGAF graph generation and conflict detection layer.

[0029] At the starting point of the requirements analysis for bridge engineering projects, the system first pulls the diverse and heterogeneous raw data scattered across different carriers into the "multimodal data source layer." This includes bidding PDFs, scanned contracts, Excel bills of quantities, and screenshots of WeChat chat records. The system first utilizes the capabilities of a multimodal large language model to perform image correction, text recognition, and named entity recognition, outputting semi-structured JSON with coordinate offsets. DWG format drawings are extracted into "component number-geometry-material" triples using a primitive vectorization parser. After completion, the data is written to the MinIO raw data lake, and a "file-project-version-responsible person" quadruple is pre-recorded to meet subsequent auditing and traceability requirements.

[0030] Processing the raw multimodal data includes: S11: Record the data lineage of the multimodal raw data, including file, project, version, and person in charge; S12: Preprocess the multimodal raw data, including image correction, character recognition, named entity recognition, and primitive vectorization parsing; S13: Extract the preprocessed multimodal raw data into "component number-geometry-material" triples to obtain semi-structured data.

[0031] The semantic extraction and alignment layer is the foundation for the implementation of step S2, which includes the following sub-steps: S21: Generate a logical list of requirement processing tasks that includes business scenario definition, goal setting, and architecture hierarchy construction; S22: Parse the text, image, and tabular data in the semi-structured data respectively, extract the business entities, attribute information, and relationships, and form a preliminary requirement description with logical steps; S23: Filter the semantic information in the preliminary requirements description; S24: Establish a unified semantic space for multimodal entities and merge entities with different names but the same meaning in different data carriers; S25: Clarify the dependencies, constraints, and relationships between the merged entities to form structured, aligned data; S26: Perform a consistency check on the alignment data.

[0032] In one implementation, the semantic extraction is based on the Langgraph framework combined with a multimodal large model fine-tuned by the domain. The multimodal large model is based on Qwen-VL and uses LoRA parameters for efficient fine-tuning. The fine-tuning corpus is a vertical corpus covering bidding documents, construction logs, supervision notices, and change orders for bridge engineering projects. The entity alignment uses a contrastive learning loss function to map text tokens, image patches, table cells, and BIMGUIDs to a 768-dimensional unified vector space. The alignment results are stored in the form of RDF triples.

[0033] Furthermore, the mapping rules for the strategy layer, business layer, and application layer are as follows: business objects are mapped to business layer nodes, application services are mapped to application layer nodes, and strategic components are mapped to strategy layer nodes. Each layer node is configured with a URI, name, and priority core attributes. Simultaneously, trace edges using `traceTo` or `realize` are established between each layer node. In a preferred embodiment, the rules are shown in Table 1.

[0034] Table 1 In a preferred embodiment, the correspondence between elements and entities is shown in Table 2:

[0035] Table 2 Furthermore, the business layer nodes include business services, business processes, business functions, business objects, business events, and business role nodes; the application layer nodes include application components, application interfaces, application functions, and data object nodes; and the strategy layer nodes include device and system software nodes.

[0036] The business layer maps business objects in bridge engineering projects to core nodes such as business services, business processes, and business functions. It constructs traceTo traceability edges with the strategy and application layers to form a complete business logic chain. Nodes cover bridge engineering-specific business entities such as bridge site topographic mapping services, geological drilling processes, and waterway hydrological calculations, achieving precise correlation between business requirements and application services and ensuring end-to-end traceability from business objectives to technical implementation.

[0037] The application layer maps application services in bridge engineering projects to core nodes such as application components, application interfaces, application functions, and data objects. Standardized interfaces provide technical support for data interoperability and functional collaboration.

[0038] The strategic layer maps the strategic components of bridge engineering projects into two core node categories: equipment and system software. These nodes encompass hardware equipment, as well as system software such as flight control firmware and geological modeling software, adapting to the multi-device collaboration needs of bridge engineering. Through standardized node definitions and traceability relationships, the implementation of strategic intent is ensured, providing reliable strategic-level data support for conflict detection and asset reuse.

[0039] Furthermore, in step S3, the mutual exclusion constraint rule is a mutual exclusion triplet constructed from indicators extracted from bridge engineering specifications, and the mutual exclusion triplet is written to the graph database in batches in CSV format. The real-time collision detection includes the following sub-steps: S31: Initialize the TOGAF attribute graph and configure initial attributes for each node; S32: Update the TOGAF attribute graph in real time, analyze the dependency, constraint, and mutual exclusion relationships between the newly added nodes and existing nodes, and add corresponding edges; S33: Use a depth-first search algorithm to detect loops in the TOGAF attribute graph, and check whether there are mutually exclusive edges in the loops and attribute graph that satisfy the mutual exclusion constraint rules; S34: If a mutual exclusion edge is detected, mark the conflict, generate a conflict prompt containing the conflict requirement, conflict attribute, and conflict reason, and attach the alternative solution node.

[0040] Batch writing to the graph database in CSV format enables convenient maintenance and rapid updates of rules. Initializing the attribute graph lays the data foundation for conflict detection, and real-time updates ensure the capture of the latest requirement associations. The depth-first search algorithm accurately identifies loops and mutually exclusive edges, efficiently locating deep logical conflicts. After a conflict is detected, not only is the conflict information clearly marked, but alternative solutions are also linked, allowing users to quickly understand the root cause of the conflict and the direction of resolution, eliminating reliance on traditional manual review and improving the accuracy and efficiency of requirements analysis.

[0041] Furthermore, in step S4, the visualization is achieved through the TOGAFExplore front-end rendering tool, and the fine-tuning operations include adding or deleting nodes, adjusting coordinates, and changing attributes.

[0042] Furthermore, during the requirements analysis of new bridge engineering projects, matching architectural assets are retrieved from the aforementioned architectural asset library and reused.

[0043] Retrieving and reusing matching architecture assets from the architecture asset repository includes the following sub-steps: S51: Receive natural language query requests for new bridge engineering projects; S52: Use the cosine similarity algorithm to retrieve the most relevant subgraph in the architecture asset library in the vector space; S53: Use a graph matching algorithm to filter out reusable architectural asset nodes and relationships from the most relevant subgraphs; S54: Call the reusable architecture asset nodes and relationships to the TOGAF attribute graph generation stage of the new bridge engineering project.

[0044] In step S52, the cosine similarity algorithm first extracts the core features of the subgraphs in the new demand query and the architecture asset library, and converts them into high-dimensional vectors. Then, it quantifies the similarity by calculating the cosine value of the angle between the two vectors. The closer the cosine value is to 1, the higher the similarity. Next, it sets a similarity threshold and selects subgraphs with cosine values ​​higher than the threshold as candidate subgraphs. Finally, it sorts the subgraphs from high to low similarity and outputs the preset number of subgraphs at the top of the sort as the most relevant subgraphs, providing a basis for subsequent reuse screening.

[0045] In step S53, the graph matching algorithm first extracts the nodes, node attributes, and relationships between nodes from the most relevant subgraph to construct a subgraph structure feature set; then it clarifies the requirements and scenario characteristics of the new project, including project type, technical requirements, and constraints; subsequently, based on the graph structure matching rules, it compares the subgraph structure feature set with the requirements and scenario characteristics layer by layer to select candidate nodes with suitable structures; finally, it verifies the completeness of the attributes and the rationality of the relationships of the candidate nodes, eliminates nodes with missing attributes or conflicting relationships, and finally obtains reusable architectural asset nodes and relationships.

[0046] Furthermore, this application also proposes a bridge engineering project requirements analysis system to implement the above method, such as... Figure 3 As shown, it includes: The multimodal data processing module is used to acquire multimodal raw data of bridge engineering projects, preprocess the multimodal raw data to obtain semi-structured data, store the semi-structured data in the raw data lake and record the data lineage information; The semantic extraction and alignment module is used to perform semantic extraction and entity alignment processing on the semi-structured data, generate a requirement description with logical steps, and realize the merging of homonymous entities and output aligned data. The TOGAF graph generation and conflict detection module is used to map the aligned data into a three-layer architecture node and relationship based on the optimized TOGAF standard architecture, generate a TOGAF attribute graph, perform real-time conflict detection on the TOGAF attribute graph based on mutual exclusion constraint rules, generate conflict prompts and provide alternative solutions, and output a conflict-free TOGAF attribute graph. The visualization fine-tuning module is used to visualize the conflict-free TOGAF attribute diagram, receive user fine-tuning operations, and perform conflict detection again. After confirming that there are no conflicts, it is packaged into a standardized architecture asset package. The asset reuse module is used to store the standardized architecture asset package in a graph database according to three-level classification tags to build an architecture asset library. All data is stored in a unified manner, which facilitates the retrieval and reuse of matching architecture assets when analyzing new project requirements.

[0047] The solutions provided by the embodiments of this application have been described in detail above. The various embodiments in the specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

[0048] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0049] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

Claims

1. A method for requirements analysis in bridge engineering projects, characterized in that, Includes the following steps: S1: Obtain multimodal raw data of bridge engineering projects, and process the multimodal raw data to obtain semi-structured data; S2: Perform semantic extraction and entity alignment processing on the semi-structured data to obtain aligned data; S3: Based on the TOGAF architecture, the aligned data is mapped to the strategy layer, business layer, and application layer to generate a TOGAF attribute graph. Based on the mutual exclusion constraint rules, the TOGAF attribute graph is subjected to real-time conflict detection to obtain a conflict-free TOGAF attribute graph. S4: Visualize the conflict-free TOGAF attribute map, receive user fine-tuning operations and perform conflict detection again, and encapsulate it to obtain a standardized architecture asset package. S5: Store the standardized architecture asset package in a graph database according to the three-layer classification labels of the TOGAF standard architecture to construct a bridge engineering project architecture asset library.

2. The bridge engineering project requirements analysis method according to claim 1, characterized in that, Processing the raw multimodal data includes: S11: Record the data lineage of the multimodal raw data, including file, project, version, and person in charge; S12: Preprocess the multimodal raw data, including image correction, character recognition, named entity recognition, and primitive vectorization parsing; S13: Extract the preprocessed multimodal raw data into triples to obtain semi-structured data.

3. The bridge engineering project requirements analysis method according to claim 1, characterized in that, Step S2 includes the following sub-steps: S21: Generate a logical list of requirement processing tasks that includes business scenario definition, goal setting, and architecture hierarchy construction; S22: Parse the text, image, and tabular data in the semi-structured data respectively, extract the business entities, attribute information, and relationships, and form a preliminary requirement description with logical steps; S23: Filter the semantic information in the preliminary requirements description; S24: Establish a unified semantic space for multimodal entities and merge entities with different names but the same meaning in different data carriers; S25: Clarify the dependencies, constraints, and relationships between the merged entities to form structured, aligned data; S26: Perform a consistency check on the alignment data.

4. The bridge engineering project requirements analysis method according to claim 1, characterized in that, The mapping rules for the strategy layer, business layer, and application layer are as follows: business objects are mapped to business layer nodes, application services are mapped to application layer nodes, and strategic components are mapped to strategy layer nodes. URI, name, and priority core attributes are configured for each layer node, and traceTo or realize trace edges are established between each layer node.

5. The bridge engineering project requirements analysis method according to claim 4, characterized in that, The business layer nodes include business services, business processes, business functions, business objects, business events, and business role nodes; the application layer nodes include application components, application interfaces, application functions, and data object nodes; and the strategy layer nodes include device and system software nodes.

6. The bridge engineering project requirements analysis method according to claim 1, characterized in that, In step S3, the mutual exclusion constraint rule is a mutual exclusion triplet constructed from the indicators extracted from the bridge engineering specifications, and the mutual exclusion triplet is written to the graph database in batches in CSV format. The real-time collision detection includes the following sub-steps: S31: Initialize the TOGAF attribute graph and configure initial attributes for each node; S32: Update the TOGAF attribute graph in real time, analyze the dependency, constraint, and mutual exclusion relationships between the newly added nodes and existing nodes, and add corresponding edges; S33: Use a depth-first search algorithm to detect loops in the TOGAF attribute graph, and check whether there are mutually exclusive edges in the loops and attribute graph that satisfy the mutual exclusion constraint rules; S34: If a mutual exclusion edge is detected, mark the conflict, generate a conflict prompt containing the conflict requirement, conflict attribute, and conflict reason, and attach the alternative solution node.

7. The bridge engineering project requirements analysis method according to claim 1, characterized in that, In step S4, the visualization is achieved through the TOGAFExplore front-end rendering tool, and the fine-tuning operations include adding or deleting nodes, adjusting coordinates, and changing attributes.

8. The bridge engineering project requirements analysis method according to claim 1, characterized in that, When conducting requirements analysis for new bridge engineering projects, matching architectural assets are retrieved from the aforementioned architectural asset library and reused.

9. The bridge engineering project requirements analysis method according to claim 8, characterized in that, Retrieving and reusing matching architecture assets from the architecture asset repository includes the following sub-steps: S51: Receive natural language query requests for new bridge engineering projects; S52: Use the cosine similarity algorithm to retrieve the most relevant subgraph in the architecture asset library in the vector space; S53: Use a graph matching algorithm to filter out reusable architectural asset nodes and relationships from the most relevant subgraphs; S54: Call the reusable architecture asset nodes and relationships to the TOGAF attribute graph generation stage of the new bridge engineering project.

10. A requirements analysis system for bridge engineering projects, characterized in that, include: The multimodal data processing module is used to acquire multimodal raw data of bridge engineering projects, preprocess the multimodal raw data to obtain semi-structured data, store the semi-structured data in the raw data lake and record the data lineage information; The semantic extraction and alignment module is used to perform semantic extraction and entity alignment processing on the semi-structured data, generate a requirement description with logical steps, and realize the merging of homonymous entities and output aligned data. The TOGAF graph generation and conflict detection module is used to map the aligned data into a three-layer architecture node and relationship based on the optimized TOGAF standard architecture, generate a TOGAF attribute graph, perform real-time conflict detection on the TOGAF attribute graph based on mutual exclusion constraint rules, generate conflict prompts and provide alternative solutions, and output a conflict-free TOGAF attribute graph. The visualization fine-tuning module is used to visualize the conflict-free TOGAF attribute diagram, receive user fine-tuning operations, and perform conflict detection again. After confirming that there are no conflicts, it is packaged into a standardized architecture asset package. The asset reuse module is used to store the standardized architecture asset package in a graph database according to three-level classification tags to build an architecture asset library, and to retrieve and reuse matching architecture assets when analyzing new project requirements.

Images