A template-based OCD design method

Abstract

The present application belongs to the field of aircraft overall design, and particularly relates to a template-based OCD design method. The method comprises the following steps: Step 1, determining the information contained in the OCD, and establishing a document structure based on the information contained in the OCD, wherein the information contained in the OCD includes R&D background and necessity information, current system and operation information, new system operation overview, system overview, system operation concept, and system analysis information; Step 2, establishing a process model based on the aircraft operation scenario, including: S201, dividing the aircraft operation process into multiple stages according to the mission profile; S202, according to the aircraft's mission or combat mode, and targeting the aircraft's usage characteristics, using the three relationships of generalization, expansion, and inclusion to identify the operation scenarios of each stage; S203, establishing a process model for each operation scenario; Step 3, establishing a system use case based on the information contained in the OCD, the document structure, and the process model, and implementing the system operation according to the system use case.

Description

Technical Field

[0001] The present invention relates to the field of aircraft overall design, and in particular to a template-based OCD design method. Background Art

[0002] Before commencing drone solution design, it is necessary to design the OCD (OpsCon) based on the system capability requirements proposed in the conceptual phase, write a system operational concept document, convert stakeholder requirements into system requirements, guide the establishment of system use cases by defining the system usage process, and establish a system functional logic model based on each use case.

[0003] Existing OCD writing simply inherits high-level concepts (Conops), including system capability requirements as part of the document. This then involves describing the system process through previous designs without identifying stakeholders, making it difficult to ensure that business and stakeholder needs are fully understood and met. As a result, system use cases designed based on OCD fail to cover all system functions and cannot be effectively used to develop functional requirements at the equipment or aircraft level.

[0004] Therefore, it is desired to have a technical solution to overcome or at least alleviate at least one of the above-mentioned deficiencies of the prior art. Summary of the Invention

[0005] The purpose of this application is to provide a template-based OCD design method to solve at least one problem existing in the prior art.

[0006] The technical solution of this application is:

[0007] A template-based OCD design method, comprising:

[0008] Step 1: Determine the information contained in the OCD and establish a document structure based on the information contained in the OCD. The information contained in the OCD includes R&D background and necessity information, current system and operation information, new system operation overview, system overview, system operation concept, and system analysis information.

[0009] Step 2: Establishing a process model based on aircraft operation scenarios includes:

[0010] S201. Divide the aircraft operation process into multiple phases according to the mission profile;

[0011] S202. Based on the aircraft's mission or combat mode, and taking into account the aircraft's operational characteristics, use the three relationships of generalization, expansion, and inclusion to identify operational scenarios at each stage.

[0012] S203, establishing a process model for each operation scenario;

[0013] Step 3: Establish a system use case based on the information contained in the OCD, the document structure, and the process model, and implement system operation based on the system use case.

[0014] In at least one embodiment of the present application, the R&D background and necessity information includes military demand information, development necessity information, and combat system information, wherein:

[0015] The military demand information includes information on weapons and equipment of both sides, and information on the gap in our equipment capabilities;

[0016] The combat system information includes combat node information, combat relationship information and supporting equipment information.

[0017] In at least one embodiment of the present application, the new system operation overview includes mission information, combat usage style and constraint information, and system operation environment information.

[0018] In at least one embodiment of the present application, the system overview includes descriptions of system capability requirements, user and operator information, system boundaries, and interface information.

[0019] In at least one embodiment of the present application, the system operation concept includes a typical operation concept and an abnormal operation concept.

[0020] In at least one embodiment of the present application, in S201, the aircraft operation process is divided into a dispatch preparation phase, an approach and take-off phase, a departure flight phase, a mission execution phase, a return flight phase, and a landing and recovery phase according to the mission profile.

[0021] In at least one embodiment of the present application, in S202, the operation scenarios of each stage include:

[0022] Dispatch preparation stage: normal dispatch preparation scenario, second dispatch preparation scenario, emergency dispatch preparation scenario;

[0023] Driving in and taking off phases: driving in scene, taking off scene;

[0024] Departure flight phase: single aircraft departure flight scenario, multi-aircraft formation departure flight scenario;

[0025] Mission execution phase: coordinate attack scenario, coordinated attack scenario;

[0026] Return flight phase: return flight scenario;

[0027] Landing and recovery phase: driving out scenario and data unloading scenario.

[0028] In at least one embodiment of the present application, in S203, the process model includes: operating environment information, system stakeholder information, condition determination information, system input and response information, result determination information, subsequent process information, and constraints in the process.

