Aero-engine system demand servitization collaborative management method

Abstract

The invention discloses an aero-engine system demand servitization collaborative management method, which comprises the steps of constructing a semantic mapping rule of an aero-engine demand document based on an OSLC specification, and converting an unstructured document into a standardized data model; standardized access of elements in the demand document is achieved through resource identification and a servitization interface, and a Web-based demand document interoperation mechanism is constructed; multidisciplinary collaborative design is carried out based on a demand document interoperation mechanism, and a demand document is updated in real time to form a complete design demand document; constructing an intelligent change analysis mechanism based on project tracking to realize multi-version comparison and change propagation path visualization of the design requirement document; constructing a fine-grained version evolution and conflict management mechanism based on the demand entry influence network, and executing demand version merging and conflict automatic detection in a parallel development scene; according to the method, aero-engine system demand document entry level collaborative editing and standardized service interface can be realized, and the development efficiency is remarkably improved.

Description

Technical Field

[0001] The present invention belongs to the field of MBSE, and particularly relates to a method for collaborative management of aviation engine system requirement serviceification. Background Art

[0002] In the design of aviation engine systems, requirement document management mainly relies on traditional document tools and dedicated requirement management platforms. Common solutions include collaborative editing based on Word documents and the requirement management toolchains proposed by IBM, such as DOORS and RQM. These tools provide basic requirement writing, version control, and tracking capabilities, and support multi-user collaboration. In addition, some enterprises use collaborative development platforms (such as Rational Team Concert) combined with test management tools (such as TestLink) to build an end-to-end requirement management process to realize the association between requirements and design and test activities.

[0003] Existing requirement management technologies mainly achieve collaboration and data flow through document locking and in-platform integration. Taking the IBM requirement management solution as an example, its core is the structured storage of requirements based on DOORS, supplemented by RQM for requirement verification and test case management. Team collaboration relies on the version control mechanism of Rational Team Concert, and concurrent modification conflicts are avoided through overall document locking.

[0004] However, in the existing technology, the collaboration granularity of requirement documents is relatively coarse, only supporting a locking mechanism based on the entire document, resulting in multi-disciplinary teams being unable to concurrently modify different entries of the same document, seriously reducing the design iteration efficiency. Summary of the Invention

[0005] Object of the Invention: The object of the present invention is to provide a method for collaborative management of aviation engine system requirement serviceification that can achieve collaborative editing at the entry level of aviation engine system requirement documents and standardized service interfaces during the requirement analysis stage.

[0006] Technical Solution: The collaborative management method described in the present invention includes the following steps:

[0007] (1) Based on the OSLC specification, construct semantic mapping rules for aviation engine requirement documents, convert unstructured documents into standardized data models, realize machine-readable and semantic interconnection of requirement information, solve the problem that traditional document formats are difficult to be automatically parsed by toolchains, and lay a data foundation for subsequent collaborative editing and system integration;

[0008] (2) Through resource identification and service interfaces, achieve standardized access to elements in requirement documents, build a Web-based requirement document interoperability mechanism, break tool silos, support cross-disciplinary teams to read and write requirement data in real time through standardized interfaces, and improve collaboration efficiency;

[0009] (3) Carry out multidisciplinary collaborative design based on the requirement document interoperability mechanism and update the requirement document in real time to form a complete design requirement document, avoiding the version inconsistency problem caused by document transfer delay in the traditional serial mode. The finally generated requirement document integrates the inputs from various fields, ensuring the integrity and consistency of system design;

[0010] (4) Build an intelligent change analysis mechanism based on project tracking to realize multi-version comparison of the design requirement document and visualization of the change propagation path, helping engineers quickly locate the impact scope of requirement modifications, reducing manual tracing errors, especially suitable for change scenarios in complex aero-engine systems where a small change can have a significant impact, and reducing iteration costs;

[0011] (5) Build a fine-grained version evolution and conflict management mechanism based on the requirement item impact network, perform requirement version merging and automatic conflict detection in parallel development scenarios, avoid omissions in manual merging, and significantly improve the reliability and development efficiency of large-scale team collaboration.

