In complex engineering systems, complexity may arise by design, or as a by-product of the system's operation. In either case, the cause of complexity is the same: the unpredictable manner in which interactions among components modify system behavior. Traditionally, two different approaches are used to handle such complexity: (i) a centralized design approach where the impacts of all potential system states and behaviors resulting from design decisions must be accurately modeled and (ii) an approach based on externally legislating design decisions, which avoid such difficulties, but at the cost of expensive external mechanisms to determine trade-offs among competing design decisions. Our approach is a hybrid of the two approaches, providing a method in which decisions can be reconciled without the need for either detailed interaction models or external mechanisms. A key insight of this approach is that complex system design, undertaken with respect to a variety of design objectives, is fundamentally similar to the multi-agent coordination problem, where component decisions and their interactions lead to global behavior. The results of this paper demonstrate that a team of autonomous agents using a cooperative coevolutionary algorithm (CCEA) can effectively design a complex engineered system. This paper uses a system model of a Formula SAE racing vehicle to illustrate and simulate the methods and potential results. By designing complex systems with a multi-agent coordination approach, a design methodology can be developed to reduce design uncertainty and provide mechanisms through which the system level impact of decisions can be estimated without explicitly modeling such interactions.

## Introduction

Complex engineering systems, such as state-of-the-art aircraft, advanced power systems, unmanned aerial vehicles, and autonomous automobiles, are required to operate dependably in an ever-widening variety of environmental conditions, over a wide range of missions. Such systems must be cost-effective while being dependable in potentially extreme conditions and adaptable to the performance desires of the system designer.

When a large system is designed, multiple design teams are involved. These teams often are formed according to disciplinary lines, and each team is responsible for the design of a subsystem. Each team aims to maximize the performance of their subsystem but must be aware of interactions between subsystems and system-level constraints to result in high overall system performance. In some occasions, the goal of one team can be in conflict with the interests of another team. In many design problems, design engineering teams share design variables or constraints, which is also controlled by a systems engineering team. Different trade-offs are required between design teams before all the subsystems can be implemented in the systems.

As the complexity of the system increases, it becomes exceedingly difficult to model such interactions and explore the design space in a manner that allows system-level certification goals to be met. A systematic method that explores this space, while providing the necessary adaptability to meet mission needs and dependability with respect to mission requirements, is required.

This research presents an innovative approach to help engineers with the design of a complex engineered system. The design of complex engineered systems undertaken with respect to a variety of design objectives is substantially comparable to the multi-agent coordination problem. In both cases, the decisions at the component level (subsystems and agents), and the interaction between those components, lead to global behavior.

In multi-agent coordination, a key research challenge is to determine what each agent needs to do so that the system as a whole achieves a predetermined objective. This does not in itself “solve” the design problem; rather, it shifts the focus from modeling interactions to determining how to evaluate/incentivize components so that their collective behavior achieves the system design goals. This change of focus is critical to enabling a new paradigm to emerge: multi-agent coordination approaches can now be used to determine how to distribute credit (or blame) in a design process to the components/stages in the design that is critical to success (or failure).

Figure 1 illustrates the design process envisioned in this paper. The approach we explore is to implement a team of autonomous agents responsible for selecting the best concept using multi-agent coordination. After the customer and engineering requirements are defined, engineers will create a team of agents suitable for the problem related to the system-level objectives. A cooperative coevolutionary algorithm (CCEA) will perform the design exploration and multi-agent coordination. The algorithm will autonomously evaluate, select, and refine the design solution that results from the best trade-offs between all the subsystems. The overall goal of this research is to develop a design methodology that will help engineers to design complex engineered systems using a multi-agent coordination approach. To be able to achieve more complex solutions, the autonomous agents will coordinate their actions (design decisions) to optimize the multi-objective system.

## Background

Sections 2.1–2.5 present background information related to the design of complex engineered systems. Also included is a discussion on integrated concurrent engineering (ICE) to design complex engineered systems. The concepts of *multi-objective optimization* and *multidisciplinary design optimization (MDO)*, which are important methods and concepts to this research, are also presented within this section.

### Complex System Design.

Selection of design architecture while considering various design criteria and sources of uncertainty is a fundamental research problem in designing complex systems. Explicitly computing quantitative and qualitative objectives of a complex system is viewed as the preferred method for formalizing the design process; however, one of the fundamental problems in typical large-scale engineering system design is the overemphasis on requirement satisfaction for evaluating design alternatives [1]. This focus is primarily the result of the acquisition process but is exacerbated by overly simplistic design objectives, such as minimizing weight or cost, which do not reflect the actual value of the designed system. As an example, rather than making design decisions based primarily upon requirement (i.e., constraint) satisfaction, value-centric design (or value-driven design) offers an alternative approach to the formulation of a system-level design objective that reflects the actual value of the system, which can be subsequently *optimized* [2]. This is a dramatic change in perspective for system design, promising a reduction (or elimination) of cost and schedule overruns [3,4] by identifying high-value designs for development. Value-centric design can be considered part of the larger field of decision-based design (DBD) [5,6]. DBD has been specifically developed in the system design community as a decision-theoretic approach to selecting a preferred system design from among the alternatives. DBD takes an enterprise-level view of the design problem, considering not only typical engineering concerns but also broader objectives that comprise the total value of the system to the enterprise.

### Complex Engineered System Modeling.

Model-based design techniques are often needed when designing complex engineered systems [7]. The model-based design approach builds a model of the system that is used to simulate the functions and evaluate the performance. These models are at times segmented and combined to form a single model, although they do not need to be [7]. The simulation of the models helps designers to understand the behavior and performance of the system before any physical testing.

Most of the times, models such as nuclear power plants are so large and complex that they are too computationally expensive to create, let alone simulate. For this type of problems, the system is divided into smaller subsystems that can be simulated separately to collect information. However, this approach outcome with high levels of uncertainty because of the missing information of the complete model simulation. Complex engineered systems present emergent interactions that are not necessarily modeled or expected couple a set of components or subsystems together. The degree of this *coupling*, or *complexity* as it is sometimes called, is difficult to determine because of the associated ambiguity related to the unknown component links. Coupling is described by the relationship between system variables and functions [8].