[0029] In at least one embodiment of the present application, the system use case includes information in the process model, system boundaries, actors, and cross-linking relationships.

[0030] The invention has at least the following beneficial technical effects:

[0031] The template-based OCD design method of this application obtains user and task requirements by describing the operating process of the system during task execution, provides a holistic view of the expected system capabilities and architecture, and links all elements together by refining the scenarios of the system completing various operating processes. According to the system capability requirements and usage style analysis in the concept research, an operation concept template is designed. For each operation scenario, the operation and use process of the system in the combat system environment is described, and the correspondence between the system function description and combat requirements is established, providing a comprehensive system operation perspective for equipment design, development, verification and validation. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 This is a schematic diagram of operating scenario identification according to one embodiment of the present application;

[0033] Figure 2 This is a system use case operation diagram of an implementation method of the present application. DETAILED DESCRIPTION

[0034] In order to make the purpose, technical solutions and advantages of the implementation of this application clearer, the technical solutions in the embodiments of this application will be described in more detail below in conjunction with the drawings in the embodiments of this application. In the drawings, the same or similar reference numerals throughout represent the same or similar elements or elements with the same or similar functions. The described embodiments are part of the embodiments of this application, not all of the embodiments. The embodiments described below with reference to the drawings are exemplary and are intended to be used to explain this application, and should not be understood as limitations on this application. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application. The embodiments of this application are described in detail below in conjunction with the drawings.

[0035] In the description of this application, it should be understood that the terms "center", "longitudinal", "lateral", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inside", "outside", etc., indicating the orientation or position relationship, are based on the orientation or position relationship shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation. Therefore, it should not be understood as limiting the scope of protection of this application.

[0036] The following is combined with Figures 1 to 2 This application is described in further detail.

[0037] This application provides a template-based OCD design method, comprising the following steps:

[0038] Step 1: Determine the information contained in the OCD and establish a document structure based on the information contained in the OCD. The information contained in the OCD includes R&D background and necessity information, current system and operation information, new system operation overview, system overview, system operation concept and system analysis information;

[0039] Step 2: Establishing a process model based on aircraft operation scenarios includes:

[0040] S201. Divide the aircraft operation process into multiple phases according to the mission profile;

[0041] S202. Based on the aircraft's mission or combat mode, and taking into account the aircraft's operational characteristics, use the three relationships of generalization, expansion, and inclusion to identify operational scenarios at each stage.

[0042] S203, establishing a process model for each operation scenario;

[0043] Step 3: Establish system use cases based on the information, document structure, and process model contained in the OCD, and implement system operation based on the system use cases.

[0044] The template-based OCD design method of this application first determines the information contained in the OCD and establishes a document structure based on the information contained in the OCD. The information contained in the OCD includes R&D background and necessity information, current system and operation use information, new system operation overview, system overview, system operation concept and system analysis information; the content and level of detail of the document depend on when it is written or updated during the system life cycle, and the purpose of document writing. The document provides relevant information about the system operation and use, timing flow and typical usage scenarios. Based on this document, system use cases can be designed quickly and accurately, thereby establishing a system functional logic model for the development of equipment-level and aircraft-level functional requirements and for various disciplines to sort out subsystem functional requirements and conduct subsequent detailed design.

[0045] In one embodiment of the present application, the R&D background and necessity information includes military demand information, development necessity information, and combat system information, wherein:

[0046] Military demand information includes information on weapons and equipment of both sides, and information on the gap in our equipment capabilities;

[0047] Combat system information includes combat node information, combat relationship information, and supporting equipment information.

[0048] Specifically, R&D background and necessity information is used to describe information in the upper-level system that is useful and relevant to the operation of the system. It helps designers understand the capability requirements and task objectives of the system being developed. To obtain R&D background and necessity information, the following steps are required:

[0049] a) Demand analysis: analyzing the current task content and required capabilities;

[0050] b) R&D necessity analysis, including the deficiencies and capability requirements of the previous level system, other systems at the same level, or the current system (for improvement and modification), and demonstrating the necessity of developing the new or improved system;

[0051] c) Description of the upper-level system architecture, including the capabilities of systems that may collaborate or interact with this system, and a brief description of the effects that can be achieved through interaction;

[0052] d) The project's development history, existing achievements, and specific content will be helpful for necessity analysis;

[0053] e) Stakeholder comments on the project and system.

