-
PDF
- Split View
-
Views
-
Cite
Cite
Moritz Neumaier, Stefan Kranemann, Bernd Kazmeier, Stephan Rudolph, Automated pipe design in 3D using a multi-objective toolchain for efficient decision-making, Journal of Computational Design and Engineering, Volume 11, Issue 5, October 2024, Pages 77–98, https://doi.org/10.1093/jcde/qwae070
- Share Icon Share
Abstract
Pipe design in 3D is typically characterized by competing objectives, since the different design objectives, such as the reduction of length, weight, number of bends, manufacturing cost, and overall angle sum, are examples for such competing design goals, where one goal is often at the expense of the other. The origin of these competing design goals lies in the highly coupled problems of finding a permissible and collision-free pipe path in a complex 3D geometry and the physical properties of the path found. Because of the complex physics and geometry, these couplings are highly non-linear and mostly accessible via simulation only. The underlying pipe design optimization problem can thus not be solved explicitly and is tackled instead with a multi-disciplinary search procedure. Since the trade-offs between different competing evaluation objectives are often not known in advance, an automated design space exploration can be performed to generate different pipe designs, leading to well-informed design decisions by human experts. Such a design space exploration is shown and discussed using the pipework in a mounting rack in an Airbus A320 main landing gear bay. A total of 144 valid designs are generated, out of which the best in each criteria and the pareto-optimal solutions are automatically selected. Compared to the manually created Airbus A320 series solution, up to |$10.4\%$| of the pipe length or up to |$16.9\%$| of the bends can be saved using the same fixings and connection points, demonstrating both the feasibility and the industrial applicability of the automated toolchain.

A multi-objective automated pipe design toolchain was developed using design languages.
The toolchain can be used to perform a machine-executable design space exploration.
An exemplary execution is shown on the pipework in an Airbus A320 mounting rack.
1 Introduction
Besides the main goal to design according to the requirements a technically sound and excellent product to be competitive in global markets, the design decisions have also a significant influence on the overall life-cycle costs. After the concept and detailed design phases, only up to 20% of the actual costs have been spent, but already 80% of the total life-cycle costs have been determined. Additionally, the correction of a design error later in the production phase can be a thousand-times more expensive than the correction in an early design stage (SE Handbook Working Group 2011) three phases earlier, also known as the ‘Rule of Ten’ (Padfield 2015). It is thus most advantageous to come to well-informed decisions for a design solution as early as possible, i.e. at best already in the early design stages where changes are still cheap.
Hydraulic pipe design is usually characterized by different competing objectives. One example for this is the pipe design shown in Fig. 1, in which the circular obstacle as well as the connection points and tangents are the same for both variants. The variant (a) has only one bend, but the pipe is longer, while the variant (b) is shorter but has a bend more. Which variant fits better depends on the design context and can be influenced by many different criteria, even from different domains. Different sub goals like the length and the mass, the costs for the raw materials or the manufacturing time, which influences the manufacturing process planning, can play a decisive role.

All these distinct interdependencies are often not known in advance or, if they are known, the importance of the different objectives is not precisely known. It is therefore difficult to search automatically for the best fitting solution. Since the required information is only available during the system development process, one way to shorten the development time is to make different variants available for analysis and later selection. It can also support the development process if new variants can be made available in a very short time as requirements change.
In the current industrial process, pipe design is still a time-consuming and manual task. Different requirements have to be fulfilled, while competing objectives have to be weighted against each other. Therefore, it is often not possible to design many variants to analyse them. In this situation the automation of the design process can help to reduce the development time and additionally to increase the quality of the solution.
It has to be distinguished between pipes with bends with discrete bend angles and pipes with continuous bend angles. This distinction is mainly driven by the manufacturing process but also has a significant influence on the algorithms used to automize the process. As hydraulic pipes in aircraft are manufactured in a rotary draw bending process [see VDI3430:2014-06 (2014) for details], the approaches discussed here are designed for pipes not limited to discrete bend angles or bend positions.
A first proof-of-concept of the technology is already described in Neumaier et al. (2022) and is summarized in Section 1.1. Subsequent to the creation of the proof-of-concept solutions, different shortcomings were identified which hampered the automated generation of many different solutions for a design task. In this paper the difficulties and possible solutions are presented. The focus is on the specific challenges when designing an automated pipe design software. The related works and research questions are presented in Section 2.
1.1 Existing proof-of-concept: automated piping in an airbus A320 landing gear bay using graph-based design languages
In Neumaier et al. (2022) the basic methodology for automated pipe design, which this paper refers to, is described. The approach is based on graph-based design languages that are compiled and executed by a design compiler, in this case the Design Compiler 43® developed by IILS mbH (2023). Figure 2 shows the example of a mounting rack located in an Airbus A320 main landing gear bay.

The fixings shown in green were taken from the series solution, and the pipes shown in orange were generated. The overall pipe design process can be summarized in the following seven steps:
Import of the obstacles and the connection list together with the specific settings
Creation of offset surfaces to ensure a minimum distance of the pipes to the obstacles
Pathfinding to find the shortest path through the installation space (the path is described as a spline, and the interaction between the pipes is neglected)
Generate initial pipe design solutions consisting of discrete straights and bends in alternating order
Optimizing different pipe design variants using simulated annealing optimization while taking user-weighed evaluation criteria into account
Verification of the final result in terms of collision-free pipes
Export of the result as STEP-File and as associated bend tables
In the optimization process different evaluation values, like length and number of bends, can be used to assess the quality of a pipe path. These evaluation values can be weighted by a user to represent the trade-offs between them. In this way, a user can influence the result.
1.2 Toolchain overview
In Fig. 3, an overview of the toolchain discussed in this paper is shown. It starts with an incoming big black arrow and ends with an outgoing one. The methods and algorithms used without modification from Neumaier et al. (2022) are set in regular font type face, the ones which were improved or extended are shown in italic font and completely new developed parts are underlined. The overall toolchain is highlighted by a dark green frame (). It contains the sub-toolchain for the automated pipe design, highlighted in light green (
), the main topic discussed in Neumaier et al. (2022). This sub-toolchain can be executed simultaneously to evaluate different sets of evaluation weights (see Section 3.2.1). The central part of it is the simulated annealing optimization based on the algorithm proposed by Kirkpatrick et al. (1983), which is shown in very light green (
). It can be executed simultaneously for pipe path variants with different start values and numbers of bends so that the desired optimum can be found despite an initial approximate estimation of them.

