Requirement-Based Component Placement for Aircraft Design ^†

Abstract

In this paper, we present an approach to automate the evaluation and improvement of geometric requirements during preliminary aircraft design, specifically focusing on the complex integration of subsystems like fuel systems. Utilizing the Codex (COllaborative DEsign and eXploration) platform and its submodule codex-geometry, we use Semantic Web Technologies (SWTs) to create a domain-neutral, integrated data representation. The system checks for compliance with geometric constraints in order to reduce manual work in the design. Building on previous work for requirement evaluation, this current research expands the system’s capabilities to suggest improved component placements when geometric inconsistencies are detected. The capabilities of this approach are demonstrated in an example use case placing fuel system components. Furthermore, we explore the use case of design space allocation impacted by an uncontained engine rotor failure.

1. Introduction

Aircraft design is a complex and challenging process that involves multiple stakeholders from different domains. One of the key challenges in this process is the modeling and integration of geometric data. This is especially challenging for the integration of large subsystems like the fuel system into the aircraft, as it has a complex geometry and is highly integrated with the other subsystems of the aircraft. Many components from different subsystems have to be placed inside the available geometric space (which we refer to as the “design space”) without overlapping, while many different requirements (e.g., minimum distances between certain components) have to be taken into account.

Especially in the early phases of aircraft design, the different subsystems are still undergoing multiple rapid changes, each of which can cause the need to adapt the designs of other subsystems. Adapting to all these changes manually is a time-consuming and error-prone task for aircraft designers. Figure 1 shows an example for an inconsistency that can easily occur during this process. This paper presents an approach to assist designers with this task by automatically evaluating geometric requirements and suggesting improved component placements.

The goal of Knowledge-Based Engineering (KBE) is to capture and formalize expert engineering knowledge into computer-supported rules and models, enabling automated, repeatable, and optimized design and decision-making. KBE approaches can be used to model information in a structured way for multidisciplinary designs. They can provide highly specialized environments and languages which are fit to their respective domain of application. For the aerospace sector, ParaPy [1] and Desmo [2] are two commonly used KBE tools. Both of them model their data in a hierarchical model, which is created in an object-oriented programming language. Similarly, tools like Design Cockpit 43 [3,4] are based on the Unified Modeling language (UML) and also use an object-oriented approach. While this is effective when modeling a product and sub-products from the same domain, it can get complicated to use when integrating knowledge from different domains. In contrast, the use of Semantic Web Technologies (SWTs) [5] delivers a domain-neutral way of knowledge formalization as well as an easy and efficient integration of knowledge between different domains.

We implement our approach in the Codex (COllaborative Design and EXploration) framework [6,7,8], a highly collaborative KBE application which uses Semantic Web Techniques in order to avoid the above-mentioned problems. Codex, which is currently being developed at the German Aerospace Center (DLR), utilizes SWT to achieve domain-neutral knowledge formalization and data integration, reducing the effort required to integrate multiple domains into a single representation of the overall product. Thereby, engineering knowledge as well as design guidelines and requirements can be simultaneously incorporated. This can support aircraft designers to evaluate their drafts and to deduce additional suggestions for even more efficient designs, thus enabling them to concentrate on the creative part of their engineering tasks.

The submodule codex-geometry [9] provides an ontology describing primitive geometric shapes (like spheres, cylinder, curves, etc.) as well as transformations on shapes and operations between pairs of shapes (e.g., union, intersection, etc.), which in combination allow the user to model complex geometries. It also allows the user to define geometric requirements, which can be automatically evaluated by Codex using a declarative rule-based approach. codex-geometry uses the Open Cascade [10] technology and pythonOCC [11] in the background for the geometric computations. The codex-geometry module defines basic geometric requirements like “contained in”, “no overlap”, or “minimum distance”, and provides the implementation to check if these requirements are fulfilled. For domain-specific applications, domain experts can easily add their own ontologies, rules, and requirements for their respective domain.

Zamboni et al. [8] describe how to use Codex for the rapid generation of novel air vehicle configurations for combat aircraft design. In [12], codex-geometry has been used for modeling a liquid hydrogen tank and performing volume computations.

