Design method for generating standard system from avionics task system architecture model

By using the avionics mission architecture model design method, the problems of delayed requirement generation and weak system correlation in the standardization system design were solved, realizing the forward-looking response of the standard system and the efficient construction of the equipment platform, ensuring clear equipment functional positioning and accurate performance indicators.

CN122018857APending Publication Date: 2026-05-12CHINESE AERONAUTICAL RADIO ELECTRONICS RES INST
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
CHINESE AERONAUTICAL RADIO ELECTRONICS RES INST
Filing Date
2025-12-27
Publication Date
2026-05-12

AI Technical Summary

Technical Problem

Traditional standardization system design methods suffer from systemic defects such as delayed demand generation and weak system linkages. The bottom-up project collection model leads to one-sided, repetitive, and retrospective standard demand generation, lacking explicit linkage with top-level equipment capability planning, task usage scenarios, and expected technological development.

Method used

A design methodology for generating a standard system from the avionics mission architecture model is adopted, including mission style framework design, logical architecture framework design and standard requirement capture. Through standardized descriptions of mission environment, mission scenario, flight profile, node deployment scheme, etc., combined with capability architecture, mission architecture and functional architecture models, standard requirements are captured and a standard system is constructed.

Benefits of technology

It has enabled the forward-looking response capability of the standard system to iterate and optimize the task process, solving the problems of lagging requirement generation and weak system correlation in traditional methods, ensuring that the functional positioning of the equipment platform is clear and the performance indicators are accurate, and avoiding resource waste and duplication of construction.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122018857A_ABST
    Figure CN122018857A_ABST
Patent Text Reader

Abstract

The invention provides a design method for generating a standard system from an avionics task system architecture model, and the method comprises the steps: 1, designing a task style framework which comprises a task environment, a task scene, a flight profile, a task plan, a node deployment scheme, a command and control relation, and a task rule; 2, designing a logic architecture framework which comprises a capability architecture, a task architecture and a function architecture; and step 3, capturing a standard demand, and generating a standard system. It can be ensured that function positioning of the equipment platform is clearer, performance indexes are more accurate, and meanwhile resource waste and repeated construction are avoided.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention belongs to the field of standards and specifications technology, and relates to a design method for generating a standard system from an avionics mission architecture model. Background Technology

[0002] Traditional standardization system design methods generally employ systems engineering approaches such as the six-dimensional model of standardization systems engineering, work breakdown structure, parallel decomposition method, genus / species division method, and classification method. However, its bottom-up project collection model has significant limitations: on the one hand, although there is a top-level design, it is only presented as an isolated standard system diagram and detailed table, lacking explicit and modeled connections with key elements such as top-level equipment capacity planning, task usage scenarios, and expected technological development; on the other hand, this linear advancement model leads to persistent problems in standard requirement generation, such as one-sidedness (limited to a local perspective), repetitiveness (difficulty in coordinating requirements from multiple departments), and ex-post nature (lagging behind task evolution). Summary of the Invention

[0003] To address the systemic shortcomings of traditional standardization models, such as delayed requirement generation and weak system coherence, this invention provides a design method for generating a standard system from an avionics mission architecture model. The technical solution is as follows: A design method for generating a standard system from an avionics mission architecture model includes: Step 1: Design the mission style framework, including mission environment, mission scenario, flight profile, mission plan, node deployment scheme, command and control relationship, and mission rules; Step 2: Design the logical architecture framework, including capability architecture and capability architecture model, task architecture and task architecture model, and functional architecture and functional architecture model; Step 3: Capture standard requirements and generate a standard system: Based on the principles of standard identification, standard revision requirements, and standard selection, capture standard requirements and build a standard system by considering the capability architecture, task architecture, and functional architecture models for typical task scenarios.

[0004] Optionally, when designing the task style framework, the task style is standardized in the form of spatiotemporal domain scenarios to form a scenario document that can guide modeling analysis and architecture design: the task scenario is described in a standardized way from the aspects of spatial environment and time plan, and its performance, consumption and cost are evaluated, thereby forming a task scenario scenario model or document as input for logical domain design.