[0012] Preferably, the construction of semantic mapping rules described in step 1 includes:

[0013] Map the service provider catalog of the OSLC core model to the central repository of the aero-engine requirement document;

[0014] Map the service provider in the OSLC specification to the disciplinary partition chapter of the requirement document;

[0015] Map the service in the OSLC specification to the add, delete, modify, and query operations of the internal items, parameters, and constraints of the requirement document;

[0016] Map the resource in the OSLC specification to independent requirement items and their parameter indicators.

[0017] The above mapping rules realize the structured decomposition of the requirement document and the standardized service encapsulation, converting the originally loose unstructured document into a programmatically accessible fine-grained resource, which not only retains the document-level logic but also provides a unified semantic and operation framework for subsequent collaborative editing, change tracking, and system integration, significantly improving the automation level of requirement management and the interoperability of multi-tool chains.

[0018] Preferably, step 1 further includes parsing the requirements document recursively: decomposing layer by layer from the top-level structure of the document to extract the chapter-level relationships and requirement items; identifying the item types, numbers, descriptions, parameter values, and qualification conditions in the requirement items; presenting the parsing results in the form of a requirement data tree that retains the original document's hierarchical structure, converting the unstructured natural language requirements document into a tree-like data model with clear semantic associations, ensuring the integrity of requirement information, and providing a computable data foundation for subsequent version control, change impact analysis, and multidisciplinary collaborative editing, significantly improving the accuracy and automated processing ability of requirement management.

[0019] Preferably, the structure of the requirement data tree is root node - chapter node - specific requirement item node; among them, the root node represents the system requirements document of the entire aero-engine, the chapter node represents performance requirements, safety requirements, environmental adaptability requirements, and reliability requirements, and the specific requirement item node contains parameter attribute information, which not only completely retains the original business logic of the requirements document but also realizes the precise positioning and independent operation of requirement items and their parameters, providing fine-grained and traceable data support for subsequent version comparison, change impact analysis, and multidisciplinary collaborative optimization, effectively solving the problems of weak requirement correlation and difficult change impact assessment in the traditional document management mode.

[0020] Preferably, the resource identification in step 2 includes: assigning a URI with a hierarchical path structure to each requirement item, including requirement categories and hierarchical relationships; describing the requirement items through semantic tags to form independently addressable entities, which not only retains the inherent hierarchical relationship of the requirements document but also realizes the precise positioning and independent management of requirement items through the standardized access mechanism of the URI, providing a unified resource location framework for cross-system and cross-team collaborative editing, requirement tracing, and change impact analysis, significantly improving the operability of requirement data and the interoperability between systems.

[0021] Preferably, the service interface in step 2 includes: establishing a three-layer tool adapter, including a data layer for interacting with the requirements document, a service layer for processing resource mapping and relationship management, and an interface layer providing RESTful APIs, building a service interface based on the RESTful architecture based on the tool adapter, the service interface supports GET, POST, PUT, DELETE operations of the HTTP protocol, realizing a unified access and management mechanism for requirements document data, enabling toolchains of different disciplines to be integrated in a loosely coupled manner, supporting cross-platform and cross-language collaborative editing and real-time synchronization, while reducing the complexity of data exchange between systems, significantly improving the flexibility and scalability of aero-engine requirement management.

[0022] Preferably, the intelligent change analysis mechanism includes: establishing a multi-dimensional comparative analysis framework for requirement changes, covering text content, parameter values, structure, and associated relationship changes, and displaying the positions and types of requirement changes based on visualization means, achieving accurate positioning and type identification of requirement changes; visually identifying the critical path based on the propagation path of requirement changes, generating a knowledge graph network diagram of change impacts, enabling engineers to quickly identify critical change paths and their potential risks, effectively solving the problem of difficult assessment of the impact scope of requirement changes in complex aero-engine systems, significantly improving the scientific nature and decision-making efficiency of change management, and at the same time reducing the iteration costs caused by missed or misjudged changes.