Nevertheless, it could be possible to shift the focus from modeling interactions to evaluate and incentivize subsystems so that their collective behavior achieves the system design goals. This shift in focus could be translated into a new methodology to model complex engineered systems. A multi-agent coordination approach could be used to determine how to distribute responsibilities in a design process to the components in the design that are crucial to the success of the system.

### Integrated Concurrent Engineering.

Integrated concurrent engineering represents a collection of practices that attempt to eradicate inefficiencies in conceptual design and reorganize the process of sharing information inside a design team. ICE uses a combination of experienced designers; state-of-the-art modeling, visualization and analysis tools; social processes, and a specialized design facility; to conceive preliminary designs for complex engineered systems.

When compared with a traditional sequential engineering method, ICE users cut project schedule by several orders of magnitude, while considerably improving design cost and maintaining quality standards. Within a brief time, ICE allows engineers to consider, implement, evaluate, accept, and reject various ideas, with a relatively high level of fidelity [9]. Traditional design approaches constrain interdisciplinary trades because of a deficiency of communication among team members. Information is often dispersed throughout the project team, meaning those searching data on a particular subject have no central location to search [10]. As a result, engineers spend a significant amount of time searching or recreating information that already exists, rather than developing new information or data.

The ICE structure allows teams to work independently on problems local to a specific subsystem and to coordinate effectively on problems that affect other teams. Projects using ICE methodology are more flexible and can quickly adapt to changes in top-level requirements. As a result of the combination of all these factors, engineering teams that work with ICE can complete rapid trades among complex multidisciplinary subsystems.

Innovators in ICE methodology are primarily in the aerospace industry such as Boeing, where similar methods are known as “ICE,” “extreme collaboration,” “concurrent design engineering,” or “radical collocation” [11]. Whereas traditional engineering superficially resembles a government bureaucracy, ICE performs the same work in an environment similar to NASA's shuttle mission control operations. One of the most skilled teams of engineers working with ICE can be found at NASA Jet Propulsion Laboratory. Jet Propulsion Laboratory is the headquarters of the *Advanced Project Development Team*, conventionally known as *Team-X* [11–14].

### Multi-Objective Optimization.

In system design, multiple criteria, such as cost, safety, and performance, are considered in the process. This represents the multi-objective design optimization (MOO) problem [15–18]. General methodologies exist for solving MOO problems [19,20]; the distinguishing feature of a MOO problem is that, in general, one cannot identify a single solution that simultaneously optimizes each objective. In the design objective space, the point obtained by solving the *k* single-criteria optimization problems individually is called the *utopia* (ideal) point. The utopia point is not achievable due to conflicts among the multiple design criteria.

A design point is said to be a Pareto solution [21] if there exists no other feasible design that would improve some design objectives without sacrifice in at least one other criterion/objective. The Pareto frontier consists of Pareto solutions in the objective space such that a design criterion cannot be further improved without sacrifice to another criterion. Various methods for finding the Pareto frontier have been developed, such as the weighted-sum method [22], compromise programming [15], and the normal boundary intersection method [23]. Work exists in identifying the Pareto frontier when uncertainty exists in the multiple objectives, either by treating the mean and variance of each objective as separate objectives [24] or by computing an expected single attribute utility for each objective [25].

In this research, the ultimate goal is to optimize a set of multiple objectives, which is one of the distinctive characteristics of a complex system. This research will enable the identification of the Pareto frontier and allow significant trade-offs in problems with nonconvex objective functions, utilizing agent-level information.

### Multidisciplinary Design Optimization.

Multidisciplinary design optimization is an optimization method used in engineering problems that involve multiple subsystems [10]. The advances in computing power have increased the popularity of this type of optimization methodologies. Some techniques have emerged in an attempt to integrate both system decomposition and optimization such as collaborative optimization (CO) and bi-level integrated system synthesis (BLISS).

Collaborative optimization is a multidisciplinary design optimization technique, developed at Stanford University, that divides a problem along disciplinary lines into subproblems. Each subproblem is then optimized so that the difference between the obtainable subsystem performance and specific variables chosen by the system optimizer is minimized [26,27]. This methodology is powerful and efficient for problems with well-defined disciplinary boundaries, a large number of shared variables and calculations, and a minimum of interdisciplinary coupling. However, on the downside, CO leads to setups with high dimensionality, which requires high processing power. CO has been successfully used in several engineering problems typically in the area of vehicle design.

Bi-level integrated system synthesis is a multidisciplinary design optimization technique, developed at NASA Langley Research Center [28–30], that uses hierarchical decomposition. BLISS works similar to CO, where the goal is to optimize distributed engineering systems created by experienced groups who work concurrently to solve a design problem. The methodology differs from CO because preference weights are used for multi-objective optimization at the subsystem level. The constraints and coupling variables are also controlled fairly differently. The design parameters in BLISS are divided into three groupings. In the first group, the variables are optimized at the local level and are found only within each of the subsystems. The second group contains variables, which are outputs by one subsystem and are used as inputs for a different subsystem. Finally, the third group includes the system-level design variables, which are shared by at least two subsystems.

One of the biggest problems in modern design results from the conflict between the problem decomposition and MDO [10]. Decomposing a problem into smaller subproblems makes the overall problem more controllable, but as a result, it is more challenging for system-level optimization to make a significant contribution. Connecting a different number of subsystems into one is not simple. As the complexity of the system increases, so does the complexity of the model needed to complete the system-level optimization. Solving optimization problems with a computer can take extended periods, which can result in a delay of time between members on a design team. While waiting for the optimization results to return, the design team continues with their work, often updating models and reacting to changes in the requirements. When an optimization does finally produce data, the results are often obsolete by these changes. This is the main weakness of MDO because it prohibits a full integration of the parts, subsystems, and teams in the design. Thus, it is necessary to have a methodology that can relieve the fundamental conflict between these two approaches throughout the design cycle.

## Related Research

Engineers invest a lot of effort to create accurate models for complex engineered systems. The desired objective is to use a model that allows engineers to perform accurate failure analysis and evaluations of the system before any manufacturing process. The modeling of complex engineered systems and the assessment of failures are highly researched areas of interest within the engineering literature. This includes different areas that cover topics from performance evaluations to sensitivity analyses with input variables under uncertainty.