[0005] Optionally, typical characteristics and development trends of the social and information environments; When designing a mission scenario, determine the basic actions in the scenario, including targeted delivery actions and monitoring actions; When designing the flight profile, the position status and action changes of the specified nodes in the entire scene are designed in the form of tables or images. When designing a task plan, determine the collaboration scheme for participating nodes. Describe the process from planning and organization, implementation, space preparation, on-site training to deployment and arrangement through text description, including the analysis and judgment of the task, game objectives and expectations, task commands and action plans. When designing a node deployment plan, we start from the balance of power between the two sides of the game and arrange the types, number, and deployment locations of the nodes participating in one side, and describe the node name and the space type it belongs to through text descriptions; When designing the command and control relationship, a command relationship diagram is used to describe the command and control relationship and methods of each level of command organization or node; When designing task rules, describe the task process using text or flowcharts, following the sequence of initiating the task, leading and driving the task, pausing or ending the task, and stabilizing the action.

[0006] Optionally, the design logic architecture framework is specifically as follows: Design capability architecture and generate capability architecture model: Based on task scenario design documents, design capability architecture, including system capability analysis, system capability-sub-capability decomposition, capability dependency analysis, capability-activity relationship analysis, and construct capability architecture model with capability conception, classification, definition, and relationship, providing input for capturing capability-related standard requirements; Design task architecture and generate task architecture model: Based on the task scenario design document, design task architecture, including task scenario analysis, task activity decomposition, node interaction analysis, build task architecture model with action concepts, node connections, organizational relationships, task activities, interface relationships, and task sequence, analyze task scenario platform-level task requirements, and provide input for capturing relevant standard requirements of unit capability class and process class. Design functional architecture and generate functional architecture model: Based on the results of task architecture design, design the system functional architecture of the participating platform, including functional domain division, functional decomposition, functional interaction analysis, construct a functional architecture model of system composition, system functions, message transmission, and state transition, analyze the functional requirements of the participating platform system, and provide input for capturing technical-related standard requirements.

[0007] Optionally, the capture standard requirements are specifically as follows: For system capabilities in the capability architecture, participating unit capabilities, action processes, and system operation processes in the mission architecture, and equipment / information system functions in the functional architecture, determine whether each capability, process, and function requires standard specifications from the following dimensions: Input for capabilities / processes / functions; Constraints and control conditions of capabilities / processes / functions; The methods or processes for using tools that enable / process / function; Output of capabilities / processes / functions; According to the preset evaluation criteria, evaluate whether the inputs, constraints and control conditions, methods or processes, and outputs should be included in the standard as standard requirements; the preset evaluation criteria are: Criterion 1: Is it necessary to ensure that the equipment meets the indicators or requirements for the mission? Criterion Two: Is it necessary to solidify and pass on standards, definitions, and descriptions? Guideline 3: Is a standardized control process required? Criterion 4: Is a standard needed to improve development efficiency or reduce development costs? When at least one criterion is met, the item is identified as a standard requirement item; when none of the evaluation criteria are met, the standard requirement for the element is recorded as none. The standard requirement items are normalized and numbered: the existing standard set is matched with the standard requirements to determine whether the existing standards can cover each standard requirement; if the existing standards are to be adopted, the standard requirement is associated with the standard configuration file model; if a new standard is to be added, the standard requirement is associated with the standard prediction description model, and combined with the logical architecture model, the content requirements of the new standard are described according to the corresponding capability / process / function satisfaction criteria.

[0008] Optionally, the construction of a standards system specifically includes: Generate a standard configuration file model: Classify and merge all standard requirements items, describe the type, number, name, and release time of the adopted standards, and obtain a standard configuration file model. The standards in the standard configuration file include standard document items corresponding to capability-type standard requirements, process-type standard requirements, and technical standard requirements. Establish a traceability relationship between standard document items and standard requirements; one standard document can correspond to multiple standard requirements, and one standard requirement can correspond to multiple standard documents. Generate a standard predictive description model: classify and merge all newly added standard requirements, describe the type, name, and content requirements of the newly revised standard, establish a traceability relationship between the new standard and the standard requirements, and obtain the standard predictive description model.