[0023] Preferably, the visualization of the propagation path of requirement changes includes: presenting the propagation path of requirement changes using a directed graph, where the nodes of the propagation path represent requirement items, the edges represent influence relationships, and the thickness or color of the edges reflects the degree of influence; identifying and highlighting the propagation chains involving critical system requirements and the critical influence paths crossing disciplinary boundaries, turning the complex analysis of requirement change impacts into an intuitive graphical expression, helping engineers quickly lock in high-risk change areas and critical propagation chains, significantly improving the efficiency and accuracy of requirement change assessment in multi-disciplinary coupled systems such as aero-engines, and effectively avoiding the problem of easily missing implicit associations in traditional text comparison.

[0024] Preferably, the fine-grained version evolution includes: constructing a version evolution model based on the influence network of requirement items, expressing the evolution process of the requirement document as a sequence of state changes of requirement items and their mutual relationships; the version evolution model tracks requirement changes at the item granularity, performs independent version management for each requirement item, enabling version management to be refined from traditional overall document control to parameter-level change records, being able to accurately trace the historical modification tracks of any item and analyze the chain reaction of changes through the relationship network, thereby significantly improving the version control accuracy and conflict detection efficiency in the parallel development scenario while ensuring the integrity of the complex requirement system of aero-engines.

[0025] Preferably, the conflict management mechanism includes: performing a merge operation when different design teams modify different requirement items; identifying and integrating complementary modifications according to relevant operations when different design teams modify the same requirement item but the modified contents do not conflict; marking conflict points when different design teams make conflicting modifications to the same requirement item, effectively solving the version coordination problem in multi-team parallel development, avoiding both missed modifications or misjudgments that may be caused by traditional manual merging and significantly improving the accuracy and processing efficiency of conflict identification, ensuring the coordination and consistency of the complex requirement change process of aero-engines, and at the same time reducing the rework risks caused by version conflicts.

[0026] Beneficial effects: Compared with the prior art, the present invention has the following remarkable advantages: 1. It can achieve collaborative editing at the entry level of the requirements document of the aero-engine system and a standardized service interface, significantly improving the development efficiency; 2. By means of the RESTful Web service, a standardized HTTP interface is exposed for each requirement entry, enabling external design tools to directly access and operate the requirement data, and solving the problem that traditional closed systems rely on private interfaces and are difficult to integrate with third-party tools; 3. A unique URI is assigned to each entry, upgrading the document-level management to resource-level control, supporting precise version control, change traceability and permission management, and meeting the refined control requirements of the high-complexity requirements of aero-engines. Brief Description of the Drawings

[0027] Figure 1 It is a schematic flowchart of the present invention;

[0028] Figure 2 It is a schematic diagram of parsing the requirements document and constructing semantic mapping rules of the present invention;

[0029] Figure 3 It is a schematic diagram of the resource identification and service interface of the present invention;

[0030] Figure 4 It is a schematic diagram of multi-disciplinary requirement analysis and design information interaction of the present invention. Detailed Embodiment

[0031] The technical solution of the present invention will be further described below with reference to the drawings.

[0032] The collaborative management method described in the present invention uses the OSLC specification to parse the key content and structure in the aero-engine requirements document, constructs semantic mapping rules, converts the requirements document content into a standardized data model, realizes the standardized expression of the aero-engine system requirements document, and through the fine-grained resource identification and service interface technology, realizes the structured data expression and cross-platform access ability of the aero-engine system requirements document. This method can solve the key technical problems in the existing aero-engine system requirements management, such as parallel editing conflicts at the requirement entry level, lack of a standardized document access interface resulting in the fragmentation of requirement data from the downstream tool chain, and difficulty in achieving efficient requirement sharing and collaborative modification among cross-disciplinary design teams.

[0033] As Figure 1 shown, the present invention includes the following steps:

[0034] Step 1: Parse the aero-engine system requirements document based on the OSLC specification and construct semantic mapping rules to realize the standardized data expression of the requirements document.

[0035] OSLC is a technical specification proposed by IBM for tool integration and collaboration within the MBSE lifecycle, which can provide a unified method to manage and operate various models and their data in lifecycle management tools. The OSLC specification consists of a core specification and domain specifications. The core specification standardizes and describes the most core integration concepts of the OSLC specification and the general features supported by OSLC services. The OSLC core model includes a service provider catalog, service providers, services, and resources.

