Support system indicator analysis method based on Harmony SE

Abstract

The present invention provides a support system indicator analysis method based on Harmony SE, which includes: conducting indicator analysis of the support system, determining standardized system indicators, and establishing a first traceability relationship and a second traceability relationship; conducting functional analysis of the support system, determining black-box activity diagrams and black-box sequence diagrams, and establishing a third traceability relationship; conducting architectural analysis of the support system, determining evaluation criteria for the support system, and obtaining an optimal solution for the support system; conducting architectural design of the support system, determining white-box activity diagrams and white-box sequence diagrams, establishing a fourth traceability relationship, and generating subsystem design requirements for the support system. By conducting indicator analysis, functional analysis, architectural analysis, and architectural design of the support system, the present invention supports the indicator-driven forward development of the support system, resolves many issues caused by designer experience, compensates for deficiencies in support system planning and design, and achieves optimization through design assurance.

Description

Technical Field

[0001] The present invention belongs to the technical field of model-based system engineering, and in particular to a support system indicator analysis method based on Harmony SE. Background Art

[0002] Harmony, short for "Rational Integrated Systems / Embedded Software Development Process Harmony," adopts the classic V-model of systems design. The left wing of the model depicts the top-down design process, Harmony SE, while the right wing illustrates the bottom-up embedded real-time development process, Harmony ESW. Models and metrics are stored in a central model / metric repository, integrating all phases from unit testing to final system acceptance testing. Harmony SE is a model-based systems engineering (MBSE) methodology. It employs a top-down design process encompassing metrics analysis, functional analysis, and design synthesis. This approach primarily identifies system functions based on system metrics and allocates them to subsystem structures. Harmony SE is a proven methodology for systems engineering, implemented using the IBM Rational Rhapsody software tool. From a systems engineering perspective, this approach uses a workflow-based approach to thoroughly delineate the tasks and responsibilities of early system development. This approach seamlessly connects subsequent system development and validation and verification, providing system engineers with a detailed, step-by-step process guide. Any change request in the workflow has a downward impact from a high level. Regardless of where a change request arises, the process restarts at the metrics analysis stage. Harmony SE's systems engineering workflow is an incremental, iterative, cyclical activity flow, with incremental iterations based on use cases. Systems engineering and its implementation analysis iterations are achieved through continuous implementation, testing, and the delivery of demonstrable results.

[0003] In the past, system design and development were primarily based on the designer's experience, which prevented the simultaneous and integrated design, feedback, and coordination of the main equipment platform and the support system. Furthermore, support system planning and design were insufficient, making it impossible to achieve the impact of support on design, and even more impossible to achieve the goal of optimizing the support system through design support. Therefore, to address this issue, given that the MBSE-based development model is now widely adopted in the development of new equipment models, it is urgent and necessary to seek a support system indicator analysis method based on Harmony SE to support the indicator-driven forward development of the support system. Summary of the Invention

[0004] In response to the shortcomings of the above-mentioned prior art, the present invention proposes a support system indicator analysis method based on Harmony SE. The method includes conducting indicator analysis of the support system, determining standardized system indicators, and establishing a first traceability relationship and a second traceability relationship; conducting functional analysis of the support system, determining black box activity diagrams and black box sequence diagrams, and establishing a third traceability relationship; conducting architectural analysis of the support system, determining the evaluation criteria for the support system, and obtaining the optimal solution for the support system; conducting architectural design of the support system, determining white box activity diagrams and white box sequence diagrams, establishing a fourth traceability relationship, and generating subsystem design requirements for the support system. By conducting indicator analysis, functional analysis, architectural analysis, and architectural design of the support system, the present invention supports the indicator-driven forward development of the support system, effectively resolving many practical problems caused by relying on designer experience, addressing the shortcomings of existing support system planning and design, and achieving optimization through design assurance.

[0005] The present invention provides a support system indicator analysis method based on Harmony SE, which includes the following steps:

[0006] S1. Conduct indicator analysis of the security system: Analyze the influencing factor indicators of the security system, convert the influencing factor indicators into standardized system indicators of the security system, and establish the first traceability relationship and the second traceability relationship;

[0007] S2. Conduct functional analysis of the assurance system: Using the assurance system use case as an assurance system black box, determine the attributes and operation process of the assurance system black box based on the standardized system indicators, combined with the black box activity diagram and black box sequence diagram, and establish a third traceability relationship between the assurance system black box and the standardized system indicators;