[0009] Optionally, capability standards trace the capability / task architecture model corresponding to the capability standard requirements and determine the content requirements of the standard, including the definition, dependent activities, dependent nodes, implementation process, and capability indicators of a series of task sub-capabilities involved. Process-related standards define the task architecture and task event tracking model corresponding to the requirements of process-related standards, and determine the content requirements of the standards, including a series of actions, task activity processes, and command and coordination relationships involved. Technical standards address the functional architecture and system event tracking models corresponding to the technical standard requirements, and determine the content requirements of the standards, including the design requirements of a series of system functions and communication interaction functions involved. Optionally, a new standard can correspond to multiple standard requirements, and a standard requirement can correspond to multiple new standards.

[0010] This invention proposes an integrated forward design standard system design method that links "task scenario" in the spatiotemporal domain to "capability type - task requirements - functional requirements - standard requirement items" in the logical domain. This includes a task style framework design method proposed in the spatiotemporal domain, a logical architecture framework design method proposed in the logical domain, and specific steps for capturing standard requirements and generating the standard system. It provides detailed steps from capability architecture, task architecture, and functional architecture to capturing standard requirements and generating the standard system, demonstrating practicality and feasibility. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. The drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A flowchart for a forward design methodology to generate a standard system from an avionics mission architecture model; Figure 2 Design flowcharts for task scenarios; Figure 3 Flowchart for capability architecture design and modeling; Figure 4 Flowchart for task architecture design and modeling; Figure 5 Flowchart for functional architecture design and modeling; Figure 6 A flowchart for capturing standard requirements and generating standard systems. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0014] The features and illustrative embodiments of various aspects of the present invention will now be described in detail. Numerous specific details are set forth in the following detailed description to provide a thorough understanding of the invention. However, it will be apparent to those skilled in the art that the invention may be practiced without requiring some of these specific details. The following description of embodiments is merely intended to provide a better understanding of the invention by illustrating examples of the invention. The invention is by no means limited to any specific setups and methods set forth below, but covers any improvements, substitutions, and modifications to structures, methods, and devices without departing from the spirit of the invention. Well-known structures and techniques are not shown in the drawings and the following description to avoid unnecessarily obscuring the invention.

[0015] It should be noted that, unless otherwise specified, the embodiments of the present invention and the features thereof can be combined with each other, and the various embodiments can be referenced and cited in each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0016] The present invention will be further described in detail below with reference to the embodiments and accompanying drawings, but the embodiments of the present invention are not limited thereto.

[0017] This invention constructs a product system for avionics architecture design through a structured modeling paradigm of "perspective + view". This method centers on three core perspectives: capability, mission, and function. Through model-based data development, it transforms top-level planning into executable system requirements, achieving both the systematic deconstruction of standardized objects and establishing a full-chain information mapping from equipment capability planning to specific technical implementation. This architecture model, by incorporating dynamic elements such as mission scenarios and technological expectations, overcomes the separation of traditional methods in the spatiotemporal and relational dimensions. It enables the standard system to proactively respond to capability requirement iterations and mission process optimizations, fundamentally solving systemic defects in traditional standardization models such as delayed requirement generation and weak system correlation.

[0018] This invention systematically integrates the reasonable requirements within the system model, transforming them into actionable standards to form an indispensable normative framework for equipment platform construction and use, providing clear direction for equipment research and development. By establishing a standard system, the functional positioning of the equipment platform can be made clearer, performance indicators more precise, and resource waste and redundant construction avoided. This connection not only reflects the deep integration of technology and management but also guides equipment construction to a higher level, ensuring the scientific rigor and practicality of the equipment and laying a solid foundation for its full lifecycle management. The forward design of generating a standard system from the avionics mission architecture model is essential.