[0036] Through the OSLC specification, the data resources of aeroengine requirement documents are uniformly described. Based on in-depth analysis of the design information of requirement documents, key information such as the entry structure, parameter indicators, and performance constraints in the aeroengine system requirement documents is obtained, and a complete set of mapping rules is constructed to convert the unstructured or semi-structured document content into a standardized data structure expression that conforms to the OSLC specification.

[0037] Based on the Open Services Lifecycle Collaboration (OSLC) specification, semantic mapping rules between the OSLC core model and aeroengine system requirement documents are established, the mapping relationship of object elements between the two is clarified, and the standardized expression of aeroengine system requirement document data is realized. The semantic mapping rules between the OSLC core model and aeroengine system requirement documents are shown in Table 1.

[0038] Table 1 Mapping Objects between OSLC Core Specification and Requirement Documents

[0039] OSLC framework Requirement document Service provider directory Aero-engine requirement document collection library Service provider Main chapters and subject partitions of requirement document Service Requirement document operation set (query, add, delete, modify, etc.) Resource Independent requirement item (inference parameter, temperature limit, etc.)

[0040] According to this mapping structure, the service provider catalog in the OSLC specification, as the top-level concept in OSLC, is responsible for managing and organizing multiple service providers, providing a unified access entry, corresponding to the document library in the aeroengine system requirement documents, that is, the central repository for all requirement documents; the service providers in the OSLC specification represent containers or partitions that provide specific services, corresponding to multiple different documents and discipline chapters in the aeroengine system requirement documents, providing a standardized access mechanism; the service in the OSLC specification defines operation methods such as creating, reading, updating, and deleting resources, ensuring the consistency of data operations, so as to achieve consistent interaction with requirement entries, corresponding to operations such as adding, deleting, modifying, and querying internal entries, parameters, and constraints in the aeroengine system requirement documents; the resources in the OSLC specification are the specific data units processed in OSLC services, uniquely identified by URIs, and can be accessed and operated independently, corresponding to basic elements such as all levels of requirement entries, performance parameters, design constraints, and verification rules in the aeroengine system requirement documents.

[0041] Furthermore, the data of the requirement document is parsed to obtain key information such as the structure level, requirement items, parameter indicators and different interfaces of the requirement document operation set (query, add, delete, modify) to ensure that the document data can be smoothly integrated. When parsing the aircraft engine system requirement document, it is necessary to search and extract the parameters and attributes of each chapter and requirement item. The parsing process adopts a recursive method, such as Figure 2 As shown in the figure, starting from the top-level structure of the document, the semantic information is decomposed layer by layer: first, the main chapters and their hierarchical relationships are identified; then the requirement items in each chapter are parsed to extract the item type, number, description, parameter value and limiting conditions. The parsing result forms a structured requirement data tree, which retains the hierarchical structure and technical content of the original document and adds standardized identification. The structure of the requirement data tree usually adopts a hierarchical design. The root node represents the entire aircraft engine system requirement document, and there are several main chapter nodes, such as performance requirements, safety requirements, environmental adaptability requirements, reliability requirements, etc. Each chapter node is further subdivided into multiple specific requirement item nodes. For example, performance requirements can be subdivided into thrust parameters, fuel consumption, operating speed, etc.; safety requirements can be subdivided into failure protection, overtemperature control, vibration control, etc. Each node contains its parameter attribute information, such as specific numerical requirements, allowable range, verification method, etc., to help the design team understand the mutual influence between different requirements.

[0042] The above mapping and parsing mechanism effectively solves the problem of unified expression and data format standardization of aircraft engine requirement documents. By establishing a unified mapping mechanism and performing document parsing, it ensures that the requirement information provided by teams in different disciplines can be standardized and integrated while maintaining the original semantics, providing a basis for subsequent document entries to be accessed as independent resources.

[0043] Step 2: Implement standardized access to document elements through resource identification and service interfaces, build a requirement document tool adapter, provide Web-based requirement document interoperability services for aircraft engine systems, and lay the foundation for architecture design and simulation verification tools to automatically extract design information from requirement documents.