The primary objective of this research is to develop a methodology where a team of engineers can design complex engineered systems with the implementation of a multi-agent coordination approach. The design of complex engineered system undertaken with respect to a variety of design objectives is fundamentally similar to the multi-agent coordination problem. In both cases, the decisions at the component level (subsystems or agents) and the interactions among those components lead to global behavior (complex system or multi-agent system). Sections 3.1 and 3.2 describe the concepts behind *multi-agent coordination* and *coevolutionary algorithms*.

### Multi-Agent Coordination.

Multi-agent coordination is a key research area in agent-based approaches to automation [31]. One of the biggest challenges in such an approach is decentralization of control and, in particular, the question of how to incentivize the individual agents such that they work together [32] to achieve the system objective. The key challenge is that a system designer needs to address two major credit assignment problems: *structural* and *temporal* [31,32] credit. The first addresses who should get credit (or blame) for system performance, and the second addresses which key action (at which key time-step) is responsible for fulfilling the objective [33,34].

The temporal credit assignment problem has been extensively studied through single-agent reinforcement learning [32,35]. The structural credit assignment problem has also received attention, and has been addressed by two broad approaches: *feedback shaping* and *organizational structures*. Feedback shaping aims to shape the system objective such that the action of agents optimizing local objectives results in desirable system-level performance [36,37]. Organizational structures decompose the agents themselves into roles that enable coordinated behavior [38,39].

One particular research area in the credit assignment problem focuses on ensuring that agents' objectives are aligned with the system objective (i.e., what is good for the agent is good for the system), and that the system objective is sensitive to agents' actions [40]. Providing agents with objectives that satisfy these two properties (formalized in Refs. [40] and [41]) leads to a solution where key interactions among the agents are implicitly accounted for. A particular set of agent objectives that achieve these goals is the *difference objectives*, which is based on the difference between the actual performance of the system and the performance of a counter-factual system in which certain agents have been removed. Difference objectives have been extensively studied and applied to real-world applications including air traffic control, multirobot coordination, and resource allocation [40,42–44].

The success of the difference objective approach in developing appropriate agent learning objectives suggests that the method applies to complex system design where a structural credit assignment problem exists when designing individual components. One implementation of this approach, based on coevolutionary algorithms, is described next.

### Coevolutionary Algorithms.

Evolutionary algorithms are a class of stochastic population-based search algorithms, which can often outperform classical optimization techniques, particularly in complex domains where gradient information is not available [45]. An evolutionary algorithm typically contains three basic mechanisms: solution generation, a mutation operator, and a selection operator. These mechanisms are used on an initial set of candidate solutions, to generate new solutions and retain solutions that show improvement. Simple evolutionary algorithms are excellent tools but need to be adjusted to apply to large multi-agent search problems for distributed optimization. One such modification is *coevolution*, where multiple populations evolve simultaneously to develop policies for interacting agents.

However, these simpler subspaces represent a large loss of information; the consequence of this is that other populations strongly influence the policies obtained by using these state projections. The result is that agents evolve to partner well with a broad range of other agents, rather than evolving to form optimal partnerships [46]. Thus, in addition to trying to decrease the complexity of the learning process, research in coevolution looks to achieve optimal policies rather than stable ones.

#### Cooperative Coevolutionary Algorithms.

Cooperative coevolutionary algorithms is a natural approach in domains where agents need to develop local solutions (such as subsystem design), but the metric for success or failure is related to overall system performance [47]. In CCEAs, distinct populations evolve simultaneously, and agents from these populations collaborate to achieve good system solutions. One issue with CCEAs is that they tend to favor stable solutions, rather than optimal solutions [48]. This phenomenon occurs because the different evolving populations adapt to each other, rather than adapting to form an optimal policy. A further concern that appears with CCEAs is the problem of credit assignment. Since the agents succeed or fail as a team, the fitness of each agent becomes subjective and context-dependent. For example, an agent might be a “good” agent, but the agents it collaborates with are “bad,” and the objective is not reached. In this case, the good agent may be perceived as bad) [48,49].

#### Difference Evaluation Function Theory.

*z*is the overall system state,

*G*(

*z*) is the system evaluation function,

*z*

_{−}

*is the system state without the effects of agent*

_{i}*i*, and

*c*is the

_{i}*counterfactual*term used to replace agent

*i*. Intuitively, the difference evaluation compares system performance with and without agent

*i*, to approximate the agent's impact on overall system performance [52]. Note that

where *a _{i}* is the action taken by agent

*i*. This means that any action an agent takes which increases the value of the difference evaluation also increases the value of the overall system performance. This property is termed

*alignment*. Also, note that the second term in Eq. (1) removes the portions of the system evaluation, which are not affected by agent

*i*. This reduces noise in the feedback signal, meaning that difference evaluations are highly

*sensitive*to the actions of an individual agent.

In addition to the theoretical properties of alignment and sensitivity, difference evaluations have been proven to increase the probability of finding optimal solutions in cases where the optimal Nash equilibrium is *deceptive* [49]. Difference evaluations do not affect the location, number, or relative ordering of Nash equilibrium [49,53]. A *deceptive* Nash equilibrium is one in which the payoff drops significantly if one agent deviates. The actions associated with a deceptive Nash equilibrium correspond with low payoffs unless all agents simultaneously select the correct action. In these cases, one agent deviating from the optimal strategy results in a large decrease in the overall system payoff, meaning that finding these Nash equilibria is typically extremely difficult.

## Methodology

This paper demonstrates that, in a design problem, a team of autonomous agents can be used to design a complex engineered system. The first step is to define the design process for the agents as shown in Fig. 2. To begin with, it is necessary to define the system-level objectives and the system constraints. Then we select the team of agents, where each agent will be responsible for optimizing a specific subsystem. Second, using the different system-level objectives, it is necessary to define the overall system objective. The overall system objective will be used by the algorithm to measure the impact of the design concept for each agent team. Using cooperative coevolutionary algorithm, the agents will evaluate all the feasible combinations of solutions and choose the best one. In this paper, we will compare the final design of a system designed by a team of engineers against the design reached by a team of autonomous agents.

### Formula SAE Design Problem.

This paper will illustrate the proof of concept of the approach using the design of a Formula SAE racing vehicle. Formula SAE is a collegiate design competition that requires students to design, build, test, and to compete with a racing automobile [54]. Formula SAE works as a fictional company, where teams of students are contracted to create and build a functional small formula racing vehicle. The final design is tested based on a series of rules, which ensure the safety of all operations and promote a design challenge for engineers.

