2Only 2¹⁹ objects because one question must be reserved to ask "Is this the object you selected?"

Currently, research into applying set-based technologies to engineering design is divided into two thrusts. One proposes a set-based mindset for design process management. Intuitively, set-based approaches to product development have several advantages to conventional, iterative design processes. Recent work provides evidence that commercial success is correlated with set-based thinking.

The second thrust pursues set-based mathematical tools. This work combines elements of predicate logic, artificial intelligence, and computer science into tools for making engineering calculations about sets of designs under sets of operating conditions, etc. The aim of this research is to provide tools supporting the automation of set-based engineering design processes. Together, these research efforts will provide tools and processes for set-based product development.

Traditional design practice, whether done "concurrently" or not, tends to quickly converge on a solution, a point in the solution space, and then modify that solution until it meets the design objectives. This would seem to be an effective approach except that if one picks the wrong starting point, subsequent iterations to refine that solution can be very time consuming and lead to a suboptimal design.

By contrast, set-based concurrent engineering (SBCE) begins by broadly considering sets of possible solutions and gradually narrowing the set of possibilities to converge on a final solution. A wide net from the start makes finding the best or better solutions more likely. This approach may require more time early to define the solutions, but later stages can then move more quickly toward convergence, and ultimately production, relative to more point-based processes.

How can this be? It may be helpful to start by considering traditional serial engineering applied to automotive design. It consists of a series of functions each designing to a single solution, a point, represented by the red dot in Figure 1. In this illustration, styling comes up with its best single solution based on styling criteria and "throws it over the wall" to marketing which develops the best marketing plan it can based on what styling has handed it, and so on. Of course, this is a simplification as there are feedback loops, but the feedback from downstream functions comes late, often after upstream functions have a considerable commitment to a particular solution. And typically the feedback consists of specific critiques that lead to minor changes to the base design.

Serial engineering is fraught with shortcomings, so concurrent engineering, as usually practiced, addresses those problems by bringing more feedback upstream earlier, generally through a lot of face-to-face meetings. When we have investigated typical concurrent engineering practice in the US, we observe a process that looks something like Figure 2. A function such as styling comes up with a design solution and very early in the process shows it to other functions for their input. These downstream functions analyze and critique the design from their perspective, often in a meeting room. Since this is done early, changes to the styling design are relatively easy and inexpensive, and ideally the design team will soon arrive at a solution that will satisfy all parties. This certainly is an improvement over serial engineering as feedback loops are shorter and more prevalent. But the basic picture remains the same: the design team is iterating on one solution. We call it "point-based concurrent engineering."

Problems with such an approach arise when engineers try to actually work concurrently with other development team members. As the design passes from group to group for critique from different functional perspectives (or even if they are critiquing it as a cross-functional team), every change causes further changes and analysis, resulting in rework and additional communication demands on the organization. There is no theoretical guarantee that the process will ever converge, and in fact the development organization never gets a clear picture of the possibilities.

In SBCE, though, design participants reason, develop, and communicate about sets of solutions in parallel and relatively independently. As the design progresses, they gradually narrow their respective sets of solutions based on additional information from development, testing, the customer, and other participants’ sets. As they narrow, they commit to staying within the sets, barring extreme circumstances, so that others can rely on their communication. Figure 3 illustrates this process of parallel design and convergence we call "set-based concurrent engineering." SBCE assumes that reasoning and communicating about sets of ideas leads to more robust, optimized systems and greater overall efficiency than working with one idea at a time, even though the individual steps may look inefficient.

To date we have discovered only one company whose practices are wholly consist with the SBCE paradigm. Oddly enough, we observed that Toyota does not use many practices often considered critical to successful concurrent engineering, such as dedicated and co-located teams and Quality Function Deployment (QFD). At the same time, Toyota is a world leader in product development effectiveness in terms of lead time, design quality, productivity, and efficiency. Toyota’s high performance in product development, we believe, is due in no small measure to its adherence to SBCE principles.

You can find additional information about SBCE in the following papers:

DK Sobek, A. Ward, J. Liker, "Principles of Toyota’s Set-Based Concurrent Engineering Process," working paper (contact dsobek@ie.montana.edu for a copy).

A. Ward, J. Liker, J. Cristiano, DK Sobek. "The Second Toyota Paradox: How Delaying Decisions Can Make Better Cars Faster," Sloan Management Review, Vol. 36, No. 3, Spring 1995.