[0008] S21. defining a black box activity diagram of the security system black box;

[0009] S22. Define a black box sequence diagram of the support system black box: generate a black box sequence diagram based on the black box activity diagram, wherein the black box sequence diagram is used to describe the information interaction between the support system black box and the external system;

[0010] S23. Defining a black box internal module diagram for the support system: Based on the support system black box, define the ports and interfaces of the support system, generate a port and interface definition diagram for the support system, and obtain the connection relationship between the support system and the external system through the port and interface definition diagram to determine the black box internal module diagram for the support system;

[0011] S24. Establishing a third traceability relationship between the security system black box and the standardized system indicator;

[0012] S3. Conduct architecture analysis of the support system: identify key system functions of the support system and determine evaluation criteria;

[0013] S31. Identify key system functions of the support system and propose corresponding alternative solutions: Based on the third traceability relationship, identify key system functions of the support system, cluster the key system functions, and determine alternative solutions for the key system functions;

[0014] S32. Determine the evaluation criteria for the security system and obtain the optimal solution for the security system;

[0015] S4. Conduct architectural design of the support system: Consider the internal architecture of the support system as a white box, construct a white box model of the support system, conduct white box analysis of the support system, and pass down the standardized system indicators.

[0016] S41. Allocate the attributes and operating procedures of the support system black box to the subsystems of the support system: Based on the architecture analysis of the support system, obtain the architecture decomposition of the support system, generate subsystems of the support system, and allocate the attributes and operating procedures of all the support system black boxes to the subsystems to obtain the attributes and operating procedures of the subsystems;

[0017] S42. Define a white-box activity diagram for the support system: Based on the black-box activity diagram, divide the subsystems of the support system into swim lanes, and refine and generate a white-box activity diagram for the support system;

[0018] S43. Define a white box sequence diagram for the support system: take the subsystem as the analysis object, and automatically generate a white box sequence diagram for the support system based on the white box activity diagram of the support system;

[0019] S44. Define a white-box internal module diagram for the support system: Define the ports and interfaces of the subsystem, and clarify the relationships between the subsystem and the support system, as well as the ports and interfaces of other subsystems at the same level, to generate a white-box internal module diagram for the support system.

[0020] S45. Define the state diagram of the support system: Analyze the state-based behavior of the underlying modules of the support system in the hierarchical decomposition and generate the state diagram of the support system;

[0021] S46. Establishing a fourth traceability relationship between the assurance system white box model and the standardized system indicator;

[0022] S47. Generate subsystem design requirements for the security system: assign a second functional indicator and a second port and interface indicator of the subsystem to each subsystem based on the properties and operation process of the subsystem, and use the second functional indicator and the second port and interface indicator of the subsystem as input for the next round of iterative analysis of step S1 for each subsystem.

[0023] Furthermore, the step S1 specifically includes the following steps:

[0024] S11. Identify the factors affecting the security system and distinguish the importance of these factors;

[0025] S12. Determine the influencing factors and indicators of the support system: Analyze the equipment combat missions, extract the support tasks within the equipment combat missions, analyze the support activities required for the support tasks, and obtain the influencing factors and indicators of the support system;

[0026] S13. Receive and sort out the first indicator assigned by the equipment system to the support system;

[0027] S14. Receive the second indicator transmitted to the support system by the peer system and the professional engineering system of the support system;

[0028] S15. Generate standardized system indicators for the support system: Analyze the impact factor indicator, the first indicator, and the second indicator, and combine them with military standard indicators, civilian standard indicators, and lessons learned indicators, organize them into an impact factor indicator document according to the indicator compilation specification, and generate standardized system indicators for the support system in the form of itemized items;

[0029] S16. Establish the first traceability relationship between the impact factor index, the first index, the second index and the standardization system index;

[0030] S17. Define the use cases of the assurance system and determine the boundaries of the assurance system;

[0031] S18. Establish a second traceability relationship between the assurance system use cases and the standardized system indicators.

[0032] Preferably, the step S21 specifically includes the following steps:

[0033] S211. Use the assurance system use case as an assurance system black box and model the black box assurance activities.

[0034] S212. Based on the black box assurance activity, define a black box activity diagram of the assurance system black box;

