A dodaf-based method and system for designing a lunar communication and navigation system

Abstract

The application discloses a kind of based on DODAF's earth-moon communication navigation system design method and system, belong to earth-moon communication navigation technical field.The application will the systematization methodology of DODAF framework as the core guidance of system design, break the disadvantage of traditional module design, build the closed loop design system of "requirement-capability-business-resource", realize the multi-perspective integrated design of earth-moon communication navigation system capability perspective, business perspective, resource perspective, Ensure accurate mapping between each perspective design model, logic coherent, requirement fit, finally form the systematization, standardization, the earth-moon communication navigation system design model that can land, solve the problems, such as system disconnection, specification loss, poor scalability, design and landing disconnection in traditional design method, improve the design quality and engineering realizable of earth-moon communication navigation system, adapt to the design and implementation demand of five application scenarios.

Description

Technical Field

[0001] This invention belongs to the field of Earth-Moon communication and navigation technology, and particularly relates to a design method and system for an Earth-Moon communication and navigation system based on DODAF. Background Technology

[0002] The Earth-Moon communication and navigation system acts as the "nerve center" and "eyes" of the Earth-Moon exploration mission, responsible for core tasks such as spacecraft orbit control, data transmission, precise positioning and navigation, and mission coordination among various devices. The rationality and completeness of the overall design of this system directly affect whether the Earth-Moon exploration mission can be completed safely, reliably, and efficiently. This includes whether the spacecraft can accurately reach the Moon, whether the exploration data can be successfully transmitted back to Earth, and whether the safety of the astronauts can be guaranteed.

[0003] Currently, most designs for Earth-Moon communication and navigation systems on the market adopt the traditional "modular design, simple splicing" approach. This involves designing separate communication, navigation, and telemetry subsystems, developing each subsystem independently, and then simply connecting them for deployment. This design approach has many obvious problems:

[0004] First, there is no unified design framework to coordinate the overall situation. The connection interfaces between various subsystems are not standardized, and the cooperation is not smooth enough. It is easy to have duplicate or missing functions, and it cannot adapt to the needs of different exploration scenarios. For example, it is difficult to meet the high safety requirements of manned lunar landing and the economic requirements of commercial spaceflight. Traditional designs are difficult to achieve this balance.

[0005] Second, the design did not take into account the overall coordination, scalability and maintainability of the system. For example, if communication and navigation support for a new lunar research station is needed in the future, or if the system is expanded to planetary exploration scenarios, the entire system will need to be modified on a large scale, which will not only cost a lot of time and money, but may also affect the stability of the original system.

[0006] Third, the inability to clearly define the relationships between the system's required capabilities, the business processes it needs to complete, and the resources it needs to configure leads to a disconnect between system design and actual exploration mission requirements. For example, it cannot meet the special requirements of long-distance communication and navigation in complex environments during planetary exploration.

[0007] DODAF, as a mature framework for designing complex systems, has been widely used in defense, aerospace, and other fields. Its core advantage lies in its multi-perspective modeling approach, which clearly and systematically outlines the system's core capabilities, business processes, resource allocation, and other key elements, while also clarifying the relationships between different parts. This provides a unified standard and methodology for the design, analysis, and optimization of complex systems. However, to date, no one has applied the DODAF framework to the design of a lunar communication and navigation system, failing to leverage its advantages to address issues such as system chaos, poor coordination between parts, and poor scalability inherent in traditional designs.

[0008] Meanwhile, the current Earth-Moon communication and navigation system faces many practical challenges: for example, ground control stations are limited by Earth's rotation and observation windows, making continuous communication with spacecraft impossible and resulting in periods of no contact; the orbital measurement range for spacecraft is insufficient, and the positioning accuracy is not high enough, affecting mission execution; when multiple probes operate simultaneously, their coordination is weak, communication link switching is frequent, and signal interruptions are likely to occur. Traditional design methods cannot fundamentally solve these problems, thus urgently requiring a new system design methodology. Through standardized and systematic modeling, this methodology can comprehensively plan all parts of the Earth-Moon communication and navigation system, achieve synergistic optimization of each part, improve the overall system performance and adaptability, and meet the needs of different exploration scenarios. Summary of the Invention

[0009] In view of the shortcomings of the existing technology, the purpose of this invention is to provide a design method for a lunar communication and navigation system based on DODAF. The core of this method is to use the systematic methodology of the DODAF framework as the core guide for system design, breaking through the drawbacks of traditional modular design, and constructing a closed-loop design system of "requirements-capabilities-business-resources". This enables integrated design from multiple perspectives, including capability, business, and resource perspectives, ensuring accurate mapping, logical coherence, and requirement matching between the models of each perspective. Ultimately, this results in a systematic, standardized, and implementable design model for a lunar communication and navigation system. This solves problems such as system disconnect, lack of standards, poor scalability, and disconnect between design and implementation in traditional design methods, improving the design quality and engineering feasibility of the lunar communication and navigation system, and adapting to the design and implementation requirements of five major application scenarios.

[0010] To achieve the aforementioned objectives, this invention provides a design method for a DODAF-based Earth-Moon communication and navigation system. The entire process is guided by the core methodology of the DODAF architecture framework, adhering to the design principles of "demand-driven, capability-centric, business-connected, resource-supported, and multi-perspective closed-loop," and constructing a multi-perspective, hierarchical system design architecture.

[0011] The first aspect discloses a design method for a DODAF-based Earth-Moon communication and navigation system, the method comprising:

[0012] The design requirements of the preset application scenarios of the Earth-Moon communication and navigation system are obtained. Based on the systematic analysis method of the DODAF framework, the design requirements of the preset application scenarios of the Earth-Moon communication and navigation system are deconstructed to obtain a standardized requirement deconstruction document.

[0013] Based on the standardized requirements deconstruction document, hierarchical modeling from a capability perspective is performed to obtain a capability-perspective design model, wherein the capabilities correspond to the design requirements of the preset application scenarios.

[0014] Based on the capability perspective design model, process modeling from a business perspective is carried out to clarify the business processes, business activities, business actions and business logic relationships, and to establish a mapping relationship between the business perspective and the capability perspective, thus obtaining the business perspective design model.

[0015] Based on the capability perspective design model and business perspective design model, a resource perspective entity model is performed to determine the system resource information that supports the implementation of business processes, and a two-way mapping relationship is established between the resource perspective and the business perspective and capability perspective to obtain the resource perspective design model.

[0016] Cross-perspective correlation verification was performed on the capability-perspective design model, business-perspective design model, and resource-perspective design model to verify the mapping consistency, logical coherence, requirement compliance, and system integrity among the design models.

[0017] After successful verification, an integrated design model of the Earth-Moon communication and navigation system based on the DODAF framework will be output.

[0018] The second aspect discloses a design system for a DODAF-based Earth-Moon communication and navigation system, the system comprising:

[0019] The requirement deconstruction document deconstruction module is used to obtain the design requirements of the preset application scenarios of the Earth-Moon communication and navigation system. Based on the systematic analysis method of the DODAF framework, the design requirements of the preset application scenarios of the Earth-Moon communication and navigation system are deconstructed to obtain a standardized requirement deconstruction document.

[0020] The capability perspective design model determination module is used to perform hierarchical modeling from a capability perspective based on the standardized requirements deconstruction document to obtain a capability perspective design model, wherein the capabilities correspond to the design requirements of the preset application scenarios.

[0021] The business perspective design model determination module is used to perform process modeling from a business perspective based on the capability perspective design model, clarify the business process, business activities, business actions and business logic relationships, and establish a mapping relationship between the business perspective and the capability perspective to obtain the business perspective design model.

[0022] The resource perspective design model determination module is used to perform entity modeling of the resource perspective based on the capability perspective design model and the business perspective design model, determine the system resource information that supports the implementation of business processes, and establish a two-way mapping relationship between the resource perspective and the business perspective and capability perspective to obtain the resource perspective design model.

[0023] The cross-perspective correlation verification module is used to perform cross-perspective correlation verification on the capability perspective design model, business perspective design model, and resource perspective design model to verify the mapping consistency, logical coherence, requirement compliance, and system integrity among the design models of each perspective.

[0024] The output module is used to output an integrated design model of the Earth-Moon communication and navigation system based on the DODAF framework after successful verification.

