Development of the Architecture of a Conceptual Design Tool for Manned and Unmanned Fixed-Wing Aircraft ^†

Abstract

Aircraft conceptual design is an iterative process that seeks to obtain a feasible design that meets a series of mission and configuration requirements. Starting with several guesses regarding the initial sizing and aerodynamics of the future aircraft, a first resulting general layout is found, which is then subjected to trade studies where initial assumptions are altered in search of a refined design. With the aim of enhancing design solutions and reducing time costs derived from calculations, the authors of the present paper have developed ARCADE (AiRcraft ConceptuAl DEsign Tool), a framework that automates, in multiple thematic modules, the steps and calculations needed for the conceptual design process of fixed-wing aircraft. This work presents the basis for the early architecture of ARCADE, developed in Python and focused on the use of data retrieved from existing aircraft for the first design hypotheses. Initial findings of the use of ARCADE show a small relative error between the first parameter guesses, made based on similar aircraft, and the results of the next design iteration, which are independent of reference aircraft. This suggests that the design parameters of the target aircraft are accurately guessed when using existing aircraft information for the initial estimations of this process.

1. Introduction

The aircraft design process is typically divided into three phases: conceptual design, preliminary design and detail design [1]. The conceptual design phase determines the general layout and size of a feasible aircraft concept that fulfils a set of required mission and configuration specifications. This first phase of aircraft design is a multidisciplinary iterative process that encompasses diverse calculation methods and supposes a high workload and time costs for designers. Since the costs associated with design modifications increase with the design phase [2], it is convenient to consider multiple design possibilities in the conceptual design stage. Computerized environments that automate the aircraft conceptual design process enable a rapid and streamlined application of this design phase, which allow designers to carry out fast comparisons of diverse design possibilities in search for the most sustainable solution. The development and application of aircraft design tools has extended in the last few decades and is present in both industry [3,4,5,6,7] and academia [8,9,10,11,12,13]. The aim of this work is to develop a new fixed-wing aircraft design framework that automates the conceptual design process following the methodological approach used by the DCAD (as per the initials in Spanish of Conceptual Design of Aircraft and Drones) research group of the UPM (Universidad Politécnica de Madrid), which is described in Figure 1. In this approach, existing aircraft are identified to obtain several guesses to estimate initial weights, design constraints for performance requirements, and the geometrical parameters of the aircraft components. After this initial sizing, component weights and the centre of gravity are obtained, alongside the aerodynamic characteristics and performance of the resulting design. Once the first iteration of this process is finished, results are fed back as inputs of the following iteration to find a converging design solution. The aforementioned design methodology has been applied in previous works of the DCAD [14,15], which support the aim of automating this conceptual design approach as a way to leverage, in future research, the comparative methods used in conventional aircraft design, to ease the analysis of possibilities that reduce environmental impact. The motivation to create a new and dedicated tool for the DCAD is also justified as a solution against the rigid design methods and opacity in the code of existing aircraft design frameworks, as mentioned in [10].

In this research, the development of the first version of the particular conceptual design tool of the DCAD, named ARCADE (AiRcraft ConceptuAl DEsign tool), is presented. Among the desired capabilities of ARCADE, it is expected that it covers the whole conceptual design process, avoiding the need to use proprietary software with no access to the source code or external programs that require some learning from the user to obtain the final solution. ARCADE should be able to generate a CAD (Computer-Aided Design) model of the geometry of the resulting aircraft. The architecture of the tool should be modular, following the current trends of the state of the art, to allow the addition of new analysis methods without altering the whole code. The first version of ARCADE automates the whole aircraft conceptual design process and is capable of obtaining a converged aircraft solution within minutes, reducing the resources needed for this design phase.

2. Materials and Methods

2.1. Architecture of the Tool

The main programming languages used in existing aircraft conceptual design frameworks are MATLAB, which is present in [8,10], and Python, in [4,5,6,11,13]. The programming language selected to develop ARCADE has been Python, due to its open source license and its variety of libraries and third-party modules that enable detailed programming of the characteristic multidisciplinary formulation of aircraft conceptual design, as well as the means to present the results and perform specific analysis. The code of the first version of ARCADE is written in Python 3.11 using a structured programming style, in contrast with the Object-Oriented Programming style used in [8,11].

