Evaluation of a Collaborative and Distributed Aircraft Design Environment, Enabled by Microservices and Cloud Computing

Presented in this paper are the outcomes from the evaluation of a distributed aircraft design environment, based on microservices and cloud computing. The evaluation was performed on a representative airframe-engine optimization case study, including the engine, wing aero-structural geometry, and high-lift devices. The (computational) design process involved multiple distributed design teams and design tools. The latter were implemented with different programming languages and deployed on the Azure cloud service. As a benchmark, the same case study was performed using the traditional email/document-based approach to design collaboration. Compared with the traditional collaboration, the cloud-based approach substantially reduced the time for design iterations between the design teams. This was mainly due to the fast remote access of models/tools on the cloud and automation of data exchange. Also, the exercise indicated that the cloud-based approach is more flexible with regard to orchestrating the computational workflows and optimization studies, while protecting the Intellectual Property (IP) of the collaborating partners.


Introduction
The design of complex systems such as modern aircraft involves the integration of multiple disciplines (sub-problems), such as aerodynamics, structures, propulsion, flight control, and so forth.The different disciplines require specialized Modelling and Simulation (M&S) capabilities, which are normally performed by distinct designers and design teams.Within this context, two major elements are required for an effective design collaboration between the different disciplines: 1) A mathematical framework for decomposition, orchestration, and coordination of the overall and sub-problems design: The overall design problem can be decomposed into various sub-problems, which form a hierarchical structure as illustrated in Fig. 1.Each sub-problem has its design variables, performance variables, constraints, and objective functions.Different sub-problems may be related by dependent inputs/outputs, shared, coupled variables, conflicting constraints, and competing objectives.These relationships highlight the challenges which the decision-making process faces to produce consistent, feasible, and optimal design solutions.
2) A collaborative environment for integration of different design tools and results: M&S for each discipline are implemented with different software, programming languages, and operating systems.In addition, the designers/teams may come from separate departments or even geographically distributed companies.The heterogeneous and distributed nature of different design tools (and their respective inputs and outputs) highlights the challenge to orchestrate these computing resources into an integrated workflow for design collaboration.
Regarding the first challenge, various distributed architectures [1][2][3][4][5] have been developed within the context of Multi-disciplinary Design Optimization (MDO) and several coordination methods [6,7] are proposed using the Set-Based Design paradigm (SBD).Research works to tackle the second challenge have focused on remote execution of models and organizing engineering capabilities using the service-oriented architecture [8].For instance, a Virtual Enterprise Collaboration Hub (VEC-Hub) [9,10] was developed in the VIVACE project [11] and a collaborative aircraft development framework is established in the AGILE project [12][13][14][15][16].In the recent APROCONE project [17], the MoSSEC standard [18] was employed for sharing Modelling and Simulation (M&S) information in a collaborative Systems Engineering Context.
Within the context of the COLBRI project [19], we have developed a cloud-based collaborative aircraft design environment: AirCADia Nebos [20].In this environment, different engineering capabilities are implemented as microservices, and deployed using commercial-off-the-shelf (COTS) technologies and cloud providers.

Fig. 1 Hierarchical structure of aircraft design problems
The research presented in this paper builds upon the study reported in [20] and extends it as follows: 1) In the previous test-case, FLOPS [21] and a separate FLOPS engine module were used to demonstrate the collaboration between airframe and engine design teams.In the new case study, the FLOPS engine module is replaced with more dedicated engine design tools developed at Cranfield University.
2) The workflow hierarchy is extended to two levels, including a lower level for high-lift devices, wing aerodynamics, structures, and engine components.In addition, the workflow The overview of the cloud-based design environment (AirCADia Nebos) is illustrated in Fig. 2.
In this environment, engineering capabilities are implemented as microservices, which form the backend of the cloud-based design environment.
A microservice can be regarded as an independent computer process for a specific task.There are three categories of microservices depending on their functionalities.The first category includes computational models and design tools, which are used to solve domain specific problems (e.g.aerodynamic analysis, weight estimation, engine cycle analysis, etc).The second category includes services to store and share project information, object models, and study results.The third category includes capabilities to orchestrate the workflow and to perform various studies, such as optimization, design space exploration, uncertainty quantification etc.These capabilities are inherited from a native version of AirCADia [22,23] and migrated to the cloudbased environment.Specifically, the communication between microservices and clients are based on Representational State Transfer (REST) Application Programming Interfaces (API) [25] and JavaScript Object Notation (JSON) files [26].This process is illustrated in Fig. 3 using remote model execution as an example (similar process can also be applied to access other microservices, such as optimization studies).Once the execution command is given, an HTTP POST request will be sent to the URL of this model.The body of this request is a JSON file, which specifies the values of the model's input variables.The model will then be executed on the cloud and an updated JSON file will be returned, which contains the values of the model output variables.It should be noted that the request, response, and the JSON files are formulated automatically without the involvement of the user.More details for the IT implementation can be found in [20].