[0025] As can be seen from the above technical solutions, the present invention has the following beneficial effects:

[0026] This invention integrates the systematic methodology of DODAF throughout the entire system design process, constructing a closed-loop design system of "requirements-capabilities-business-resources." This overcomes the drawbacks of traditional modular design, achieving integrated design from the perspectives of capabilities, business, and resources. It ensures seamless integration between design stages, resolving the problems of system disconnect and missing requirements in traditional design. Secondly, this invention employs the hierarchical modeling method of the DODAF framework, decomposing capabilities, business, and resources at multiple levels to form a standardized, hierarchical design model. The design deliverables are standardized and unified, supporting cross-unit and cross-professional collaborative development, solving the problems of inconsistent deliverables and high collaboration difficulty in traditional design. Furthermore, based on DODAF's multi-perspective mapping and association rules, this invention establishes precise mapping relationships between different perspectives. When new application scenarios are added or design requirements are adjusted, only local iterations of the design model for the corresponding perspective are needed, without reconstructing the entire system. This significantly improves the scalability of the system design and reduces development costs and time. Furthermore, this invention adheres to the principle of "combining design with implementation." Through resource-based physical modeling, it clarifies system components, resource configurations, interface specifications, and deployment schemes. The design results can be directly transformed into engineering implementation guidelines, solving the problem of design-implementation disconnect in traditional designs and improving engineering feasibility. The design method of this invention is adaptable to five major application scenarios, including lunar research station exploration. Through multi-scenario adaptability modeling from a capability perspective, scenario-based process design from a business perspective, and modular deployment and adaptation design from a resource perspective, it ensures that the system can flexibly switch and efficiently adapt between the five scenarios, meeting the diverse needs of Earth-Moon and deep space exploration. The integrated design model of the Earth-Moon communication and navigation system based on DODAF formed by this invention provides a unified basis for the system's entire lifecycle management. From engineering development and deployment to operation and maintenance upgrades, related work can be carried out based on the model, ensuring design consistency and management standardization throughout the system's lifecycle. Attached Figure Description

[0027] Figure 1 The present invention provides an overall flowchart of a design method for a DODAF-based Earth-Moon communication and navigation system.

[0028] Figure 2 This invention provides a schematic diagram of the system architecture for a DODAF-based Earth-Moon communication and navigation system. Detailed Implementation

[0029] To make the objectives, features, and advantages of the present invention more apparent and understandable, specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Several embodiments of the present invention are shown in the drawings. However, the present invention can be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided so that the disclosure of the present invention will be thorough and complete.

[0030] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0031] It should be noted that when an element is referred to as being "fixed to" another element, it can be directly on the other element or there may be an intervening element. When an element is considered to be "connected to" another element, it can be directly connected to the other element or there may be an intervening element. The terms "vertical," "horizontal," "left," "right," "up," "down," and similar expressions used herein are for illustrative purposes only and are not intended to indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore should not be construed as limiting the invention.

[0032] In this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," "linking," "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal communication between two components. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances. The term "and / or" as used herein includes any and all combinations of one or more of the related listed items.

[0033] To achieve the aforementioned objectives, this invention provides a design method for a DODAF-based Earth-Moon communication and navigation system. The entire process is guided by the core methodology of the DODAF architecture framework, adhering to the design principles of "demand-driven, capability-centric, business-connected, resource-supported, and multi-perspective closed-loop," and constructing a multi-perspective, hierarchical system design architecture, such as... Figure 1 As shown, the specific steps include:

[0034] S101. Obtain the design requirements of the preset application scenarios of the Earth-Moon communication and navigation system. Based on the systematic analysis method of the DODAF framework, deconstruct the design requirements of the preset application scenarios of the Earth-Moon communication and navigation system to obtain a standardized requirement deconstruction document.

[0035] Specifically, the design requirements for the Earth-Moon communication and navigation system are comprehensively analyzed, covering functional, performance, environmental adaptability, and engineering constraints for five pre-defined application scenarios: lunar research station exploration, manned lunar exploration, commercial spaceflight, planetary exploration, and international collaborative deep space exploration. The DODAF framework's requirement decomposition methodology is adopted, hierarchically decomposing the overall requirements into "task layer—capability layer—business layer—resource layer." The task layer corresponds to the core tasks of the five pre-defined application scenarios; the capability layer corresponds to the system capabilities supporting the tasks; the business layer corresponds to the business activities implementing the capabilities; and the resource layer corresponds to the system resources carrying the business. A hierarchical correlation matrix for the design requirement decomposition is established, clarifying the correspondence between each layer. This ensures that all design requirements are mapped to the DODAF design dimensions without omission or redundancy, forming a standardized requirement deconstruction document, which serves as the sole input for subsequent modeling and design from each perspective.

[0036] Specifically, the hierarchical association matrix is ​​constructed as follows: First, using tasks as rows and capabilities as columns, the capabilities required by each task are identified one by one, forming a task-capability mapping table; then, using capabilities as rows and business as columns, the business processes that implement each capability are identified, forming a capability-business mapping table; finally, using business as rows and resources as columns, the system resources that support each business process are identified, forming a business-resource mapping table. Through the cascading relationship of these three mapping tables, a complete traceability chain from requirements to resources is constructed, thereby obtaining the hierarchical association matrix.

[0037] S102. Based on the standardized requirements deconstruction document, hierarchical modeling from a capability perspective is performed to obtain a capability perspective design model, wherein the capabilities correspond to the design requirements of the preset application scenarios.

[0038] In one embodiment, the above steps specifically include:

[0039] The core capabilities of the Earth-Moon communication and navigation system are extracted, and each core capability is decomposed into sub-capabilities to obtain a capability hierarchy structure diagram, wherein the sub-capabilities are the specific implementation dimensions of the corresponding core capabilities;

[0040] Determine the capability indicators for each sub-capability and construct a capability indicator specification document, wherein the capability indicators correspond to the design requirements of the preset application scenario;

[0041] Analyze the dependencies between core capabilities and sub-capabilities, clarify the priority and mutual constraints of each capability, and obtain a capability relationship diagram;

[0042] A capability-scenario mapping matrix is ​​constructed based on each core capability, sub-capability, and corresponding preset application scenario.

[0043] Based on the obtained capability hierarchy structure diagram, capability association diagram, capability-scenario mapping matrix, and capability indicator description document, a standardized capability perspective design model is formed.

[0044] Specifically, the DODAF capability perspective (CV) modeling design is based on the deconstructed design requirements and follows the DODAF framework's capability system construction methodology. It employs a three-tiered modeling approach: core capabilities, sub-capabilities, and capability indicators. First, it extracts six core capabilities of the Earth-Moon communication and navigation system: Earth-Moon communication capability, Earth-Moon navigation capability, mission collaboration capability, fault tolerance capability, system operation and maintenance capability, and multi-scenario adaptation capability. Second, each core capability is decomposed into sub-capabilities, forming a two-tier sub-capability system. These sub-capabilities represent the specific implementation dimensions of the core capabilities and must cover the capability requirements of five major application scenarios. Then, quantifiable and verifiable three-tiered capability indicators are developed for each sub-capability, with indicators precisely corresponding to design requirements. Finally, a capability association model is established to analyze the dependencies, collaborations, and constraints between capabilities, constructing a capability-scenario mapping matrix to ensure the capability system fully covers and supports the five major scenarios, forming a standardized capability perspective design model.

[0045] When constructing the capability association graph, the method of constructing a capability dependency directed graph is adopted: each core capability and sub-capability is used as a graph node, the dependency type between nodes is analyzed (including "needed", "predecessor", "enabling" relationship, etc.), and the dependency direction is represented by directed lines.

[0046] When constructing the capability-scenario mapping matrix, core capabilities and sub-capabilities are used as matrix rows, and five major application scenarios are used as matrix columns. Identifiers are used in the cross cells to indicate the support relationship between the capability and each scenario.

[0047] Additionally, it should be noted that the decomposition of the six core capabilities into sub-capabilities and the formulation of capability indicators must take into account the environmental characteristics of the Earth-Moon space and the differentiated needs of the five application scenarios. Specific requirements are as follows:

[0048] The sub-capabilities of Earth-Moon communication need to cover dimensions such as long-distance data transmission, multi-band communication, link switching, and communication anti-interference. The capability indicators need to be adapted to the environmental characteristics of Earth-Moon space, such as signal attenuation and radiation interference.