[0044] Based on the established parsing and mapping framework, each aircraft engine requirement is converted into an independently accessible network resource, and a standardized interactive interface system is constructed. This transformation transforms the requirements from items in static documents into dynamic and operable data resources, and realizes the precise management and access control of requirement items.

[0045] like Figure 3As shown in the figure, first, for each requirement entry element in the requirement document, such as the thrust in the engine performance requirement document and the temperature constraint entry of the lubricating oil system, a unique URI that complies with the specification is assigned. The URI design adopts a hierarchical path structure, including the category and hierarchical relationship of the requirements, ensuring that it can be accurately located or accessed. Taking the performance requirements of an aero-engine system as an example, its maximum thrust requirement entry is mapped to the resource concept in OSLC, through the semantic label <oslc>Describe, and represent the maximum thrust requirement by the URI value "http: / / engine-requirements.com / performance / thrust / max", and "XXX / lubrication / temperature / max" represents the maximum temperature constraint requirement of the lubrication system. This resource-based identification makes each requirement entry an independently addressable entity, providing a basis for fine-grained access.

[0046] Based on the resource-based identification, build a service interface based on the RESTful architecture to implement standardized operations on the requirement resources. Through methods such as GET, POST, PUT, DELETE of the HTTP protocol, achieve comprehensive management of the requirement entries of the aero-engine system. For example, by accessing the resource with the URI "http: / / engine-requirements.com / performance / R001 / properties" through the GET method, all attribute information of the thrust requirement of the aero-engine system numbered R001 can be obtained; by updating the corresponding resource of "XXX / R001 / description" through the PUT method, its requirement description can be modified; by adding a new reliability requirement entry to "XXX / reliability" through the POST method; by deleting the outdated environmental adaptability requirement corresponding to "XXX / environmental / E009" through the DELETE method. For the operation requirements under special working conditions of the aero-engine, the high-altitude performance requirement module can be accessed through "XXX / performance / high-altitude", and the safety parameters of the anti-icing system can be obtained through "XXX / safety / icing-protection". To support the implementation of these service interfaces, a dedicated Web-based requirement document tool adapter is developed in this step. This adapter adopts a three-layer structure: the data layer is responsible for interacting with the original requirement document to achieve format conversion and content extraction; the service layer implements the service functions defined by the OSLC specification, processes resource mapping and relationship management; the interface layer provides a standardized RESTful API to support external system integration. This resource-based and service-based design fundamentally changes the access mode of the requirement document, enabling multiple teams to edit different requirement entries simultaneously without interfering with each other. For example, when the aerodynamic team modifies the intake parameters, the structural team can update the material strength requirements at the same time, and the control team can adjust the relevant control parameters to achieve true parallel collaborative work.

[0047] This requirement document management mode based on resource identification and service-oriented interfaces also lays a foundation for the subsequent automatic extraction of requirement document design information for architecture design and simulation verification tools. Through standardized RESTful interfaces, future architecture design tools can directly query key performance parameters (such as maximum thrust value, operating speed range, etc.), and simulation verification tools can automatically obtain verification rules and constraints without manual transcription, thus eliminating human errors in the data transfer process. For example, the simulation verification tool for aeroengines can directly call 'http: / / engine-requirements.com / performance / thrust / max' through the API to obtain the maximum thrust value and apply it to the parameter configuration of system design and simulation. This forward-looking research paradigm provides a new approach for the digital collaborative design of the entire life cycle of aeroengine systems.

[0048] Step 3: Conduct multidisciplinary requirement analysis and design information interaction for the aeroengine system based on the resource-based requirement document. Through the real-time update of the requirement document and the parallel collaborative editing of multiple teams, a complete aeroengine system design requirement document is finally formed, providing a reliable authoritative truth source for the analysis and selection of requirement document information in the subsequent architecture design and simulation verification phases.