The objective is to create a racing vehicle, which will win the acceleration and skid-pad event of a Formula SAE race. The acceleration event evaluates the vehicle acceleration in a straight line on the flat pavement. The course layout for the acceleration event has a length of 75 m and 4.9 m wide from start to finish line [54]. The skid-pad event measures the car's cornering ability on a flat surface while making a constant radius turn. The course layout for this event has two pairs of concentric circles in a figure of eight patterns. The centers of these circles will be 18.25 m apart. The inner circles will be 15.25 m in diameter, and the outer circles will be 21.25 m diameter.

In this paper, we compare the design process of a Formula SAE engineering team against a team of autonomous design agents. The design process for the autonomous agents will follow the same design principles as the one followed by the team of engineers, using the parameters in Fig. 2. We will set some customer requirements for the vehicle performance. Second, we will define the system-level objectives and constraints. Finally, the autonomous design teams (agents) will be defined, and an algorithm will be implemented. The key factor of the presented design process will be the design agent's selection. For the purpose of this paper, the system to be analyzed is going to be simplified. The selection of components such as the differential, clutch, and transmission is not being considered for this first part of the research. All the subsystems and components mentioned will be implemented as part of future work.

### Formulating the System Level Objective.

The first step is to investigate the form of a system-level design objective that ensures an intrinsically dependable and adaptable system directly from the design process. The key principle here is that the objective function should capture the designer's (agent's) underlying preferences for the system while ensuring the design is both adaptable and dependable. The presented approach allows adaptability or learning within the design agents, the final design will have a significant performance improvement in comparison with other approaches that do not [55].

There are two key points related to adaptability. First, the system designer can change the overall system objective function by either adding new metrics or changing the weights of existing metrics, and the system can adapt its design to optimize the new metrics. In this case, the system is adaptable to the performance desires of the system designer. Second, the system can adapt to the design of different components being changed because the interaction between agents ensures that agents optimize their components not only with respect to local performance measures but also on how their components interact with the system as a whole.

To win the competition, the system needs to maximize the vehicle acceleration and aerodynamic grip, and minimize weight, drag, and the location of the center of gravity. Engineering teams are responsible for designing the system, and each team is responsible for designing one specific subsystem as shown in Fig. 3. Consistent with the philosophy of engineering design, the goal is to make the decisions as accurately as possible without having to build prototypes or conduct costly testing.

### Formulating the Agents as Design Teams.

There are eleven design teams (agents) each responsible for a subsystem in the overall design problem. The design agents in this system do not share any design variable. There are two key challenges with ensuring coordination, including cases where design agents do not share variables among themselves.

First, the utility function for each subsystem being optimized must be constructed such that they ensure that the overall system is optimized. For example, the rear wing agent (rw) may optimize the downforce of the system by making a larger wing. Although the large wing would optimize the downforce of that specific subsystem, it may harm the overall system performance due to the increased weight and drag of the large wing. Thus, the agent should be optimizing the subsystem with respect to its impact on the overall system, not based on local performance measures.

Second, when decomposing the design problem into multiple subsystem optimizations, each subsystem must be optimized in a manner that ensures it will work well with the additional subsystems being optimized. For example, the concept of an “optimal” front suspension system (fsp) is ill defined without notions of the torque provided by the engine, the weight of the overall vehicle, etc. The agent optimizing the suspension must thus optimize the suspension such that it will perform well with the other subsystems being simultaneously optimized.

These teams, as well as the design parameters they are responsible for, are given in Table 1. Note that for each component, *h* corresponds to height, *l* corresponds to length, *w* corresponds to width, *α* corresponds to angle of attack, *x* corresponds to an *x*-position, *y* corresponds to a *y*-position, *ρ* corresponds to density, *P* corresponds to pressure, *r* corresponds to radius, *m* corresponds to mass, Φ corresponds to power, *τ* corresponds to torque, *t* corresponds to thickness, and *E* corresponds to a material's modulus of elasticity. Further, note that each team name has an abbreviation given in Table 1 to define variable naming conventions. So, for example, the height of the rear wing is denoted *h*_{rw}. Continuous variables such as height are chosen from a constrained portion of $\mathbb{R}$ (constraints based on SAE competition rules), while discrete variables such as engine power, engine mass, and engine dimension are determined by choosing from a discrete list of available engines.

Team name | Continuous parameters | Discrete parameters |
---|---|---|

Rear wing (rw) | h_{rw}, l_{rw}, w_{rw}, α_{rw}, x_{rw}, y_{rw} | ρ_{rw} |

Front wing (fw) | h_{fw}, l_{fw}, w_{fw}, α_{fw}, x_{fw}, y_{fw} | ρ_{fw} |

Side wings (sw) | h_{sw}, l_{sw}, w_{sw}, α_{sw}, x_{sw}, y_{sw} | ρ_{sw} |

Rear tires (rt) | P_{rt}, x_{rt} | r_{rt}, m_{rt} |

Front tires (ft) | P_{ft}, x_{ft} | r_{ft}, m_{ft} |

Engine (e) | x, _{e}y_{e} | Φ, _{e}l, _{e}h, _{e}τ), _{e}m_{e} |

Cabin (c) | h, _{c}l, _{c}w, _{c}t, _{c}x, _{c}y_{c} | ρ_{c} |

Impact attenuator (ia) | h_{ia}, l_{ia}, w_{ia}, x_{ia}, y_{ia} | ρ_{ia}, E_{ia} |

Brake system (brk) | x_{brk}, y_{brk} | ρ_{brk}, l_{brk}, h_{brk}, w_{brk}, t_{brk}, r_{brk} |

Rear suspension (rsp) | x_{rsp}, y_{rsp} | k_{rsp}, c_{rsp}, m_{rsp} |

Front suspension (fsp) | x_{fsp}, y_{fsp} | k_{fsp}, c_{fsp}, m_{sp} |

Team name | Continuous parameters | Discrete parameters |
---|---|---|

Rear wing (rw) | h_{rw}, l_{rw}, w_{rw}, α_{rw}, x_{rw}, y_{rw} | ρ_{rw} |

Front wing (fw) | h_{fw}, l_{fw}, w_{fw}, α_{fw}, x_{fw}, y_{fw} | ρ_{fw} |