[0049] The sub-capabilities of Earth-Moon navigation need to cover dimensions such as positioning, velocity measurement, time synchronization, orbit calculation, and autonomous navigation. The capability indicators need to meet the differentiated requirements such as the high-precision requirements of manned exploration and the economic requirements of commercial spaceflight.

[0050] The sub-capabilities of task collaboration need to cover dimensions such as multi-node scheduling, multi-task parallelism, dynamic resource allocation, and cross-scenario adaptation and collaboration. The capability indicators need to support the collaborative execution needs of five major scenarios.

[0051] The sub-capabilities of fault tolerance must cover dimensions such as fault detection, fault diagnosis, fault isolation, fault recovery, and redundancy backup, and the capability indicators must meet the high reliability requirements of aerospace systems.

[0052] The sub-capabilities of system operation and maintenance should cover dimensions such as status monitoring, parameter adjustment, remote maintenance, upgrade and iteration, and data management, and the capability indicators should support the operation and maintenance needs of the entire system lifecycle.

[0053] The sub-capabilities of multi-scenario adaptation need to cover dimensions such as scene recognition, parameter adaptive adjustment, and dynamic resource reconstruction. The capability indicators need to ensure that the system can flexibly switch and efficiently adapt between the five major scenarios.

[0054] S103. Based on the capability perspective design model, perform process modeling from a business perspective, clarify the business processes, business activities, business actions and business logic relationships, and establish a mapping relationship between the business perspective and the capability perspective to obtain the business perspective design model.

[0055] In one embodiment, the above steps specifically include:

[0056] Based on the core capabilities, the corresponding business domains are determined, and the business domains correspond one-to-one with the core capabilities, resulting in a business domain partitioning diagram.

[0057] Within each business domain, the core business processes are identified, where each core business process is the overall business logic that implements the corresponding core capabilities, resulting in a business process diagram.

[0058] Each business process is decomposed into several ordered business activities, and each business activity is further refined into specific business actions to obtain a business activity decomposition table. The business activity is the basic execution unit of the corresponding business process, and the business action is the smallest execution unit of the business activity.

[0059] Establish a mapping model between the business perspective and the capability perspective, determine the correspondence between business domain and core capability, business process and sub-capability, and business activity and capability indicator, and obtain the business-capability mapping matrix;

[0060] Analyze the logical relationships, data interaction relationships, and collaborative execution relationships between various business domains and business processes to form an end-to-end business process system and obtain a business data interaction diagram.

[0061] Based on the obtained business domain division diagram, business process diagram, business activity decomposition table, business-capability mapping matrix, and business data interaction diagram, a standardized business perspective design model is formed.

[0062] Specifically, the Business Perspective (OV) modeling design is driven by a capability perspective design model, follows the business process construction methodology of the DODAF framework, and adopts a four-level process modeling approach of "business domain - business process - business activity - business action" to conduct business perspective modeling. First, based on six core capabilities, six corresponding business domains are defined, with each business domain corresponding to a core capability. Second, within each business domain, core business processes are identified, clarifying the initiation conditions, execution logic, and termination criteria of the process. Then, the business processes are decomposed into ordered business activities, and the business activities are further refined into executable business actions, clarifying the execution subject, inputs, and outputs of each business unit. Finally, a precise mapping model between the business perspective and the capability perspective is established, clarifying the correspondence between business domains and core capabilities, business processes and sub-capabilities, and business activities and capability indicators. A business association model is constructed, analyzing the logical and data interaction relationships between various business units to form an end-to-end business process system and output a standardized business perspective design model.

[0063] In addition, when constructing the business association model, the method of constructing business activity logic flow and data interaction relationship diagram is adopted: first, identify all key business activity nodes in an end-to-end business process, then define the sequence, branching conditions and loop logic between activities, and draw the logic flow; at the same time, clarify the information entity types, interaction interfaces and communication protocols exchanged between activities, and form a business data interaction relationship diagram.

[0064] When constructing the business-capability mapping matrix, business domains and business processes are used as matrix rows, core capabilities and sub-capabilities are used as matrix columns, and identifiers are used in the cross cells to indicate the support relationship between the business and the capability.

[0065] S104. Based on the capability perspective design model and business perspective design model, perform entity modeling from the resource perspective, determine the system resource information that supports the implementation of business processes, and establish a two-way mapping relationship between the resource perspective and the business perspective and capability perspective to obtain the resource perspective design model.

[0066] In one embodiment, the above steps specifically include:

[0067] Based on the business process system, the overall system architecture of the Earth-Moon communication and navigation system is divided, and multiple core systems are identified to obtain the system architecture diagram.

[0068] Each core system is decomposed into several subsystems to obtain a subsystem decomposition diagram, wherein the subsystems are functional subdivisions of the core system and correspond to the execution stages of the business process;

[0069] Within each subsystem, the core hardware components and software components are identified, and the functional positioning and technical characteristics of each component are clarified to obtain a component configuration table. The components are the basic carrier units of system resources.

[0070] Configure corresponding hardware and software resources, network resources, and deployment resources for each component, specifying the specifications, quantity, and configuration method of the resources to obtain system resource information.

[0071] Establish a mapping model between resource perspective and business perspective, determine the correspondence between system-business domain, subsystem-business process, and component-business activity, and establish an indirect mapping model between resource perspective and capability perspective to obtain the resource-business mapping matrix.

[0072] Determine the interface types, communication protocols, and data formats between each system, subsystem, and component, as well as the deployment locations, deployment methods, and networking methods of each system's resources on Earth, Earth-Moon space, and the lunar surface, to obtain the interface definition document;

[0073] A standardized resource-perspective design model is derived based on the system architecture diagram, subsystem decomposition diagram, component configuration table, system resource information, interface definition document, and resource-business mapping matrix.

[0074] Specifically, the resource perspective (SV) modeling design is based on both capability and business perspectives, following the system resource construction methodology of the DODAF framework. It employs a four-level entity modeling approach: system layer - subsystem layer - component layer - resource layer. First, based on the business process system, six core systems are defined: ground telemetry and control system, lunar relay system, lunar surface communication and navigation system, space navigation constellation system, data processing system, and terminal adaptation system. Second, the core systems are decomposed into functional subsystems, and then further broken down into core hardware and software components, configuring corresponding hardware, software, network, and deployment resources for each component. Next, a precise mapping model between the resource perspective and the business perspective is established, clarifying the correspondence between system-business domain, subsystem-business process, and component-business activity. Through the business perspective as an intermediary, a closed-loop mapping of resources, business, and capabilities is formed. Finally, system interface design and deployment scheme design are completed, clarifying the interface specifications of each system unit and its deployment method in lunar space, forming a standardized system resource perspective design model.

[0075] Furthermore, when establishing the resource-business mapping matrix, systems and subsystems are used as matrix rows, and business domains and business processes are used as matrix columns. The support relationship between system resources and business activities is identified in the cross cells. Through this matrix, the two-way traceability questions of "which system resources implement a certain business activity" and "which business activities are supported by a certain system resource" can be clearly answered.

[0076] It should be further noted that the deployment scheme design for the six core systems must follow the resource optimization and allocation methodology of the DODAF framework, taking into account the geographical characteristics of the Earth-Moon space and the deployment requirements of the five application scenarios. Specific requirements are as follows:

[0077] The ground-based telemetry and control system adopts a global multi-site deployment approach to compensate for the telemetry and control blind spots caused by the Earth's rotation and support all-weather coverage of Earth-Moon communication and navigation;

[0078] The Earth-Moon relay system is deployed at the Earth-Moon Lagrange point or the Earth-Moon transfer orbit to achieve communication relay between the ground and the lunar surface and Earth-Moon space, thereby improving the continuity of communication and navigation.

[0079] The lunar surface communication and navigation system is deployed in key areas of the lunar surface, including the lunar polar regions, the vicinity of research stations, and the manned landing area, to support local communication and navigation needs on the lunar surface.

[0080] The space navigation constellation system is deployed in Earth-Moon space orbit, forming a multi-satellite network navigation system to provide full-space navigation services for Earth-Moon spacecraft and lunar surface equipment;

[0081] The data processing system adopts a ground-cloud architecture deployment method, combined with edge computing nodes, to realize real-time processing, storage and analysis of Earth-Moon communication and navigation data;