Overview of toolchain partitioning (legend: regular font |$\, =\,$| no substantial change, italic font |$\, =\,$| improved or extended, underlined |$\, =\,$| new).
2 Related Work and Research Questions
For a well-founded decision on a specific pipe design, the various target criteria must be weighed up and the corresponding variants must be drawn up. In order to keep the effort required to create the variants as low as possible, automated solutions were presented by different authors, which are discussed below.
2.1 Literature review
Different approaches for the pipe design automation were presented in the past. An extensive literature review was done by Blokland et al. (2023). The presented methodologies can be divided into two categories. One approach is the routing between discrete points, e.g., on a grid, and another is a continuous routing without this limitation. Independently from this, the different procedures differentiate in the obstacle avoidance technology, the interaction between the pipes, the available optimization criteria, the runtime, the ability to route branches and to take manufacturing constraints into account. Some of the approaches are selected and are summarized here in the following.
Qu et al. (2016) present a pipe routing approach for aero engines using a modified max-min ant system optimization algorithm, which takes the length and the number of bends into account. To reduce the runtime, an adaptive octree is used to divide the installation space. The octree cells are categorized into white (i.e. no collision with obstacles), grey (i.e. partly colliding with an obstacle), and black (i.e. collides with an obstacle). The routes are described as sequence of octree nodes and the bends are created by rounding the edges. A parallel routing can be done which makes it possible to define the positions of the branches automatically.
Yuan et al. (2021) use a visibility graph together with an A* algorithm to find possible routes. Since the routing is performed on the surface of an aero engine, the routing problem is considered as 2D. The obstacles are represented by regional grids. Also the sequencing rules of the pipe laying process is discussed. Also a method to decide which pipes should be routed in parallel and how to achieve this, is described.
Ji et al. (2022) did extensive research on how to avoid vibration already by adequately designing the pipe. An exemplary optimization of a single pipe by adjusting the length of a straight part, considering the minimal straight length given by the manufacturing process, is shown.
2.2 Open research questions
The approaches described in the literature have been used so far to generate a small number of variants. However, to be able to make a well-founded decision, a large number of variants is required, which gives rise to questions that play only a subordinate role in the generation of individual variants. However, these must be dealt with to obtain a generic toolchain that can be used on a large scale. In the following section these questions as well as the implementations of their respective solutions are presented.
3 Steps Towards an Applicable Process Chain
There are different facets which have to be addressed to get a generic automation solution. Like any other extensive software project different methods and design rules, like the usage of design patterns and automated testing, should be followed. This is the basis to be able to research domain specific methods and implementations as this ensures that the software behaves as expected. Since the research on software design and implementation is not limited to automated pipe design and extensive research was already done in the past on this topic, this will not be discussed. The paper therefore addresses primarily the methodical aspects of automated pipe design. The domain specific aspects are discussed on the example of Neumaier et al. (2022) described and in Chapter 1.1 summarized methodology to be able to use it in a more generically and comprehensively way.
The new or improved methods are used in both areas of the overall toolchain. Firstly, the actual automated pipe design has been improved (Section 3.1), and secondly, the overall toolchain, which in turn utilizes it, has been significantly expanded (Section 3.2).
3.1 Automated pipe design
This section focuses on the improvements in the methodology for the automated generation of a single pipework variant.
3.1.1 Repeatability
The repeatability guarantees that for the same evaluation weight setting the exact same result is found if the algorithm is rerun. This is necessary to evaluate the influences of different evaluation weight settings, otherwise it would not be apparent if a difference between two results is based on the difference in the evaluation weight settings or just on randomness.
The optimization of the pipe paths is carried out with a simulated annealing algorithm. This algorithm is a stochastic algorithm which relies on random numbers to decide if a worse solution should temporarily be accepted. Furthermore it is useful if the bends are moved to different positions to generate new variants. An easy way to achieve this is by ensuring an equal distribution of the used positions within a given interval created using random number generators. Using a true physical random number generator in the algorithm would, even with identical start values, possess only a tiny chance of yielding the same result when re-executing the whole workflow. Pseudorandom number generators generate a number series using a mathematical formula and a start value, the so-called seed. If the seed is set to the same value the ‘pseudo random’ number series is always the same. Nevertheless, the numbers are equally distributed. In Java, the class java.util.Random is available, which accepts a seed. The algorithm used within the class was proposed by (Knuth, 1997, section 3.2.1). The seed determination needs to be based on values which are not runtime dependent like the start- and endpoints and the respective tangents.
3.1.2 Preparation: grid
To reduce the runtime (Section 3.1.6) and for a new evaluation criterion called density (Section 3.1.5), a grid is created. Since it is independent of the pipes, it can be created in advance. The creation of the grid may become computationally expensive because of the necessary collision detection thus the result is stored. This grid consists of cuboids with diagonal lengths in a user-defined range. An exemplary grid is shown in Fig. 4a. For better visibility the diagonals of the grid are twice the size than in the grid used to generate the solutions shown in Fig. 10.

To simplify the density calculation, it is beneficial that the cuboids are approximately cubes. The grid is constructed as octree except for the second node layer. This layer is constructed so that the subsequent cuboids are approximately cubes. Generally speaking the overall axis aligned bounding box has not the shape of a cube, which necessitates this. In Fig. 4b, such a structure is illustrated. The root node, shown in cyan, which has not the shape of the cube, is divided into smaller cubes (shown in grey). Every cube is divided into eight smaller, equally sized cubes. This subdivision is continued until the requested cube size is reached.
During the optimization, the cuboids close to the pipe are selected. The selection of the cuboids is illustrated in Fig. 5, where the pipe tendon is drawn in red, the cuboid containing the startpoint is filled in yellow, the one containing the endpoint is filled in brown, and the close ones are filled in green. Suppose the midpoint of the cuboid is closer to the pipe tendon than the half diagonal of the cuboid it gets selected. As a result of this also cuboids, which are not intersected by the pipe tendon, can be chosen. This is illustrated by the orange lines in Fig. 5, which are drawn orthogonal to the pipe tendon and connect it with the central point of a cuboid. The shown orange lines are shorter than the half diagonals of the cuboids, as a result of this the central points are close enough to the pipe tendon that the respective cuboids are selected. As the selection is primarily used for collision detection this can be accepted as it leads to a more conservative evaluation.

3.1.3 Start values: creation of initial pipe variants
For iterative optimization approaches start solutions need to be known. The closer the starting solution is to the optimum sought, the faster it can be found. Inferior start-up solutions can even lead to no good solution being found. A generic, thoughtful process starts with a shortest part estimate, as shown in Fig. 6, is therefore a first building block for a successful automated pipe design system. Even for simple environments, an estimate where a pipe should be placed is challenging, as this depends on the obstacles, the weightings of the evaluation criteria as well as on the other pipes. If the obstacle landscape includes bottlenecks or holes, this estimation gets even more complex. For the estimation of the initial pipe paths, the shortest paths through the installation space shown in Fig. 6 are used for a first basic approximation. Each path is available as an ordered list of points, as the underlying pathfinding [see Eheim et al. (2021) for details] is done on a regular grid, connected by splines for the display.

The bends are spread around the paths. The first and the last bends are limited in their positions as the start and the end tangent have to be satisfied, the other bends can be placed in |$\mathbb {R}^3$|. Additionally it has to be ensured that the pipe path is valid concerning the limitations of the bending machine, like the bend angles and the minimal straight length between the bends.
However, the shortest path through the installation space can still contain additional clues about where bends can most sensibly be placed. To determine these positions, the list of points describing the shortest path is thinned out step by step until only as many points are left as bends are desired. In Algorithm 1, this is shown as pseudo-code. It is iterated over all points and continuously calculates for three points how much shorter the path would be if the centre point were removed. The point at which the deviation is slightest is then removed in each case. This is repeated until the desired number of points is reached. One exemplary pipe connection with the corresponding trace reduction is shown in Fig. 7.