[0054] Current system operational information describes the current system's operational environment, system composition, system operation, operational constraints, support environment, and related personnel. Understanding the current system's operational use helps understand the newly developed system, and the content and level of detail provided should facilitate understanding of the new system's operation.

[0055] In this embodiment, the newly developed system operation overview is used to provide a static description of the relationship between the system and its operating environment, explaining the operation of the developed system and its operating environment. The operation is described from the user's perspective within the system operating environment. The system operating environment is the environment that users face when performing tasks. It includes:

[0056] a) Mission information: used to describe the tasks to be performed by the system and is a high-level summary of the mission objectives;

[0057] b) Operational Usage Patterns and Constraints: This describes the system's usage and applicability, referencing relevant standards and specifications. It also describes any operational constraints or restrictions. This includes: Operational Usage Patterns: The operational usage of the newly developed system, including combat patterns and attack methods; Operational Constraints: Constraints and restrictions that must be considered during system operation, such as airport conditions, airspace, weather conditions, and threats.

[0058] c) System operating environment information: used to describe the support environment, threat environment, and physical environment for system operation. This includes the support environment (network resources that support system operation, such as the command network, intelligence network, and early warning aircraft, and other systems. If relevant demonstration reports are available, they can be directly cited), the threat environment (including enemy systems or systems that may limit the system's capabilities or threaten the system's survival. If relevant demonstration reports are available, they can be directly cited), and the physical environment (natural environment: temperature, humidity, pollution, etc.; induced environment: noise, shock, vibration, etc.; electromagnetic environment: electromagnetic interference and radiation from facilities, equipment, computer hardware and software, lightning environment, static electricity environment, etc.). It should also include any environmental changes that may occur during the system's life cycle.

[0059] Also includes:

[0060] d) Personnel information: This is used to define the "personnel" in the operating system. This includes: organizational structure (which defines and describes the personnel organizational structure, and also specifies the definition of each organization and the relationship between them), personnel positions (which completely defines the various types of personnel involved in the mission. The following information should be provided for each type of personnel: position title, roles and responsibilities related to the mission, activities required to complete the mission, qualifications and training requirements; physical fitness requirements, skill level requirements, and relationships with stakeholder organizations). In this embodiment, any personnel changes that may occur during the system lifecycle should also be included.

[0061] In this embodiment, the system overview includes information describing system capability requirements, user and operator information, system boundaries, and interface information (including important internal interfaces). The system overview should be described from the perspective of system operators and maintenance personnel, identifying key areas of concern for operating the system within their operating environment. The system overview only needs to provide the information necessary to understand the rest of this document. In the early stages of development, it should describe the system concept and be updated as development progresses. In the later stages of development, it should describe the actual system's operational concepts.

[0062] Furthermore, in this embodiment, the system operation concept includes a typical operation concept and an abnormal operation concept.

[0063] In a preferred embodiment of the present application, in S201, the aircraft operation process is divided into a dispatch preparation phase, an approach and take-off phase, a departure flight phase, a mission execution phase, a return flight phase, and a landing and recovery phase according to the mission profile.

[0064] In S202, the operation scenarios of each stage include:

[0065] Dispatch preparation stage: normal dispatch preparation scenario, second dispatch preparation scenario, emergency dispatch preparation scenario;

[0066] Driving in and taking off phases: driving in scene, taking off scene;

[0067] Departure flight phase: single aircraft departure flight scenario, multi-aircraft formation departure flight scenario;

[0068] Mission execution phase: coordinate attack scenario, coordinated attack scenario;

[0069] Return flight phase: return flight scenario;

[0070] Landing and recovery phase: driving out scenario and data unloading scenario.

[0071] Each scenario should be relevant to specific users and system elements. Several different types of scenarios should be considered, including normal task mode, abnormal and special processing mode, critical activity mode, security mode, and maintenance mode.

[0072] In S203 , the process model includes: operating environment information, system stakeholder information, condition determination information, system input and response information, result determination information, subsequent process information, and constraints in the process.

[0073] In the template-based OCD design method of the present application, the system use case includes information in the process model, system boundaries, actors, and cross-linking relationships.

[0074] In step 2 of this application's template-based OCD design method, based on initial capability requirements and the operational view, the major phases of combat aircraft mission execution are identified. The system usage process description is transformed from a user perspective to a system perspective. Taking into account multi-aircraft formation flight and coordinated operations, system operations are divided into multiple operational scenarios, including mission planning, deployment preparation, entry, and takeoff. For each operational scenario, a process model is designed to describe the system's operational activities. The process description uses a grid format, as shown in Table 1. This grid can be expanded or reduced as needed based on the process description requirements.