[0035] S213, defining the operations that the support system black box needs to complete in the black box activity diagram;

[0036] S214, analyzing the operations to be completed in the black box activity diagram to obtain functional indicators of the guarantee system;

[0037] The step S24 specifically includes the following steps:

[0038] S241. Determine the attributes and operation procedures of corresponding security system black boxes based on all the security system black boxes.

[0039] S242: Establish a third traceability relationship between the security system black box and the standardized system indicators: Analyze all attributes and operation processes of the security system black box to obtain corresponding first functional indicators and first port and interface indicators of the security system.

[0040] Preferably, the step S32 specifically includes the following steps:

[0041] S321. Determine evaluation criteria for the security system and assign a weight to each evaluation criterion;

[0042] S322. Define a corresponding utility curve for each evaluation criterion;

[0043] S323, allocating a measure of effectiveness (MoE) corresponding to each evaluation criterion to the candidate solution;

[0044] S324: Multiply the MoE value of each evaluation criterion by the corresponding weight to obtain the total score of all the alternative solutions, and select the alternative solution with the highest total score as the optimal solution for the security system.

[0045] Preferably, the first traceability relationship is used to ensure that the standardized system indicators of the assurance system can meet and cover the influencing factor indicators, the first indicator and the second indicator; the second traceability relationship is used to ensure that the assurance system use case can cover all the standardized system indicators; the third traceability relationship ensures that each of the first functional indicators and the first port and interface indicators corresponds to at least one attribute and operation process of the assurance system black box; the fourth traceability relationship ensures that each of the standardized system indicators corresponds to at least one attribute and operation process of the subsystem.

[0046] Preferably, the influencing factors in step S11 include subjects, objects, supervisory bodies, suppliers and R&D bodies, and the basis for identifying the influencing factors includes typical combat usage indicators and tasks of equipment, definition files of influencing factors in the use of existing equipment, and equipment system-level and equipment platform influencing factor definition files; the support tasks in step S12 include usage support and maintenance support; the same-level systems in step S14 include equipment platforms and training systems, and the professional engineering systems include safety systems, reliability systems, maintainability systems, support systems, testing systems, maintenance engineering systems, process systems, environmental adaptability systems, economic systems and standard professional systems; the black box support activities in step S211 include usage support activity diagrams and maintenance support activity diagrams, and the usage support activity diagrams include pre-mobilization support, during-mobilization support and post-mobilization support, and the maintenance support activity diagrams include corrective maintenance support, preventive maintenance support and wartime support; the evaluation standards in step S321 include technical feasibility standards, technical maturity standards, development cycle standards, deployment standards and maintenance standards.

[0047] Preferably, the white box activity diagram in step S42 does not add new functions and has no missing functions compared to the black box activity diagram, maintaining the integrity of the standardized system indicator transmission, but there is a situation where a certain function is undertaken by two subsystems.

[0048] Preferably, the standardized system indicator in step S15 is only applicable to the level where the security system is located; the sum of all the weights in step S321 is 1; and the standardized value of the utility curve in step S322 is between 0 and 10.

[0049] Preferably, the indicator analysis, functional analysis, architecture analysis and architecture design are all conducted based on Harmony SE theory, and the black box activity diagram, black box sequence diagram, black box internal module diagram, white box activity diagram, white box sequence diagram, white box internal module diagram and state diagram are all defined in SysML language.

[0050] Compared with the prior art, the technical effects of the present invention are:

[0051] 1. This invention designs a support system indicator analysis method based on Harmony SE. By capturing, analyzing, and decomposing support system indicators, this method accurately and completely captures and analyzes support system indicators. This method provides a basis for formulating support system plans, proposing support resource design requirements at all levels, and designing and developing support system architectures, thereby supporting the indicator-driven forward development of support systems.

[0052] 2. The present invention designs a support system indicator analysis method based on Harmony SE. This method effectively solves many practical problems caused by relying on designer experience, such as the inability to achieve synchronous design, integrated design, synchronous feedback and coordination between the main equipment platform and the support system. It can make up for the shortcomings in support system planning and design, realize support-influenced design, and achieve the goal of optimizing the support system through design support. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] Other features, objects and advantages of the present application will become more apparent from the detailed description of non-limiting embodiments made with reference to the following drawings.

