## 5 Related Work  
[PERSON] et al. conduct a literature review on the joint use of MBSE and MDAO in the early stages of development [26]. They come to three conclusions: First, there is a lack of confidence that the MDAO problem correctly represents the MBSE system model. Second, the MDAO formulation takes a non-negligible amount of time. At the same time, necessary information is already available in the MBSE system model. Third, MDAO solutions are rarely implemented in the MBSE system model. As reasons, the lack of expressiveness of the MBSE languages and high manual effort are indicated. [PERSON] et al. [50] link MDAO and MBSE using the three branches of approach, type, and tool for refining requirements. Thus MDAO is to be used already in the early phases of the requirement formulation. The approach stands for the fact that the MBSE triggers the MDAO execution and the MDAO results enrich the MBSE system model. The type describes a coupling of language and methodical level. On the language level, the description in the MBSE system model is extended by new stereotypes for requirements used for the MDAO formulation (e.g., solver, model accuracy, etc.). Methodically, five steps are proposed to read out these requirements from the MBSE system model and enrich them through MDAO. Papyrus and OpenMDAO are used as tools. The use case is the dimensioning of a drone battery. Reuse of models is not addressed, and the MDAO problem remains a black box for the system engineer. A further work [51] focuses on the refinement of requirements in MBSE by linking them to MDAO. For this purpose, tool interfaces between TTool, OpenMDAO, and UPPAAL-SMC are implemented. [PERSON] et al. [52] describe a framework for the joint use of MBSE and MDAO. The MBSE system model contains all the system specification information. MDAO is used to evaluate individual architectures. In the presented example, the MBSE system specification is enriched with MDAO input parameters, and these parameters are extracted and finally evaluated in MDAO. Finally, the MDAO results are fed back into the MBSE system model. The procedure is demonstrated in an aircraft application. The MDAO problem remains a black box in the MBSE system model. [PERSON] et al. [24] describe a linking of MBSE and MDAO using an architectural framework. In this context, the concept of a development system and a system of interest (SoI) is introduced. A development system is one of the supporting systems (simulation, MDAO, etc.) for the development of the SoI in different phases. It is proposed to use MBSE for the development of MDAO systems and thus accelerate the development of SoI. The MDAO system is formally described in structure and behavior by an MDAO system architecture. The MDAO system architecture is developed using an architectural framework consisting of ontology (nomenclature and terminology) and viewpoints (organizational, architectural, lifecycle, process, requirements). In this way, the so-called upstream engineering phases (system identification, specification, architecting), which are formalized by the MBSE, are linked to the downstream engineering phases (system synthesis and exploration), including MDAO. The definition of MDAO as an individual system establishes a vertical integration into the development of complex systems. So far, only high-level elements of this MBSE-driven approach to developing MDAO systems have been published. The reuse of existing development data and models of the system of interest was not described. It is not addressed how MDAO is executed and how the parameterization of the system of interest architecture is accomplished. [PERSON] et al. [53] describe the integration of SysML and the process integration and design optimization framework (PIDO) of the ModelCenter software. The integration allows to model analyses in SysML and to transfer and execute them one-to-one in the analysis environment. For this purpose, a tool-specific profile is presented, in which the considered models have to be embedded.