Positive design method for electromechanical system architecture based on servitization thought

Abstract

The invention discloses an electromechanical system architecture forward design method based on a servitization thought, and belongs to the field of airplane electromechanical system design. The connection of requirements, functions, services, logic and physical architectures is realized through model-based system engineering (MBSE). Specifically, the method comprises the following steps of: establishing a demand structured model by using a SysML language, analyzing a target system function to obtain a service scheme meeting a function demand, realizing service logic through a logic layer state machine, and performing joint simulation with a physical layer simulation model to form'demand-function-service-logic-physics' full-link mapping taking the model as a clue; and the forward design of the system architecture is realized.

Description

Technical Field

[0001] This invention belongs to the field of aircraft electromechanical system design, specifically relating to a forward design method for electromechanical system architecture based on the service-oriented approach. Background Technology

[0002] In the development of complex aerospace equipment, model-based systems engineering (MBSE) has become an effective method for guiding the development of aerospace equipment systems and ensuring the efficiency and quality of system development, in accordance with the aerospace system development workflow. Typical electromechanical system design mainly adopts a top-down design process, proceeding hierarchically according to the system structure. This process mainly includes requirements capture, system requirements analysis and design, subsystem and component-level requirements analysis and design, system-level integration verification, and on-board verification. Due to the complexity of aircraft electromechanical systems, system design often requires a significant investment of manpower and time; furthermore, the reusability of system design models is low, and even with high similarity in design requirements, designers still need to perform a large amount of repetitive modeling work.

[0003] To address the aforementioned issues, this paper introduces service-oriented design principles to redefine system functions based on model-based electromechanical system design methods. This involves generalizing functions at each level into one or more specific service solutions. Furthermore, guided by design requirements, applicable system services are matched to the service solutions and their service objects, and the interaction rules between services are refined to complete the system's logical architecture design. Finally, the logical architecture is mapped to the physical architecture, and co-simulation analysis is conducted to verify the system design. Summary of the Invention

[0004] The purpose of this invention is to provide a forward design method for electromechanical system architecture based on the service-oriented approach. This method integrates the service-oriented design concept into the model-driven system design, thereby improving the reusability of system design models and reducing the workload of manual modeling.

[0005] The technical solution of the present invention:

[0006] A forward design methodology for electromechanical system architecture based on service-oriented principles is proposed. This methodology utilizes Model-Based Systems Engineering (MBSE) to connect requirements, functions, services, logic, and physical architecture. Specifically, a structured requirement model is built using SysML. Service-oriented solutions that meet the functional requirements are obtained through functional analysis of the target system. Service logic is implemented through a state machine at the logic layer, and the model is used to simulate the physical layer model, forming a full-link mapping of "requirements-functions-services-logic-physical" with the model as the guiding thread, thus achieving forward design of the system architecture. The design process can be divided into two main stages: service-oriented requirements analysis and service design application, including four main design steps:

[0007] S1, Requirements Capture and Analysis: Conduct requirements capture, system behavior analysis, and stakeholder analysis to clarify system behavior boundaries and core objectives. Define key performance indicators based on the Measure of Effectiveness (MOE), complete the top-level system function definition, ensure that requirements are consistent with stakeholder expectations, and establish a requirements traceability baseline.

[0008] S2, Service Solution Design: Propose corresponding service solutions based on the needs of the service recipients, and realize the allocation of system functions and performance. Decompose the service solutions to the component level to ensure that the requirements of each component are strictly aligned with the overall system goals.

[0009] S3, Logical Architecture Definition: Design logical interfaces and behavioral logic, clarify service interoperability and system service matching and invocation mechanisms, and verify the collaboration and consistency between services. Through iterative logical architecture analysis, optimize interface definitions and behavioral logic, and avoid potential conflicts.

[0010] S4, Physical Implementation Verification: Based on the SysML model and the interface definition of the physical performance simulation component, the system logical architecture model is reconstructed into a system physical architecture model. Iterative optimization is carried out in conjunction with functional performance co-simulation until the system performance target is achieved.

[0011] Furthermore, a forward design method for electromechanical system architecture based on service-oriented principles, wherein the S1 design step includes the following sub-steps:

[0012] S11, Design Requirements Capture: Analyze stakeholder needs using model-based and detailed methods, visualize them in SysML requirement diagrams, and establish a traceability matrix between stakeholders and business requirements.

[0013] S12, System Behavior Analysis and Stakeholder Analysis: For specific business scenarios, SysML use case diagrams are used to analyze the possible interaction behaviors between the target system and stakeholders, refine the needs of stakeholders, and thus clarify the behavioral boundaries and core objectives of the target system.