J. Liker, DK Sobek, A. Ward, and J. Cristiano "Involving Suppliers in Product Development in the US and Japan: Evidence for Set-Based Concurrent Engineering," IEEE Transactions in Engineering Management, Vol. 43, No. 2, May, 1996.

A. Ward, DK Sobek, J. Cristiano, and J. Liker "Toyota, Concurrent Engineering, and Set-Based Design," a chapter of Liker, et al. (ed.), Engineered in Japan: Japanese Technology Management Practices, New York: Oxford Press, 1995.

A growing body of research integrates elements of predicate logic, constraint satisfaction techniques, and the Set-Based Design paradigm into tools for automating parts of design problems complicated by multiple sources of uncertainty. Uncertainty in the precise value of system parameters enters design problems from many sources, including: manufacturing variations, operating conditions, operator adjustments, etc. One objective for this work is to provide computer tools to automate engineering calculations on sets of variations and support set-based product development processes.

Quantified relations (QR's) are a new class of design constraints among sets of variations, and one contribution of this work. Their patterns of predicate logic quantifiers represent when and how different sources of variation affect engineering systems. This expressive capacity allows QR inference mechanisms to make correct inferences about feasible sets of variation in many situations where conventional set-propagation techniques (e.g. interval mathematics) fail.

Set-based extensions to constraint satisfaction problems ground this work in a large body of computer science and AI research. Since quantified relations are just another type of constraint, a variety of constraint satisfaction techniques, including consistency and search, may be applied to networks of quantified relations. These algorithms form the basis of set-based design software tools.

To illustrate one application of interval propagation to engineering design, consider the pneumatic actuator shown in Figure 4. Force, pressure, and cross-sectional area are related by

which is derived from the physics underlying the mechanical system. For simplicity, assume the actuator is a custom-designed component so that piston area is treated as a continuous variable. Suppose the cylinder is connected to a pressure regulator that is accurately adjustable to any value between 50 and 100 psig. Also, from past experience, the designer knows that the piston cross-sectional area is between 1 and 2 square inches. Closed intervals represent these design variations, P=[50, 100] and A=[1, 2] respectively. Given the regulator and range of cross sections, a straightforward application of interval mathematics calculates the interval of possible forces:

However, assume the designer now wants to restrict actuator force to values between 50 and 200 pounds. Assuming the same pressure regulator, what effect does this constraint have on allowable piston areas? Solving the force-pressure-area relation for a, interval propagation returns

This result is clearly incorrect: a 3 square inch piston at a regulator pressure of 100 psig yields a 300 pound actuator force, which violates the constraint. Therefore, [0.5, 4] can not be the interval of feasible cylinder cross-sectional areas.

Quantified relations, and their associated inference mechanisms, are now used to make the correct inference about feasible piston cross sections.

This simple design problem is complicated by two sources of variation: the adjustable pressure regulator and the designer's range of piston cross sections. Although few engineers speak this way, one verbal description of the design constraint limiting actuator forces might be: "For all feasible cross sections and all pressures between 50 and 100 psig, there exists a force between 50 and 200 pounds that satisfies f = p a." An equivalent predicate logic expression for this constraint is

which is a design constraint among the set of cylinder cross sections available to the designer, A, the set of regulator pressures, P, and the set of allowable forces, F. In this set-based approach, constraints on the memberships of P and F impose a constraint on the membership of A.

Now, the QR inference mechanism makes the correct inference. It takes the quantified relation with the assigned sets and returns an upper bound on the membership of A. Calculations are guided by the QR's pattern of quantifiers and the monotonicities of the force-pressure-area equation. Formally, the inference is given by

That is, in order to satisfy the design constraint, the set of cylinder cross sections available to the designer must be a subset of [1, 2]. (Compare this result with the A=[0.5, 4] returned by interval propagation).

The advantage of QR representations is that their patterns of quantified variables represent part of an engineering systems causal information, i.e. how and when different variation sources affect the values of system parameters. In this example, the quantified relation represents the dependence of actuator force on the designer's decision and the regulator setting. Also, the universal quantifier () on p represents the designer's inability to control the regulator pressure, so the design must work for all pressure settings. In contrast, conventional interval techniques do not make these distinctions. These methods treat all system parameters identically, which can lead to incorrect inferences, as demonstrated above.

 = related research Website = email address

 Attention! If you would like to add yourself, your business, or your research group
to these pages please contact Bill Finch.

This Website is completely my fault. Questions, comments, gripes, or praise to wfinch@mit.edu.