[0054] Figure 1 is a flow chart of the support system indicator analysis method based on Harmony SE of the present invention;

[0055] Figure 2 is a flow chart of an indicator analysis of the security system of the present invention;

[0056] Figure 3 is a flow chart of a functional analysis of the security system of the present invention;

[0057] Figure 4 is a flow chart of the architecture analysis of the security system of the present invention;

[0058] Figure 5 It is a flow chart of the architecture design of the security system of the present invention. DETAILED DESCRIPTION

[0059] The present application will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are merely for the purpose of explaining the relevant invention and are not intended to limit the invention. It should also be noted that, for ease of description, only portions relevant to the relevant invention are shown in the accompanying drawings.

[0060] It should be noted that, in the absence of conflict, the embodiments and features of the embodiments in this application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0061] Figure 1 The present invention shows a method for analyzing security system indicators based on Harmony SE, which includes the following steps:

[0062] S1. Conduct indicator analysis of the security system: Analyze the influencing factor indicators of the security system, convert the influencing factor indicators into standardized system indicators of the security system, establish the first traceability relationship and the second traceability relationship, such as Figure 2 shown.

[0063] S11. Identify the influencing factors of the support system and distinguish the importance of the influencing factors. The influencing factors include the subject, object, regulatory body, supplier and R&D body. The basis for identifying the influencing factors includes the typical combat use indicators and tasks of the equipment, the definition documents of the influencing factors in the use of existing equipment, and the definition documents of the influencing factors at the equipment system level and equipment platform level.

[0064] S12. Determine the impact factor indicators of the support system: The support system's function is to meet the operational mission requirements of the equipment. As a key component of the equipment system, the support system works with the equipment to complete the operational mission requirements assigned to each equipment type during system-level confrontations. Therefore, support system requirements are captured based on typical combat scenarios for each equipment type decomposed during system-level confrontations. Analyze the equipment's operational missions, extract the support tasks within these missions, analyze the support activities required for these missions, and derive the impact factor indicators of the support system. Support tasks include operational support and maintenance support.

[0065] S13. Receive and sort out the first indicator assigned by the equipment system to the support system.

[0066] S14. Receive the second indicator transmitted to the support system by the peer systems and professional engineering systems of the support system. The peer systems include equipment platforms and training systems, and the professional engineering systems include safety systems, reliability systems, maintainability systems, support systems, testing systems, maintenance engineering systems, process systems, environmental adaptability systems, economic systems, and standard professional systems.

[0067] S15. Generate standardized system indicators for the support system: Analyze the impact factor indicators, first indicators, and second indicators, and combine them with military standard indicators, civilian standard indicators, and lessons learned indicators. Organize them into the impact factor indicator document according to the indicator writing specifications to generate standardized system indicators for the support system. The standardized system indicators are only applicable to the level where the support system is located.

[0068] S16. Establish a first traceability relationship between the impact factor indicator, the first indicator, the second indicator and the standardization system indicator. The first traceability relationship is used to ensure that the standardization system indicator of the guarantee system can meet and cover the impact factor indicator, the first indicator and the second indicator.

[0069] S17. Define the use cases of the assurance system and determine the boundaries of the assurance system.

[0070] S18. Establish a second traceability relationship between the assurance system use case and the standardized system indicators. The second traceability relationship is used to ensure that the assurance system use case can cover all standardized system indicators.

[0071] S2. Conduct functional analysis of the support system: Take the support system use case as the support system black box, determine the attributes and operation process of the support system black box based on the standardized system indicators, combined with the black box activity diagram and black box sequence diagram, and establish a third traceability relationship between the support system black box and the standardized system indicators, such as Figure 3 shown.

[0072] S21. Define the black box activity diagram of the black box of the security system.

[0073] S211. Treat the support system use cases as a support system black box and model black box support activities. Model the support system activities from a functional logic perspective. Note that the "support system" should be described as a black box as a whole. Black box support activities include operational support activity diagrams and maintenance support activity diagrams. The operational support activity diagram includes pre-mobilization support, in-mobilization support, and post-mobilization support. The maintenance support activity diagram includes corrective maintenance support, preventive maintenance support, and wartime support.

[0074] S212. Based on the black box assurance activities, define the black box activity diagram of the assurance system black box.

[0075] S213. Define the operations that need to be completed by the black box of the security system in the black box activity diagram.