[0082] The terminal adaptation system adopts a modular design and is customized according to the terminal types of five major application scenarios (manned spacecraft, detectors, scientific research station equipment, commercial spacecraft, etc.) to ensure seamless connection between the terminal and the core system.

[0083] S105. Perform cross-perspective correlation verification on the capability perspective design model, business perspective design model, and resource perspective design model to verify the mapping consistency, logical coherence, requirement compliance, and system integrity among the design models.

[0084] Specifically, the multi-perspective design model correlation verification is based on the systematic verification methodology of the DODAF framework. It takes the closed-loop mapping of "requirements-capabilities-business-resources" as the core and conducts cross-perspective correlation verification of the three perspective design models from four dimensions: mapping consistency, logical coherence, requirement compliance, and system integrity.

[0085] The mapping consistency verification employs a bidirectional traceability method: forward traceability starts from the requirement and checks layer by layer along the requirement-capability-business-resource chain to verify whether each requirement can be traced back to the final physical system component. If a requirement cannot be traced back to the end of this chain, it is determined that there is a "requirement omission" or "implementation deficiency"; backward traceability starts from the system component and traces backward along the resource-business-capability-requirement chain to verify whether each component can be traced back to a clear source of requirement. If a component cannot be traced back to any requirement, it is determined that there is "design redundancy". Through bidirectional traceability, it is ensured that the mapping relationship is without misalignment or contradiction.

[0086] Logical coherence verification employs a scenario-based approach: Selecting typical task scenarios, from the start to the end of the task, we sequentially trace the capability implementation logic from a capability perspective, the business process execution logic from a business perspective, and the system resource state switching logic from a resource perspective, to verify whether the phase division and logical order of the state transitions of the three are consistent and whether they form a closed loop.

[0087] The requirement compliance verification adopts a step-by-step verification method based on quantitative indicators: using quantitative requirement indicators as verification conditions, firstly, it checks whether the indicator definition of the corresponding sub-capability in the capability perspective has been quantified into the requirement; secondly, it checks whether the business process for implementing the capability in the business perspective includes the algorithm steps and operational steps required to implement the indicator; finally, it checks whether the performance parameters of the system components executing the business in the resource perspective theoretically support the implementation of the indicator.

[0088] The system integrity verification adopts the checklist verification method: based on the design requirements deconstruction document in step S101, check item by item whether the elements of the design model from each perspective are complete, that is, whether the core capabilities cover all the capabilities mapped to the requirements, whether the business processes cover all the business corresponding to the capabilities, and whether the system resources cover all the resource requirements of the business activities.

[0089] When a cross-perspective mapping problem is found during verification, the cross-validation method is used to locate the problem: First, check the business perspective design model to confirm the clarity of the business process definition, and then check the mapping matrix of the resource perspective design model to confirm whether the process is associated with system components. If the business process is clear but the mapping matrix is ​​missing any association with any component, the root cause of the problem can be determined to be in the resource perspective design model.

[0090] The final result is a detailed verification report, which clearly identifies the problems, their locations, and their types, providing a basis for model optimization.

[0091] S106. After verification, output the integrated design model of the Earth-Moon communication and navigation system based on the DODAF framework.

[0092] In one embodiment, the invention further includes:

[0093] If the verification fails, the problem is accurately located based on the multi-perspective model correlation verification report, clarifying the perspective to which the problem belongs, the design dimension corresponding to the problem, and the related perspectives affected by the problem.

[0094] To address the positioning issue, the design model for the corresponding perspective was locally adjusted and optimized;

[0095] The optimized viewpoint model is independently verified, and then it is re-linked and verified with other viewpoint models until all problems are resolved.

[0096] Specifically, the optimization and implementation of the system design model follows the model iterative optimization methodology of the DODAF framework, employing an iterative process of "problem identification - model adjustment - re-verification - implementation output" to optimize the design model. Based on the verification report, problems are accurately identified, and the corresponding perspective design model is adjusted locally or optimized overall. After adjustment, independent verification is performed first, followed by cross-perspective correlation verification until all problems are resolved.

[0097] The model optimization method employs precise localization and local adjustment, including:

[0098] To address the issues identified during the verification process, cross-validation is first used to determine the perspective to which the issue pertains. Then, relevant model elements or mapping relationships are added, deleted, or modified in the corresponding perspective design model. During re-verification, the optimized single-perspective model is first independently verified to check its internal logical consistency. Then, it is re-verified across perspectives with other perspective design models.

[0099] The final multi-perspective integrated design model is standardized and packaged to form a complete design deliverable package containing model drawings, documents, matrices, and lists.

[0100] This invention consistently adheres to the core methodology of the DODAF framework, upholding the design principles of "demand-driven, capability-centric, business-connected, resource-supported, and multi-perspective closed-loop," ensuring that the design of the Earth-Moon communication and navigation system possesses systematic, standardized, hierarchical, and scalable characteristics. Specifically:

[0101] Demand-driven: All design stages are based on the initial, comprehensive design requirements to ensure a high degree of alignment between the design deliverables and the requirements.

[0102] Capability-centric approach: Modeling from a capability perspective is the core, with both business and resource perspectives revolving around capability implementation to ensure the effective realization of the system's core capabilities.

[0103] Business integration: Modeling from a business perspective serves as an intermediary bridge, connecting capability and resource perspectives to form an end-to-end mapping of capabilities, business, and resources;

[0104] Resource support: Modeling from a resource perspective serves as the final implementation vehicle, ensuring that all capability requirements and business processes have corresponding system resource support;

[0105] Multi-perspective closed loop: Through multi-perspective model correlation and verification, ensure that the design system forms a closed loop from the perspectives of capability, business, and resources, without any breaks or disconnects.

[0106] The technical solution and effects of the present invention will be described in detail below through specific embodiments. This embodiment takes the design of a lunar communication and navigation system supporting two core scenarios: manned lunar exploration and lunar research station exploration, as an example. The system architecture design is carried out using the DODAF-based lunar communication and navigation system design method of the present invention. The core requirements of the two scenarios are: manned exploration needs to meet the requirements of high-precision navigation, high-reliability communication, and emergency fault tolerance; research station exploration needs to meet the requirements of high-volume data transmission, long-term stable operation and maintenance, and multi-device collaboration. At the same time, the system needs to have the ability to expand to commercial aerospace and planetary exploration scenarios.

[0107] Step 1: Design requirements and scenario deconstruction.

[0108] First, we outline the comprehensive requirements for the two major application scenarios, including performance requirements such as high-precision navigation (positioning accuracy ≤ X1m, where X1 can be set according to actual needs), mobile communication (link reliability ≥ 99.9%), and emergency fault recovery (recovery time ≤ 10s) for manned exploration; functional requirements such as high-volume data transmission (rate ≥ X2Gbps, where X2 can be set according to actual needs) and long-term operation and maintenance (fault-free operation ≥ 1 year) for scientific research station exploration; and environmental adaptability requirements such as vacuum, radiation, and large temperature differences in the Earth-Moon space, as well as constraints on engineering costs and development cycles.

[0109] The DODAF requirement decomposition methodology is adopted, decomposing requirements into a "task layer - capability layer - business layer - resource layer": the task layer includes manned lunar exploration and lunar research station exploration; the capability layer includes core capabilities supporting the mission such as Earth-Moon communication, Earth-Moon navigation, and mission coordination; the business layer includes business processes such as communication link establishment and navigation information generation to realize the capabilities; and the resource layer includes system resources such as ground tracking and control stations and relay satellites to carry out the business. By establishing a three-layer mapping table of task-capability, capability-business, and business-resource and cascading it, the correspondence between each layer is clarified, forming a standardized requirement decomposition document, ensuring that requirements are mapped to each design dimension without omission.

[0110] Step 2: Capability Perspective (CV) Modeling Design.

[0111] Following the DODAF capability system construction methodology, a three-level model of "core capabilities - sub-capabilities - capability indicators" is adopted:

[0112] Six core capabilities were extracted: Earth-Moon communication capability, Earth-Moon navigation capability, task collaboration capability, fault tolerance capability, system operation and maintenance capability, and multi-scenario adaptation capability.

