A complex network-based launch vehicle demand change influence domain analysis method
By constructing a complex network for launch vehicles, establishing demand traceability relationships and quantitative analysis, the problem of frequent demand changes in launch vehicle R&D has been solved, achieving demand consistency and efficient management throughout the entire life cycle, and improving development efficiency and product quality.
Patent Information
- Application Number
- CN202410916480.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-07-09
- Publication Date
- 2026-02-10
- Estimated Expiration
- 2044-07-09
AI Technical Summary
In traditional launch vehicle development, the lack of correlation and mapping between requirements and system architecture leads to frequent changes in requirements, making it difficult to achieve the integrity and consistency of requirements, which affects development costs and cycle time.
We adopt a demand change impact domain analysis method based on complex networks. By constructing a complex network of launch vehicles, we establish demand traceability relationships, conduct demand change request decision-making and ripple effect analysis, quantify the impact domain, and use MOE, MOP and TPM as network parameter values to achieve demand management and consistency throughout the entire life cycle.
This improved the integrity and consistency of requirements during the development of launch vehicles, reduced the risk of requirement changes, enhanced development efficiency and transparent management capabilities, and ensured the stability of requirements and product quality at each stage.
Smart Images
Figure CN118839919B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the aerospace field and relates to a method for analyzing the impact domain of launch vehicle demand changes based on complex networks. Background Technology
[0002] With the development of aerospace technology, my country is gradually moving from a major spacefaring nation to a leading spacefaring nation. Launch vehicles are characterized by increasingly complex system technologies and shorter development cycles, posing unprecedented challenges to rocket development and the integration of various subsystems. In traditional launch vehicle development, textual descriptions of requirements, schemes, design, production, and testing elements are used. However, the overall requirements are not well correlated or mapped with the system architecture, design verification models, and test cases, making accurate mission requirement analysis impossible and leading to frequent requirement changes later on. Launch vehicle development involves cross-departmental, cross-unit, and cross-regional collaboration, involving multiple parties such as overall model, overall engineering, subsystems, individual units, and components. The large volume and multiple versions of documents increase the difficulty of technical management. The low coupling of technical documents along the development line results in poor completeness and consistency of requirements, making traceability difficult. This increases the difficulty of controlling requirement changes during scheme demonstration and product development, leading to poor consistency between top-level requirements and the final product, and exacerbating development costs and mission cycle risks.
[0003] Model-Based System Engineering (MBSE) utilizes formal models to manage the entire process from conceptual design, scheme design, experimental verification to engineering implementation. This method effectively addresses the challenges faced by document-based design methods in areas such as requirements verification, technical status management, and data traceability, and has become a hot topic in aerospace research and application in recent years. Therefore, conducting research and application of MBSE-based launch vehicle development methods, starting from mission requirements, and constructing a complex network-based method for analyzing the impact domain of launch vehicle requirement changes, is a crucial step. Summary of the Invention
[0004] Based on the main problems existing in the current application of MBSE in model requirement modeling, and building upon the classic methodology RFLP (R: Requirement, F: Function, L: Logical, P: Physical) design framework, this invention provides a method for analyzing the impact domain of requirement changes based on complex networks, including the following steps:
[0005] S1: Construction of Complex Launch Vehicle Network. The construction of complex launch vehicle network involves building a demand model information architecture, dividing the demands into five levels: stakeholder demands, system-level demands, subsystem-level demands, sub-demand-level demands, and unit-level demands. Based on this demand model information architecture, a complex launch vehicle network is constructed.
[0006] S2: Requirements Traceability Modeling. Each level of requirements includes two types of traceability relationships: vertical relationships (traceability between upper and lower level requirements) and horizontal relationships (traceability between the current level's requirements and the design model, product model, and simulation test data model of the current level). A full-level traceability model for the launch vehicle is constructed based on these two dimensions: vertical and horizontal relationships.
[0007] S3: Decision-Making for Demand Change Requests. Based on the characteristics of the launch vehicle and its design, a change decision-making method based on demand change impact assessment is proposed. This method analyzes the impact of the change on the entire design process and makes an accurate decision based on the magnitude of the impact.
[0008] S4: Demand Change Slide Effect Analysis. Based on the demand traceability relationship, the spillover effect is divided into vertical and horizontal spillover effects. Based on the demand traceability relationship model, the affected demand model, design model, product model, and simulation test data model can be clearly obtained by searching the change path. Through demand change spillover effect analysis, the demand work-in-process and design work-in-process affected by the demand change are identified, forming the work-in-process affected by the demand.
[0009] S5: Quantitative Analysis of the Impact Domain of Demand Changes. Using the Measures of Effectiveness (MOE), Measures of Performance (MOP), and Technical Performance Measure (TPM) as network parameter values, and based on the complex network model of the launch vehicle, the quantitative analysis values of the virtual simulation are obtained by mapping the above network parameter values, thereby obtaining the design attributes and technical indicators of the launch vehicle's impact domain after demand changes.
[0010] MOE (Mean Objective of Product) is a measurement metric for the successful implementation of a product from an operational perspective, defined under specific operating environments and conditions. It is closely related to the completion of tasks or the operational objectives to be evaluated, i.e., the degree to which the product achieves its expected goals. MOPs (Mean Objectives of Product) are measurement metrics used to reflect the physical or functional attributes related to system operation under specific testing or operating environments. TPM (Technical Productivity Management) is used to measure the attributes of system elements to determine the extent to which the system or system elements meet or will meet technical requirements and objectives.
[0011] This invention provides a method for analyzing the impact domain of demand changes based on complex networks, which guides the implementation of demand changes and has the following beneficial effects:
[0012] 1) Fully maintain the integrity and correctness of requirements in the R&D process.
[0013] Exploring a launch vehicle requirements methodology based on MBSE (Model-Based Execution System) allows requirements management and design to be communicated through models, ensuring the correctness and consistency of requirements throughout the entire lifecycle. This improves design efficiency, guarantees product development quality, comprehensively maintains the integrity and correctness of requirements during the development process, ensures stable input at each stage, and avoids the risks caused by frequent changes and the significant impact of erroneous requirements on future development stages.
[0014] 2) Strictly support the consistency of requirements with each stage of the launch vehicle's entire life cycle.
[0015] Launch vehicles are characterized by high dynamics and high reliability, complex and ever-changing development processes, high development costs, and varying development cycles. They also possess significant features such as long development chains, multiple disciplines, comprehensive stages, and complex mission scenarios. The MBSE integrated model enables unified management of data sources, resolving the fragmentation between different design stages, saving time for personnel across the entire development process in maintaining development data, improving development efficiency and transparent management capabilities, strictly supporting consistency between each stage of development and requirements, ensuring that the impact of requirement changes is not lost or overlooked, and keeping it within a reasonable range.
[0016] This invention focuses on the entire lifecycle development process of launch vehicles. It establishes a traceability framework by creating relationships between current-level requirements and lower-level requirements, as well as between current-level requirements and design models, product models, and simulation test verification data models during the launch vehicle R&D process. From stakeholder requirements to system-level requirements, system-level requirements to subsystem requirements, subsystem requirements to individual system requirements, and finally to unit-level requirements, the traceability of requirements is controllable. A traceability coverage network confirms the correctness and completeness of traceability. By establishing a full-cycle, end-to-end requirement traceability framework, bottom-up requirement traceability ensures that all requirements meet stakeholder expectations. Top-down requirement traceability ensures the completeness of launch vehicle design. Based on the formally expressed requirement traceability mechanism, it provides a verification basis for ineffective and out-of-specification designs. Attached Figure Description
[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0018] Figure 1 This is a schematic diagram of the launch vehicle requirement change response process of the present invention;
[0019] Figure 2 This is a schematic diagram of a method for analyzing the spillover effects of launch vehicle demand changes based on complex networks, according to the present invention.
[0020] Figure 3 This is a diagram illustrating the demand dependencies of launch vehicles.
[0021] Figure 4 This is a schematic diagram of the launch vehicle demand traceability matrix;
[0022] Figure 5 A schematic diagram illustrating the quantitative mapping of changes in launch vehicle requirements;
[0023] Figure 6 A schematic diagram of the complex network of a launch vehicle;
[0024] Figure 7 This is a schematic diagram of the launch vehicle demand traceability network.
[0025] Specific implementation methods
[0026] The invention will now be further described with reference to the accompanying drawings.
[0027] The above specific embodiments are used to explain and illustrate the present invention. Any modifications and changes made to the present invention within the spirit and scope of the claims shall fall within the protection scope of the present invention.
[0028] Example 1
[0029] This invention provides a method for analyzing the impact domain of demand changes based on complex networks, and constructs a response process for demand changes in launch vehicles, such as... Figure 1 As shown, it specifically includes the following 5 steps:
[0030] S1: Complex Network Construction for Launch Vehicles
[0031] Complex networks are often used to abstractly model objects in reality that have hierarchical structures and complex internal relationships. Based on the functions and characteristics of the components, complex products inherently possess strong hierarchical structures. Therefore, the structure of a launch vehicle can be viewed as a complex network, with each component of the launch vehicle being a network node, and the relationships between components being network edges.
[0032] Based on the launch vehicle requirement model information architecture, requirements are divided into five levels: stakeholder requirements, system-level requirements, subsystem-level requirements, sub-requirement-level requirements, and unit-level requirements. The launch vehicle structure can be viewed as a complex network, and based on the stakeholder-requirement change-trajectory change within this complex network, a corresponding requirement change management process is established.
[0033] The complex network of launch vehicles, such as Figure 6 As shown, the rocket's complex network is constructed by proceeding from stakeholder requirements to mission requirements, from mission requirements to system requirements, and from system requirements to subsystem requirements. The subsystem requirements include overall rocket structure requirements, control (GNC) subsystem requirements, propulsion subsystem requirements, electrical subsystem requirements, and separation subsystem requirements. Then, from subsystem requirements to subsystem design, a strongly coupled model is built. At the subsystem design layer, the design process is a tightly coupled model.
[0034] S2: Demand Traceability Relationship Modeling
[0035] This paper outlines a formalized requirements traceability framework that establishes connections between requirements and other elements (such as other levels of requirements, design models, product models, and simulation test data models) throughout the entire lifecycle of launch vehicle development. This framework ensures controllable traceability of requirements from launch vehicle-level requirements to system-level requirements, from system-level requirements to subsystem requirements, and across test cases. The launch vehicle project utilizes traceability reports generated by a mature requirements management platform to confirm the absence of data traceability vulnerabilities in the database; a traceability coverage matrix is also used. Figure 4 As shown, the correctness and completeness of traceability are confirmed.
[0036] By establishing a full-cycle, end-to-end demand traceability framework, such as Figure 3 As shown, bottom-up demand traceability ensures that the entire demand chain meets stakeholder expectations. Top-down demand traceability ensures the completeness of launch vehicle design, and the formally expressed demand traceability mechanism provides a verification basis for ineffective and out-of-specification designs.
[0037] 1) Demand Origin:
[0038] By recording the changes and processed information throughout the entire life cycle of a launch vehicle, from its creation to its demise or transformation, a launch vehicle demand archive is constructed. The demand archive information includes the people, entities, and activities involved in the generation, decomposition, and transmission of demand, forming a database that can express the process of launch vehicle products from creation to demise or transformation in demand tracing.
[0039] 2) Demand Relationship:
[0040] Based on the RFLP framework, the architecture design allows designers to establish model elements, relationships, and views to form a complete launch vehicle model. Through model readers and reviewers, the model is "consumed" through activities such as model review, automatic generation of model documents, and automatic generation of mission specifications. Based on the relationships required for model generation, the view is displayed, providing research content for the tracking and decomposition process between various model elements.
[0041] Based on the full-link model of launch vehicles, the relationship display view for engineering applications includes:
[0042] a) Demand Influence Tree
[0043] Starting from a specified root node, it displays elements traced downwards by specific "relationships," such as derivation relationships and refinement relationships. Taking "requirement specifications" as an example, it displays the influence tree downwards.
[0044] This section shows the stakeholder requirements included under the "requirement specification," which are then refined into use cases, derived system requirements, and further derived allocation requirements, etc.
[0045] b) Demand Relationship Table
[0046] Another form of demand traceability impact tree is the demand association table, which most conveniently expresses the decomposition, allocation, and derivation relationships between upper-level and lower-level demands. The upper and lower levels are unrestricted and depend on the actual modeling needs.
[0047] c) Demand Relationship Matrix
[0048] The requirement association table can also be displayed as an association matrix, which is the most direct way to express the relationship. However, the problem is that a matrix can only represent two types of related objects and cannot represent multiple levels of association. Multiple levels of association need to be expressed using multiple association matrices.
[0049] Based on the entire lifecycle development process of launch vehicles, the system requirements analysis verifies mission requirements and subsystem requirements through a dual closed-loop process. For details, please refer to [link to detailed process]. Figure 4 As shown, in the closed-loop process of tracing from low-level to high-level, a stakeholder coverage matrix, a task requirement coverage matrix, a task functional performance requirement coverage matrix, a use case coverage matrix, and a system requirement coverage matrix are generated throughout the entire lifecycle. In the closed-loop process of tracing from high-level to low-level, a stakeholder coverage matrix, a system functional performance requirement coverage matrix, a scenario coverage matrix, and a subsystem requirement coverage matrix are generated throughout the entire lifecycle. Traceability is achieved between requirement design and virtual verification and confirmation based on the traceability matrix. Traceability is also achieved at the physical implementation layer based on the test case traceability matrix, thereby constructing a controllable and traceable framework for the entire lifecycle of the launch vehicle.
[0050] S3: Decision on Requesting Changes
[0051] Taking ballistic modification as an example, ballistic design plays a crucial role in the overall design of a launch vehicle. The determination of the overall rocket scheme, design parameters, payload capacity, and flight plan all require reference to the ballistic design. Ballistic design is integrated throughout the entire model development process, from the initial launch vehicle scheme demonstration to the completion and analysis of flight tests. The launch vehicle's launch mission originates from the launch of spacecraft. During national project approval, the spacecraft scheme and its launch scheme are usually reviewed together. Therefore, the launch vehicle provider typically begins early in the process of cooperating with the satellite's overall design to demonstrate the launch scheme. The spacecraft imposes requirements on the launch scheme, while existing launch conditions impose limitations on the spacecraft's mass, shape, and other design aspects.
[0052] Taking ballistic modification as an example, the launch vehicle structure can be viewed as a complex network. Based on the complex network of the launch vehicle, such as... Figure 7 The following stakeholders, requirement changes, and trajectory changes form the corresponding requirement change management process.
[0053] First, requirements agreed upon at the overall project task level are accepted. Then, at the launch vehicle system level, requirements are written, confirmed, released, and verified. After release, these requirements should be agreed upon with the launch vehicle system and dependencies established with stakeholders. If requirements change after release or verification, it may necessitate rewriting and confirmation of requirements, potentially severely impacting later requirements verification and product integration. Uncontrolled requirements changes often impose a heavy burden and unpredictable risks on the project. Therefore, establishing a launch vehicle requirements change control procedure is crucial for effectively managing changes during the development process.
[0054] Taking the change of requirements for ballistic launch vehicles as an example, this paper defines a change management process and forms a rapid response network for change of requirements, involving the roles and nodes of the process:
[0055] 1) Change submission: The stakeholder's role is to submit changes based on the ballistic trajectory change factors analysis, which identify requirements from the telemetry and control system, launch site, satellite orbit, overall launch vehicle parameters, and stage landing area. The corresponding stakeholder, acting as the change submitter, submits the changes in the launch vehicle change system.
[0056] 2) Acceptance and approval of changes to launch vehicle system requirements. There are three possible outcomes after approval:
[0057] □a) Accept and proceed to the implementation stage.
[0058] □b) Return to submitter. The submitter may resubmit as needed.
[0059] □c) Reject: If the submitter does not accept the submission after a second submission, the rejection path will be followed.
[0060] 3) After approval, the launch vehicle system will handle the change of requirements.
[0061] 4) Implementing ballistic launch vehicle requirements changes, with the role of change implementer. The implementation process includes ballistic requirements decomposition, functional and logical analysis, physical implementation analysis, change implementation, and definition of change review views.
[0062] 5) Launch vehicle requirements change review; the role is launch vehicle requirements change reviewer. There are two possible outcomes after the review:
[0063] □a) The review was passed, and the process proceeded to the baseline stage of launch vehicle requirements and modeling.
[0064] □b) Return the case to the person who accepted it, and return it for re-acceptance.
[0065] 6) Baseline requirements and models, with the role of launch vehicle model manager. Baseline all requirement items and modified models for version control. In practice, since requirement change requests are processed item by item, it is not advisable to create a baseline version for each requirement on the modeling platform. Instead, requirement reviews should be organized in batches. For the requirements that have passed the review, create version baselines sequentially and tag each version with the launch vehicle requirement.
[0066] S4: Analysis of the spillover effects of demand changes
[0067] a) Horizontal spillover effect analysis based on demand dependency graph
[0068] Given the established launch vehicle model, this paper analyzes the cross-sweep effect of demand changes based on demand dependence to determine the work-in-process inventory affected by launch vehicle demand changes, i.e., the "breadth of impact." The existence of launch vehicle demand dependence means that a change in a certain demand will trigger a chain reaction of changes in launch vehicle demand. The analysis steps are as follows:
[0069] a.1) Given the launch vehicle demand set, where n represents the total number of launch vehicle demand items, establish the demand set directly affected by demand changes, where m represents the number of affected demand items;
[0070] a.2) Select a launch vehicle requirement that has not yet been analyzed from the set of requirements directly affected by the demand change, where i is traversed starting from 0, and mark the requirement in the launch vehicle demand dependency graph.
[0071] a.3) Starting from the point of origin, perform a depth-first traversal of the launch vehicle demand dependency graph along the direction of refining the dependency relationship. Mark all the launch vehicle demands that are traversed and classify all the marked launch vehicle demands into the demand set.
[0072] a.4) Mark the demand that depends on the elements of the launch vehicle demand set, and classify the marked launch vehicle demand into the demand set. Then, the demand set indirectly affected by the launch vehicle demand is the demand set of the launch vehicle demand change.
[0073] b) Vertical spillover effect analysis based on demand traceability
[0074] By performing a depth-first search to trace the relationship between demand work-in-process and lower-level abstraction artifacts of the launch vehicle, the launch vehicle work-in-process affected by demand changes is determined, i.e., the "depth of impact". After identifying the demand work-in-process affected by launch vehicle demand changes, based on the launch vehicle demand tracing matrix, matrix operations based on the demand tracing matrix are performed along the entire life cycle of the launch vehicle to stakeholders, mission requirements to functional requirements, use cases to functions, system requirements to functional requirements, scenarios to functions, mission requirements to virtual verification, test cases to verification, requirements to design artifacts, and single-machine artifacts. For example, lateral spillover effect analysis determines the set of use cases updated by trajectory changes. Based on the use case-function use case coverage matrix, the impact of demand changes on system functions is analyzed.
[0075] S5: Quantitative Analysis of the Impact Domain of Demand Changes
[0076] Based on the complex network of launch vehicle functions, stakeholders, mission requirements, system requirements, and subsystem designs are represented as product components, and the relationships between these components are considered as edges in the network. Ballistic requirements, i.e., stakeholder change requests, are mapped to changes in various product characteristics. By analyzing the relationships between launch vehicle subsystems, a complex network model of the launch vehicle is established. By searching the propagation paths, the affected product components can be identified. Based on this, a modified complex network can be generated. The mission requirement layer uses MOE as the network parameter value, the system requirement layer uses MOP as the network parameter value, and the subsystem requirement layer uses TPM as the network parameter value. Based on the launch vehicle functional network model, quantitative analysis values for virtual simulation are derived through mapping these network parameter values. Specifically, as follows... Figure 5 As shown.
Claims
1. A method for analyzing the impact domain of launch vehicle demand changes based on complex networks, characterized in that, Includes the following steps: S1: Construct a complex network for launch vehicles based on the information architecture of the launch vehicle demand model; S2: Demand traceability relationship modeling, each level of demand includes vertical and horizontal relationships, and a full-level traceability model of the launch vehicle is constructed from the two dimensions of the vertical and horizontal relationships; S3: Decision on Requesting Changes in Requirements Based on the characteristics of launch vehicles and their design, a change decision-making method based on demand change impact assessment is proposed. This method analyzes the impact of the change on the entire design process and makes accurate decisions based on the magnitude of the impact. S4: Surge effect analysis of demand changes, including horizontal surge effect analysis based on demand dependency diagrams and vertical surge effect analysis based on demand traceability; S5: Quantitative Analysis of the Impact Domain of Demand Changes Based on the complex network model of the launch vehicle, MOE, MOP and TPM are used as network parameter values to map and obtain the quantitative analysis values of the virtual simulation, thereby obtaining the design attributes and technical indicators of the launch vehicle's influence domain after the demand change. In step S4, the cross-sweep effect analysis based on the demand dependency graph includes the following steps: The first step is to determine the launch vehicle requirement set R. all ={r1,r2,...,r n }, where n represents the total number of launch vehicle requirement items, and a requirement set R is established that is directly affected by changes in demand. direct_impacted ={r1,r2,...,r m }, where m represents the number of affected requirement items; The second step is to examine the demand set R directly affected by the change in demand. direct_impacted ={r1,r2,...,r m Select a launch vehicle requirement r that has not yet been analyzed from the list. i , where i is traversed starting from 0, and the requirement is marked in the launch vehicle requirement dependency graph; The third step, with r i Starting from the beginning, perform a depth-first traversal of the launch vehicle requirement dependency graph along the direction of refining dependencies. Mark all launch vehicle requirements encountered and classify all marked launch vehicle requirements into requirement set R. dfs middle; The fourth step is to analyze the demand set R, which depends on the launch vehicle demand. dfs The requirements of the elements in the code are marked, and the marked launch vehicle requirements are categorized into the requirement set R. bfs In the middle, the demand set R is indirectly affected by the demand for launch vehicles. indirect_impacted =R dfs ∪R bfs The demand set R for changes in launch vehicle requirements impacted =R indirect_impacted ∪R direct_impacted ; In step S4, the longitudinal spillover effect analysis based on demand traceability includes the following steps: The first step is to perform a depth-first search by tracing the demand work-in-process to the lower-level abstraction of the launch vehicle work-in-process to determine the launch vehicle work-in-process affected by the demand change, i.e., the depth of impact. The second step is to identify the work-in-progress requirements affected by changes in launch vehicle requirements. Based on the launch vehicle requirements traceability matrix, matrix operations based on the requirements traceability matrix are performed along the entire lifecycle of the launch vehicle, from stakeholders, mission requirements to functional requirements, use cases to functions, system requirements to functional requirements, scenarios to functions, mission requirements to virtual verification, test cases to verification, requirements to design artifacts, and single-machine artifacts.
2. The method for analyzing the impact domain of launch vehicle demand changes according to claim 1, characterized in that, In step S2, the launch vehicle requirements are divided into 5 levels: Stakeholder requirements, system-level requirements, subsystem-level requirements, sub-requirement-level requirements, and stand-alone-level requirements.
3. The method for analyzing the impact domain of launch vehicle demand changes according to claim 1, characterized in that, In step S2, the vertical relationship is the tracing of upper-level and lower-level requirements, and the horizontal relationship is the tracing of the current-level requirements and the design model, product model, and simulation test data model of the current level.
4. The method for analyzing the impact domain of launch vehicle demand changes according to claim 1, characterized in that, In step S3, the changes in requirements include changes in the trajectory caused by changes in the requirements of the telemetry and control party, launch site requirements, satellite orbit changes, changes in the overall parameters of the launch vehicle, and requirements for the stage landing area, thereby causing changes in the launch vehicle requirements.