[0019] This invention provides a design method for generating a standard system from an avionics mission architecture model. The method includes mission style framework design, logical architecture framework design, standard requirement capture and standard system generation, forming a forward design process of the standard system from "spatial domain to logical domain".

[0020] 1) Task style framework design The task patterns are standardized and described in the form of spatiotemporal domain scenarios to form scenario documents that can guide modeling analysis and architecture design. This involves standardizing the description of task scenario concepts from aspects such as spatial environment and time schedule, and evaluating their performance, consumption, and cost, thereby forming a reasonable task scenario concept model or document as input for logical domain design. The specific implementation steps are as follows: 1.1) Task Environment Analysis. Describe the typical characteristics and development trends of the vision environment, natural environment, social environment, and information environment through text and images.

[0021] 1.2) Task Scenario Description. Describe the basic actions in the scenario, such as pinpoint delivery and detection / surveillance actions.

[0022] 1.3) Flight profile design. Design the position, status, and action changes of the specified node in the entire scene using tables or images.

[0023] 1.4) Task planning. Task planning clarifies the collaborative schemes of participating nodes, describing the process from planning and organization, implementation, space preparation, on-site training to deployment and arrangement through text description, including the analysis and judgment of the task, game objectives and expectations, task orders and action plans, etc.

[0024] 1.5) Node Deployment Design. Node deployment design starts from the balance of power between the two sides in the game and arranges the types, number, and deployment locations of nodes participating on one side. This needs to be described in text, including node names and their corresponding spatial types.

[0025] 1.6) Command and Control Relationship Analysis. Command and control relationship analysis constrains the organizational structure and command and coordination relationships of one party's nodes, and describes the command and control relationships and methods of command organizations or nodes at each level through a command relationship diagram.

[0026] 1.7) Task rule analysis. Task rule analysis answers the questions of process sequence and action details. It needs to describe the task process through text or flowcharts, and can be carried out in the order of initiating the task -> leading and driving the task -> pausing or ending the task -> stabilizing the action.

[0027] 2) Logical architecture framework design The task scenario definition document (in which the task scenario, node deployment, command and control relationship, and task rules serve as inputs to the task architecture) describes the composition of the system architecture and the relationships between them from three levels: system-level capability architecture, device-level task architecture, and system-level functional architecture. The specific implementation steps are as follows: 2.1) Capability architecture design and generation of capability architecture model: Based on the task scenario design document, design capability architecture, including system capability analysis, system capability-sub-capability decomposition, capability dependency analysis, capability-activity relationship analysis, etc., and build capability architecture model such as capability conception, classification, definition, and relationship, to provide input for capturing capability-related standard requirements.

[0028] 2.2) Task architecture design and generation of task architecture model: Based on the task scenario design document, design the task architecture, including task scenario analysis, task activity decomposition, node interaction analysis, etc., and build a task architecture model including action concepts, node connections, organizational relationships, task activities, interface relationships, task sequence, etc. Analyze the platform-level task requirements of the task scenario and provide input for capturing relevant standard requirements of unit capability class and process class.

[0029] 2.3) Functional architecture design and generation of functional architecture models. Based on the results of the task architecture design, design the system functional architecture of the participating platform, including functional domain division, functional decomposition, functional interaction analysis, etc., construct functional architecture models of system composition, system functions, message transmission, state transition, etc., analyze the functional requirements of the participating platform system, and provide input for capturing technical-related standard requirements.

[0030] 3) Standard requirements capture and standard system generation Based on the principles of standard identification, standard revision requirements, and standard selection, and considering the capability architecture, task architecture, and functional architecture models for typical task scenarios, standard requirements are captured, and a standard system is constructed. The specific steps are as follows: 3.1) Identify standard requirements For the system capabilities in the capability architecture, the participating unit capabilities, action processes, and system operation processes in the task architecture, and the equipment / information system functions in the functional architecture, analyze whether each capability, process, and function requires standard specifications. The analysis dimensions are as follows: 1. Input of capabilities / processes / functions; 2. Constraints and control conditions of capabilities / processes / functions; 3. The methods or processes for using the tools for capabilities / processes / functions; 4. Output of capabilities / processes / functions.