In our previous work [9,13], codex-geometry was extended for the automatic evaluation of geometric requirements, which was demonstrated using the example use case of an aircraft fuel system. For example, this application implements rules like “a boost pump has to be attached to the bottom surface of the tank”. As a result, a list of the failed requirements was returned. While this was already useful for detecting errors that might be hard to recognize otherwise, it still required designers to manually look for a solution for each failed requirement, implement it, and then run all the checks again.

In our current work, we use codex-geometry for modeling our geometric data and requirements to automatically check compliance with geometric, functional, and certification constraints. In contrast to previous work, the requirements are not only evaluated, but the system determines suggestions for automatic repositioning of components if conflicts are detected. Thus, it can save aircraft designers the tedious (and possibly repeated) step of manually finding an improved placement for the components.

The proposed system is particularly useful for handling complex geometries and geometric requirements from certification specifications and guidelines. While the approach is implemented in the Codex platform, it is possible to use it on designs created in other KBE tools or CAD platforms by importing the geometry into Codex as a .brep or .step file.

This paper is structured as follows: Section 2 introduces the idea of our approach on a very simple data integration use case. From this, we derive a set of “ground rules” for the suggested component placement. Section 3 explores a method to allocate a design space restricted by an uncontained engine rotor failure (UERF). Section 4 summarizes the paper and provides an outlook on our future work.

2. Rule-Based Component Placement

A common use case for our approach is the integration of geometric data from different sources, e.g., different departments designing different components of the aircraft. Especially in early design phases with their rapid changes, this task can be challenging and result in errors like in Figure 1, where two different components are placed such that an overlap occurs. For this use case, we assume that codex-geometry receives the geometric shapes for the wingbox (which is used as the design space) and for the two components “Pump” and “Probe”. Furthermore, we assume the following requirements to be defined:

1.

“Pump must be contained in design space wingbox”.

2.

“Probe must be contained in design space wingbox”.

3.

“Pump must have a minimum distance of 10 cm to probe”.

Codex-geometry will then automatically check the given requirements one by one. While the first two requirements can be verified, for the minimum distance requirement, an error will be detected, as the two components overlap. Based on this failed requirement, the system proposes to move the pump as shown in Figure 2. The required translation vector to ensure the minimum distance is computed by codex-geometry and suggested to the user.

It is important to note that, while this suggestion solves the failed requirement 3, it could be the case that, by moving the component, another requirement might be hurt, even if it has been verified before. Thus, all of the requirements have to be checked again after the movement. This process is repeated by the system until all requirements are verified and no component is moved.

Based on these considerations, we introduce the basic framework for placement suggestions. First of all, our current approach is based on local improvements, meaning that, for each failed requirement, the system proposes a change of placement in order to resolve this specific problem (this local approach may not lead to globally optimal results in the case of multiple conflicting requirements; however, assuming that the given placement is reasonable and that few requirements are hurt, it is a flexible approach to resolve these problems; comparing it to a global optimization approach will be part of future work.). This keeps the framework flexible, as it is straight-forward to add user-defined requirements and suggestions for specific domains. For each requirement type that is added, a rule has to be implemented to check if the requirement is fulfilled. Optionally, it can contain code for “resolving” a failed check by suggesting a change of placement for one of the components.

The suggested changes must follow the following ground rules and considerations:

• Only suggest changes for “Movable” shapes: For some shapes in the geometry it does not make sense to move them, e.g., the wing box that we consider as a given design space. If the requirement “Pump contained in wingbox” is hurt, it makes sense to move the pump, but probably not the wingbox. Therefore, codex-geometry allows users to mark components as “Movable”. Only components that are marked like this may be moved automatically by rules.
• Only suggest translations: Rules are only allowed to suggest translations for the given components; other transformations are not allowed. In particular, the size and shape of a component must not be altered, as they are defined by the respective domain experts and are important for the function of the component. Thus, the output of a rule must always be a translation vector.
• Max. number of movements: Using the proposed approach of local improvements, in the worst case, it can occur that a shape is moved back and forth indefinitely by different rules, especially if contradictory requirements are set. Therefore, the system allows to define a maximum number of allowed movements per shape, after which an exception will be made.
• Exceptions: For some requirements, it can be immediately determined that they are not fulfillable, e.g., a shape cannot be contained in a smaller shape. In these cases, rules may throw an exception and stop the reasoning immediately.