Fig. 3 Remote model execution on the cloud 2.2 Storyboard for Design Collaboration
In design collaboration, multiple designers will be working simultaneously to perform the analysis in each discipline, as illustrated in Fig. 4.

Fig. 4 Storyboard of design collaboration between different designers
Each designer can create their model and add it to the library by providing an endpoint and specify the input/output variables of this model, as shown in Fig. 5(a).
The chief designer is able to oversee different design projects under their account and browse through relevant models from various domain designers.If a model is needed, the chief designer can request to add it into the integrated workflow, as shown in Fig. 5(b).This request needs to be affirmed by the domain designer as the owner of the model.
Once the access is granted, the chief designer can execute the integrated workflow and further define various studies, such as optimization and design of experiments.The results are then visualized with different plots for further decision making.All the operations above are performed with web-based user interfaces, and the microservices to support these actions are shown in the middle column of Fig. 4.
It should be noted that, some of the tasks (e.g., to grant the access to a model) are administrative and thus not necessarily performed by a designer/engineer.This storyboard serves only for demonstration of the case study and is by no means a predetermined process.In engineering practice, other actors and actions can be added into the collaboration.For instance, a project manager can be involved to make decisions on accessing Intellectual Properties (IP) and communications with domain designers.The airframe design problem starts with aircraft sizing, based on a set of Top-Level Requirements (TLRs), such as number of passengers, design range, take-off field length, landing field length, and approaching velocity.At this level, the target is to minimise the block fuel and the climb time, while maintaining the TLRs, by varying design variables such as wing reference area, aspect ratio, taper ratio, tail volumes, etc.During this process, no engine cycle analysis is performed, however sea level static thrust is also considered as a design variable to scale a rubberised baseline engine deck.This setup represents a practical scenario where the airframer has relatively limited knowledge on the engine (which hasn't been designed yet) but needs to start with a realistic guess at the outset.
The aerodynamic analysis, mass-fuel loop, component weight estimation, and mission performance were performed with the NASA Flight Optimization System (FLOPS) [21].The rubberised engine deck was produced by the Stanford University Aerospace Vehicle Environment (SUAVE) [27].This is because the FLOPS built-in engine module achieves relatively lower accuracy in modelling the state-off-the-art high bypass ratio turbofan engines.
After the wing planform geometry is frozen, two lower-level airframe subproblems are initiated which include high-lift devices design and wing aero-structural design.This process demonstrates the hierarchical and multi-fidelity context of a realistic industrial problem as discussed in Section 1.The analysis of high-lift design problem defines the dimensions of wing slats and flaps.ESDU models [28] are employed to produce maximum lift coefficients and (low speed) drag polars at different slat/flap deflection angles.These results are passed back to the FLOPS to perform more detailed take-off and landing analysis.The wing aero-structural design problem was performed with Michigan University's OpenAeroStruct (OAS) [29,30], which further optimise the airfoil twist, spar thickness, and skin thickness distributions along the wing.The outputs include updated wing structural mass and the high-speed drag polar, which are used to replace the results from the FLOPS built-in empirical models.With the updated results, the top-level aircraft sizing will be performed again.A few iterations are needed to ensure that all constraints are satisfied.The detailed optimization setups for the airframe subproblems are summarised in Table 4, Table 5, and Table 6 in the Appendix.
Once the airframe was finalised, the net thrust, auxiliary power and ECS air supply requirements for all (engine) design points are extracted from the FLOPS mission summary and transferred to the engine design team.For modern large turbofan engines, the cruise condition is considered as the engine design point, since this is the operating condition where the engine needs to present the maximum efficiency.A multi-point (3-point in this case) approach for engine cycle design optimisation is followed, and the most suitable engine cycle design is selected.After In this case study, the engine preliminary design optimization process is implemented with serval in-house tools developed by the Centre for Propulsion and Thermal Power Engineering in Cranfield University.In particular, the cycle analysis and engine sizing are performed with Turbomatch [31] and ATLAS [32], respectively.Both tools are integrated in the Engine Preliminary Design Optimisation System (EPIDOSYS) [33][34][35], which optimize the on-design cycle parameters to minimise the SFC and total engine weight, while meeting all aircraft requirements.
The detailed optimization setup for the engine design is summarised in Table 7 in the Appendix.
Once the engine is optimised, the engine deck, weight, and dimensions are passed back to the airframe design team to replace the original rubberised engine.As the engine is replaced, the mass-fuel loop and mission analysis need to be executed and this will lead to another iteration between the airframe and engine.
It can be noted that in this case study, each subproblem is formulated as a distinct optimization problem.As illustrated in Fig. 7(a), the subproblems are executed iteratively and the dependent variables are passed between different subproblems to produce a final integrated aircraft design solution.This is hereby referred to as a "local-to-local" approach.Such an approach is adopted in this case study to minimize code modification (of existing design tools) required for cloud migration, because some of the tools (i.e., EPIDOSYS) have inbuilt optimizers.
However, if the analysis modules inside each design tool can be decoupled from the local optimizer, a global optimization can also be formulated as illustrated in Fig. 7(b).Further comparison between the global and current "local-to-local" approach concerns the challenge of design coordination (as discussed in Section 1), therefore falls outside the scope of the current paper, which focuses on the evaluation of the cloud-based environment itself.

Fig. 7 Illustration of Two Optimization Approaches 4 Evaluation
The evaluation of the cloud-based design environment is presented from two perspectives.
The first perspective is the study results of each subproblem.The second perspective is a semiquantitative comparison with the traditional email-based approach.The optimization results of each subproblem are visualized using the web interface of AirCADia Nebos, as presented in Fig. 8, Fig. 9, and Fig. 10 (some labels have been enhanced for clarity).

Study Results
For instance, Fig. 8 illustrates the results of top-level aircraft sizing optimization.The scatter plot on the top left illustrates the objective space of block fuel and climb time, while the scatter plot on the top right illustrates the constraint space of take-off and landing field length.The combinatorial space of all the design and performance variables is visualised using a parallel coordinates plot [36] at the bottom, where each vertical axis is a dimension, and a polyline represents a point in the high-dimensional space.In these plots, the green, red, and blue colours indicate feasible, infeasible, and pareto-front solutions, respectively.The solution high-lighted with orange colour is the selected solution which is passed down to the lower-level optimization.The maximum lift coefficients, drag polar, and wing structural mass produced at the lower-level design problems are passed back to the FLOPS to update the mission analysis.The values of all design variables and revised thrust requirements are summarized in Table 2.With the thrust requirements, the results from engine optimizations are illustrated in Fig. 11 and summarized in Table 3.
A back-to-back comparison of the resulted engine annulus diagrams and weights between the two optimum engine cycle designs is presented in Fig. 12.The two engine models selected as potential candidates present a difference of +1.12% cruise SFC, -2.27% weight and -8.69% fan frontal area relative to the Model A -Red.These numbers are depended on the current set of assumptions and modelling approach.For example, for the engine weight estimation of such engines, the power gearbox (PGB) resulted in around 40% of the bare engine weight, while the fan module around 16%.Consider the iterations between airframe and engine optimization as illustrated in Fig. 13(a).
In the traditional approach, the airframe design team first needs to extract the thrust requirements from the mission summary in the FLOPS output file.These requirements are then forwarded to the engine design team, which needs to reformulate the requirements for execution of EPIDOSYS.From the output of the latter, the engine deck, weight, and size are produced and delivered back to the airframe design team.The engine data need to be reformatted so that it could be read by FLOPS for the next design iteration.Similar processes are also needed for the interfaces between the top-level aircraft sizing, high-lift system design, and wing aero-structural design, as well as between the level 2 engine cycle design and level 3 engine component sizing and weight estimation.In the benchmark study, one complete iteration of all the design tools (as shown in Fig. 6) can take up to a few hours.
On the other hand, the cloud-based environment enables automatic extraction and exchange of the results.Once the optimization study of a subproblem is finished, the corresponding output variables will be updated instantly in the cloud database and ready for execution of the next design tool in the queue, as illustrated in Fig. 13(b).Within the same amount of time, more design iterations could be performed between different design teams

Fig. 13 Traditional Email-based Approach vs Cloud-based Approach
Faster data exchange also enables better design assumptions and more efficient negotiation of design requirements.For instance, in the top-level aircraft sizing problem, the maximum lift coefficients and angles of attack for take-off and landing analysis need to be assumed in the first design iteration.These assumed values will become target/constraints for the lower-level high-lift design problem.If the assumed values are too optimistic, they may turn out to be non-feasible solutions in the high-lift design space.If that happens, either the top-level solution needs to be modified (i.e., by increasing the wing area), and/or the constraints need to be relaxed (i.e., by allowing longer take-off and landing field lengths).In the traditional approach, such a design change may be very expensive due to the time-consuming steps involved in iterations.As a result, large design margins should be applied to mitigate such risks.In the cloud-based environment, the studies can be quickly set up and re-executed.Therefore, the top-level designer could start with more optimistic assumption and avoid allocating too much design margins.If permitted, the designer from one design team can even directly execute the tools from other design teams to quickly access the feasibility of some design requirements.
Last but not least, the cloud-based environment also provides greater flexibility to orchestrate the studies.In the current implementation, the subproblems are solved on the airframe side first, from the top-level aircraft sizing to lower-level wing aero-structural design and high-lift design.
The execution of engine optimization is triggered after the airframe is frozen.As all the models are now easily accessed on the cloud, it is also possible to perform the iterations between the top-level airframe and engine optimizations first, then move into the lower levels.Such reformulation may introduce additional benefits on time efficiency and performance improvement.
However, comparison of different execution sequences is out of the scope of this paper and will be explored in our future research.

Conclusion
The The optimal solution is produced in a much shorter time compared with the traditional email/document-based design collaboration.The automation and easy assessment of design tools deployed on the cloud also provide more efficient negotiation between different design teams and flexibility to reconfigure the studies.As a result, excessive margins can be avoided In: AIAA SciTech Forum 2023, 23-27 January 2023, National Harbor, Maryland DOI: 10.2514/6.2023-1163 involves multiple domain experts to demonstrate a more representative and complex design scenario.The rest of the paper is structured as follows: Section 2 presents the proposed cloud-based design methodology, including an overview of the cloud-based design environment (AirCADia Nebos) and a storyboard of collaboration between different designers.Section 3 presents the specification of the design problem for evaluation of the cloud-based design environment.The optimization results and comparison between the traditional and cloud-based design collaboration are presented in Section 4. Finally, lessons learned from the case study, conclusions, and future work are outlined in Section 5.

Fig. 2
Fig. 2 Overview of the cloud-based design environment (AirCADia Nebos) The microservices are deployed on Microsoft Azure [24] and their endpoints are defined with the Uniform Resource Locator (URL).A microservice can be accessed remotely by another microservice on the cloud, or by a client (designer/expert) using the web-based Graphical User Interfaces (GUI), as listed on the right side of Fig. 2.

Fig. 5
Fig. 5 Creation of model and workflow in AirCADia Nebos

Fig. 6
Fig. 6 Schematic view of different sub-systems, models, repositories, and flows of variables selection of the optimum engine cycle, an off-design analysis is conducted to produce the engine performance over its operating envelop.The results are stored in an engine deck which contains the thrusts and Specific Fuel Consumptions (SFC) at different Mach numbers, altitudes, and throttle settings in tabular format.The actual thrusts at the Top-of-Climb (TOC) and End-of-Runway (EOR) are taken as 15% greater than the required values from the airframe design teams, accounting for potential failure modes.Using the engine cycle performance analysis, the mass flow, pressure, temperature, and fuel/air ratio (FAR) computed at each component station are used for the engine sizing and weight estimation.

Fig. 8
Fig. 8 Pareto fronts of top-level aircraft sizing Fig. 9 and Fig. 10 illustrate the results of wing aero-structural design and high-lift design, respectively, using the same colour scheme.Specifically, the parallel coordinates plots at the bottom of Fig. 9 are used to visualize the distribution of twist, thickness to chord ratio, spar thickness, and skin thickness.

Fig. 9
Fig. 9 Results of Wing Aero-Structural Design

Fig. 12 Engine
Fig. 12 Engine Models A & B Annulus Diagrams research work presented in this paper regards the development of an integrated and distributed aircraft design computational environment, based on microservices and cloud computing.The goal of such a computational environment is to enable the multidisciplinary design and optimization of complex systems through cloud-based collaboration which protects the IP of the stakeholders.It involves a number of design teams and design tools implemented in different programming languages, operating systems and deployed on different repositories.The evaluation of the cloud-based aircraft design environment is performed through a comparison with the traditional email/document-based design collaboration on a representative airframe-engine optimization case study.The storyboard of the cloud-based collaborationbetween airframe and engine designers is demonstrated with a focus on the flexibility to orchestrate and coordinate the execution of the computational workflows, while protecting the IP of the collaborating partners.The computational workflows are orchestrated to achieve an integrated "local-to-local" optimisation between the airframe and the engine designs.The main outcome of the case study is an optimal aircraft design solution, including the specification of the engine and a number of subsystems.

Table 2 Airframe Design Results and Thrust requirements
Maximum Engine Diameter []   * 1.8 Auxiliary Power Extraction [hp]   * 200 Bleed Air Mass Flow Rate [lb/s] ̇  * 1 Fig. 11 Results of Engine Design Optimization