[0049] After the service-oriented construction of the requirement document is completed, multidisciplinary requirement analysis and design can be carried out. As Figure 4 shown, aeroengine design involves the close collaboration of multiple professional fields. Based on the requirement document tool adapter, the collaborative work of multiple professional teams such as aerodynamics, structure, thermodynamics, and control can be realized. Each team is responsible for analyzing, refining, and supplementing the requirements in its respective field. For example, the aerodynamics team is responsible for formulating parameter requirements such as inlet flow rate and pressure ratio; the structure team focuses on design constraints such as blade strength and vibration characteristics; the thermodynamics team pays attention to thermal management requirements such as temperature distribution and cooling efficiency; the control team focuses on control characteristic requirements such as response time and stability. Through the service-oriented requirement document, each team can access and modify the requirement items it is responsible for in parallel without interfering with each other. For example, when the aerodynamics team modifies the high-altitude performance parameters, the structure team can simultaneously check and adjust the relevant material strength requirements, and the control team can parallelly update the corresponding control logic requirements. Through this service-oriented collaboration mechanism, each professional team can efficiently collaborate based on a unified requirement document platform to jointly create a complete, consistent, and high-quality aeroengine system requirement specification. Each requirement in the document has been reviewed and improved from a multidisciplinary perspective to ensure technical feasibility and system consistency. The finally formed requirement document will serve as the authoritative basis for subsequent architecture design and simulation verification, providing clear guidance for the detailed design and development of aeroengine systems.

[0050] Step 4: Build an intelligent change analysis mechanism based on project tracking to achieve multi-version comparison and analysis of the requirements documents of the aero-engine system and visualization of the change propagation path, supporting the engineering team to accurately understand the requirement evolution process and the scope of influence.

[0051] Based on the service-oriented collaborative management of the aero-engine system requirements documents, build an intelligent change analysis mechanism. Through the automatic comparison and analysis between different versions of the requirements documents, identify the modification, addition or deletion of requirement items, and use a graphical method to present the changed content and its influence propagation path, helping the engineering team accurately grasp the requirement evolution process and the scope of influence.

[0052] First, the system establishes a multi-dimensional comparison and analysis framework for requirement changes, supporting the automatic comparison of requirements documents in different versions. The comparison process covers multiple dimensions, including text content changes (such as the modification of descriptive text), parameter value changes (such as the adjustment of numerical indicators), structural changes (such as the adjustment of requirement hierarchy relationships), and association relationship changes (such as the update of dependencies or verification methods). The core functions of the change comparison and analysis include: ① Item-level change identification: accurately locate the specific requirement items that have changed, and intuitively display the change location and type through visual means such as color coding; ② Change classification and statistics: automatically classify changes into three categories: addition, deletion, and modification, and further subdivide them into sub-categories such as parameter adjustment, constraint change, and description clarification, providing statistical analysis of the change distribution; ③ Multi-version side-by-side comparison: support the side-by-side comparison of two or more versions, facilitating the review of the requirement evolution process at milestone nodes.

[0053] Second, the system constructs visualization technology for change propagation paths and key path identification, analyzes the interdependent relationships between requirement items, and automatically generates a knowledge graph network diagram of change impacts. When a change occurs in a requirement item, the system can automatically track all relevant requirement items that may be affected by this change, forming a complete impact chain. For example, when the maximum thrust requirement increases from "250 kN" to "280 kN", the system will automatically identify that the requirement items in aspects such as the fuel system, cooling system, and material strength related to thrust may be affected. The visualization technology for change propagation paths has the following key features: ① Graphical impact network: Intuitively present the propagation path of requirement changes in the form of a directed graph, where nodes represent requirement items and edges represent impact relationships, and the thickness or color of the edges reflects the degree of influence; ② Key path highlighting: Automatically identify and highlight the key paths affected by the change, that is, those propagation chains with the greatest degree of influence or involving key system functions; ③ Cross-disciplinary boundary identification: Specifically identify the boundary points where the change impact crosses different disciplinary fields; ④ Impact level aggregation: Support aggregating and displaying the scope of influence at different levels such as system requirements and subsystem requirements, facilitating personnel in different roles to obtain the information granularity suitable for their decision-making needs.

[0054] Through this intelligent change analysis mechanism, the engineering team can clearly grasp the evolution process of requirements, accurately understand the content of each change and its impact scope, and effectively avoid design inconsistency problems caused by poor transmission of requirement changes. Especially in highly complex systems such as aero-engines with extremely high safety requirements, accurate change management plays a crucial role in ensuring design quality and shortening the R & D cycle.