Currently, codex-geometry offers suggestions for the following built-in requirements:

• “Component A must be contained in design space B”: Provides a translation vector moving component A (if marked as Movable) into the design space, if possible.
• “Component A may not overlap component B”: Provides a translation vector moving component A (if marked as Movable) so that it does not overlap component B further.
• “Component A must have a minimum distance of x to component B”: Provides a translation vector moving component A such that the minimum distance to B is fulfilled.

However, the structure of the framework allows for easily adding custom checks [9] and the corresponding suggestions for the specific application. The computational performance of conducting these checks and generating suggestions affects the scalability of the approach. Other scalability factors are the number and interdependency of the requirements.

3. Design Space Allocation

In the previous section, we considered the placement of single components, assuming that some knowledge about the placement already exists in the form of requirements, e.g., “Component x should be contained in design space y”. In this section, we discuss the more general problem of design space allocation. The selection of the design space can be restricted by different requirements such as, e.g., safety-, maintainability- or performance-related requirements. For the application within this study, we consider the selection of the engine feed tank compartment in which the the engine boost pumps are placed. Each engine requires a separate feed compartment, and its boundaries need to be defined to minimize the impact of an uncontained engine rotor failure (UERF) [14]. Therefore, the hazard of “loss of thrust” by “damage to fuel feed” is addressed as isolated from other hazards caused by an UERF to determine the design space for this specific application. An UERF event in which the rotor disk segments puncture both feed compartments simultaneously would result in a “loss of thrust” since the remaining operating engine would be cut-off from the fuel supply. Within this study, the feed compartment is considered as a viable design space, if the probability of an UERF hitting both feed compartments is extremely improbable, which is in the order of $1\times {10}^{-9}$ [15].

A turbofan short-range aircraft from the DLR-internal project EXACT with the research designation D239 [16] is used as input for the use case. For the engine, a geared turbofan engine is assumed, comprising a low-pressure compressor (LPC) with three stages, a high-pressure compressor (HPC) with eight stages, a high-pressure turbine (HPT) with two stages, and a low-pressure turbine (LPT) with two stages. The geometric data of the aircraft structure, the engine and the fuel system components is stored in a central data model using the Common Parametric Aircraft Configuration Schema (CPACS) [17,18], which serves as starting point for the analysis within the Codex framework. The calculation of the trajectories of the rotor disk fragments is conducted as stated in [19] and takes into account the geometry and position of each rotor disk and blades. For this analysis, only the 1st/3rd rotor segments are considered, having a maximum spread angle of 3° to showcase the approach. The results of these calculations are shown in Figure 3 and

Table 1. Probabilities $P_{\mathrm{geo},i}$ of a combined fuel compartment hit in the case of an uncontained rotor failure for different engine parts: low-pressure compressor (LPC), high-pressure compressor (HPC), high-pressure turbine (HPT) and low-pressure turbine (LPT).

Engine Part	Stage	Comp. 1	Comp. 2	Comp. 3	Comp. 4	Comp. 5
LPC	1	0.0%	0.0%	0.0%	0.0%	0.0%
	2	0.0%	0.0%	0.0%	0.0%	0.0%
	3	0.0%	0.0%	0.0%	0.0%	0.0%
HPC	1	0.83%	0.63%	0.48%	0.12%	0.0%
	2	1.27%	0.95%	0.67%	0.36%	0.0%
	3	1.63%	1.27%	0.87%	0.44%	0.0%
	4	1.94%	1.55%	0.95%	0.40%	0.0%
	5	1.94%	1.55%	1.07%	0.52%	0.0%
	6	2.38%	1.90%	1.07%	0.60%	0.0%
	7	2.38%	1.87%	1.31%	0.67%	0.0%
	8	2.74%	1.98%	1.27%	0.67%	0.0%
HPT	1	3.25%	2.62%	1.94%	1.39%	0.00%
	2	3.29%	2.74%	2.02%	1.43%	0.12%