[0076] S214. Analyze the operations that need to be completed in the black box activity diagram to obtain the functional indicators of the guarantee system.

[0077] S22. Define the black box sequence diagram for the support system black box: Generate a black box sequence diagram based on the black box activity diagram. This diagram describes the information exchange between the support system black box and external systems. This diagram clearly identifies the external participants involved in the support system use case and the information or material transfer between them, thus guiding the subsequent identification of interface types and requirements.

[0078] S23. Define the black box internal module diagram for the support system: Based on the support system black box, define the support system's ports and interfaces, generate a port and interface definition diagram for the support system, and use this diagram to determine the connection between the support system and external systems, ultimately determining the black box internal module diagram for the support system. This diagram more clearly demonstrates the connection between the support system and external participants.

[0079] S24. Establish a third traceability relationship between the security system black box and the standardized system indicator; the third traceability relationship ensures that each first functional indicator and first port and interface indicator has at least one attribute and operation process of the security system black box corresponding thereto.

[0080] S241. Based on all the support system black boxes, determine the attributes and operation procedures of the corresponding support system black boxes.

[0081] S242. Establish a third traceability relationship between the security system black box and the standardized system indicators: Analyze the properties and operation processes of all security system black boxes to obtain the corresponding first functional indicators and first port and interface indicators of the security system.

[0082] S3. Conduct architecture analysis of the support system: Identify the key functions of the support system and determine the evaluation criteria, such as Figure 4 shown.

[0083] S31. Identify the key system functions of the security system and propose corresponding alternative solutions: Based on the third traceability relationship, identify the key system functions of the security system, cluster the key system functions of the security system, and determine alternative solutions for the key system functions.

[0084] S32. Determine the evaluation criteria for the security system and obtain the optimal solution for the security system.

[0085] S321. Determine the evaluation criteria for the support system and assign weights to each evaluation criterion. The evaluation criteria include technical feasibility criteria, technical maturity criteria, development cycle criteria, deployment criteria, and maintenance criteria. The sum of all weights is 1.

[0086] S322 . Define a corresponding utility curve for each evaluation criterion, where the standardized value of the utility curve is between 0 and 10.

[0087] S323. Assign the effectiveness metric MoE corresponding to each evaluation criterion to the alternative solution.

[0088] S324. Multiply the MoE value of each evaluation criterion by the corresponding weight to obtain the total score of all alternative solutions, and select the alternative solution with the highest total score as the optimal solution for the security system.

[0089] S4. Carry out the architecture design of the support system: take the internal architecture of the support system as the white box of the support system, build the white box model of the support system, conduct white box analysis of the support system, and pass down the standardized system indicators, such as Figure 5 shown.

[0090] S41. Allocate the attributes and operation procedures of the security system black box to the subsystems of the security system: Based on the architecture analysis of the security system, obtain the architecture decomposition of the security system, generate the subsystems of the security system, and allocate the attributes and operation procedures of all the security system black boxes to the subsystems to obtain the attributes and operation procedures of the subsystems.

[0091] S42. Define the white-box activity diagram for the support system: Based on the black-box activity diagram, divide the support system's subsystems into swimlanes and refine the generated white-box activity diagram. Compared to the black-box activity diagram, the white-box activity diagram does not add new functionality or omit functionality, maintaining the integrity of the standardized system's indicator delivery. However, a function may be shared by two subsystems.

[0092] S43. Define the white box sequence diagram of the support system: Same as the principle of the black box sequence diagram, with the subsystem as the analysis object, the white box sequence diagram of the support system is automatically generated based on the white box activity diagram of the support system.

[0093] S44. Define the white-box internal module diagram of the support system: define the ports and interfaces of the subsystem, and clarify the relationship between the subsystem and the support system, and the ports and interfaces of other subsystems at the same level, and generate the white-box internal module diagram of the support system.

[0094] S45. Define the state diagram of the security system: Analyze the state-based behavior of the underlying modules of the security system in the hierarchical decomposition and generate the state diagram of the security system.

[0095] S46. Establish a fourth traceability relationship between the white box model of the security system and the standardized system indicators. After completing the above modeling, as with the black box, it is necessary to establish a satisfaction relationship between the white box scenario and the system requirements. The fourth traceability relationship ensures that each standardized system indicator corresponds to at least one subsystem attribute and operation process.