The architecture of the ARCADE software consists of eleven modules and multiple databases. All modules are programmed in Python scripts, except for one, which is written in a JSON file, as the databases of the tool. JSON is a data-interchange format consisting of name/value pairs organized in lists [16] that resemble dictionaries. This structure allows the user to read and modify files, and it simplifies access to information from each module of the tool. The content of ARCADE modules is defined based on the typical aircraft design disciplines covered in the modular frameworks of the state of the art and the methodological approach followed by the DCAD. Figure 2 shows the execution sequence of the modules of ARCADE: Requirements, Similar Aircraft, Initial Weights, Design Point, Fuselage, Geometry, Landing Gear, Refined Weights and Centre of Gravity, Aerodynamics, Performance and Convergence. As it can be seen, this sequence matches the design methodology used by the DCAD (see Figure 1), except from the geometry step, which is separated in three modules: (1) Fuselage, since it is highly dependent on the mission, the payload and the kind of aircraft that the user aims to design; (2) Geometry, where the wing and tail are designed; and (3) Landing Gear. ARCADE modules are connected to one another through a JSON file called saved_aircraft, that stores the outputs of each module. The databases featured in the first version of ARCADE are dedicated to aircraft, engines and tyres. Additionally, ARCADE contains an original database, called Joker Values, that stores diverse reference parameters retrieved from the literature, systems manufacturers and airworthiness codes.

To meet the requirements of the DCAD, ARCADE also has an integrated architecture, as it includes two external tools: (1) OpenVSP 3.42.3, through its Pyhton API (Application Programming Interface) [17], which is used to generate the CAD model of the geometry of the target aircraft, and (2) XFOIL 6.99 [18], which runs from ARCADE and is used to find the aerodynamic characteristics of aerofoils. These tools are open-source and there is no need for the user to learn how to use them in order to use ARCADE, because the programming of the tool covers all required learning.

ARCADE does not have a graphic user interface yet, so it interacts with the user through the command window of the corresponding integrated development environment. To make the tool user-friendly, the code prevents and reacts to erroneous inputs.

2.2. Calibration of the Tool and Baseline Aircraft

Due to the level of detail in the design that it is expected to achieve with ARCADE, it has been necessary to use a previous aircraft design project from the DCAD [19] as a basis for the development of the tool. The reference project serves two purposes: (1) it is the baseline of the procedures and calculation methods to be implemented in ARCADE to reproduce the methodological approach of the DCAD; and (2) its information regarding design decisions and results is available to the authors of the present work, which allows the testing and calibration of the tool. The baseline aircraft project used for the development and calibration of ARCADE is an Unmanned Aircraft System (UAS) named SLV-1; therefore, the first version of ARCADE has been developed focused on the design of UAS. The layout of the SLV-1 is inspired by the General Atomics MQ-9 Reaper [20] and MQ-1 Predator [21], by Elbit Hermes 900 [22] and by TAI Anka [23]. These aircraft have a conventional wing configuration and a V-tail. The target mission of the SLV-1 is a surveillance mission with the characteristic range and endurance values of the MALE (Medium-Altitude Long-Endurance) category of UAS, and its powerplant is a piston engine with a pusher propeller.

2.3. Requirements Module

The Requirements module of the first version of ARCADE is a JSON file that acts as a form in which the user completes the relevant mission and configuration specifications of the target aircraft. The information filled out in this file will be the input data for the subsequent modules of ARCADE. The requirements of the SLV-1 [19] have been written in this file to test the capabilities of the tool.

2.4. Similar Aircraft Module

As previously stated, the design methodology followed by the DCAD focuses on the use of information from existing aircraft as initial guesses to estimate the design parameters of the target aircraft. To retrieve data that is relevant to the desired solution, the Similar Aircraft module of ARCADE defines metrics to establish similarity relations between different aircraft, in terms of range, endurance, mission purpose, powerplant and general layout. Based on these metrics, the tool identifies, within its Aircraft database, those aircraft that are similar in mission, configuration or both to the target aircraft. Among the aircraft by which SLV-1 [19] is inspired, all of them are similar in configuration to SLV-1; furthermore, MQ-9 Reaper and MQ-1 Predator are similar in mission as well.

The outputs of this module are reference parameters to estimate the initial weights and performance of the target aircraft. For the initial weights estimation, ARCADE determines a parameter that relates the $OEW$ (Operative Empty Weight) to the $MTOW$ (Maximum Take-Off Weight), which is either the ratio of both variables, $OEW$/$MTOW$, or a linear regression as suggested by Roskam [24]. Regarding performance, ARCADE obtains reference data that will act as initial guesses for the zero-lift drag coefficient, $C_{D0}$, Oswald efficiency number, $\phi$, specific fuel consumption of the engine, $SFC$, and lift-to-drag ratio, $L/D$. These parameters are retrieved as mean values of the identified similar aircraft. In case some information is missing, the required parameters are extracted from the Joker Values database.