[0014] S13, Performance Measurement Definition: Based on system requirements and system behavior analysis, complete the performance measurement definition, and based on the performance measurement, clarify the quantitative evaluation indicators of the system under specific operating environment and conditions, use them as key performance indicators, and further complete the top-level system function definition.

[0015] Furthermore, a forward design method for electromechanical system architecture based on service-oriented principles includes the following sub-steps in the S2 design step:

[0016] S21, System Function Performance Allocation: Based on use case scenarios, analyze system functions and decompose them step-by-step to the smallest indivisible functional units (usually corresponding to basic physical components) according to system complexity and modeling granularity. The service solutions corresponding to the smallest functional units can be broken down into one or more atomic services. Combine atomic services to form upper-level service solutions, establish service solution activity diagrams, and logically verify their feasibility.

[0017] S22, Service Solution Traceability and Coverage Analysis: Use a refined relationship matrix to establish a traceable relationship between service solutions and requirements, conduct a service solution coverage analysis, and identify which service solutions are used to refine a certain requirement to ensure that no requirement is missed.

[0018] S23, Service-Oriented Restructuring of Requirements: Based on the traceability relationship between requirements and service solutions, the description method, organizational logic, and granularity of requirements are reorganized, transforming requirements from function-oriented or document-oriented to service-oriented. The restructured service-oriented requirements cover both functional and non-functional system requirement categories.

[0019] Furthermore, a forward design method for electromechanical system architecture based on service-oriented principles includes the following sub-steps in the S3 design step:

[0020] S31, based on the mapping relationship between service objects and service solutions, defines unique services for service objects from a service perspective, and searches for matching services from the service library based on service requirements. The service library stores relevant services from historical design solutions.

[0021] S32 utilizes the callable ports exposed by the system services to implement service invocation and service behavior control. Among the exposed ports, the "XX service call in" port is used for service control, while the "XX service output out" port's use depends on whether the specific service sends signals externally. Based on this, STM state machine diagrams are used to simulate the system service behavior logic and optimize the iterative system logic architecture.

[0022] S33 uses an IBD diagram to illustrate the interaction relationships between services, service objects, and stakeholders, clearly presenting the system architecture solution.

[0023] Furthermore, in a forward design method for electromechanical system architecture based on the service-oriented approach, in the S31 sub-design step, if there is no service in the service library that matches the service requirements, service design is required: defining the corresponding components as service component attributes using a BDD diagram, defining the component value attributes of reaction performance parameters according to standard specifications or design experience, defining the internal interaction of services based on the material, control, and information interface relationships between components, and defining service behavior using an STM state machine diagram based on the service carrying function.

[0024] Furthermore, a forward design method for electromechanical system architecture based on service-oriented principles includes the following sub-steps in the S4 design step:

[0025] S41 uses AMESim as the system performance analysis tool. Based on the mapping relationship between AMESim simulation models and physical components, a SysML basic model component library is constructed. On this basis, the IBD diagram of the system architecture scheme is physically reconstructed, enabling the physical components in the architecture scheme to be mapped to simulation models.

[0026] S42. Use Python scripts to convert the system architecture scheme IBD diagram into an AMESim system functional performance simulation model. Perform system functional performance simulation calculations and adjust the system architecture scheme based on the calculation results until the system design requirements are met.

[0027] The beneficial effects of this invention are:

[0028] (1) The system functions are generalized into one or more specific service solutions. The functions can be reused by repeatedly using the service solution, which reduces the manpower and time costs of system design and modeling, allowing designers to devote their energy to the research and development of more innovative technologies.

[0029] (2) By calling service solutions with the same or similar functions, the logical architecture design can be completed quickly, which greatly reduces the process of analyzing the functions and logical architecture of similar technical routes. Attached Figure Description

[0030] Figure 1 This is a flowchart illustrating the design of the present invention.

[0031] Figure 2 This is a diagram showing the requirements for the fuel subsystem.

[0032] Figure 3 This is a use case diagram for the fuel subsystem.

[0033] Figure 4 A schematic diagram defining the MOE (Metric of Performance) for the fuel subsystem.

[0034] Figure 5 A breakdown diagram of the "single-pump main oil transport" service scheme.

[0035] Figure 6 A schematic diagram of the service plan and system requirements traceability matrix for the fuel subsystem.

[0036] Figure 7 A schematic diagram illustrating the reconfiguration of the fuel system to serve fuel transportation demand.

[0037] Figure 8 A schematic diagram illustrating the uniqueness of fuel supply and transportation services for the fuel subsystem.

[0038] Figure 9 A schematic diagram defining the service definition for "single pump fuel supply to front compartment of No. 1 fuel tank".