[0096] S47. Generate subsystem design requirements for the security system: Based on the properties and operation process of the subsystem, assign the second functional indicators and the second port and interface indicators of the subsystem to each subsystem, and use the second functional indicators and the second port and interface indicators of the subsystem as input for the next round of iterative analysis of step S1 for each subsystem.

[0097] Index analysis, functional analysis, architecture analysis and architecture design are all carried out based on Harmony SE theory. Black box activity diagrams, black box sequence diagrams, black box internal module diagrams, white box activity diagrams, white box sequence diagrams, white box internal module diagrams and state diagrams are all defined in SysML language.

[0098] The following is a detailed description of this invention, based on the development of a rescue helicopter. This invention includes four steps: indicator analysis, functional analysis, architecture analysis, and architecture design of a support system based on Harmony SE. Ultimately, the support system captures and transmits influencing factor indicators. The specific implementation steps are as follows:

[0099] Typical use activities in the development of a certain type of rescue helicopter include: after an earthquake, carrying emergency rescue engineers, medical personnel, loading machinery and equipment, rescue tents, food, medical supplies and other materials to the disaster area, and carrying the wounded back to the base for treatment.

[0100] The influencing factors of this type of helicopter include flight crews, maintenance personnel, the Ministry of Emergency Management, equipment suppliers, etc., which put forward the needs for helicopter use and maintenance support, and pay attention to the support capabilities for the "earthquake relief" mission.

[0101] To support the "earthquake relief" mission, the helicopter's mission execution process includes takeoff, cruising, entry, mission execution, exit, return, and landing. To support the execution of the helicopter mission, support tasks are required, including pre-flight preparation, re-deployment preparation, and post-flight inspection, which puts forward the demand for operational support and maintenance support capabilities.

[0102] Helicopter support use cases are divided into operation support (pre-flight preparation, re-deployment preparation, post-flight inspection), maintenance support (corrective maintenance support, preventive maintenance support), transfer support and supply support.

[0103] A black box activity diagram was defined for "corrective maintenance support." In the proposed helicopter support use case, the support system needs to perform activities such as helicopter preparation, fault isolation, access, disassembly and replacement, reassembly, calibration, and inspection. Analysis shows that the support system should include fault detection and isolation, faulty component access, faulty component disassembly and replacement, and faulty component adjustment. Further definition of the black box sequence diagram and internal module diagram revealed that, for example, to implement fault detection and isolation, a detection and isolation interface should be established between the support system and the helicopter.

[0104] Clustering the functions identified in the previous analysis yields a functional architecture consisting of: information upload / download / processing, mooring and mobilization, routine operations, inspection, and replacement. Based on these functions, two candidate support system architectures are proposed: 1) by function category: information upload / download / processing, mooring and mobilization, routine operations, inspection, and replacement; 2) by general support resource element category: information systems, support equipment, support tools, technical documentation, supply support, and support facilities. Through a trade-off analysis, the second support system architecture was determined.

[0105] Define a white-box activity diagram for the support system, and decompose functions into subsystems using swimlanes. For example, the "fault detection and isolation function" is handled by the "support equipment," and the "faulty component removal and replacement function" is handled by the "support tool." Further defining white-box sequence diagrams and white-box internal module diagrams reveals that, for example, to implement the fault detection and isolation function, a detection and isolation interface should exist between the support equipment and the helicopter; and to implement the faulty component removal and replacement function, a reachable and operable interface should exist between the support tool and the helicopter. This allows for the allocation of functional and interface requirements for subsystems such as the information system, support equipment, support tools, technical documentation, supply support, and support facilities.

[0106] Through the above analysis, we can capture and decompose the top-level demand such as "earthquake relief" layer by layer to obtain the security system architecture plan and put forward design requirements for security resources at all levels in the architecture.

[0107] The present invention designs a support system indicator analysis method based on Harmony SE. By capturing, analyzing, and decomposing support system indicators, the method accurately and completely captures and analyzes support system indicators, providing a basis for formulating support system plans, proposing design requirements for support resources at all levels, and designing and developing support system architectures, thereby supporting indicator-driven forward research and development of support systems. The method effectively solves many practical problems caused by adopting designer experience, such as the inability to achieve synchronous design, integrated design, synchronous feedback, and coordination between the main equipment platform and the support system. It can compensate for deficiencies in support system planning and design, realize support-influenced design, and achieve the goal of optimizing the support system through design support.