2.5. Initial Weights Module

For the initial weights estimation in ARCADE, it is assumed that the $MTOW$ of the aircraft is composed of $OEW$, the $PL$ (Payload), and the $FW$ (Fuel Weight). This module of ARCADE solves the weight balance in the form of the sum of the ratios of these weights to the $MTOW$, also known as the unity equation [1], where the $OEW/MTOW$ is an output of the similar aircraft module, the $PL$ is retrieved from the Requirements file, and the the $FW/MTOW$ is decomposed as a sum of the fuel consumption of each flight phase. ARCADE identifies the segments of the design mission in the Requirements file and accordingly uses either fuel fractions suggested by Roskam [24] and stored in the Joker Values database, or the Breguet equation for the cruise phase, where the values of $L/D$ and $SFC$ are the ones guessed in the Similar Aircraft module. Since this first version of ARCADE considers two ways of obtaining the $OEW$/$MTOW$, the tool will get two results for the $MTOW$. User input is demanded in this stage to decide a $MTOW$ value and proceed with the calculation of the remaining initial weights.

2.6. Design Point Module

In the Design Point module, ARCADE calculates the design constraints, which are imposed by the performance requirements of the target mission. This module derives one equation for each performance requirement specified in the Requirements file, in the form of the power to weight ratio as a function of the wing loading, $P/W=f(W/S_w)$. Then, these equations are plotted together in a graph such as the one presented in Figure 3, which shows the design space of the case study [19], where the considered design constraints are take-off, landing, climb and two types of cruise (ingress to the target, and loiter or reconnaissance phase). To plot these constraints, some parameters are fixed based on hypotheses, requirements or similar aircraft, such as $C_{D0}$. Other parameters are swept within known intervals; namely, maximum lift coefficients at take-off, $C_{LmaxTO}$, and landing, $C_{LmaxL}$, are swept within ranges defined by Roskam [24], while wing aspect ratio, $AR$, and $W/S_w$ are swept within intervals defined based on similar aircraft.

Once the design space is found, the user must choose a design point in the acceptable design region. To do so, ARCADE asks the user to enter a value for $W/S_w$, which is used to identify compatible flaps, according to the values suggested by Torenbeek [25] and stored in the Joker Values database, and to stablish a search area, based on constraints intersections, of compatible engines within the Engine database. Then, the user selects one of the suggested engines in an interactive plot and introduces the desired $AR$. With these choices, the design point is found. For every decision, the tool checks whether inputs are consistent with the calculated design. If they are not, ARCADE restarts the user loop in the conflicting questions and asks the user to try again.

2.7. Geometry-Related Modules

The geometry-related modules of ARCADE seek to define and calculate the geometrical parameters of each element of the aircraft, and to generate a CAD model that represents these elements in accordance with their resulting dimensions. This approach is also found in the equivalent modules of existing frameworks, such as [8,10], which generate file formats compatible with CAD programs. ARCADE combines the design methodology used by the DCAD to define the main elements of the aircraft with the process that the user would have to follow in the desktop application of OpenVSP to generate this same geometry. The information needed by the API of OpenVSP to generate the desired aircraft sketch is retrieved by ARCADE through the user loop. These modules are very interactive, and ARCADE provides in them a guided design based on data from aircraft with similar layout to the target design. The user can decide whether to use the values suggested by the tool or to enter new ones.

In the Fuselage module, ARCADE reads the payload information specified in the requirements file and calculates the minimal dimensions needed to fit it in the payload bay. This module also allows the user to define the dimensions of the fuel tanks and to choose an aviation fuel from the Joker Values database to calculate the maximum fuel weight.

The Geometry module covers wing and tail design. The first version of ARCADE focuses on the initial sizing of trapezoid wings. Some geometric parameters of the wing, such as the $AR$ or the wing surface, $S_w$, have already been obtained in the Design Point module. Remaining parameters and aerofoil selection are user-defined. The design of ailerons and flaps is also included in this module. In case flaps are installed, ARCADE checks whether they meet the $C_{LmaxTO}$ and $C_{LmaxL}$ guessed in the Design Point module at a feasible deflection angle, according to the values proposed by Torenbeek [25]. For the tail design, functions to size vertical and horizontal stabilizers and V-tails, as well as their respective control surfaces, have been programmed.