[0075] Table 1

[0076]

[0077] The operational process corresponds to a set operational scenario and is assigned a number. The priority describes the importance and priority of the operational scenario. The operational purpose describes the purpose of the process operation. For example, the operational purpose of the normal sortie preparation process is to perform pre-flight preparation according to the combat mission plan. The operational time describes the time when the process runs. For example, the operational time of the sortie preparation process is before the mission is executed and the aircraft enters the takeoff line. The operational location describes the location where the process runs. For example, the operational location of the sortie preparation process is the deployment airport or control station. The stakeholders describe the actors involved in the process operation, such as the command center, combat support personnel, and navigation satellites. The preconditions describe the preconditions that must be met for the process to run. For example, the precondition for the sortie preparation process is that the combat mission plan of the superior command has been completed. The trigger condition describes the trigger event or instruction of the process. When this trigger event occurs and the precondition is met, the process is executed. The stakeholder action and system response have a one-to-one correspondence. The stakeholder action describes the response of the system to external influences. The stakeholder action describes the actions and instructions issued by the stakeholder during the process operation, which is the interaction with the system. The system response describes the system's response after the stakeholder issues an instruction or performs an action.

[0078] The template-based OCD design method of the present application may also include a description of the concept of abnormal operation. Abnormal situations include unexpected events and system failures. An unexpected situation refers to the situation where the drone is unable to adapt to external environmental disturbances when its own system is intact, resulting in system abnormalities, such as link failure and navigation interference. A system failure refers to the failure of the drone's own equipment, resulting in the inability to fly normally or complete the mission, such as power loss, insufficient fuel, etc.

[0079] The template-based OCD design method of this application provides a holistic view of the expected system capabilities and architecture by describing the operating process of the system during task execution, listing the users and task requirements therein, and linking all elements together by refining the scenarios in which the system completes various operating processes, providing comprehensive information about the system's operational use, timing process and typical usage scenarios.

[0080] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A template-based OCD design method, characterized in that: include: Step 1: Determine the information contained in the OCD and establish a document structure based on the information contained in the OCD. The information contained in the OCD includes R&D background and necessity information, current system and operation information, new system operation overview, system overview, system operation concept, and system analysis information. The R&D background and necessity information includes military demand information, development necessity information and combat system information, among which: The military demand information includes information on weapons and equipment of both sides, and information on the gap in our equipment capabilities; The combat system information includes combat node information, combat relationship information and supporting equipment information; Step 2: Establishing a process model based on aircraft operation scenarios includes: S201. Divide the aircraft operation process into multiple phases according to the mission profile; S202. Based on the aircraft's mission or combat mode, and taking into account the aircraft's operational characteristics, use the three relationships of generalization, expansion, and inclusion to identify operational scenarios at each stage. S203. Establish a process model for each operation scenario, wherein the process model includes: operation environment information, system stakeholder information, condition determination information, system input and response information, result determination information, subsequent process information, and process constraints; Step 3: Establish a system use case based on the information contained in the OCD, the document structure, and the process model, and implement system operation based on the system use case.

2. The template-based OCD design method according to claim 1, characterized in that: The operation overview of the newly developed system includes mission information, combat usage style and constraint information, and system operation environment information.

3. The template-based OCD design method according to claim 2, characterized in that: The system overview includes descriptions of system capability requirements, user and operator information, system boundaries, and interface information.

4. The template-based OCD design method according to claim 3, wherein: The system operation concept includes a typical operation concept and an abnormal operation concept.

5. The template-based OCD design method according to claim 4, characterized in that: In S201, the aircraft operation process is divided into a dispatch preparation phase, an approach and take-off phase, a departure flight phase, a mission execution phase, a return flight phase, and a landing and recovery phase according to the mission profile.

6. The template-based OCD design method according to claim 4, characterized in that: In S202, the operation scenarios of each stage include: Dispatch preparation stage: normal dispatch preparation scenario, second dispatch preparation scenario, emergency dispatch preparation scenario; Driving in and taking off phases: driving in scene, taking off scene; Departure flight phase: single aircraft departure flight scenario, multi-aircraft formation departure flight scenario; Mission execution phase: coordinate attack scenario, coordinated attack scenario; Return flight phase: return flight scenario; Landing and recovery phase: driving out scenario and data unloading scenario.

7. The template-based OCD design method according to claim 6, wherein: The system use case includes information in the process model, system boundaries, actors, and cross-linking relationships.

Images