[0055] Step 5: Based on the requirement item impact network, build a fine-grained version evolution and conflict management mechanism to achieve requirement version merging and automatic conflict detection in parallel development scenarios, ensuring the overall consistency of aero-engine system design.

[0056] On the basis of realizing the service-oriented collaborative management and change analysis of requirement documents, build a fine-grained version evolution and conflict management mechanism to support requirement version control, branch management and merge operations in parallel development scenarios, focus on solving the version conflict problem in the process of multi-team parallel modification, and ensure the overall consistency of aero-engine system requirements.

[0057] First of all, the system constructs a version evolution model based on the requirement item impact network, expressing the evolution process of requirement documents as a sequence of state changes of requirement items and their relationships. Different from traditional document-level version control, this model uses item-level granularity to track requirement changes and realizes independent version management for each requirement item. The system assigns a unique version identifier to each requirement item and maintains key information such as modified content. Based on this model, the system supports complex version branch operations, allowing multiple parallel design branches to be created for the same baseline version to meet the needs of different design teams to explore multiple technical solutions simultaneously.

[0058] During the version evolution process, the system focuses on building a version merging mechanism in parallel design scenarios. When different teams create multiple design branches based on the same baseline and independently modify requirements on their respective branches, these modifications need to be integrated into a consistent version. The system uses an intelligent merging algorithm to analyze the modified content in different branches and identify conflicts. Specific merging strategies include: automatic merging of non-conflicting areas: for the case where different branches modify different requirement items, the system automatically performs the merging operation; intelligent integration of complementary modifications: for the case where different branches modify the same requirement item but the modified content does not conflict (such as one branch modifies the description text and the other branch modifies the parameter value), the system can intelligently identify and perform relevant operations to integrate complementary modifications; clear identification of conflicting modifications: for the case where different branches make conflicting modifications to the same requirement item, the system clearly identifies the conflict points to assist engineers in making reasonable decisions.

[0059] Conflict detection and resolution are the core aspects of version merging. The system employs a multi-dimensional conflict detection algorithm to check for direct conflicts in texts or parameters. For example, when the pneumatic team reduces the upper limit of the intake air temperature to 600°C in one branch, while the thermal management team designs a cooling system based on a temperature assumption of 650°C in another branch, even if these two modifications occur in different requirement entries, the system can identify the indirect conflict between them. Specific ways of conflict detection include: Direct conflict detection: Identifying conflicting modifications to the same requirement entry, such as inconsistent parameter value settings; Constraint conflict detection: Analyzing the constraint relationships between different requirement entries and identifying modification combinations that violate the overall system constraints; Cross-domain consistency detection: Checking the consistency of requirements across interdisciplinary fields to ensure that requirements from different professional perspectives are coordinated. To support engineers in effectively resolving conflicts, the system provides conflict visualization and auxiliary decision-making tools, which display complex conflict relationships graphically and provide relevant background information and suggestions for possible solutions. At the same time, the system supports collaborative conflict resolution, allowing relevant teams involved in the conflict to directly discuss and negotiate solutions through built-in communication channels. After resolving the conflict, the system records the process and basis of conflict resolution to form a complete decision traceability record.

[0060] In the design of aero-engines, typical application scenarios of version evolution and conflict management include: Parallel evaluation of technical solutions: Different teams explore multiple technical solutions simultaneously, such as the comparative evaluation of different compressor ratio solutions for turbofan engines; Response to updated airworthiness requirements: When airworthiness clauses are updated, multiple disciplinary teams need to simultaneously modify relevant requirements in their respective fields and ensure overall consistency; Iterative optimization of performance indicators: During the performance optimization process, each professional team makes parallel iterative improvements to key indicators, such as the collaborative optimization of indicators like thrust-to-weight ratio and fuel efficiency.

[0061] Through this fine-grained version evolution and conflict management mechanism, the aero-engine system design team can, while maintaining efficient parallel development, effectively manage the version evolution process, identify and resolve potential conflicts, ensure the overall consistency and traceability of system requirements, thereby significantly improving the quality and efficiency of complex system design.< / oslc>