[0039] Figure 10 A schematic diagram illustrating the dispatch of fuel supply and transportation services for the fuel subsystem.

[0040] Figure 11 This is an IBD diagram of the fuel delivery architecture for the fuel subsystem.

[0041] Figure 12 This is a flowchart for the joint simulation verification of the fuel system's functions and performance. Detailed Implementation

[0042] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0043] Example 1: Fuel subsystem architecture design based on service-oriented principles.

[0044] As attached Figure 1 As shown, this embodiment includes four main design steps:

[0045] S1, Requirements Capture and Analysis.

[0046] S2, Service Solution Design.

[0047] S3, Logical Architecture Definition.

[0048] S4, Physical Implementation Verification.

[0049] Specifically, in this embodiment, the S1 design step includes the following sub-steps:

[0050] S11, such as Figure 2 As shown, stakeholder requirements are visualized in the form of a SysML requirement diagram, and a traceability matrix between stakeholders and business requirements is established.

[0051] S12, as Figure 3 As shown, for the fuel subsystem business scenario, SysML use case diagrams are used to analyze the possible interaction behaviors between the target system and stakeholders, refine stakeholder requirements, and clarify system behavior.

[0052] S13, as Figure 4 As shown, the MOE (Metric of Performance) definition is completed based on system requirements and system behavior, and quantitative design indicators such as tank residual pressure, oil flow rate, and oil delivery time are identified as key performance indicators. Furthermore, the top-level system function definition is completed.

[0053] Specifically, in this embodiment, the S2 design step includes the following sub-steps:

[0054] S21, as Figure 5 As shown, based on the use case scenario of the fuel subsystem, service solutions are designed for the fuel supply and transportation functions, considering different fuel tank types. These service solutions are further decomposed into atomic service layers. A service solution activity diagram is established to logically verify its feasibility.

[0055] S22, as Figure 6 As shown, a refined relationship matrix is ​​used to establish a traceable relationship between service solutions and requirements, and a service solution coverage analysis is performed to identify which service solutions are used to refine a certain requirement.

[0056] S23, as Figure 7 As shown, based on the system's top-level service scheme, the top-level requirements are restructured using service-oriented architecture to improve the structural completeness of the design requirements. The service-oriented top-level requirements cover all requirement categories of a typical system.

[0057] Specifically, in this embodiment, the S3 design step includes the following sub-steps:

[0058] S31, such as Figure 8 As shown, based on the mapping relationship between service objects and service solutions, unique services are defined for each service object from a service perspective. "Front compartment of fuel tank 1" and "Single pump fuel supply" constitute "Front compartment of fuel tank 1 single pump fuel supply"; "Rear compartment of fuel tank 1" and "Single pump main fuel supply" constitute "Rear compartment of fuel tank 1 single pump main fuel supply"; "Fuel tank 2" and "Single pump auxiliary fuel supply" constitute "Fuel tank 2 single pump auxiliary fuel supply"; "Fuel tank 3" and "Single pump auxiliary fuel supply" constitute "Fuel tank 3 single pump auxiliary fuel supply". For services not in the service library, such as "Front compartment of fuel tank 1 single pump fuel supply", service definitions are made based on information such as function and components. Figure 9 As shown.

[0059] S32, such as Figure 10 As shown, service calls and service behavior control are implemented through the callable ports exposed by the system services. The system service behavior logic is simulated using an STM state machine diagram to optimize and iterate the system logic architecture.

[0060] S33, such as Figure 11 As shown, the IBD diagram is used to illustrate the fuel subsystem's services such as fuel supply and transportation, the interaction between various fuel tanks, the propulsion system, etc., and clearly present the system architecture scheme.

[0061] Specifically, in this embodiment, the S4 design step includes the following sub-steps:

[0062] S41 uses AMESim as the system performance analysis tool. Based on the mapping relationship between AMESim simulation models and physical components, a SysML basic model component library is constructed. On this basis, the IBD diagram of the system architecture scheme is physically reconstructed, enabling the physical components in the architecture scheme to be mapped to simulation models.

[0063] S42, as Figure 12 As shown, the IBD diagram of the system architecture scheme is converted into an AMESim system functional performance simulation model using a Python script. System functional performance simulation calculations are then performed, and the system architecture scheme is adjusted based on the calculation results until the system design requirements are met.

Claims