[0113] Core capabilities are broken down as follows: Earth-Moon communication capability is broken down into sub-capabilities such as long-distance data transmission, multi-band communication, link switching, and communication anti-interference; Earth-Moon navigation capability is broken down into sub-capabilities such as high-precision positioning, velocity measurement and time synchronization, orbit calculation, and autonomous navigation.

[0114] Develop capability indicators: For example, in the manned exploration scenario, the high-precision positioning sub-capability indicator is "positioning accuracy ≤ X1m during lunar landing phase", and in the scientific research station exploration scenario, the long-distance data transmission sub-capability indicator is "scientific data transmission rate ≥ X2Gbps", and establish the correlation between these indicators and the requirements.

[0115] Establish a capability association diagram: clarify that Earth-Moon communication capability is the foundation of Earth-Moon navigation capability and mission collaboration capability, and fault tolerance capability provides a guarantee for all core capabilities;

[0116] Construct a capability-scenario mapping matrix: clarify the supporting relationship between each core capability and sub-capability for manned exploration and scientific research station exploration, while reserving capability expansion interfaces for commercial aerospace and planetary exploration scenarios;

[0117] The final result is a capability-perspective design model that includes a capability hierarchy structure diagram, a capability association diagram, and a capability-scenario mapping matrix.

[0118] The capability association graph is constructed using a capability dependency directed graph method. The specific process involves treating the six core capabilities and their sub-capabilities as graph nodes, analyzing the dependency types between nodes, including "needed," "preceding," and "enabling" relationships, and representing the dependency direction with directed lines bearing arrows. Specifically, the Earth-Moon communication capability provides the communication link foundation for the Earth-Moon navigation capability and task collaboration capability; therefore, directed lines are constructed between "Earth-Moon communication capability → Earth-Moon navigation capability" and "Earth-Moon communication capability → Task collaboration capability." Fault tolerance capability provides fault protection for all other capabilities; therefore, multiple directed lines are constructed from "fault tolerance capability" pointing to "Earth-Moon communication capability," "Earth-Moon navigation capability," "task collaboration capability," "system operation and maintenance capability," and "multi-scenario adaptation capability." System operation and maintenance capability provides maintenance assurance for the long-term operation of all other capabilities; therefore, directed lines are constructed from "system operation and maintenance capability" pointing to each core capability. This directed graph clarifies the implementation priority and inter-constraint relationships of each capability.

[0119] The capability-scenario mapping matrix is ​​constructed using a symbolic notation method. Specifically, a two-dimensional coordinate system is established using all decomposed sub-capabilities as the vertical row vectors and the five major application scenarios as the horizontal column vectors. For each cell where rows and columns intersect, the sub-capability is marked according to its priority in the corresponding scenario. This marking allows for the rapid identification of the key capability sets supporting each scenario and the core scenarios to which each capability is adapted.

[0120] Step 3: Business Perspective (OV) Modeling and Design.

[0121] This step uses a capability-based design model as the driving force, with the capability-based design model established in step 2 serving as the input and basis. The division of business domains is determined by core capabilities, the goals and boundaries of business processes are defined by capability indicators, and each business activity can be traced back to its corresponding capability requirements. A four-level modeling approach is adopted: "Business Domain - Business Process - Business Activity - Business Action".

[0122] The system is divided into six major business domains: mobile communication, lunar navigation, task collaboration, fault tolerance, system operation and maintenance, and multi-scenario adaptation, each corresponding to a core capability.

[0123] Streamline core business processes: For example, the mobile communication business domain has been streamlined into a process of "communication link establishment - data transmission - link release", and the lunar navigation business domain has been streamlined into a process of "navigation data collection - information calculation - navigation information distribution".

[0124] Decompose business activities and actions: For example, the "mobile communication activity" process is decomposed into business actions such as "initiating a call request - accepting a call request - resource allocation - session management - paging - receiving a call - calling - hanging up the phone - determining the end of the session - releasing resources";

[0125] Establish a service-capability mapping model: clarify the sub-capabilities of "mobile communication" corresponding to "mobile communication activities", and define how "mobile communication activities" are implemented by the corresponding mobile communication architecture;

[0126] Construct a business relationship model: such as the interface and data transmission relationship between various mobile communication architectures in the "mobile communication" business process;

[0127] The final design model is a business-perspective model that includes a business domain partitioning diagram, a business process diagram, and a business-capability mapping matrix.

[0128] The construction process of the business-capability mapping matrix is ​​as follows: The six major business domains and their subordinate business processes are used as the matrix rows, and the six core capabilities and their sub-capabilities are used as the matrix columns. The cross cells indicate whether there is a supporting relationship between the business and the capability. If a supporting relationship exists between a business process and a sub-capability, it is marked in the corresponding cell; otherwise, it is left blank. For example, the "communication link establishment" business process in the mobile communication business domain has a supporting relationship with the "multi-band communication" sub-capability in the Earth-Moon communication capability, and this is marked in the matrix; similarly, the "navigation information distribution" business process in the Earth-Moon navigation business domain has a supporting relationship with the "long-distance data transmission" sub-capability in the Earth-Moon communication capability, and this is also marked in the matrix. This matrix ensures that every capability requirement has a corresponding business process to implement it.

[0129] The business association model is constructed using a method that combines business activity logic flow with data interaction relationship diagrams. Taking the "mobile communication" business process as an example, it first identifies all key business activity nodes in the end-to-end business process, including "initiating a call request," "accepting a call request," "resource allocation," "session management," "paging," "receiving a call," "calling," "hanging up the phone," "determining session end," and "releasing resources." Then, it defines the sequence, branching conditions, and loop logic between each activity, and draws the logic flow. Simultaneously, it clarifies the types of information entities exchanged between activities; for example, "call request message" is transmitted between "initiating a call request" and "accepting a call request," and "resource allocation confirmation message" is transmitted between "resource allocation" and "session management." Finally, it defines the interaction interfaces between activities; for example, the interface between mobile communication architecture A and mobile communication architecture B uses a standard communication protocol, and the transmitted information entities include fields such as user identifier, call type, and time slot allocation parameters. Through the above methods, an end-to-end business process system is formed.

[0130] Step 4: Resource Perspective (SV) Modeling Design.

[0131] Based on a capability and business perspective, the design model adopts a standardized interface design. Taking the interface design between the "Ground Measurement and Control System" and the "Earth-Moon Relay System" as an example, the specific process is as follows: First, it is determined that the communication link between the two systems adopts a space communication protocol, and the physical layer adopts S-band or X-band radio frequency transmission. Second, the data format of the interface is defined, including the data frame structure (frame header, data field, check field), information entity type (including measurement and control command frame, telemetry data frame, navigation ephemeris frame, etc.), and the byte length and encoding method of each field. Third, the communication timing of the interface is defined, including the link establishment handshake timing, data transmission timing, and link release timing, clarifying the message interaction order and timeout retransmission mechanism for each timing stage. Finally, the above interface parameters are entered into a standardized interface model to establish the port connection relationship from the "radio frequency port of the antenna component of the Ground Measurement and Control System" to the "relay satellite receiving front end of the Earth-Moon Relay System".

[0132] Four-level modeling: "System Layer - Subsystem Layer - Component Layer - Resource Layer"

[0133] The system is divided into six core systems: ground tracking and control system, Earth-Moon relay system, lunar surface communication and navigation system, space navigation constellation system, data processing system, and terminal adaptation system.

[0134] Hierarchical decomposition and resource allocation: For example, the ground telemetry and control system is decomposed into the telemetry and control station subsystem and the data receiving subsystem. The telemetry and control station subsystem is further broken down into antenna components, radio frequency components, and signal processing components. High-performance processors and large-capacity storage resources are configured for the signal processing components.

[0135] Establish a resource-service mapping model: clarify that the "antenna resource release function" supports the "relevant resource release" service activity, and the "signal scanning function" and "signal reception and forwarding function" support the "receive call request" service activity;

[0136] Interface and Deployment Design: Design standardized interfaces between various systems, clarifying the ports and information flows between resources. Taking the interface design between the "Ground Measurement and Control System" and the "Earth-Moon Relay System" as an example, the specific process is as follows: First, clarify that the communication link between the two systems adopts a space communication protocol, and the physical layer uses S-band or X-band radio frequency transmission. Second, define the data format of the interface, including the data frame structure (frame header, data field, check field), information entity type (including measurement and control command frames, telemetry data frames, navigation ephemeris frames, etc.), and the byte length and encoding method of each field. Third, define the communication timing of the interface, including the link establishment handshake timing, data transmission timing, and link release timing, clarifying the message interaction order and timeout retransmission mechanism at each timing stage. Finally, input the above interface parameters into a standardized interface model, and establish the port connection relationship from the "Antenna Component Radio Frequency Port of the Ground Measurement and Control System" to the "Relay Satellite Receiving Front End of the Earth-Moon Relay System".