LPT	1	4.13%	3.33%	2.90%	2.30%	1.11%
	2	4.44%	3.77%	3.29%	2.50%	1.43%
	3	4.68%	4.13%	3.33%	2.86%	1.67%

.

Figure 3 shows the output of the trajectory calculations in Codex from different perspectives. Only trajectories are displayed that hit two symmetrical compartments simultaneously. In Figure 3b, the possible feed compartments are displayed and numbered, which will be used for referencing below.

In Table 1, the probability $P_{\mathrm{geo},i}$ (probability that compartment i is hit by an uncontained engine failure of the respective stage) is given for every stage and every compartment. It can be noted that the inner compartments (and their symmetric counterparts) are hit with a higher probability than outer compartments. The engine stage with the highest probability hitting both compartments simultaneously is the last stage of the LPT, since it has the largest diameter (disk and blades) and the spread angle includes all compartments. The LPC of the engine does not contribute direct hits in the case of an UERF.

In order to estimate an initial guess for the criticality of the design space allocation, the probability $P_{\mathrm{tot}}$ of a simultaneous hit of both feed compartments per flight hour (1/FH) is calculated:

$$P_{\mathrm{tot}}=n_{\mathrm{eng}}·P_{\mathrm{eng}}·P_{\mathrm{geo}}=n_{\mathrm{eng}}·P_{\mathrm{eng}}·{\displaystyle \frac{1}{n}}{\displaystyle \sum _i^n}{P}_{\mathrm{geo},i}$$

(1)

with the number of engines $n_{\mathrm{eng}}$, the probability of an UERF of one engine $P_{\mathrm{eng}}$, and the geometrical probability $P_{\mathrm{geo}}$ of the trajectories hitting both feed compartments simultaneously. $P_{\mathrm{eng}}$ is determined by summarizing each stage i and dividing by the number of stages n.

Summarizing the $P_{\mathrm{geo}}$ for the whole engine, the probability spans from 2.18% for compartment 1 to 0.27% for compartment 5, which can be obtained from

Table 2. Geometric probability $P_{\mathrm{geo}}$ in % and total probability $P_{\mathrm{tot}}$ in 1/FH of a combined fuel compartment hit in cases of an uncontained rotor failure for the engine or aircraft, respectively.

Probability	Comp. 1	Comp. 2	Comp. 3	Comp. 4	Comp. 5
$P_{\mathrm{geo}}$	2.18%	1.77%	1.32%	0.89%	0.27%
$P_{\mathrm{tot}}$	$1.31\times {10}^{-8}$	$1.06\times {10}^{-8}$	$7.95\times {10}^{-9}$	$5.34\times {10}^{-9}$	$1.62\times {10}^{-9}$

. These values are used to calculate $P_{\mathrm{tot}}$ using an UERF rate of 0.3 per million engine operating hours [20]. Referring to the requirement of an UERF simultaneously hitting both feed compartments being extremely improbable (a factor of two could be considered as “on the order of” $1\times {10}^{-9}$ to show compliance with regulation [15]), only compartment 5 can be considered a viable design space. Hence, the compartment is declared as the design space for our considered components in Codex. This can now be formalized as requirements like “Pump must be contained in design space compartment 5”, which are then evaluated by the approach described in Section 2.

4. Conclusions and Outlook

This paper presents a rule-based approach for the verification and improvement of geometric designs based on user-defined geometric requirements. This approach was implemented using the semantic web-based KBE platform Codex. Its capabilities were demonstrated on a data integration use case as well as the design space allocation impacted by an UERF.

The application of rule-based component placement in aircraft design has the potential to speed up the design process by reducing the time and effort required for geometric design tasks. By leveraging advanced knowledge-based engineering tools and Semantic Web Technologies, we can create a more efficient, effective, and scalable design process that can accommodate the increasing complexity of modern aircraft designs.

Suggesting improved component placements is an important step towards an automated design. While the current approach suggests local improvements to the design by proposing a better placement for single components, the next step for our future work will be to automatically suggest a placement for a set of components that comply with all given requirements. Additionally, we plan to extend our methodology to accommodate more complex geometries and requirements.