Shortest path through the installation space: trace reduction.
3.1.4 Routing sequence
All pipes, which can possibly collide, are depending on each other. If all pipes would be routed simultaneously in every optimization step all distances between every pipe need to be calculated. For n pipes, this would lead to
calculations. Since the calculations are computationally expensive (see later the runtime evaluation in Section 3.1.6) this would lead to unreasonable long runtimes. If the pipes are laid in sequence for n pipes, only
calculations need to be done in every simulation step. As an example, this means that for 15 pipes, only 14 instead of 91 distance calculations need to be done. The drawback of this method is that a routing sequence must be defined. For this purpose, the expected volume of every pipe connection is calculated using the shortest path through the installation space (step three in the in Section 1.1 described process) and the pipe radius. A sequence of the pipe connections is determined by ordering them ascending or descending by the expected volume. In Fig. 8, the influence of the sequence is illustrated.

If the pipe connections in the example in Fig. 8 are routed in an ascending order the pipes have lesser bends, if they are routed in descending order the pipes are shorter in total.
3.1.5 Pipe path modification: adaptability
In Section 3.1.3 it is described why a prior estimation of the best positions for the bends is not feasible. The same problem also arises when different pipes should be routed in a narrow installation space. An academic example for such an installation space is the plate in Fig. 9 with four holes.

Figure 9 also shows the initial pathfinding for the automated pipe design process. The pathfinding searches for the shortest boundary collision-free connection path but neglects collisions between the paths. In this initial stage, the paths themselves are made of splines and not of alternating straights and bends, as the pipes will be later on. It is obvious that a priory estimation, which pipe should be routed through which hole or around the plate, cannot be done easily. The decision where a pipe should be routed needs thus to be made by the algorithm at runtime. As a result, it needs to be possible to move a pipe between holes, or more general gaps, during the optimization process. Additionally, a measurement is necessary to spread the pipes over the available installation space efficiently.
As a new optimization objective, the so-called density was introduced. It is calculated in every simulation step how much of a cuboid is filled, e.g., a cuboid which is colliding with the installation space is filled with |$100\%$| as well as a cuboid filled from a pipe. This can lead to densities above |$100\%$|, which indicates an overfull area. Based on these values the optimization algorithm can move pipes in lesser occupied areas and therefore distribute them over the available installation space. The usage of the evaluation values is described in Section 3.2.1. The benefit of this methodology compared to evaluating collisions between different pipes as well as the pipe and the obstacles (which nevertheless needs to be done in a subsequent step of the optimization to ensure the correct minimal distances) is that the denser populated areas are prioritized in the process of distributing the pipes.
In Fig. 10 automated pipe design results are shown for 1–15 pipes. It can be seen that the holes are used as well as the possibility to route pipes around the plate.

3.1.6 Runtime pipe path evaluation
The importance of the runtime depends on the problem’s complexity and the available computational capacity. For small examples, which are running on a laptop within seconds, often no performance optimization is required. With increasing problem size the computational demand, e.g., in terms available RAM, as well as the runtime increases. Even if computational capacity is available the usage still costs money and needs energy.
In an empirical study the runtime influences for generating the pipes shown in Fig. 10 were studied. The pipes were generated on a computer equipped with AMD Ryzen 7 3700X and 64GB RAM. It has to be taken into account that for the runtime measurement the simple difference of system time stamps were used. The results are shown in the diagram in Fig. 11. It can be seen that not only the runtime increases with an increasing number of pipes, as more calculations for the collision detection between the pipe and the obstacles are necessary, also the runtime per pipe increases. A plausible explanation may be that with an increasing number of pipes, the number of distance calculations between pipes also increases. Both suggest that the main driver for the runtime is the pipe path evaluation.

Distance calculation pipe |$\leftrightarrow$| pipe. The distance calculation between two pipes has a high influence on the runtime, therefore a computational inexpensive methodology is preferred. On the other hand a coarse approximation cannot be used as this would lead to an increased demand on installation space which can lead to problems at bottlenecks or gaps.
Every pipe consists of alternating straights and bends. To calculate the distance between two pipes, the distance between the pipe tendons can be calculated. The pipe tendon of a straight is a line segment, and the tendon of a bend is an arc. As the distance calculations point |$\leftrightarrow$| line segment and line segment |$\leftrightarrow$| line segment are widespread problems, they are not discussed. For the distance calculations point |$\leftrightarrow$| arc, line segment |$\leftrightarrow$| arc and arc |$\leftrightarrow$| arc an approximation approach was developed. The calculations of point |$\leftrightarrow$| line segment and point |$\leftrightarrow$| arc are necessary to calculate if a start- or endpoint is the closest point.
Distance point |$\leftrightarrow$| arc. The distance of a point to an arc is calculated iteratively. In Fig. 12a, the initial state is shown. The arc is shown in red, and two auxiliary planes (shown in blue and black) are introduced. The planes are positioned to intersect the centre point and the start- (blue plane) or endpoint (black plane) of the arc. The normal of the planes are the same as the start tangent or respectively the end tangent of the arc. As a signed distance of a point to a plane can be calculated, different states can occur:
the point is considered on one of the planes (distance is smaller than a given value): the smallest distance can be calculated as the distance between the point and the intersection point of the arc and the plane
the distance to both planes is negative: the closest point on the arc is the start point, which can be used for the distance calculation
the distance to both planes is positive: the closest point on the arc is the endpoint, which can be used for the distance calculation
the distance to both planes does not have the same sign: the closest point on the arc has to be calculated

Using the signed distances leads to a function where the position of the zero can be sought. As a result, it can be searched for a plane that intersects the centre of as well as the arc itself, whose normal is the same as the tangent on the intersection point of the arc and the point. This can be done iteratively utilizing the bisection method or, more efficiently, by regula falsi as described in Munz & Westermann (2018). In Fig. 12b, the addition of a third plane is shown. In every iteration, a new plane is added. The iteration stops if the point is considered in the plane (state 1).
Distance line segment |$\leftrightarrow$| arc and arc |$\leftrightarrow$| arc. .For the distance calculation of line segment |$\leftrightarrow$| arc and arc |$\leftrightarrow$| arc the arc is discretizised by one or more line segments. As a result, the methods for the distance calculations of point |$\leftrightarrow$| line segment and line segment |$\leftrightarrow$| line segment can be applied.The approximation of the red arc by two black line segments is shown in Fig. 13. The approximation error is drawn in orange. For a given maximal approximation error E, the required number of line segments |$n_{ls}$| for an arc with radius |$r_b$| and opening angle |$\alpha$| can be calculated as follows:
At least one approximation line segment must be defined. If more line segments than required are used the accuracy is increased but, as more distance calculations are necessary, the runtime also increases.