Side wings (sw) | h_{sw}, l_{sw}, w_{sw}, α_{sw}, x_{sw}, y_{sw} | ρ_{sw} |

Rear tires (rt) | P_{rt}, x_{rt} | r_{rt}, m_{rt} |

Front tires (ft) | P_{ft}, x_{ft} | r_{ft}, m_{ft} |

Engine (e) | x, _{e}y_{e} | Φ, _{e}l, _{e}h, _{e}τ), _{e}m_{e} |

Cabin (c) | h, _{c}l, _{c}w, _{c}t, _{c}x, _{c}y_{c} | ρ_{c} |

Impact attenuator (ia) | h_{ia}, l_{ia}, w_{ia}, x_{ia}, y_{ia} | ρ_{ia}, E_{ia} |

Brake system (brk) | x_{brk}, y_{brk} | ρ_{brk}, l_{brk}, h_{brk}, w_{brk}, t_{brk}, r_{brk} |

Rear suspension (rsp) | x_{rsp}, y_{rsp} | k_{rsp}, c_{rsp}, m_{rsp} |

Front suspension (fsp) | x_{fsp}, y_{fsp} | k_{fsp}, c_{fsp}, m_{sp} |

For the purpose of this analysis, the customer requirement for the designed vehicle is to win the acceleration event of a Formula SAE race. The following assumptions will be used as the requirements for the system-level objectives and the environment:

- (1)
The car's top velocity

*v*_{car}is 26.8 m/s (60 mph). - (2)
The car's engine speed

*ω*is 3600 rpm._{e} - (3)
The density of air

*ρ*_{air}during the race is 1.225 kg/m^{3}. - (4)
The track radio of curvature

*r*_{track}is 9 m. - (5)
The pressure applied to the brakes

*P*_{brk}is 1 × 10^{7}Pa (1450 psi).

### System Level Objectives.

#### Mass.

*t*, and its mass is given by

Note that as there are two side wings, two rear tires, and two front tires, these mass values are doubled in the overall mass calculation.

#### Center of Gravity Height.

*) of the car, or to keep the center of gravity as low as possible. The*

_{y}*y*-position of the center of gravity is defined as

#### Drag and Downforce.

The third and fourth objectives are to minimize the overall drag of the vehicle and to maximize the downforce of the vehicle. We assume that the components which influence drag are the rear wing, front wing, side wings, and cabin. We also assume that only the wings influence vehicle downforce. We will first analyze the wings and then the cabin.

*C*of a wing is defined as

_{l}*C*of a wing is defined as

_{d}*F*of a wing is given by

_{d}*F*of a wing is given by

_{R}For the cabin, we assume a drag coefficient *C _{d}*

_{,}

*of 0.04 for a streamlined body [56].*

_{c}#### Acceleration.

*x*-direction. The rolling resistance coefficient

*C*of the car is given by

*p*is the tire pressure. The overall rolling resistance

*R*

_{roll}of the car is given by

*g*is the gravitational constant. Thus, the total resistance of the car

*R*

_{tot}is given by the sum of drag and rolling resistance

*η*of the engine is given by

*F*

_{wheels}at the rear tires is given by

*ω*

_{wheels}is the rotational speed of the rear wheels, given by

*a*

_{car}as follows:

#### Crash Force.

*δ*of the impact attenuator is given by

*F*

_{crash}is defined as

#### Impact Attenuator Volume.

*V*

_{ia}, given by

#### Corner Velocity.

The eighth objective of the design process is to maximize the velocity of the car *V*_{cor} while turning in the skip pad. We assume that the forces which influence the radial acceleration of the car are the the overall downforce *F _{d}*, the overall rolling resistance

*R*

_{roll}, and the suspension force

*F*

_{sp}.

The suspension force *F*_{sp} of the car is given by:

*F*

_{fsp}

*F*

_{rsp}

*k*and

_{r}*k*are the front and rear suspension spring constants;

_{f}*k*and

_{f}*c*are the front and rear suspension damping constants;

_{r}*y*is the distance the suspension is stretched or compressed away from its equilibrium position; and $y\u02d9$ is the velocity the suspension is stretched or compressed. We assume values of

*y*= 0.05 m and $y\u02d9=0.025\u2009m/s$ for the system. We can thus find the radial acceleration of the car

*a*

_{radial}as follows:

#### Braking Distance.

*D*

_{brk}. We assume that the pilot will be applied an equal breaking pressure

*P*

_{brk}simultaneously at the four disk brakes. The resulting braking torque at each disk can be estimated as follows:

*c*

_{brk}is the brake friction coefficient,

*A*

_{brk}is the brake pad area, and

*r*

_{disk}is the brake disk radio. We can thus find the braking de-acceleration of the car

*a*

_{brk}as follows:

*d*

_{brk}as follows:

#### Suspension Acceleration and Pitch Moment.