[0137] Forming a closed-loop mapping of resources, business, and capabilities: Through the mediation of the business perspective, a closed-loop mapping is achieved for "navigation constellation components - navigation data acquisition activities - high-precision positioning sub-capabilities - manned exploration positioning requirements"; ultimately forming a resource-perspective design model that includes system architecture diagrams, subsystem decomposition diagrams, component configuration tables, system resource information, interface definition documents, and system deployment diagrams.

[0138] Step 5: DODAF multi-view model correlation verification.

[0139] Conduct cross-perspective correlation verification from four dimensions:

[0140] Mapping consistency: Verify that the mapping relationships between different perspectives are consistent and without misalignment or contradiction.

[0141] The specific verification of mapping consistency adopts a two-way traceability method: forward traceability starts from the requirement and checks layer by layer along the "requirement-capability-business-resource" chain. First, starting from the top-level task requirement, the corresponding capability is found in the requirement deconstruction hierarchy association matrix established in step 1 (such as "manned exploration → high-precision positioning capability"). Then, starting from the capability, the corresponding business activity is found in the business-capability mapping matrix in step 2 (such as "high-precision positioning capability → navigation information calculation process"). Then, starting from the business activity, the corresponding system resource is found in the resource-business mapping matrix in step 3 (such as "navigation information calculation process → space navigation constellation system"). It is verified whether each requirement can be traced back to the final physical system component. If a requirement cannot be traced back to the end of this chain, it is determined that there is a "requirement omission" or "implementation deficiency". Reverse tracing starts from system components and traces backward along the "resource-business-capability-requirement" chain. First, starting with any system component, it searches backward in the resource-business mapping matrix to find the business activities it supports. Then, it searches backward in the business-capability mapping matrix to find the capabilities implemented by that business activity. Finally, it searches backward in the requirement deconstruction matrix to find the task requirements it satisfies. This verifies whether each component can be traced back to a clear source of requirements. If a component cannot be traced back to any requirements, it is determined that there is "design redundancy." By checking the mapping relationships between functions and activities, it is ensured that the mapping relationships from each perspective are one-to-one, without misalignment or contradiction.

[0142] Logical coherence: Verify that the execution logic of "communication link establishment process - data transmission process - link release process" is smooth and consistent with the implementation logic of Earth-Moon communication capability.

[0143] The specific verification of logical coherence employs a scenario-based deduction method, selecting the typical scenario of "communication between a manned spacecraft and a ground control center" for full-process tracking. From a capability perspective, the implementation logic of "Earth-Moon communication capability" follows a three-stage sequential logic of "establishing a link first → transmitting data then → releasing the link." From a business perspective, the corresponding business process is "communication link establishment process (initiating a call request → accepting a call request → resource allocation) → data transmission process (session management → paging → receiving a call → making a call) → link release process (hanging up the phone → determining the end of the session → releasing resources)," the three-stage division of which is consistent with the logical stages from the capability perspective. From a resource perspective, the corresponding system resource state transition is "antenna assembly: standby → pointing at the target → locking → transmitting → releasing," the state transition matching the three-stage sequence of business activities. By sequentially tracing the logical flow of this scenario in the three perspectives and verifying whether the stage division and logical sequence of the state transitions are consistent, the logical coherence between the perspectives can be confirmed.

[0144] Requirements compliance: Verify that the design model meets the core requirements of positioning accuracy ≤ Xm for manned exploration and data transmission rate ≥ XGbps for scientific research station exploration.

[0145] The specific verification of requirement compliance employs a step-by-step verification method using quantitative indicators. Taking the requirement of "positioning accuracy ≤ Xm" for manned exploration as an example: First, it is checked whether the "high-precision positioning" sub-capability indicator of "Earth-Moon navigation capability" in the capability perspective has been defined as "positioning accuracy ≤ Xm during lunar landing," and it is confirmed that it has been defined. Second, it is checked whether the "navigation information calculation" business process within the "Earth-Moon navigation" business domain in the business perspective includes the business steps required to achieve this accuracy, and it is confirmed that it has been included. Finally, it is checked whether the component performance of the "space navigation constellation system" executing this business process in the resource perspective theoretically supports the realization of this accuracy. If the performance parameters are confirmed to meet the requirements after calculation, the verification is passed. Taking the requirement of "data transmission rate ≥ XGbps" for scientific research station exploration as an example: the capability indicator definition, business process steps, and system component performance are verified in sequence to ensure that they all meet the rate requirement. Through the above step-by-step verification, it is ensured that the quantitative requirement indicators have corresponding design support and are theoretically achievable at the capability, business, and resource levels.

[0146] System integrity: Verification of the six core capabilities, six business domains, and six core systems without omissions, with proper hierarchical decomposition, capable of supporting the full-process requirements of two major scenarios.

[0147] The system integrity verification employs a combination of checklist review and full-process simulation. First, based on the design requirements deconstruction document from Step 1, a complete list of elements—"requirements-capabilities-business-resources"—is established. Second, the six core capabilities and their sub-capabilities are compared item by item with the requirements list to confirm that each functional performance requirement is covered by the corresponding capability, with no missing capabilities. Third, the "business-capability mapping matrix" is checked to confirm that each sub-capability is supported by one or more business processes, with no capabilities left unsupported. Next, the "resource-business mapping matrix" is checked to confirm that each key business process has corresponding system resources for execution and support, with no execution breakpoints. Finally, two core scenarios—manned lunar exploration and lunar research station exploration—are selected, and a full-process simulation is conducted along the "task → capability → business → resource" chain to verify that the complete task flow for each scenario runs smoothly at all three levels. If, after the above verification, capability coverage reaches 100%, business support coverage reaches 100%, resource support coverage reaches 100%, and the full-process simulation of both scenarios has no breakpoints, then the system integrity verification is passed.

[0148] For example, the joint audit found that the mapping relationship between the "fault recovery business process" and the "fault tolerance component" was unclear, so an audit report was generated and the perspective from which the problem belonged was the resource perspective.

[0149] The problem localization employed a cross-validation method, with the following steps: First, the business perspective model was examined to confirm that the initiation conditions (fault detection signal triggering), activity decomposition (fault diagnosis → recovery strategy selection → recovery execution → recovery confirmation), and termination logic (successful recovery or manual intervention) of the "fault recovery business process" were clearly defined, indicating that the problem was not in the business perspective. Next, the resource-business mapping matrix in the resource perspective model was examined, revealing that no system component was associated with the "fault recovery business process" in the matrix, meaning the business process lacked corresponding resource support. This determined that the root cause of the problem lay in the resource perspective's missing system components required to implement the process. Finally, the definition of the "fault tolerance component" in the resource perspective model was examined, confirming that this component only included "fault detection" and "fault diagnosis" modules, lacking the functional modules corresponding to the recovery process. Through these three steps of cross-validation, the problem was precisely located in the resource perspective model.

[0150] Step 6: System design model optimization and implementation.

[0151] Specifically, in response to the issues identified during the verification, the functional positioning of the fault tolerance component was optimized in the resource perspective model. A new "fault recovery trigger module" was added, clarifying the one-to-one correspondence between this module and the "fault recovery business process," thus completing a partial adjustment to the model.

[0152] The specific implementation process of model optimization is as follows: First, a "Fault Recovery Trigger Module" sub-component is added to the internal structure of the "Fault Tolerance Component" in the resource perspective model. Second, the function of this module is defined as "receiving fault diagnosis results and triggering the generation of a fault recovery instruction sequence," with its input being "fault diagnosis signals" (including fault type code, fault location identifier, and fault severity level) and its output being "recovery instruction sequence" (including instructions to switch to backup channel, rerouting instructions, and degraded operation instructions). Third, in the resource-business mapping matrix, a correspondence is established between the "fault recovery business process" and this newly added module, and an identifier is made. Finally, the interface definition document is supplemented with the interface definitions between this module and the "Fault Diagnosis Module" (input interface) and the "Actuator Component" (output interface), including parameters such as interface type, communication protocol, and data format. After completing the above adjustments, an independent internal consistency check is performed on the resource perspective model. Only after confirming that there are no new contradictions does it proceed to the re-verification stage.