[0108] Finally, it should be noted that the above embodiments are only intended to illustrate rather than limit the technical solutions of the present invention. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that the present invention can still be modified or replaced by equivalents. Any modification or partial replacement that does not depart from the spirit and scope of the present invention should be included in the scope of the claims of the present invention.

Claims

1. A support system indicator analysis method based on Harmony SE, characterized by: It includes the following steps: S1. Conduct indicator analysis of the security system: Analyze the influencing factor indicators of the security system, convert the influencing factor indicators into standardized system indicators of the security system, and establish the first traceability relationship and the second traceability relationship; S2. Conduct functional analysis of the assurance system: Using the assurance system use case as an assurance system black box, determine the attributes and operation process of the assurance system black box based on the standardized system indicators, combined with the black box activity diagram and black box sequence diagram, and establish a third traceability relationship between the assurance system black box and the standardized system indicators; S21. defining a black box activity diagram of the security system black box; S22. Define a black box sequence diagram of the support system black box: generate a black box sequence diagram based on the black box activity diagram, wherein the black box sequence diagram is used to describe the information interaction between the support system black box and the external system; S23. Defining a black box internal module diagram for the support system: Based on the support system black box, define the ports and interfaces of the support system, generate a port and interface definition diagram for the support system, and obtain the connection relationship between the support system and the external system through the port and interface definition diagram to determine the black box internal module diagram for the support system; S24. Establishing a third traceability relationship between the security system black box and the standardized system indicator; S3. Conduct architecture analysis of the support system: identify key system functions of the support system and determine evaluation criteria; S31. Identify key system functions of the support system and propose corresponding alternative solutions: Based on the third traceability relationship, identify key system functions of the support system, cluster the key system functions, and determine alternative solutions for the key system functions; S32. Determine the evaluation criteria for the security system and obtain the optimal solution for the security system; S4. Conduct architectural design of the support system: Consider the internal architecture of the support system as a white box, construct a white box model of the support system, conduct white box analysis of the support system, and pass down the standardized system indicators. S41. Allocate the attributes and operating procedures of the support system black box to the subsystems of the support system: Based on the architecture analysis of the support system, obtain the architecture decomposition of the support system, generate subsystems of the support system, and allocate the attributes and operating procedures of all the support system black boxes to the subsystems to obtain the attributes and operating procedures of the subsystems; S42. Define a white-box activity diagram for the support system: Based on the black-box activity diagram, divide the subsystems of the support system into swim lanes, and refine and generate a white-box activity diagram for the support system; S43. Define a white box sequence diagram for the support system: take the subsystem as the analysis object, and automatically generate a white box sequence diagram for the support system based on the white box activity diagram of the support system; S44. Define a white-box internal module diagram for the support system: Define the ports and interfaces of the subsystem, and clarify the relationships between the subsystem and the support system, as well as the ports and interfaces of other subsystems at the same level, to generate a white-box internal module diagram for the support system. S45. Define the state diagram of the support system: Analyze the state-based behavior of the underlying modules of the support system in the hierarchical decomposition and generate the state diagram of the support system; S46. Establishing a fourth traceability relationship between the assurance system white box model and the standardized system indicator; S47. Generate subsystem design requirements for the security system: assign a second functional indicator and a second port and interface indicator of the subsystem to each subsystem based on the properties and operation process of the subsystem, and use the second functional indicator and the second port and interface indicator of the subsystem as input for the next round of iterative analysis of step S1 for each subsystem.

2. The support system indicator analysis method based on Harmony SE according to claim 1, characterized in that: The step S1 specifically includes the following steps: S11. Identify the factors affecting the security system and distinguish the importance of these factors; S12. Determine the influencing factors and indicators of the support system: Analyze the equipment combat missions, extract the support tasks within the equipment combat missions, analyze the support activities required for the support tasks, and obtain the influencing factors and indicators of the support system; S13. Receive and sort out the first indicator assigned by the equipment system to the support system; S14. Receive the second indicator transmitted to the support system by the peer system and the professional engineering system of the support system; S15. Generate standardized system indicators for the support system: Analyze the impact factor indicator, the first indicator, and the second indicator, and combine them with military standard indicators, civilian standard indicators, and lessons learned indicators, organize them into an impact factor indicator document according to the indicator compilation specification, and generate standardized system indicators for the support system in the form of itemized items; S16. Establish the first traceability relationship between the impact factor index, the first index, the second index and the standardization system index; S17. Define the use cases of the assurance system and determine the boundaries of the assurance system; S18. Establish a second traceability relationship between the assurance system use cases and the standardized system indicators.