The two final objectives of the design problem are to minimize the suspension acceleration *a*_{sp} and minimize the pitch moment *M*_{pitch} for the under-damped system with response time *t*_{sp} = 0.13 s. We assume initial values of *y*(0) = 0.05 m and $y(0).=0.025\u2009m/s$ for the system. We assume that the front tires are in contact with the step simultaneously. First, we must find the natural frequency *wn* and damping ratio/*xi* for the suspension system.

*F*(

*t*) = 0 and the system is under damping (0 ≤

*ξ*< 1). In this situation, the system will oscillate at the natural damped frequency

*wd*, which is a function of the natural frequency

*wn*and the damping ratio

*ξ*. In this case, the solution can be generally written as

*wd*represents the natural damped frequency of the system, and A and B are determined by the initial conditions of the system

*a*

_{sp}and pitch moment

*M*

_{pitch}as follows:

### Overall System Objective.

In a Formula SAE competition, the car prototype is judged in a number of different events. In this paper, we are not replicating a Formula SAE competition; however, it is necessary to judge the design of the vehicle. A weighted linear sum is our approximation on how to judge the design with respect to its performance.

*z*, the system evaluation function

*G*(

*z*) is defined as

where *w _{i}* is a weight corresponding to objective

*i*.

where *z* is the overall system state, *G*(*z*) is the system evaluation function, *z*_{−}* _{i}* is the system state without the effects of agent

*i*, and

*c*is the

_{i}*counterfactual*term used to replace agent

*i*. Intuitively, the difference evaluation compares system performance with and without agent

*i*, to approximate the agent's impact on overall system performance.

### Constraints.

The constraints used for the vehicle were set according to the rules of the 2016 Formula SAE rules [54]. The SAE rules present the competition regulations technical and design requirements. The Formula SAE rules were used to define the minimum and maximum dimensions and the areas where the structural components are allowed to be placed.

### CCEA's Implementation.

The CCEA is a stochastic, population-based search algorithm which is capable of exploring any design solution in the search space. However, as this is a high-dimensional continuous search space, it is computationally intractable to evaluate every possible solution explicitly. Thus, during the beginning phases of the CCEA, solutions across the entire search space are considered. As the CCEA discovers local portions of the search space where good solutions are concentrated, the algorithm begins to focus on fine-tuned optimizations within those search spaces.

The approach to optimizing the vehicle design using CCEA is shown in Algorithm 1, and presented in a graphical illustration in Fig. 4. Initially, *N* populations are seeded with *k* random solutions. In this case, there are eleven populations, one for each subsystem agent (rear wings, front wings, etc.). In each generation, each population creates mutated solutions, and then the solutions are used to create teams, where a team consists of an entire vehicle design. The solution presented by the team is then evaluated, and each member of the team is assigned a fitness score. For this specific case study, the vehicle has been evaluated using the weighted linear sum defined in Eq. (40). Once each member of each population has been assigned a fitness score, solutions in each population are selected to survive to the next generation. Each of these evolutionary mechanisms is explained in the following paragraphs.

A “solution” in the cooperative coevolutionary algorithms consists of two elements: a continuous element and a discrete element. For any given team (optimized by a single population), the continuous element of the solution contains an array of values corresponding to that team's subsystem. For example, for the rear wing team, the continuous portion of the solution is an array of the form {*h*, *l*, *w*, *α*, *x*, *y*}. The discrete element of the solution contains an array of choices corresponding to that team's subsystem. For the rear wing team, the discrete portion of the solution is of the form {*ρ*}, where the density *ρ* was chosen from a list of available materials for wing construction. A random solution is chosen by drawing the continuous variables from a uniform probability distribution, and drawing discrete variables where each discrete choice has an equal probability of selection. Each population (corresponding to different design subsystems) is initially populated with random solutions.

For mutation, each population of size *k* is doubled in size to 2*k* solutions. Each solution in the original population is copied and then mutated to create a child solution. For the continuous portion of the solution, mutation is carried out by first adding a value drawn from a Gaussian distribution *N* (*μ* = 0, *σ* = 0.001) to each element, and then ensuring the resulting value is still within the allowable constraints. For example, if a mutated parameter is *a* + *ϵ*, but the maximum value (based on vehicle constraints) that the parameter may take is *a*, then the value is changed to *a*.

For team formation, one solution is drawn from each population to form a complete vehicle design. Each solution in a population has an equal probability of being selected for a team, and each solution is used only once (i.e., if each population has a size of 2*k*, then 2*k* teams are tested).

For fitness assignment (line 11 in Algorithm 1), we test two fitness assignment operators. First, we use the global evaluation *G*(*z*) to assign fitness to each agent in a team. This means that the performance of each subsystem design is assigned using the overall system performance. Next, we use the difference evaluation *D _{i}*(

*z*) to assign fitness to each agent. In this case, we assign a counterfactual of 0, meaning we analyze the performance of the car if a component was removed from the design. This provides an estimate of the impact on the overall system performance provided by a single component.

For selection, we use binary tournament selection, which reduces a population of size 2*k* to size *k* using the following procedure. Two solutions are drawn from the population (each solution may be drawn only once). The solution with the higher fitness value is returned to the population, and the solution with the lower fitness value is discarded. Binary tournament selection ensures that the best solution in the population is retained and that the worst solution in the population is discarded. For all other solutions in the population, their probability of survival increases with their fitness value.

## Results

To validate the performance of the vehicle designed using a cooperative coevolutionary algorithm with difference reward, we need to compare the CCEA design solution with a real Formula SAE racing vehicle. The current Formula SAE Michigan champion since 2010 is the global formula racing (GFR) of Oregon State University [57]. GFR is a Formula SAE team formed by an international cooperation between the BA racing team from DHBW Ravensburg Campus Friedrichshafen, located in Baden-Württemberg, Germany and the Beaver Racing team from Oregon State University, located in Corvallis, OR. GFR team has proven to be the best student engineering team, winning more than 15 competitions worldwide since 2010. The results from the cooperative coevolutionary algorithm with difference reward will be compared to the GFR 2013 combustion car as a proof of concept.

For the simulation run, the population size was set to 50 and the number of generations for evolution, 10,000. The weights for the overall system objective (Eq. (40)) are defined in Table 2.

Weight | |||
---|---|---|---|

Objective | Scenario 1 | Scenario 2 | Scenario 3 |

Mass | 14 | 25 | 14 |

CG_{y} | 1 | 1 | 1 |

Drag | 20 | 15 | 20 |

Downforce | 30 | 20 | 15 |

Acceleration | 10 | 15 | 25 |

Crash force | 1 | 1 | 1 |

IA volume | 1 | 1 | 1 |

Corner velocity | 10 | 15 | 10 |

Braking distance | 10 | 5 | 10 |

Suspension acceleration | 2 | 1 | 2 |

Pitch moment | 1 | 1 | 1 |

Total (%) | 100 | 100 | 100 |

Weight | |||
---|---|---|---|

Objective | Scenario 1 | Scenario 2 | Scenario 3 |

Mass | 14 | 25 | 14 |

CG_{y} | 1 | 1 | 1 |

Drag | 20 | 15 | 20 |

Downforce | 30 | 20 | 15 |

Acceleration | 10 | 15 | 25 |

Crash force | 1 | 1 | 1 |

IA volume | 1 | 1 | 1 |

Corner velocity | 10 | 15 | 10 |

Braking distance | 10 | 5 | 10 |

Suspension acceleration | 2 | 1 | 2 |

Pitch moment | 1 | 1 | 1 |

Total (%) | 100 | 100 | 100 |

Three design scenarios with a different set of weights were analyzed to test the adaptability of our methodology. This would allow us to test the two key points related to adaptability. We modify the weights of the metrics in three different scenarios to see how the agents will adapt the design of the vehicle to optimize the system. Since the primary objectives of the GFR team are to reduce the overall mass and drag of the vehicle while maximizing the car's acceleration and the resulting downforces, these objectives have the higher weight. Comparing the effects of weight variation between systems' objectives allow us to compare the design decisions of the agents. For example, if the weight value for the downforce objective is increased, the design agents will create larger wings. However, the use of large wings will increase the resulting drag forces on the vehicle, and thus could cause a lower overall system performance.

Before going further with the result of the three weight scenarios, first it is necessary to compare the agents' performance using the two cases. Case number one is the implementation of cooperative coevolutionary algorithm with the global objective called *G*(*z*) defined in Eq. (40). Case number two is the implementation of cooperative coevolutionary algorithm with the difference evaluation function called difference reward *D _{i}*(

*z*) defined in Eq. (1). Figure 5 shows how the system performance increases for

*G*(

*z*) and

*D*(

_{i}*z*) as the number of generations increases. The system performance has negative values because eight of the eleven objectives need to be minimized.

As seen in Fig. 5, the difference reward *D _{i}*(

*z*) provides better performance than the system evaluation function

*G*(

*z*). This is due to the fact that all team members are given better feedback on their performance.

*G*(

*z*) outperforms

*D*(

_{i}*z*) when weights are chosen that significantly favor acceleration and crash forces being optimized. This is because these parameters are the most coupled as they depend on the mass of each component as well as engine specs. So, basically every team member affects these parameters; and

*D*(

_{i}*z*) has problems when there is extremely high coupling between agents.

More importantly, in these cases where *D _{i}*(

*z*) struggles, we see the effect of one agent being very good with one team but very poor with another team. This type of behavior is also difficult for

*D*(

_{i}*z*) to handle, because it will only provide good feedback to an agent if its teammates are reasonably well suited to work with that agent. For example, an agent that works extremely well with engine

*A*but extremely poorly with engine

*B*will get a poor difference evaluation if it is paired with a teammate which selects engine

*B*, even if it is a decent solution.

The results from the design of the three weight scenarios are shown in Tables 3–5 where we compare a solution found using the CCEA with difference reward *D _{i}*(

*z*) against the GFR solution for each weight scenario. The results marked with bold text identify values with better performance for each objective.

Objective | CCEA solution | SAE solution |
---|---|---|

Mass | 71.07 | 71.87 |

CG_{y} | 0.228 | 0.228 |

Drag | 9.22 | 22.43 |

Downforce | 24.86 | 15.91 |

Acceleration | 1.39 | 3.28 |

Crash force | 918,377.23 | 2,077,933.89 |

IA volume | 0.0135 | 0.00864 |

Corner velocity | 0.710 | 0.694 |

Braking distance | 21.35 | 21.74 |

Suspension acceleration | 35.77 | 30.16 |

Pitch moment | 5202.13 | 5187.53 |

Objective | CCEA solution | SAE solution |
---|---|---|

Mass | 71.07 | 71.87 |

CG_{y} | 0.228 | 0.228 |

Drag | 9.22 | 22.43 |

Downforce | 24.86 | 15.91 |

Acceleration | 1.39 | 3.28 |

Crash force | 918,377.23 | 2,077,933.89 |

IA volume | 0.0135 | 0.00864 |

Corner velocity | 0.710 | 0.694 |

Braking distance | 21.35 | 21.74 |

Suspension acceleration | 35.77 | 30.16 |

Pitch moment | 5202.13 | 5187.53 |

Objective | CCEA solution | SAE solution |
---|---|---|

Mass | 71.06 | 69.92 |

CG_{y} | 0.224 | 0.224 |

Drag | 10.19 | 22.43 |

Downforce | 28.62 | 15.91 |

Acceleration | 1.54 | 3.74 |

Crash force | 918,314.05 | 1,944,330.88 |

IA volume | 0.0135 | 0.00864 |

Corner velocity | 0.708 | 0.694 |

Braking distance | 56.25 | 50.69 |

Suspension acceleration | 37.30 | 37.46 |

Pitch moment | 5019.51 | 4997.23 |

Objective | CCEA solution | SAE solution |
---|---|---|

Mass | 71.06 | 69.92 |

CG_{y} | 0.224 | 0.224 |

Drag | 10.19 | 22.43 |

Downforce | 28.62 | 15.91 |

Acceleration | 1.54 | 3.74 |

Crash force | 918,314.05 | 1,944,330.88 |

IA volume | 0.0135 | 0.00864 |

Corner velocity | 0.708 | 0.694 |

Braking distance | 56.25 | 50.69 |

Suspension acceleration | 37.30 | 37.46 |

Pitch moment | 5019.51 | 4997.23 |

Objective | CCEA solution | SAE solution |
---|---|---|

Mass | 71.05 | 71.96 |

CG_{y} | 0.228 | 0.228 |

Drag | 6.6 | 22.43 |

Downforce | 5.00 | 15.91 |

Acceleration | 1.02 | 3.30 |

Crash force | 918,266.96 | 2,079,199.38 |

IA volume | 0.0135 | 0.00864 |

Corner velocity | 0.694 | 0.694 |

Braking distance | 19.30 | 21.75 |

Suspension acceleration | 29.87 | 24.85 |

Pitch moment | 4473.13 | 4444.53 |

Objective | CCEA solution | SAE solution |
---|---|---|

Mass | 71.05 | 71.96 |

CG_{y} | 0.228 | 0.228 |

Drag | 6.6 | 22.43 |

Downforce | 5.00 | 15.91 |

Acceleration | 1.02 | 3.30 |

Crash force | 918,266.96 | 2,079,199.38 |

IA volume | 0.0135 | 0.00864 |

Corner velocity | 0.694 | 0.694 |

Braking distance | 19.30 | 21.75 |

Suspension acceleration | 29.87 | 24.85 |

Pitch moment | 4473.13 | 4444.53 |

The first weight scenario presented in Table 3 gives higher priority to maximize downforces and minimize drag. As expected, the CCEA design has indeed minimized the drag and maximized the downforces of the system while keeping a similar system weight. The agents decide to reduce the acceleration of the system while generating high downforces and keeping a minimal drag.

The second weight scenario presented in Table 4 gives higher priority to minimize weight and minimize downforces while keeping low drag. The final CCEA design has a better performance generating downforces and minimizing drag. However, the design is heavier and has less acceleration than the GFR. Even though the weight for the objective mass was 25%, the agents completed trade-offs that would guarantee higher downforces and less drag while keeping the performance of the system.

Finally, the third weight scenario presented in Table 5 gives higher priority to minimize drag and maximize acceleration of the system. The CCEA designs choose to minimize drag and maximize acceleration while sacrificing the generation of downforces.

For the three weight scenarios, the CCEA designs have minimized the crash force of the vehicle as a result of the trade-off with acceleration, downforces, and drag. The CCEA design has less than half of the GFR car acceleration for the three scenarios. However, the CCEA design can achieve similar results for corner velocity, braking distance, suspension acceleration, and pitch moment with the current trade-offs.

## Discussion and Conclusions

The key motivation of our paper is to develop an automated design tool for the design of complex engineered systems. The long-term goal of this research is to enable new design paradigms for complex systems to ensure that design space exploration, system architecture selection, and system integration are conducted in a way to produce a certifiably *dependable* and *adaptable* system meeting high-level design objectives. The work done in this paper shows preliminary evidence that distributed artificial intelligence can be used in design processes by splitting up the overall system into specific teams.

For the design of complex engineered systems, current design approaches, such as value-centric design, decision-based design, or multidisciplinary design optimization, focus on achieving consistency between the subsystems. Each subsystem must achieve the desired engineering target while not necessarily accomplishing a specific design objective. In these types of approaches, the subsystems are not acutely aware of the system objectives or do not know the objectives at all.

On the contrary, the presented methodology is using multi-agent coordination that guarantees the collaboration between the subsystems toward designing the optimal system. The team of agents will learn how to coordinate their design decisions toward achieving the best solution. The learning interaction between the agents (subsystems) inside the system makes our approach smarter than current design approaches.

For our approach, we implemented a cooperative coevolutionary algorithm with difference evaluations (CCEA *D _{i}*(

*z*)), which modifies the evolutionary search as well as shapes agent fitness functions to boost collaboration that benefits the system level performance. Our results corroborate that the performance and coordination of the subsystems integrated as a team of agents can be evaluated with the implementation of cooperative coevolutionary algorithm.

The results presented in Fig. 5 validate the necessity of implementing an evaluating method for the agent's performance. The results show that a methodology combining the difference evaluation function with CCEA (*D _{i}*(

*z*)) outperforms a method that uses only the global evaluation function with CCEA (

*G*(

*z*)). The CCEA with difference evaluation function (

*D*(

_{i}*z*)) allows us to evaluate the performance of the team of agents, but it cannot evaluate the performance of each individual agent inside the team. Implementing the difference evaluation function with CCEA results in a more effective method to optimize the performance of the system because the performance of each agent inside the team can be evaluated. Difference reward allows each agent to learn what its contribution is to the performance of the system, and how its individual design decisions affect each multi-objective.

The counterfactual is used to allow the evaluation of the agent in the system. In the best case, the counterfactual should be equivalent to removing the agent from the system. In cases that are impossible due to the nature of the system objective function, other counterfactuals must be used. When we use a counterfactual with a value of 0 assigned, we are analyzing the performance of the vehicle as if the agent (subsystem) is removed from the design. This provides an estimated impact on the overall system performance provided by a single component. Agents such as the front tire, rear tire, and engine need a different counterfactual value with a feasible starting point; otherwise, in our particular case study, the vehicle will not be able to move. In such cases, the counterfactual used for each agent is the minimal value for the subsystem based on the constraints of the system.

A team of autonomous agents using a cooperative coevolutionary algorithm with difference evaluation function can be used as a design optimization methodology. We have shown that combining difference evaluation function with CCEAs (*D _{i}*(

*z*)) outperformed the CCEAs performance (

*G*(

*z*)). The results of the cooperative coevolutionary algorithm with difference reward

*D*(

_{i}*z*) allow adaptability during the design process. The three weight scenarios were created to test how the agents would behave when the overall system objective was modified. The results confirm that with our approach, the system is adaptable to the performance desired of the system designer, and the system can adapt to the design of different components being changed. The interaction between agents ensures that agents optimize their subsystems not only with respect to local performance measures but also with respect to how their subsystem interacts with the entire vehicle.

In our results, we compare the system performance of a racing vehicle designed by a Formula SAE engineering team against the design of the vehicle using autonomous agents. The results illustrate the proof of concept of the presented approach. More specifically, the results from Tables 3–5 illustrate that a team of autonomous agents using a cooperative coevolutionary algorithm with difference reward can effectively design a formula racing vehicle.

It is important to notice that the same objectives were used for the performance comparison between agent- and human-based design optimizations. Both the learning algorithm and the Formula SAE team were optimizing the vehicle design for the same set of objectives, under the same design constraints. However, these results do not prove that our approach outperforms the design completed by the Formula SAE engineering team. The racing vehicle designed by the Formula SAE engineering team was completed with more race events that our model is considering at this time. Future simulation needs to incorporate all of the racing events of a Formula SAE competition. In addition, the Formula SAE team designs their car for the sole purpose of winning the competition; as such, their team focuses on optimizing what they consider to be the most important objectives such as acceleration and downforces, while overlooking the optimization of other subsystems less critical for their goals, such as suspension and braking. If victory is achieved, the team will not necessarily optimize the less critical subsystems. Human designers will ignore objectives with a weight of 1–2%. With our approach, the designing agents will optimize all of the objectives of the system including those with a weight of 1–2%.

## Future Work

The next step in this research is to obtain results increasing the complexity of the system. In this paper, the case study was a simple vehicle, but a real formula racing vehicle needs to consider all of the dynamics between the system, driver, engineers, and the racing environment. The system needs to accurately simulate different dynamic racing scenarios. Different types of mechanical and electrical components must be included using a large number of agents. The system objective must also consider the cost of manufacturing and assembly operations. As a system objective function defined as the weighted linear sum is a simple approach, work will explore how the team of agents behaves with a large set of multi-objectives, different forms of the overall system objective, and different weights distribution.

## Acknowledgment

Any opinions or findings of this work are the responsibility of the authors, and do not necessarily reflect the views of the sponsors or collaborators. Special thanks to Universidad San Francisco de Quito for supporting one of the authors' graduate studies, and to the GFR team for the constant support.

## Funding Data

- •
National Science Foundation (Grant No. CMMI-136341).