The Landing gear module includes a survey for the user to define the desired landing gear arrangement. Aircraft and Tyre databases are used for the landing gear sizing.

2.8. Refined Weights and Centre of Gravity Module

The outputs of the geometry-related modules are used to determine a refined estimation of the $OEW$ and the location of the centre of gravity, $CG$ of the aircraft. The Refined Weights and Centre of Gravity module of ARCADE applies the empirical formulation introduced by Nicolai and Carichner [2] to calculate the weight of each aircraft component. The sum of these weights results in the $OEW$ of the next design iteration, since the $OEW$ of the current iteration was estimated in the Initial Weights module with data from existing aircraft. To obtain the location of the $CG$, ARCADE considers component weights and reference positions of the $CG$ of each aircraft element, retrieved from Sadraey [26].

2.9. Aerodynamics and Performance Modules

The Aerodynamics module focuses on the estimation of the trimmed drag polar by means of the model presented by Torenbeek [25]. This module runs XFOIL to get the aerodynamic coefficients of the selected aerofoil needed for each equation. The user can choose the flight condition in which the drag is analysed.

The Performance module of ARCADE obtains the maximum range and endurance of the resulting aircraft through the calculation of the respective optimum lift coefficients. ARCADE generates plots to present payload-range and payload-endurance diagrams.

2.10. Convergence Module

The Convergence module of ARCADE takes the outputs of the modules of each design iteration as inputs of the subsequent one. To simplify programming and achieve a faster convergence for the early architecture of ARCADE, this module leaves the user out of the feedback loop. Since geometry modules are very interactive, to achieve this independence from the user, it was decided to assume that the values of geometric variables determined in the first design iteration are constant in the following ones. Therefore, although its value is user-defined in the Design Point module, $W/S_w$ changes every iteration along with the $MTOW$. The feedback loops considered for this module of ARCADE take the results from Refined Weights and Centre of Gravity, Aerodynamics and Performance modules as inputs for the Initial Weights and Design Point modules (see Figure 1). The converged solution is found when both the following conditions are met, where i is the current iteration and $i-1$ is the previous one: (1) $MTO{W}_i=MTO{W}_{i-1}$, and (2) $|C_{D0,i}-C_{D0,i-1}|\le {10}^{-6}$.

3. Results and Discussion

3.1. CAD Model of the Aircraft

Figure 4 shows the resulting CAD model obtained by inserting the different CAD files generated by ARCADE in the desktop application of OpenVSP. As it can be seen, it will be necessary to manually smooth some surfaces in the desktop application of OpenVSP; however, most corrections have been automated in ARCADE, independently from the user, to get the desired geometry. This sketch meets the needs of the DCAD, since in this stage of the conceptual design process, a very detailed model of the aircraft geometry is not sought.

3.2. Design Convergence

It has been observed that ARCADE achieves $MTOW$ convergence within a small number of iterations, and that the ratio between the converged $MTOW$ and the first $MTOW$ guessed with similar aircraft is ∼1%. This suggests that the use of baseline aircraft provides accurate estimations for the final solution; however, said small difference was expected because most variables are considered constant in the feedback loops.

4. Conclusions

This work presents the development and calibration of the first version of ARCADE, a user-centred tool that provides an assisted design based on information from existing aircraft. The resulting framework is capable of automating the whole conceptual design process of fixed-wing aircraft and finding a converged solution within minutes. ARCADE also achieves a streamlined application of the design process by integrating external programs without the need for any further learning. The use of data from existing similar aircraft for the initial design guesses has proven to be useful and provides accurate estimations for the final solution, which reduces the number of iterations needed, as well as the derived time costs. The outputs obtained when testing the capabilities of the tool show consistency with the baseline aircraft. The main benefit of ARCADE is that it significantly reduces the associated workload and resources of the conceptual phase of aircraft design.

Regardless of the advantages achieved with the creation of ARCADE, this is an early architecture that still requires further development. The capabilities of this tool are limited due to the hypotheses and simplifications made to ease programming when taking into account user decisions. However, thanks to the modular architecture of ARCADE, most shortcomings will be easily addressed in its subsequent versions. The main tasks identified as future work for this framework are to broaden its scope to other types of aircraft, and to include an optimization module, following the current trends of the state of the art.