Claims

1. A collaborative management method for service-oriented requirements of an aero-engine system, characterized in that, It includes the following steps: (1) Construct semantic mapping rules for aero-engine requirement documents based on the OSLC specification, and convert unstructured documents into a standardized data model; (2) Achieve standardized access to elements in the requirement document through resource identification and service interfaces, and construct a Web-based requirement document interoperability mechanism; (3) Carry out multidisciplinary collaborative design based on the requirement document interoperability mechanism and update the requirement document in real time to form a complete design requirement document; (4) Construct an intelligent change analysis mechanism based on project tracking to realize multi-version comparison of the design requirement document and visualization of the change propagation path; (5) Construct a fine-grained version evolution and conflict management mechanism based on the requirement item impact network, and perform requirement version merging and automatic conflict detection in a parallel development scenario.

2. The collaborative management method according to claim 1, wherein The construction of semantic mapping rules described in step 1 includes: Mapping the service provider catalog of the OSLC core model to the central repository of aero-engine requirement documents; Mapping the service providers in the OSLC specification to the disciplinary partition chapters of the requirement document; Mapping the services in the OSLC specification to the addition, deletion, modification, and query operations of internal entries, parameters, and constraints in the requirement document; Mapping the resources in the OSLC specification to independent requirement entries and their parameter indicators.

3. The collaborative management method according to claim 1, wherein Step 1 also includes recursively parsing the requirement document for data: Decompose layer by layer from the top-level structure of the document to extract the chapter-level relationship and requirement entries; Identify the entry type, number, description, parameter value, and qualification conditions in the requirement entries; Display the parsing results in the form of a requirement data tree that retains the original document hierarchy.

4. The collaborative management method according to claim 3, wherein The structure of the requirement data tree is root node - chapter node - specific requirement entry node; among them, the root node represents the system requirement document of the entire aero-engine, the chapter node represents performance requirements, safety requirements, environmental adaptability requirements, and reliability requirements, and the specific requirement entry node contains parameter attribute information.

5. The collaborative management method according to claim 1, wherein The resource identification described in step 2 includes: Assign a URI with a hierarchical path structure to each requirement entry, including the requirement category and hierarchical relationship; Describe the requirement entry through semantic tags to form an independently addressable entity.

6. The collaborative management method according to claim 1, wherein The service interface described in step 2 includes: Establish a three-layer tool adapter, including a data layer for interacting with the requirement document, a service layer for processing resource mapping and relationship management, and an interface layer providing RESTful APIs, Construct a service interface based on the RESTful architecture based on the tool adapter, and the service interface supports GET, POST, PUT, and DELETE operations of the HTTP protocol.

7. The collaborative management method according to claim 1, wherein The intelligent change analysis mechanism includes: Establish a multi-dimensional comparative analysis framework for requirement changes, covering text content, parameter values, structure, and association relationship changes, and display the location and type of requirement changes based on visualization means; Identify the critical path based on the visualization of the requirement change propagation path, and generate a knowledge graph network diagram of the change impact.

8. The collaborative management method according to claim 7, characterized in that, The visualization of the requirement change propagation path includes: Use a directed graph to present the propagation path of requirement changes. Among them, the nodes of the propagation path represent requirement items, the edges represent influence relationships, and the thickness or color of the edges reflects the degree of influence. Identify and highlight the propagation chains involving key system requirements and the key influence paths across disciplinary boundaries.

9. The collaborative management method according to claim 1, wherein The fine-grained version evolution includes: Construct a version evolution model based on the influence network of requirement items, and express the evolution process of the requirement document as a sequence of state changes of requirement items and their mutual relationships; the version evolution model tracks requirement changes at the item granularity and performs independent version management for each requirement item.

10. The collaborative management method according to claim 1, wherein The conflict management mechanism includes: When different design teams modify different requirement items, perform a merge operation. When different design teams modify the same requirement item but the modified contents do not conflict, identify and integrate complementary modifications according to the relevant operations. When different design teams make conflicting modifications to the same requirement item, identify the conflict points.

Images