[0153] Re-verification: The optimized system resource perspective model was independently verified, and then cross-perspective correlation verification was carried out. The verification problem was solved, and each perspective model met the requirements of consistency, coherence, compliance and completeness.

[0154] The specific verification process for re-verification is as follows: First, the optimized resource perspective model is independently verified. Through internal consistency checks, it is confirmed that the newly added "fault recovery trigger module" has correctly established interface connection relationships with the upstream "fault diagnosis module" and the downstream "actuator component," with no isolated nodes or unconnected ports. Second, the resource-business mapping matrix is ​​re-examined to confirm that the mapping relationship between the "fault recovery business process" and the "fault recovery trigger module" has been established, and the tracing path "fault recovery business process → fault recovery trigger module" is unobstructed. Third, following the bidirectional tracing method established in step 5, the "fault recovery trigger module" is traced backward along the "resource-business-capability-requirement" chain to verify that it can trace back to the "fault recovery" sub-capability in "fault tolerance capability," and then trace back to the requirement of "emergency fault recovery for manned exploration (recovery time ≤ 10s)," confirming that the tracing chain is closed. Finally, a comprehensive cross-perspective correlation verification is performed on the capability, business, and resource perspectives to re-verify the requirements of consistency, coherence, compliance, and completeness in four dimensions, confirming that all issues have been resolved.

[0155] Model encapsulation: Standardize and encapsulate the design models from the three perspectives to form a design deliverable package that includes model drawings, mapping matrices, resource lists, and interface documentation.

[0156] Engineering Implementation: Based on the design deliverables, develop a system engineering development plan, clarifying the technical parameters and development cycle of each component; develop a deployment implementation plan, clarifying the installation, networking, and debugging processes of each system; develop an operation and maintenance upgrade plan, clarifying the methods for system status monitoring, parameter adjustment, and version upgrade, so as to achieve seamless integration from DODAF system design to engineering implementation.

[0157] This embodiment successfully constructed an integrated system design model supporting manned lunar exploration and lunar research station exploration. The design results achieved a closed-loop mapping of "requirements-capabilities-business-resources," with logical coherence and requirement alignment across design models from various perspectives. The standardized design model provides a unified basis for cross-unit collaborative work in overall design, subsystem development, and engineering implementation. The model has good scalability; when new commercial aerospace scenario requirements are added, scenario expansion can be completed by only locally optimizing the multi-scenario adaptation capabilities from the capability perspective and the terminal adaptation system from the resource perspective. The design results are directly transformed into the basis for engineering implementation, ensuring a high degree of consistency between system development, deployment, and design requirements, and significantly improving engineering feasibility.

[0158] This invention also provides a design system for a DODAF-based Earth-Moon communication and navigation system, corresponding to the above-described method embodiments. Since the system embodiments are basically similar to the method embodiments, the description is relatively simple. For details of the relevant technical features and their effects, please refer to the corresponding descriptions of the above-described method embodiments. This invention discloses a design system for a DODAF-based Earth-Moon communication and navigation system, such as... Figure 2 As shown, this system includes:

[0159] The requirement deconstruction document deconstruction module is used to obtain the design requirements of the preset application scenarios of the Earth-Moon communication and navigation system. Based on the systematic analysis method of the DODAF framework, the design requirements of the preset application scenarios of the Earth-Moon communication and navigation system are deconstructed to obtain a standardized requirement deconstruction document.

[0160] The capability perspective design model determination module is used to perform hierarchical modeling from a capability perspective based on the standardized requirements deconstruction document to obtain a capability perspective design model, wherein the capabilities correspond to the design requirements of the preset application scenarios.

[0161] The business perspective design model determination module is used to perform process modeling from a business perspective based on the capability perspective design model, clarify the business process, business activities, business actions and business logic relationships, and establish a mapping relationship between the business perspective and the capability perspective to obtain the business perspective design model.

[0162] The resource perspective design model determination module is used to perform entity modeling of the resource perspective based on the capability perspective design model and the business perspective design model, determine the system resource information that supports the implementation of business processes, and establish a two-way mapping relationship between the resource perspective and the business perspective and capability perspective to obtain the resource perspective design model.

[0163] The cross-perspective correlation verification module is used to perform cross-perspective correlation verification on the capability perspective design model, business perspective design model, and resource perspective design model to verify the mapping consistency, logical coherence, requirement compliance, and system integrity among the design models of each perspective.

[0164] The output module is used to output an integrated design model of the Earth-Moon communication and navigation system based on the DODAF framework after successful verification.

[0165] This invention also provides an electronic device, which includes a processor and a memory. The memory stores at least one instruction or at least one program, which is loaded and executed by the processor. The above-described method embodiment provides a design method for a DODAF-based Earth-Moon communication and navigation system.

[0166] Furthermore, the electronic device may participate in or include the apparatus or system provided in the embodiments of the present invention. The electronic device may include one or more processors (processors may include, but are not limited to, processing devices such as microprocessors (MCUs) or programmable logic devices (FPGAs), memory for storing data, and transmission devices for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, a power supply, and / or a camera.

[0167] It should be noted that the aforementioned one or more processors and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuit may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the device (or mobile device). As involved in the embodiments of the present invention, the data processing circuit serves as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0168] The memory can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the method described in the embodiments of the present invention. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby realizing the above-mentioned data processing method. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to electronic devices via a network. Examples of the above-mentioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0169] The transmission device is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the device's communication provider. In one example, the transmission device includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0170] The display can be, for example, a touchscreen liquid crystal display (LCD), which allows users to interact with the user interface of an electronic device (or mobile device).

[0171] This invention also provides a computer storage medium storing at least one instruction or at least one program, which is loaded and executed by a processor to implement the DODAF-based Earth-Moon communication and navigation system design method provided in the above-described method embodiments.

[0172] Optionally, in this embodiment, the aforementioned computer storage medium may be located at at least one of the multiple network servers in a computer network. Optionally, in this embodiment, the aforementioned storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0173] This invention also provides a computer program product or computer program, which includes computer instructions stored in a computer storage medium. The processor of an electronic device reads the computer instructions from the computer storage medium and executes the computer instructions, causing the electronic device to perform the DODAF-based Earth-Moon communication and navigation system design method provided in the above-described method embodiments.

[0174] It should be noted that the order of the above embodiments of the present invention is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, specific embodiments have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0175] It should be understood that the above description of the preferred embodiments is quite detailed and should not be construed as a limitation on the scope of protection of the present invention. Those skilled in the art can make substitutions or modifications under the guidance of the present invention without departing from the scope of protection of the claims of the present invention, and all such substitutions or modifications fall within the scope of protection of the present invention. The scope of protection of the present invention should be determined by the appended claims.

Claims

1. A design method for a DODAF-based Earth-Moon communication and navigation system, characterized in that, The method includes: The design requirements of the preset application scenarios of the Earth-Moon communication and navigation system are obtained. Based on the systematic analysis method of the DODAF framework, the design requirements of the preset application scenarios of the Earth-Moon communication and navigation system are deconstructed to obtain a standardized requirement deconstruction document. Based on the standardized requirements deconstruction document, hierarchical modeling from a capability perspective is performed to obtain a capability-perspective design model, wherein the capabilities correspond to the design requirements of the preset application scenarios. Based on the capability perspective design model, process modeling from a business perspective is carried out to clarify the business processes, business activities, business actions and business logic relationships, and to establish a mapping relationship between the business perspective and the capability perspective, thus obtaining the business perspective design model. Based on the capability perspective design model and business perspective design model, a resource perspective entity model is performed to determine the system resource information that supports the implementation of business processes, and a two-way mapping relationship is established between the resource perspective and the business perspective and capability perspective to obtain the resource perspective design model. Cross-perspective correlation verification was performed on the capability-perspective design model, business-perspective design model, and resource-perspective design model to verify the mapping consistency, logical coherence, requirement compliance, and system integrity among the design models. After successful verification, an integrated design model of the Earth-Moon communication and navigation system based on the DODAF framework will be output.