3. The support system indicator analysis method based on Harmony SE according to claim 2, characterized in that: The step S21 specifically includes the following steps: S211. Use the assurance system use case as an assurance system black box and model the black box assurance activities. S212. Based on the black box assurance activity, define a black box activity diagram of the assurance system black box; S213, defining the operations that the support system black box needs to complete in the black box activity diagram; S214, analyzing the operations to be completed in the black box activity diagram to obtain functional indicators of the guarantee system; The step S24 specifically includes the following steps: S241. Determine the attributes and operation procedures of corresponding security system black boxes based on all the security system black boxes. S242: Establish a third traceability relationship between the security system black box and the standardized system indicators: Analyze all attributes and operation processes of the security system black box to obtain corresponding first functional indicators and first port and interface indicators of the security system.

4. The support system indicator analysis method based on Harmony SE according to claim 3 is characterized in that: The step S32 specifically includes the following steps: S321. Determine evaluation criteria for the security system and assign a weight to each evaluation criterion; S322. Define a corresponding utility curve for each evaluation criterion; S323, allocating a measure of effectiveness (MoE) corresponding to each evaluation criterion to the candidate solution; S324: Multiply the MoE value of each evaluation criterion by the corresponding weight to obtain the total score of all the alternative solutions, and select the alternative solution with the highest total score as the optimal solution for the security system.

5. The support system indicator analysis method based on Harmony SE according to claim 3 is characterized in that: The first traceability relationship is used to ensure that the standardized system indicators of the assurance system can meet and cover the influencing factor indicators, the first indicator, and the second indicator; the second traceability relationship is used to ensure that the assurance system use case can cover all the standardized system indicators; the third traceability relationship ensures that each of the first functional indicators and first port and interface indicators corresponds to at least one attribute and operation process of the assurance system black box; the fourth traceability relationship ensures that each of the standardized system indicators corresponds to at least one attribute and operation process of the subsystem.

6. The support system indicator analysis method based on Harmony SE according to claim 4 is characterized in that: The influencing factors described in step S11 include subjects, objects, supervisory bodies, suppliers and R&D bodies. The basis for identifying the influencing factors includes typical combat usage indicators and tasks of equipment, definition files of influencing factors in the use of existing equipment, and definition files of equipment system-level and equipment platform influencing factors; the support tasks described in step S12 include usage support and maintenance support; the same-level systems described in step S14 include equipment platforms and training systems, and the professional engineering systems include safety systems, reliability systems, maintainability systems, support systems, testing systems, maintenance engineering systems, process systems, environmental adaptability systems, economic systems and standard professional systems; the black box support activities described in step S211 include usage support activity diagrams and maintenance support activity diagrams, and the usage support activity diagrams include pre-mobilization support, support during mobilization and post-mobilization support, and the maintenance support activity diagrams include corrective maintenance support, preventive maintenance support and wartime support; the evaluation standards described in step S321 include technical feasibility standards, technical maturity standards, development cycle standards, deployment standards and maintenance standards.

7. The method for analyzing security system indicators based on Harmony SE according to claim 1, characterized in that: Compared with the black box activity diagram, the white box activity diagram in step S42 does not add new functions and has no missing functions, maintaining the integrity of the standardized system indicator transmission, but there is a situation where a certain function is undertaken by two subsystems.

8. The method for analyzing security system indicators based on Harmony SE according to claim 4, characterized in that: The standardized system indicators in step S15 are only applicable to the level of the security system; the sum of all the weights in step S321 is 1; and the standardized value of the utility curve in step S322 is between 0 and 10.

9. The method for analyzing security system indicators based on Harmony SE according to claim 1, characterized in that: The indicator analysis, functional analysis, architecture analysis and architecture design are all carried out based on Harmony SE theory, and the black box activity diagram, black box sequence diagram, black box internal module diagram, white box activity diagram, white box sequence diagram, white box internal module diagram and state diagram are all defined in SysML language.

Images