Collision detection. The grid described in Section 3.1.2 is used to accelerate the collision detection. For that, the minimal distance of the midpoint of every cuboid to the obstacles and if the cuboid collides with an obstacle is calculated in a preprocessing step. Based on the distance of the cuboid midpoint to the obstacles, whether the cuboid collides with an obstacle and the pipe radius (with an additional, optional safety distance) it is evaluated if the pipe is collision free.
In Fig. 14, an exemplary grid for the mounting rack is shown. For better visibility the cuboids diagonals are five-times the size than in the grid used to generate the solutions shown in Section 4.

Due to the computational effort to create the grid the cuboids cannot be infinitesimally small. This induces an error in collision detection, which depends on the size of the cuboids. A mesh–mesh collision detection is far more expensive than the approximated approach, therefore the mesh–mesh collision detection is only used to verify the collision freeness of the final solution.
3.2 Automated generation of multiple variants
This section focuses on the improvements and the extensions of the methodology to be able to execute the automated pipe design methodology multiple times to obtain automatically a multitude of variants.
3.2.1 Setting of the evaluation weights
For every optimization problem an evaluation function needs to be defined to be able to order different solution variants by their quality. The evaluation function to calculate the evaluation value v for a pipe path based on i evaluation values used in this approach reads as follows:
For each instance of an evaluation criteria the value |$v_i$| is calculated as follows:
For every criterion, the value |$x_i\in \mathbb {R}_0^+$| is calculated in every optimization step. The factor |$f_i \in \mathbb {R}^+$| and the power |$p_i \in \mathbb {R}^+$| have to be set for each. By selecting the factor and the power, the result can be influenced.The factor |$f_i$| and the power |$p_i$| influence the result in different ways. The factor has a linear influence, while the power can penalise large values for |$x_i$| disproportionally. A more detailed explanation of the structure of the evaluation function can be found in the appendix on page 93.
Different evaluation value types, which can also be used more than once, are available:
Length of pipe
Aperture of bends
Number of bends
Boundary violation
Distance to the path through the installation space
Minimal distance between two bends
Density
Distance between pipes
The values reflect the trade-offs of the different criteria, as a result of this the value set is often problem or at least domain specific.
Manual setting. The weights and powers for the evaluation settings can be set manually. This is particularly useful when just a small study with only a handful of variants or small adaptions should be made.
Automatic setting: design space evaluation. It is often not known in advance how the trade-off of the different criteria should be carried out, and therefore it is impossible to define all factors and powers in the first attempt. The manual setting of the values is a time-consuming task as the results have to be analysed iteratively and then the changes have to be made. A possibility to overcome these difficulties is to shift the workload from the user to a server. This can be done by automatically generating different value sets and the corresponding designs from which the user can select the best-fitting one. This leads to an increasing demand on computation time by reducing the time required to adjust the input manually.
Since the allowed values for |$f_i$| and |$p_i$| are only limited by definition on the lower end (values below zero are not allowed and a value of zero actually neglects the criteria) a range, which should be evaluated, needs to be defined by the user. This also reduces the design space to meaningful variants. Nevertheless the number of variants which can be generated is limited due to the available computational resources. Depending on the runtime for one variant it can be calculated how many variants can be generated. Together with the desired number of evaluation criteria, a method to settle the values can be selected.
The question of how this can be done appropriately for the given problem is independent of whether it is an actual experiment or a simulation. In order to create meta-models, special measurement points must be chosen. The quality of the model depends on these points. Various methods have been developed for this purpose and an overview can be found in Liu et al. (2018). Three approaches have been implemented and are discussed below.
Random. If many designs can be evaluated the values can be distributed randomly within the design space. This has the advantage that the generation of the value sets is easy and that the number of designs can be increased sequentially. The drawback is that for covering a multidimensional design space a great number of points are necessary, which is computationally expensive.
Design of experiments. A design of experiments study can be used to find a response surface to estimate the behaviour of the result based on the evaluation value settings. Often, models of second or third order are used. For a full factorial study for a second order model |$2^{2i}$| and a third order model |$3^{2i}$| designs for i evaluation criteria need to be created. When a factorial plan is used, the question arises about selecting which points can be omitted. For tasks where the edges of the design space are not interesting or challenging to reach, the Box–Behnken–Design proposed by Box & Behnken (1960) can be used. This approach can be used for a few evaluation criteria or if many experiments can be conducted.
MiniMax. It is not always possible to realize the generation of the necessary number of designs for a random distribution or a design of experiment study. In this case, the MiniMax design proposed by Johnson et al. (1990) can be used. The great advantage of this method is that it works for any combination of number of evaluation criteria and number of designs to be created. In a MiniMax design, the distance between the two furthest points in the design space is minimised. This covers the design space evenly while preferentially positioning the points within the space rather than on the edges. The distribution of the points is carried out in the unit hypercube, and these are then transformed in each dimension to the respective interval of the associated evaluation criterion. In Fig. 15, two exemplary distributions are shown. For the generation of the value sets used in this paper, the package minimaxdesign (Mak 2021) of the statistics package R, which implements Mak & Joseph (2018), was used.
![MiniMax designs in ${[0,1]}^2$.](https://oup.silverchair-cdn.com/oup/backfile/Content_public/Journal/jcde/11/5/10.1093_jcde_qwae070/12/m_qwae070fig15.jpeg?Expires=1749665498&Signature=C4V71iBeaDKDJcty4cLJ-nitab528DFCjXozT8nR9wBVkWSqjQmt8m2sOw-EmLyL1U70VobgKp87WmLNEl4WMlvBnFf-FqZbcZTbACzrc~-2bZPGtSTdeYnGMgLTFlvyq2mW6vW8BMokb6sH4FHq1YunUDI79SJKXznCokiI3gElQawc0~68iCgqxFYPNgGQmXMVjD8N2sLnQ-5ilXqtE8gII94ly6qK0XJDRlDhmZCMNilnmAqbZWEVnE0xOLmAWUeVGRQ5EZ13Y~ntzvirVq2qJoYqpI00~6qPeZEFXej6klNwnU6~QZhj4CkIebC2xsaHPQuFvvNEFBPpNSnvPw__&Key-Pair-Id=APKAIE5G5CRDK6RD3PGA)
3.2.2 Result assessment
With an increasing number of results the assessment of these becomes more and more time consuming. As a result of this not only the pipe design needs to be automated, but also the assessment of the results. Different aspects need to be considered:
Collection of result values of different solutions
Selection of valid solutions
Illustration of the results to allow a fast overview
Easy access to get a fast impression of a single result
Methods to assist the assessment The goal of the pipe design automation is to enable a user to make a well-founded decision for the best fitting pipe design for a given task. If all trade-offs were known in detail in advance, an additional assessment at this stage would not be necessary. The settings of the evaluation weights (see Section 3.2.1) would lead directly to the desired solution. But it often happens that these trade-offs are not explicitly known, the final assessment must thus be carried out by a user. This also needs to be done if not all requirements or trade-offs, as discussed in Section 6, are part of the optimization process.
To assist this decision process, it is necessary to present the pipe design results in a sufficient way. Since designs with different evaluation weights can be run in parallel in the first step, all result values, like length, number of bends, etc., need to be collected. For documentation purposes, these are stored in an Excel sheet. Out of these collected results, the invalid ones need to be removed. A pipe design is considered invalid if a collision is found or a pipe is unreasonably long compared to the other solutions for the same connection. For that purpose a statistic for every pipe is created and if a pipe is longer than the average length times a user defined factor the pipe is considered invalid. These filtered results are shown in diagrams.
A selection of the best fitting design based on numbers and diagrams is possible but often it is helpful to be able to inspect the solution visually. For every result the bend tables and STEP-files are stored that can be viewed in a 3D-CAD-System. The drawback of this approach is that every solution needs to be loaded manually which is time consuming. To avoid this and to get a fast first impression, a workflow to render every solution in Blender was developed. After creating the desired scenes the solutions are rendered fully automatically and this way a lightweight, easy accessible illustration is available.
Preselection methods. Despite that the selection of the best fitting solution is problem depending some generic preselection methods can be offered to assist this process.
Best solutions in each dimension. The overall best design for each parameter [length, number of bends, necessary number of bending jaws (if the straight length is too short the bending machine is not able to grab the pipe; if this is the case a bending jaw must be used in which the specific shape of the bend-straight-bend combination is milled), angle sum, and number of bends out of range] can be selected. This selection is not necessarily unique.
Pareto optimal solutions. In a multi-objective optimization, like the pipe design, there is often no overall best solution. Typically a trade-off between different target criteria needs to be done. The Pareto optimal solutions are the ones where an improvement of one criteria leads to worsening another criteria. This Pareto optimal set can be calculated for two or more criteria at once, described in the appendix on page 93.
4 Exemplary Execution of the Toolchain: Mounting Rack in an Airbus A320 Main Landing Gear Bay
The capabilities of the toolchain are demonstrated on the pipework in a mounting rack in an Airbus A320 main landing gear bay. For this real-world installation space 24 pipe connections shall be designed, which are hold by 36 fixings (if one fixing geometry holds e.g., two pipes it is counted as two fixings). The series solution is shown in Fig. 16, and the corresponding values are included in Table 2. Additionally to the number of bends and the length of the pipes the accumulated bend angle and if the bend angles are within a range of |$[20^\circ ,120^\circ ]$| is of interest. The overall bend angle influences the manufacturing time on the bending machine together with the awaited pressure drop. While a range of |$[5^\circ ,160^\circ ]$| is allowed for the bend angles, it is beneficial for the reliability of the bending process if the angles are within a range of |$[20^\circ ,120^\circ ]$|.

4.1 Determination of the evaluation value weights
For this study an evenly exploration of the design space was favored. This ensures that the following result interpretation is not distorted by unintentionally missing designs. Otherwise it would not be apparent if gaps in the result plots are justified by the problem (e.g., bottlenecks in the design space where only a limited amount of pipes can be routed within) or by the selection of the evaluation weights. This is achieved by selecting the evaluation value weighting sets with the MiniMax approach described in Section 3.2.1. A total of 120 sets were created. For each set the piping algorithm was executed with the pipe connections ordered ascending and descending by the expected volume of the pipes (see Section 3.1.4), which leads to an overall number of 240 executions.
A significant advantage of this approach is that no interaction with the user has to take place during the creation of the variants. In addition, the variants can be created independently of each other, which makes it possible to carry out the calculation in parallel, even on several computers or servers.
4.2 Results
The results are shown in Figs 17 (page 87) and 18 (page 88). Of the 240 created results 144 were considered valid, which is a fraction of |$60\%$|, nevertheless for all 240 evaluation weight settings results were created. The designs were created on a workstation equipped with an AMD Ryzen 7 3700X and 64 GB RAM, as well as a server equipped with AMD EPYC 7502P and 256 GB RAM. [Both computers used Debian 10 as operating system. On the workstation a graphical user interface (KDE Plasma) was available whereas the server was run headless. Execution under Microsoft Windows would also be possible.] On the server the pipe designs for four evaluation value sets could be generated simultaneously. Each pipe design took about 8 h to be generated. As the result space is 6D (length, number of bends, angle sum, number of bending jaws, number of bends out of range of |$[20^\circ ,120^\circ ]$| and the index of the variant), the values for every variant are shown in different plots where three dimensions can be compared at a time. The indices of the variants are assigned in order of the respective overall length.


Through the multitude of solutions, trends can be identified for this concrete example. For example, a reduction in the overall length has to be paid for with more and more bends, while at the same time, the number of bends outside the desired range is also increasing. This is to be expected, since with an increasing number of bends the shortest path can be approximated better and better, but this has to be done with bends of smaller and smaller bending angles. The opposite effect can be seen in the number of out-of-range bends versus the number of bends. The smaller the absolute number of bends, the fewer out-of-range bends are required. Compared to the series solution all pipe designs are shorter, while 142 of the 144 valid ones have less bends.
4.3 Optimal solution selection
The selection of the optimal, i.e. best fitting, solution is problem depending. The described preselection methods in Section 3.2.2 are applied on the 144 valid designs for the mounting rack.
4.3.1 Best solution in each dimension
One could select a design which is best in one of the criteria. These solutions are shown in Fig. 19 (as for 122 of 144 designs no bending jaw is necessary, it was waived to show an extra example for this). To manufacture the pipes shown in Fig. 19 no bending jaw is needed. The characteristic values for these solutions are given in Table 1.

Variant . | Length . | Number of bends . | Angle sum . | Bends out of range . |
---|---|---|---|---|
V001 (*) | 22707.25 mm | 128 | 4709.9|$^\circ$| | 49 |
V134 (![]() | 23196.37 mm | 103 | 4813.2|$^\circ$| | 29 |
V047 (![]() | 22924.70 mm | 112 | 4592.0|$^\circ$| | 36 |
V101 (![]() | 23107.24 mm | 103 | 4685.2|$^\circ$| | 26 |
Variant . | Length . | Number of bends . | Angle sum . | Bends out of range . |
---|---|---|---|---|
V001 (*) | 22707.25 mm | 128 | 4709.9|$^\circ$| | 49 |
V134 (![]() | 23196.37 mm | 103 | 4813.2|$^\circ$| | 29 |
V047 (![]() | 22924.70 mm | 112 | 4592.0|$^\circ$| | 36 |
V101 (![]() | 23107.24 mm | 103 | 4685.2|$^\circ$| | 26 |
Variant . | Length . | Number of bends . | Angle sum . | Bends out of range . |
---|---|---|---|---|
V001 (*) | 22707.25 mm | 128 | 4709.9|$^\circ$| | 49 |
V134 (![]() | 23196.37 mm | 103 | 4813.2|$^\circ$| | 29 |
V047 (![]() | 22924.70 mm | 112 | 4592.0|$^\circ$| | 36 |
V101 (![]() | 23107.24 mm | 103 | 4685.2|$^\circ$| | 26 |
Variant . | Length . | Number of bends . | Angle sum . | Bends out of range . |
---|---|---|---|---|
V001 (*) | 22707.25 mm | 128 | 4709.9|$^\circ$| | 49 |
V134 (![]() | 23196.37 mm | 103 | 4813.2|$^\circ$| | 29 |
V047 (![]() | 22924.70 mm | 112 | 4592.0|$^\circ$| | 36 |
V101 (![]() | 23107.24 mm | 103 | 4685.2|$^\circ$| | 26 |
Compared to the series solution all best solutions in a single dimension are shorter, up to 10.4% of the overall length can be saved. The solution with the smallest number of bends has 21 bends less, which means a reduction of 16.9%. This can be achieved even though the same connection points and fixings are used, whereby many design decisions have already been made due to their positioning. This shows the great potential offered by automated exploration of the design space. All comparisons are shown in Table 2.
Variant . | Length . | Divergence . | Number of bends . | Divergence . |
---|---|---|---|---|
Series S. | 25355.62 mm | – | 124 | – |
V001 (|$\ast$|) | 22707.25 mm | |$-$|2648.37 mm | 128 | +4 |
V134 (![]() | 23196.37 mm | |$-$|2159.25 mm | 103 | |$-$|21 |
V047 (![]() | 22924.70 mm | |$-$|2430.92 mm | 112 | |$-$|12 |
V101 (![]() | 23107.24 mm | |$-$|2248.38 mm | 103 | |$-$|21 |
Variant . | Length . | Divergence . | Number of bends . | Divergence . |
---|---|---|---|---|
Series S. | 25355.62 mm | – | 124 | – |
V001 (|$\ast$|) | 22707.25 mm | |$-$|2648.37 mm | 128 | +4 |
V134 (![]() | 23196.37 mm | |$-$|2159.25 mm | 103 | |$-$|21 |
V047 (![]() | 22924.70 mm | |$-$|2430.92 mm | 112 | |$-$|12 |
V101 (![]() | 23107.24 mm | |$-$|2248.38 mm | 103 | |$-$|21 |
Variant . | Length . | Divergence . | Number of bends . | Divergence . |
---|---|---|---|---|
Series S. | 25355.62 mm | – | 124 | – |
V001 (|$\ast$|) | 22707.25 mm | |$-$|2648.37 mm | 128 | +4 |
V134 (![]() | 23196.37 mm | |$-$|2159.25 mm | 103 | |$-$|21 |
V047 (![]() | 22924.70 mm | |$-$|2430.92 mm | 112 | |$-$|12 |
V101 (![]() | 23107.24 mm | |$-$|2248.38 mm | 103 | |$-$|21 |
Variant . | Length . | Divergence . | Number of bends . | Divergence . |
---|---|---|---|---|
Series S. | 25355.62 mm | – | 124 | – |
V001 (|$\ast$|) | 22707.25 mm | |$-$|2648.37 mm | 128 | +4 |
V134 (![]() | 23196.37 mm | |$-$|2159.25 mm | 103 | |$-$|21 |
V047 (![]() | 22924.70 mm | |$-$|2430.92 mm | 112 | |$-$|12 |
V101 (![]() | 23107.24 mm | |$-$|2248.38 mm | 103 | |$-$|21 |
4.3.2 Pareto optimal solutions
The length, the number of bends, the angle sum, the number of necessary bending jaws and the number of bends out of the desired range are the five dimensions which can be used to determine a Pareto front. Different Pareto fronts are calculated: The 2D Pareto front based on length and number of bends, the 3D Pareto front based on length, number of bends and the angle sum and the 5D Pareto front based on all five criteria mentioned in the beginning. These Pareto fronts are illustrated in Fig. 20.

Figure 20a can be seen as the top view of Fig. 20b, whereby the same 3D front is shown in both. The higher dimensional fronts, which are projected into two dimensions in Fig. 20a, only seem to go through the point cloud as they consider more objectives (a detailed discussion for which can be found in the appendix on page 93). The 5D front consists of 34 Pareto optimal solutions which can be found in Fig. A2 in the appendix.
4.3.3 Exemplary design selection
A variant can be selected from the available variants, which becomes the final result. One result candidate is exemplarily chosen in the following. Since 122 of the 144 variants do not require a bending jaw, it was decided to choose one of these designs to avoid unnecessary manufacturing effort. Since the length (and thus the mass) and the number of bends are the most important criteria, a variant that is part of the Pareto front determined in Section 4.3.2 was selected. In addition, it is desirable if the new solution found automatically is better in both criteria than the manually generated series solution. Since an improvement in one criterion goes hand in hand with a deterioration in another, it makes sense not to choose a variant at the edge of the Pareto front. It should be good in all criteria and not excellent in one and comparatively poor in the others. As the length and the number of bends are more important than the sum of the angles and the number of bends outside the desired range, a variant was selected that considers this. For the above reasons, V026 was exemplarily chosen as the most suitable candidate for the given task. The pipework has a length of 22822.1 mm, 108 bends, a bend angle sum of |$4597.5^\circ$| and 33 bends have a bend angle out of the range of |$[20^\circ ,120^\circ ]$|. This design is shown in Fig. 21, in the previous diagrams this solution is represented by a blue times sign (|$\times$|).

In Table 3 the solution and the best solutions in each dimension are compared to the selected variant V026. The potential savings are significant. The series solution is 11.1% longer and has 14.8% more bends compared to the selected variant, or expressed the other way round, 10% of the length and 12.9% of the bends can be saved compared to the series solution.
Variant . | Length . | Number of bends . | Angle sum . | Bends out of range . |
---|---|---|---|---|
Series S. | 11.1% | 14.8% | – | – |
V001 (*) | |$-$|0.5% | 18.5% | 2.5% | 48.5% |
V134 (![]() | 1.6% | |$-$|4.6% | 4.7% | |$-$|12.1% |
V047 (![]() | 0.5% | 3.7% | |$-$|0.1% | 9.1% |
V101 (![]() | 1.2% | |$-$|4.6% | 1.9% | |$-$|21.2% |
Variant . | Length . | Number of bends . | Angle sum . | Bends out of range . |
---|---|---|---|---|
Series S. | 11.1% | 14.8% | – | – |
V001 (*) | |$-$|0.5% | 18.5% | 2.5% | 48.5% |
V134 (![]() | 1.6% | |$-$|4.6% | 4.7% | |$-$|12.1% |
V047 (![]() | 0.5% | 3.7% | |$-$|0.1% | 9.1% |
V101 (![]() | 1.2% | |$-$|4.6% | 1.9% | |$-$|21.2% |
Variant . | Length . | Number of bends . | Angle sum . | Bends out of range . |
---|---|---|---|---|
Series S. | 11.1% | 14.8% | – | – |
V001 (*) | |$-$|0.5% | 18.5% | 2.5% | 48.5% |
V134 (![]() | 1.6% | |$-$|4.6% | 4.7% | |$-$|12.1% |
V047 (![]() | 0.5% | 3.7% | |$-$|0.1% | 9.1% |
V101 (![]() | 1.2% | |$-$|4.6% | 1.9% | |$-$|21.2% |
Variant . | Length . | Number of bends . | Angle sum . | Bends out of range . |
---|---|---|---|---|
Series S. | 11.1% | 14.8% | – | – |
V001 (*) | |$-$|0.5% | 18.5% | 2.5% | 48.5% |
V134 (![]() | 1.6% | |$-$|4.6% | 4.7% | |$-$|12.1% |
V047 (![]() | 0.5% | 3.7% | |$-$|0.1% | 9.1% |
V101 (![]() | 1.2% | |$-$|4.6% | 1.9% | |$-$|21.2% |
5 Summary
An overall toolchain for the automated pipe design process has been presented. It was mainly focused on the aspects that had to be tackled to come from a proof-of-concept of the approach to the overall toolchain. These are the repeatability, the creation of initial pipe path variants as start values for the optimization, the routing sequence, the adaptability, the runtime, the setting of the evaluation weights and the result assessment. These topics became relevant to create a large number of variants effectively, but also to process and assess them.
To examine different influences, the algorithm must work deterministically although a stochastic optimization procedure is used. The initial variants of the pipe paths influence how quickly and whether an optimum is found, so for the creation of these, a generic, geometrically motivated approach was presented. The order of the pipe connection during the optimization has a significant influence on the result, especially in narrow installation spaces, so a further setting option was added. The adaptability to narrow installation spaces was improved by adding a density criterion as an optimization parameter. A background mesh was introduced for this purpose. This mesh is also used to shorten the runtime in the collision calculation. Furthermore, methods were developed to calculate the distance between two pipe sections efficiently. Since the trade-offs between the different evaluation criteria are often not known in advance, approaches were investigated to search the design space efficiently and uniformly. Since the improvements allow a large number of designs to be created automatically, it was apparent to also partially automate the assessment to facilitate the selection of the most suitable result.
The pipework in a mounting rack in an Airbus A320 main landing gear bay was used to demonstrate the capabilities of the toolchain. A total of 144 valid designs were generated. Out of these designs the best design, respectively, in terms of length, fewest bends, smallest angle sum and smallest number of bends out of the desired bend angle range of |$[20^\circ ,120^\circ ]$| and the Pareto optimal solutions are automatically selected. Additionally, the characteristic values of all designs are shown in different diagrams.
Compared to the manually created series solution, up to |$10.4\%$| of the pipe length and up to |$16.9\%$| of the bends can be saved. This can be achieved even though the same fixings and connection points are used as in the reference solution. Because these positions are already fixed, many design decisions have already been made, and the piping can only be changed within narrow limits. The execution of the toolchain was finished by selecting a variant which is 10% shorter and has 12.9% fewer bends than the series solution. These potential savings, together with the large number of variants that can be evaluated, demonstrate the automation power of this approach.
6 Prospects
The discussed approach has the ability to reduce the development time by simultaneously increasing the quality of the designs. Nevertheless, different aspects concerning the overall methodology and the evaluation criteria could be addressed in the future.
6.1 Visibility graph to generate initial solutions
Automated pipe routing can also be done by using visibility graphs. A visibility graph connects the edges of the obstacles as well as the start and end points of the pipes. This allows the shortest connection through the installation space to be determined on the graph. A simple example is shown in Fig. 22.This graph could help to find short initial solutions. Further research needs to be done if this preprocessing can improve the quality of the initial solutions adequately. This should lead to a reduction of the runtime that is higher than the additional construction and the routing on the graph. This especially needs to be investigated for artificially complex installation spaces.

6.2 Search algorithm to find the pareto front
In Section 4.3.2 it is described that the pipe designs, which are Pareto optimal in terms of length, number of bends, angle sum, number of necessary bending jaws, and number of bends out of the desired range are selected. If a Pareto optimal solution based on these objectives should be found, it can be more efficient to search for these solutions than to pick them after many solutions have been generated. For optimizing an electric powertrain of a sports car, Vaillant (2016) describes a methodology for this based on a genetic algorithm. However, this approach reverses the procedure for designing the pipe work. Based on less extensive target criteria, the required trade-offs are determined to obtain the desired solution subsequently.
6.3 Physics based evaluation criteria
At the current status, only geometry-based evaluation criteria are available. Supplementary to these physics-based evaluation criteria can be of interest. One could be the pressure drop as a performance indicator for hydraulic efficiency. Another could be the eigenfrequency to ensure no resonance occurs during operation, which also depends on the positions and the rigidity of the connection points and fixings. Both criteria have in common that no closed formula is available to calculate the respective values. Therefore numerical approaches like computational fluid dynamics for flows and structural dynamic simulations often based on the finite element approach have been developed. Due to the numerical approach, which results in high computational costs, these cannot be used in the described iterative pipe design approach. Because of this, substitute models must be found that can be evaluated quickly but still have sufficient accuracy. Once the pipe design is complete, a comprehensive simulation could be carried out fully automatically to check the estimated results.
6.4 Cost estimation
Currently mainly technical aspects are taken into account. As for commercial applications the costs play an essential role they could be estimated and added as a design criteria. The automation of the design process can help to reduce design costs, but life cycle costs include many more items. Direct costs like the ones for the wrought material, the production, the installation, the logistics as well as indirect costs, like the depreciation of the bending machines, need to be considered. Estimating these costs is a challenging task, especially in an early design stage. Due to the design automation a more detailed solution is available in an early design stage, which helps to elaborate a well-founded estimation. This estimation could be included in the optimization or the result evaluation process, depending on the computational effort. Different heuristics on how to make an estimate have been described by Valerdi (2011). A cost estimation for a hydraulics system was developed by Houseman et al. (2008) and is used to compare different configurations in a conceptual design stage. The previously mentioned issues can be the starting point for further research.
6.5 Combination of pipe design and other design domains
The overall product performance depends not solely the quality of the pipe design as the pipe system is only one of many subsystems. Additionally the achievable pipe design quality depends on other design domains like the structure design, which limits the available installation space.
6.5.1 Combined packing and pipe design
In this paper the installation space and the packing are considered predetermined. They must be defined at the beginning of the toolchain execution, but this could also be done by an automated procedure. For this purpose, the connection points of the pipes to the components would have to be specified relative to them, so that the transformation of the equipment can be also applied to the connection points and tangents. A new obstacle landscape could be created by positioning the equipment or other obstacles. The determination of the best fitting transformations could be done by a packing algorithm.
6.5.2 Combined structural and pipe design
If the structure design process is also modeled and part of the optimization a combined optimum could be found. This could include that the pipes influence the structural design, e.g., by defining holes or gaps. Also, the structure could be annotated to incorporate knowledge about the structural design intentions into the pipe design process. For example if the holes in a structure, like in Fig. 10, are annotated the bend positions can be calculated directly (e.g., precisely in the middle or at the beginning and the end) and do not need to be optimized.
6.5.3 Combined design of different systems
The hydraulic pipes share the available installation space with other systems like the wire harness. This aggravates depending tasks like defining and optimizing the installation sequence as well as to ensure the accessibility for installation and maintenance. Creating a combined design process for different systems, which could also include the packing and the structural design, is a challenging task, but allows to search for one global optimum instead of local optima for the different domains. First studies have been conducted by Dinkelacker et al. (2023) which can be the starting point for a development for industrial use-cases.
Conflicts of interest statement
The authors declare no conflict of interest.
Author Contributions
Conceptualization by MN, SK, BK, and SR. Data curation by SK. Methodology by MN and SR. Project administration by BK and SR. Software by MN. Supervision by BK and SR. Visualization by MN. Writing (original draft) by MN and SR. Writing (review and editing) by MN, SK, BK, and SR.
Acknowledgement
The work shown here as a part of the H2020 CS2-Project PHAROS has received partly funding from the Clean Sky 2 Joint Undertaking (JU) under grant agreement number 865044 (see https://cordis.europa.eu/project/id/865044 for details). The JU receives support from the European Union’s Horizon 2020 research and innovation programme and the Clean Sky 2 JU members other than the Union. The content of this paper reflects only the author’s view and the JU is not responsible for any use that may be made of the information it contains. The authors would like to thank the Airbus Operations GmbH, Hamburg, for providing the context of this study.
References
Appendix 1:
A.1 Structure of the Evaluation Function
The evaluation function is inspired by the least squares method. The obvious way to calculate the evaluation value for a criterion would be |$v_i = f_i x_i^{p_i}$|, but for |$0\le x_i \lt 1$| this leads to smaller values for |$v_i$| if |$p_i$| is increased. However, this is undesirable, as a higher value for |$p_i$| should lead to a penalty, i.e., a higher |$v_i$|, for the same value of |$x_i$|. To prevent this, a translation was added, resulting in equation (6). In the graphs in Fig. A1, this is illustrated for |$p_i=0.5$| (purple), |$p_i=1$| (green) and |$p_i = 2$| (blue). In Fig. A1a, it can be seen that for |$x_i \lt 1$| that for an increase of the value of |$p_i$| (purple |$\rightarrow$| green |$\rightarrow$| blue) |$v_i$| decreases. In contrast, the desired behaviour can be seen in Fig. A1b.

A.2 Multi-Dimensional Pareto Front
A point is Pareto optimal if an improvement in one objective is only possible if another is worsened. This means that a point is Pareto optimal if it is not dominated by any other point. A point is dominated by another point if it is strictly worse in one objective and equal or worse in the other objectives. If all Pareto optimal solutions are plotted, this is known as Pareto front.
Mathematically speaking this can be defined as follows (definitions and notation taken from Van Veldhuizen & Lamont 1998), where
should be minimized while x is an n-dimensional decision variable vector from some universe |$\mathcal {U}$| and |$p \ge 2$| objectives are taken into account:
Definition Pareto Dominance (Van Veldhuizen & Lamont 1998): A vector |${\bf u} = (u_1,\ldots ,u_p)$| is said to dominate |${\bf v} = (v_1,\ldots ,v_p)$| if and only if |${\bf u}$| is partially less than |${\bf v}$|, i.e., |$\forall i \in \lbrace 1,\ldots ,p\rbrace , u_i \le v_i \wedge \exists i \in \lbrace 1,\ldots ,p\rbrace : u_i\lt v_i$|.
Definition Pareto Optimality (Van Veldhuizen & Lamont 1998): A solution |$x_u \in \mathcal {U}$| is said to be Pareto optimal if and only if there is no |$x_v \in \mathcal {U}$| for which |$v = f(x_v) = (v_1,\ldots ,v_p)$| dominates |$u=f(x_u)=(u_1,\ldots ,u_p)$|.
In Fig. 20 a the 5D Pareto front seems to go through the point cloud, but this is just an impression resulting from the projection into two dimensions. In the following this is exemplary illustrated for the results V044-V047, that are shown in Table A1 and were originally presented in Section 4.2. For all four variants no bending jaw is necessary, therefore based on this objective no variant can be excluded from the Pareto front as no variant is strictly worse than another. V045 is dominated by V044 as it is worse in length, the number of bends, the number of bends out of range and only equal in the number of bending jaws. V046 is dominated by V044 as it is worse in length and the number of bends out of range and only equal in the number of bends and the number of bending jaws. As V045 and V046 are dominated by V044, they can not be part of the Pareto front. V044 is not dominated by the other three points as it is shorter and has fewer bends out of range than V045–V047. V047 is not dominated by V044 (and V045 and V046) as it is better in terms of the angle sum. Therefore, V044 and V047 from the exemplary considered subset are part of the Pareto front. This is why it seems that the 5D Pareto front crosses between V045 () and V046 (
) in Fig. 20a, although this is not the case.
Variant . | Length . | Number of bends . | Angle sum . | Bends out of range . |
---|---|---|---|---|
V044 (![]() | |$\boxed{22875.01{\rm{mm}}}$| | 105 | 4622.3|$^\circ$| | |$\boxed{31}$| |
V045 (![]() | 22887.96 mm | 110 | 4693.7|$^\circ$| | 35 |
V046 (![]() | 22901.94 mm | 105 | 4677.4|$^\circ$| | 32 |
V047 (![]() | 22924.70 mm | 112 | |${\boxed{4592.0^\circ}}$| | 36 |
Variant . | Length . | Number of bends . | Angle sum . | Bends out of range . |
---|---|---|---|---|
V044 (![]() | |$\boxed{22875.01{\rm{mm}}}$| | 105 | 4622.3|$^\circ$| | |$\boxed{31}$| |
V045 (![]() | 22887.96 mm | 110 | 4693.7|$^\circ$| | 35 |
V046 (![]() | 22901.94 mm | 105 | 4677.4|$^\circ$| | 32 |
V047 (![]() | 22924.70 mm | 112 | |${\boxed{4592.0^\circ}}$| | 36 |
Variant . | Length . | Number of bends . | Angle sum . | Bends out of range . |
---|---|---|---|---|
V044 (![]() | |$\boxed{22875.01{\rm{mm}}}$| | 105 | 4622.3|$^\circ$| | |$\boxed{31}$| |
V045 (![]() | 22887.96 mm | 110 | 4693.7|$^\circ$| | 35 |
V046 (![]() | 22901.94 mm | 105 | 4677.4|$^\circ$| | 32 |
V047 (![]() | 22924.70 mm | 112 | |${\boxed{4592.0^\circ}}$| | 36 |
Variant . | Length . | Number of bends . | Angle sum . | Bends out of range . |
---|---|---|---|---|
V044 (![]() | |$\boxed{22875.01{\rm{mm}}}$| | 105 | 4622.3|$^\circ$| | |$\boxed{31}$| |
V045 (![]() | 22887.96 mm | 110 | 4693.7|$^\circ$| | 35 |
V046 (![]() | 22901.94 mm | 105 | 4677.4|$^\circ$| | 32 |
V047 (![]() | 22924.70 mm | 112 | |${\boxed{4592.0^\circ}}$| | 36 |
A.3 Pareto Optimal Solutions
All 34 solutions, which are part of the 5D Pareto front, are shown in Fig. A2 and named (a)–(ah). In the supplementary material a flip-book video of these figures, where the differences between the solutions can be easily spotted, can be found. One area where a change is clearly visible, for example, is the U-shaped pipe in the centre. The change is particularly clear between Fig. A2s V044 and Fig. A2t V047, where the number of bends is reduced from three to two. For all other designs, the changes are quite difficult to spot, since they all lie on the Pareto front in Fig. 20 which represents slightly different solutions ordered (a) along the axis of overall length or (b) in the plane (overall length, number of bends).
Pareto optimal solutions.