[0031] The evaluation criteria for determining whether inputs, constraints and control conditions, methods or processes, and outputs should be included in the standard as standard requirements are as follows: Criterion 1: Is it necessary to ensure that the equipment meets the indicators or requirements for the task? Criterion 2: Is it necessary to solidify and pass on standards, definitions, and descriptions? Criterion 3: Is a standard control process required? Criterion 4: Is it necessary to use standards to improve development efficiency or reduce development costs?

[0032] Determine the standard requirements evaluation criteria. When at least one criterion is "yes", the item can be identified as a standard requirement item; when none of the evaluation criteria are met, the standard requirement for that element is recorded as none.

[0033] The standard requirement items are normalized and numbered, and the existing standard set is matched with the standard requirements to determine whether the existing standards can cover each standard requirement. If an existing standard is to be adopted, the standard requirement is associated with the standard configuration file model; if a new standard is to be added, the standard requirement is associated with the standard prediction description model, and the content requirements of the new standard are described in conjunction with the logical architecture model according to the corresponding capability / process / function satisfaction criteria.

[0034] 3.2) Standard Set Generation Using the standards perspective in the DoDAF method, a set of standards that the system needs to adopt and new standards is constructed. Among them, the standard configuration file (StdV-1) describes the various standards currently adopted by the system and their summary information, while the standard prediction description (StdV-2) describes the new standards to be added within a certain period of time and their potential impact on the system.

[0035] Standard configuration file model generation: All standard requirements are categorized and merged, describing the type, number, name, and release date of the adopted standards to complete the standard configuration file model, as shown in Table 1. The standards in the configuration file include standard document entries corresponding to capability-related, process-related, and technical standard requirements. A traceability relationship between standard document entries and standard requirements is established; one standard document can correspond to multiple standard requirements, and one standard requirement can correspond to multiple standard documents.

[0036] Table 1 Standard Configuration File Model

[0037] Standard predictive description model generation: All newly added standard requirements are categorized and merged, describing the type, name, and content requirements of the newly revised standards. A traceability relationship between new standards and standard requirements is established, and a standard prediction description model is completed (see Table 2). Specifically, capability-related standards should trace the corresponding capability / task architecture model to extract the standard's content requirements, including the definition, dependent activities, dependent nodes, implementation processes, and capability indicators of the involved task sub-capabilities. Process-related standards should trace the corresponding task architecture and task event tracking model to extract the standard's content requirements, including the involved actions, task activity processes, and command and coordination relationships. Technical standards should trace the corresponding functional architecture and system event tracking model to extract the standard's content requirements, including the design requirements of the involved system functions and communication interaction functions. One new standard can correspond to multiple standard requirements, and one standard requirement can correspond to multiple new standards.

[0038] Table 2 Standard Predictive Description Model Framework

[0039] This invention proposes an integrated forward design standard system design method that links "task scenario" in the spatiotemporal domain to "capability type - task requirements - functional requirements - standard requirement items" in the logical domain. This includes a task style framework design method proposed in the spatiotemporal domain, a logical architecture framework design method proposed in the logical domain, and specific steps for standard requirement capture and standard system generation. It emphasizes the specific steps from capability architecture, task architecture, and functional architecture to standard requirement capture and standard system generation, demonstrating practicality and feasibility, and solving the problems of one-sidedness, repetition, and retrospective nature of bottom-up standard requirement generation.

[0040] For example, Figure 1 This is a block diagram illustrating the implementation of the method of the present invention. Figure 1 As shown, the implementation process of the method of this invention includes task style framework design, logical architecture framework design, standard requirement capture, and standard system generation. The output of the task style framework design—the task scenario description document—becomes the input of the logical architecture framework design, performing capability, task, and functional architecture design and modeling. It identifies system / unit capability-type standard requirements, process-type standard requirements, and technical-type standard requirements from the model and compares them with the existing standard set to confirm association with existing standards or new standards. If process specifications are formed during the task style framework design and logical architecture framework design processes, they can also be identified as new standards and added to the standard prediction model as appropriate.