1. A method for forward design of a mechatronic system architecture based on the idea of service, characterized in that, Includes the following steps: S1, Requirements Capture and Analysis: Conduct requirements capture, system behavior analysis, and stakeholder analysis to clarify the boundaries and core objectives of system behavior; define key performance indicators based on performance metrics, complete the top-level system function definition, ensure that requirements are consistent with stakeholder expectations, and establish a requirements traceability baseline; S2, Service Solution Design: Propose corresponding service solutions based on the needs of the service recipients to achieve system function and performance allocation; decompose the service solutions to the component level to ensure that the needs of each component are strictly aligned with the overall system goals. S3, Logical Architecture Definition: Design logical interfaces and behavioral logic, clarify service interconnection relationships and system service matching and invocation mechanisms, and verify the collaboration and consistency between services; Through logical architecture analysis and iteration, we optimize interface definitions and behavioral logic to avoid potential conflicts. S4, Physical Implementation Verification: Based on the SysML model and the interface definition of the physical performance simulation component, the system logical architecture model is reconstructed into a system physical architecture model. Iterative optimization is carried out in conjunction with functional performance co-simulation until the system performance target is achieved.

2. The method of claim 1, wherein the method is characterized by: The S1 design step includes the following sub-steps: S11, Design Requirements Capture: Analyze stakeholder needs using model-based and detailed methods, visualize them in SysML requirement diagrams, and establish a traceability matrix between stakeholders and business requirements; S12, System Behavior Analysis and Stakeholder Analysis: For specific business scenarios, SysML use case diagrams are used to analyze the possible interaction behaviors between the target system and stakeholders, refine the needs of stakeholders, and thus clarify the behavioral boundaries and core objectives of the target system. S13, Performance Measurement Definition: Based on system requirements and system behavior analysis, complete the performance measurement definition, and based on the performance measurement, clarify the quantitative evaluation indicators of the system under specific operating environment and conditions, use them as key performance indicators, and further complete the top-level system function definition.

3. The forward design method for electromechanical system architecture based on service-oriented principles as described in claim 1, characterized in that, The S2 design steps include the following sub-steps: S21, System Function Performance Allocation: Based on the use case scenarios, analyze the system functions and decompose the system functions step by step to the smallest indivisible functional units according to the system complexity and modeling granularity; the service solutions corresponding to the smallest functional units can be decomposed into one or more atomic services; combine atomic services to form upper-level service solutions, establish service solution activity diagrams, and logically verify their feasibility. S22, Service Solution Traceability and Coverage Analysis: Use a refined relationship matrix to establish a traceable relationship between service solutions and requirements, conduct a service solution coverage analysis, and identify which service solutions are used to refine a certain requirement to ensure that no requirement is missed. S23, Service-Oriented Restructuring of Requirements: Based on the traceability relationship between requirements and service solutions, the description method, organizational logic, and granularity of requirements are reorganized, transforming requirements from function-oriented or document-oriented to service-oriented requirements; the restructured service-oriented requirements cover both functional and non-functional system requirement categories.

4. The forward design method for electromechanical system architecture based on service-oriented principles as described in claim 1, characterized in that, The S3 design steps include the following sub-steps: S31, based on the mapping relationship between service objects and service solutions, defines unique services for service objects from a service perspective, and searches for matching services from the service library based on service requirements; the service library stores relevant services of historical design solutions; S32 implements service invocation and service behavior control through the callable ports exposed by the system services. The ports exposed by the services are defined as "XX service call in" ports to control the services, and "XX service output out" ports to be used depending on whether the specific service sends a signal to the outside world. Based on this, the system service behavior logic is simulated with the help of STM state machine diagrams to optimize and iterate the system logic architecture. S33 uses an IBD diagram to illustrate the interaction relationships between services, service objects, and stakeholders, clearly presenting the system architecture solution.

5. The forward design method for electromechanical system architecture based on service-oriented principles as described in claim 4, characterized in that, In the S31 sub-design step, if there is no service in the service library that matches the service requirements, service design is required: use a BDD diagram to define the corresponding components as service component attributes, define the component value attributes of reaction performance parameters according to standard specifications or design experience, define the internal interaction of the service based on the material, control, and information interface relationships between components, and define the service behavior based on the service carrying function using an STM state machine diagram.

6. The forward design method for electromechanical system architecture based on service-oriented principles according to claim 1, characterized in that, The S4 design steps include the following sub-steps: S41 uses AMESim as the system performance analysis tool. Based on the mapping relationship between AMESim simulation models and physical components, a SysML basic model component library is constructed. On this basis, the IBD diagram of the system architecture scheme is physically reconstructed so that the physical components in the architecture scheme can be mapped to simulation models. S42, use Python scripts to convert the system architecture scheme IBD diagram into an AMESim system functional performance simulation model; conduct system functional performance simulation calculations and adjust the system architecture scheme based on the calculation results until the system design requirements are met.

Images