2. The design method for a DODAF-based Earth-Moon communication and navigation system according to claim 1, characterized in that, The systematic analysis method based on the DODAF framework deconstructs the design requirements of the pre-defined application scenarios of the Earth-Moon communication and navigation system, resulting in a standardized requirement deconstruction document, including: Extract common and individual design requirements from preset application scenarios. The common requirements are the basic design indicators of the Earth-Moon communication and navigation system, and the individual requirements are the differentiated design indicators for each preset application scenario. The design requirements are decomposed into a DODAF hierarchy according to a preset hierarchical relationship, which includes, in order, a task layer, a capability layer, a business layer, and a resource layer. The task layer corresponds to the core tasks of the preset application scenario, the capability layer corresponds to the system capabilities that support the tasks, the business layer corresponds to the business activities that implement the capabilities, and the resource layer corresponds to the system resources that carry the business. Establish a hierarchical relationship matrix for design requirement decomposition, determine the correspondence between the task layer and the capability layer, the capability layer and the business layer, and the business layer and the resource layer, and form a standardized requirement decomposition document.

3. The design method for a DODAF-based Earth-Moon communication and navigation system according to claim 1, characterized in that, The hierarchical modeling from a capability perspective based on the standardized requirements deconstruction document yields a capability-perspective design model, including: The core capabilities of the Earth-Moon communication and navigation system are extracted, and each core capability is decomposed into sub-capabilities to obtain a capability hierarchy structure diagram, wherein the sub-capabilities are the specific implementation dimensions of the corresponding core capabilities; Determine the capability indicators for each sub-capability and construct a capability indicator specification document, wherein the capability indicators correspond to the design requirements of the preset application scenario; Analyze the dependencies between core capabilities and sub-capabilities, clarify the priority and mutual constraints of each capability, and obtain a capability relationship diagram; A capability-scenario mapping matrix is ​​constructed based on each core capability, sub-capability, and corresponding preset application scenario. Based on the obtained capability hierarchy structure diagram, capability association diagram, capability-scenario mapping matrix, and capability indicator description document, a standardized capability perspective design model is formed.

4. The design method for a DODAF-based Earth-Moon communication and navigation system according to claim 3, characterized in that, The analysis examines the dependencies between core capabilities and sub-capabilities, clarifies the priority and mutual constraints of each capability, and yields a capability relationship diagram, including: Each core capability and its sub-capabilities are treated as nodes in a graph. The dependencies between nodes are analyzed to clarify the priority and mutual constraints of each capability. The direction of dependency is represented by directed lines with arrows to obtain a capability association graph. The dependencies include required relationships, leading relationships, and enabling relationships.

5. The design method for a DODAF-based Earth-Moon communication and navigation system according to claim 1, characterized in that, The process modeling from a business perspective, based on the capability-perspective design model, clarifies business processes, activities, actions, and logical relationships, and establishes a mapping relationship between the business perspective and the capability perspective, resulting in the business perspective design model, including: Based on the core capabilities, the corresponding business domains are determined, and the business domains correspond one-to-one with the core capabilities, resulting in a business domain partitioning diagram. Within each business domain, the core business processes are identified, where each core business process is the overall business logic that implements the corresponding core capabilities, resulting in a business process diagram. Each business process is decomposed into several ordered business activities, and each business activity is further refined into specific business actions to obtain a business activity decomposition table. The business activity is the basic execution unit of the corresponding business process, and the business action is the smallest execution unit of the business activity. Establish a mapping model between the business perspective and the capability perspective, determine the correspondence between business domain and core capability, business process and sub-capability, and business activity and capability indicator, and obtain the business-capability mapping matrix; Analyze the logical relationships, data interaction relationships, and collaborative execution relationships between various business domains and business processes to form an end-to-end business process system and obtain a business data interaction diagram. Based on the obtained business domain division diagram, business process diagram, business activity decomposition table, business-capability mapping matrix, and business data interaction diagram, a standardized business perspective design model is formed.

6. The design method for a DODAF-based Earth-Moon communication and navigation system according to claim 1, characterized in that, The process of performing entity modeling from a resource perspective based on the capability-perspective design model and the business-perspective design model to determine the system resource information supporting the implementation of business processes includes: Based on the business process system, the overall system architecture of the Earth-Moon communication and navigation system is divided, and multiple core systems are identified to obtain the system architecture diagram. Each core system is decomposed into several subsystems to obtain a subsystem decomposition diagram, wherein the subsystems are functional subdivisions of the core system and correspond to the execution stages of the business process; Within each subsystem, the core hardware components and software components are identified, and the functional positioning and technical characteristics of each component are clarified to obtain a component configuration table. The components are the basic carrier units of system resources. Configure corresponding hardware and software resources, network resources, and deployment resources for each component, specifying the specifications, quantity, and configuration method of the resources to obtain system resource information.

7. The design method for a DODAF-based Earth-Moon communication and navigation system according to claim 6, characterized in that, The establishment of a two-way mapping relationship between the resource perspective and the business and capability perspectives yields a resource perspective design model, including: Establish a mapping model between resource perspective and business perspective, determine the correspondence between system-business domain, subsystem-business process, and component-business activity, and establish an indirect mapping model between resource perspective and capability perspective to obtain the resource-business mapping matrix. Determine the interface types, communication protocols, and data formats between each system, subsystem, and component, as well as the deployment locations, deployment methods, and networking methods of each system's resources on Earth, Earth-Moon space, and the lunar surface, to obtain the interface definition document; A standardized resource-perspective design model is derived based on the system architecture diagram, subsystem decomposition diagram, component configuration table, system resource information, interface definition document, and resource-business mapping matrix.

8. The design method for a DODAF-based Earth-Moon communication and navigation system according to claim 1, characterized in that, The cross-perspective correlation verification of the capability-perspective design model, business-perspective design model, and resource-perspective design model verifies the mapping consistency, logical coherence, requirement compliance, and system integrity among the various perspective design models, including: Verify whether the mappings between the capability perspective and design requirements, the business perspective and capability perspective, and the resource perspective and business perspective correspond one-to-one. Verify whether the logical relationships within the design models from each perspective are smooth, whether the logic of capability realization, business execution, and resource support form a closed loop; Verify whether the design models from the perspectives of capability, business, and resources fully meet the design requirements of the preset application scenarios; Verify whether the elements of the design model from each perspective are complete.

9. The design method for a DODAF-based Earth-Moon communication and navigation system according to claim 1, characterized in that, The method further includes: If the verification fails, the problem is located based on the multi-perspective model correlation verification report, and the perspective to which the problem belongs, the design dimension corresponding to the problem, and the related perspectives affected by the problem are determined. To address the positioning issue, the design model for the corresponding perspective was locally adjusted and optimized; The optimized perspective design model is independently verified, and then re-linked and verified with other perspective design models until all problems are resolved.

10. A design system for a DODAF-based Earth-Moon communication and navigation system, characterized in that, The system includes: The requirement deconstruction document deconstruction module is used to obtain the design requirements of the preset application scenarios of the Earth-Moon communication and navigation system. Based on the systematic analysis method of the DODAF framework, the design requirements of the preset application scenarios of the Earth-Moon communication and navigation system are deconstructed to obtain a standardized requirement deconstruction document. The capability perspective design model determination module is used to perform hierarchical modeling from a capability perspective based on the standardized requirements deconstruction document to obtain a capability perspective design model, wherein the capabilities correspond to the design requirements of the preset application scenarios. The business perspective design model determination module is used to perform process modeling from a business perspective based on the capability perspective design model, clarify the business process, business activities, business actions and business logic relationships, and establish a mapping relationship between the business perspective and the capability perspective to obtain the business perspective design model. The resource perspective design model determination module is used to perform entity modeling of the resource perspective based on the capability perspective design model and the business perspective design model, determine the system resource information that supports the implementation of business processes, and establish a two-way mapping relationship between the resource perspective and the business perspective and capability perspective to obtain the resource perspective design model. The cross-perspective correlation verification module is used to perform cross-perspective correlation verification on the capability perspective design model, business perspective design model, and resource perspective design model to verify the mapping consistency, logical coherence, requirement compliance, and system integrity among the design models of each perspective. The output module is used to output an integrated design model of the Earth-Moon communication and navigation system based on the DODAF framework after successful verification.

Images