[0041] Figure 2This is a flowchart illustrating the core steps of the task scenario design within the task style framework. Through the design of each step, it defines the input environment, basic actions, spatiotemporal relationships, solutions, organizational structure, command structure, and task rules for the scenario scenario document.

[0042] Figures 3-5 These are flowcharts illustrating the process of capability, task, and functional architecture design and model generation. Follow these steps to complete the modeling of the corresponding view model.

[0043] Using the capability types in the capability architecture - capability classification model (CV-2), the components in the task flow (OV-5) of the task requirements in the task architecture analysis, and the system function requirements (SV-4) and functional information interaction (SV-6, SV-10) of the functional architecture as the analysis objects, fill in Table 3: Table 3 Standard Requirements Analysis Table

[0044] For the above standard requirements, experts will make a judgment and benchmark against the existing system standard set to determine whether there is already a standard describing this standard requirement. If there is, capture a standard adoption requirement and fill in the table as shown in Table 3 "Capability Type 2"; if not, capture a new standard requirement and fill in the table as shown in Table 3 "Capability Type 1".

[0045] Finally, as Figure 6 As shown, the standard type corresponding to the requirement is added to the standard configuration file description, and the standard type corresponding to the newly added requirement is included in the standard prediction description.

[0046] If the sample size of the analyzed scenarios is large enough, the size of its standard configuration files and standard predictions will also be larger, eventually forming a standard system.

[0047] The above detailed embodiments are a description of the present invention. It should not be considered that the specific embodiments of the present invention are limited to these descriptions. For those skilled in the art, several simple deductions and substitutions can be made without departing from the concept of the present invention, and all of these should be considered to fall within the protection scope of the present invention.

Claims

1. A design method for generating a standard system from an avionics mission architecture model, characterized in that, include: Step 1: Design the mission style framework, including mission environment, mission scenario, flight profile, mission plan, node deployment scheme, command and control relationship, and mission rules; Step 2: Design the logical architecture framework, including capability architecture and capability architecture model, task architecture and task architecture model, and functional architecture and functional architecture model; Step 3: Capture standard requirements and generate a standard system: Based on the principles of standard identification, standard revision requirements, and standard selection, capture standard requirements and build a standard system by considering the capability architecture, task architecture, and functional architecture models for typical task scenarios.

2. The method according to claim 1, characterized in that, When designing the task style framework, the task style is described in a standardized way using spatiotemporal domain scenarios to form a scenario document that can guide modeling analysis and architecture design: the task scenario is described in a standardized way from the aspects of spatial environment and time plan, and its performance, consumption and cost are evaluated, thereby forming a task scenario scenario model or document, which serves as input for logical domain design.

3. The method according to claim 2, characterized in that, When designing the task environment, describe the typical characteristics and development trends of the vision environment, natural environment, social environment, and information environment through text and images; When designing a mission scenario, determine the basic actions in the scenario, including targeted delivery actions and monitoring actions; When designing the flight profile, the position status and action changes of the specified nodes in the entire scene are designed in the form of tables or images. When designing a task plan, determine the collaboration scheme for participating nodes. Describe the process from planning and organization, implementation, space preparation, on-site training to deployment and arrangement through text description, including the analysis and judgment of the task, game objectives and expectations, task commands and action plans. When designing a node deployment plan, we start from the balance of power between the two sides of the game and arrange the types, number, and deployment locations of the nodes participating in one side, and describe the node name and the space type it belongs to through text descriptions; When designing the command and control relationship, a command relationship diagram is used to describe the command and control relationship and methods of each level of command organization or node; When designing task rules, describe the task process using text or flowcharts, following the sequence of initiating the task, leading and driving the task, pausing or ending the task, and stabilizing the action.

4. The method according to claim 1, characterized in that, The specific design logic architecture framework is as follows: Design capability architecture and generate capability architecture model: Based on task scenario design documents, design capability architecture, including system capability analysis, system capability-sub-capability decomposition, capability dependency analysis, capability-activity relationship analysis, and construct capability architecture model with capability conception, classification, definition, and relationship, providing input for capturing capability-related standard requirements; Design task architecture and generate task architecture model: Based on the task scenario design document, design task architecture, including task scenario analysis, task activity decomposition, node interaction analysis, build task architecture model with action concepts, node connections, organizational relationships, task activities, interface relationships, and task sequence, analyze task scenario platform-level task requirements, and provide input for capturing relevant standard requirements of unit capability class and process class. Design functional architecture and generate functional architecture model: Based on the results of task architecture design, design the system functional architecture of the participating platform, including functional domain division, functional decomposition, functional interaction analysis, construct a functional architecture model of system composition, system functions, message transmission, and state transition, analyze the functional requirements of the participating platform system, and provide input for capturing technical-related standard requirements.

5. The method according to claim 1, characterized in that, The specific requirements for capturing standards are as follows: For system capabilities in the capability architecture, participating unit capabilities, action processes, and system operation processes in the mission architecture, and equipment / information system functions in the functional architecture, determine whether each capability, process, and function requires standard specifications from the following dimensions: Input for capabilities / processes / functions; Constraints and control conditions of capabilities / processes / functions; The methods or processes for using tools that enable / process / function; Output of capabilities / processes / functions; According to the preset evaluation criteria, evaluate whether the inputs, constraints and control conditions, methods or processes, and outputs should be included in the standard as standard requirements; the preset evaluation criteria are: Criterion 1: Is it necessary to ensure that the equipment meets the indicators or requirements for the mission? Criterion Two: Is it necessary to solidify and pass on standards, definitions, and descriptions? Guideline 3: Is a standardized control process required? Criterion 4: Is a standard needed to improve development efficiency or reduce development costs? When at least one criterion is met, the item is identified as a standard requirement item; when none of the evaluation criteria are met, the standard requirement for the element is recorded as none. The standard requirement items are normalized and numbered: the existing standard set is matched with the standard requirements to determine whether the existing standards can cover each standard requirement; if the existing standards are to be adopted, the standard requirement is associated with the standard configuration file model; if a new standard is to be added, the standard requirement is associated with the standard prediction description model, and combined with the logical architecture model, the content requirements of the new standard are described according to the corresponding capability / process / function satisfaction criteria.

6. The method according to claim 5, characterized in that, The specific steps for building a standards system are as follows: Generate a standard configuration file model: Classify and merge all standard requirements items, describe the type, number, name, and release time of the adopted standards, and obtain a standard configuration file model. The standards in the standard configuration file include standard document items corresponding to capability-type standard requirements, process-type standard requirements, and technical standard requirements. Establish a traceability relationship between standard document items and standard requirements; one standard document can correspond to multiple standard requirements, and one standard requirement can correspond to multiple standard documents. Generate a standard predictive description model: classify and merge all newly added standard requirements, describe the type, name, and content requirements of the newly revised standard, establish a traceability relationship between the new standard and the standard requirements, and obtain the standard predictive description model.

7. The method according to claim 6, characterized in that, Capability standards trace the capability / task architecture model corresponding to capability standard requirements, and determine the content requirements of the standards, including the definition, dependent activities, dependent nodes, implementation process, and capability indicators of a series of task sub-capabilities involved. Process-related standards define the task architecture and task event tracking model corresponding to the requirements of process-related standards, and determine the content requirements of the standards, including a series of actions, task activity processes, and command and coordination relationships involved. Technical standards address the functional architecture and system event tracking models corresponding to the technical standard requirements, and determine the content requirements of the standards, including the design requirements of a series of system functions and communication interaction functions involved.

8. The method according to claim 7, characterized in that, A new standard can correspond to multiple standard requirements, and a single standard requirement can correspond to multiple new standards.