The Faucet Reloaded: Improving Axiomatic Design by Example

Axiomatic Design Theory and Complexity Theory have made large impacts in the research of design methodologies, but a major obstacle to widespread use is the challenge of teaching it. A standard example used for educating students on the importance of coupling in Functional Requirements involves the difference between a two-valve and a lever-type faucet. Unfortunately, this simplistic example has its limitations in implementation due to imbalances in pressure and temperature variation. Strangely enough, these limitations turn out to be inspirations for expanding the example to make it better for teaching Axiomatic Design and Complexity Theory. In this work, we update the faucet example to map it to real-world application. Secondly, the concepts of ‘Information in Design’ and ‘Complexity in Axiomatic Design’ are explained from a perspective that increases understanding and acceptation by students and learning professionals. Lastly, we highlight other illustrative examples in manufacturing including the Manufacturing System Design Decomposition.


Introduction
Teaching by example is such a common practice in the modern education system that we don't think bout it.
In the case of Axiomatic Design, the traditional example for learning about the possible coupling between functional requirements (FR) is the problem of designing a proper faucet [1] [2, p7,50-55]. Oddly enough, this example does not show up in Suh's first book on the subject "Principles of Design" [3]; instead, an similar example discussing the design of a Reaction Injection Molding (RIM) system is discussed. The first reference to Axiomatic Design of a faucet is by Swenson and Nordlund in 1996 in an unpublished report which is not available on the Internet [4]. This example was developed by Gunnar Sohlenius in the early 1990's during a visit with Nam Suh at MIT to make the newly-developed independence axiom easier to explain. This example was first published in 2001 [1]. In particular, he wanted to make it very clear what the difference between a coupled and uncoupled design was [5].
In the standard example, we consider two FRs that must be fulfilled: The traditional faucet design has these DPs: [2, p.7]. DP 1 Opening angle of hot water valve, φ 1 DP 2 Opening angle of cold water valve, φ 2 e-mail: foley@ru.is and results in a coupled design matrix (Eq 1): When instead a lever-type faucet is used which is able to separately match flow and temperature, these DPs are presented: DP 1 ' Handle lifting DP 2 ' Handle moving sideways This new design has an uncoupled design matrix as shown in Equation 2.
For this purpose, the different kinds of faucets do a great job of simplifying the explanation of these two states. However, students who go home to test the concept on their lever-type faucets are quickly disappointed by the fact that it doesn't seem to be true.

Going deeper into the land of faucets
Joseph T. Foley, this paper's Icelandic author discovered these implementation problems with this example in his kitchen ( Figure 1). The kitchen faucet has a pair of valves that are connected to a single valve stem. Pulling the valve stem out increases the flow, and rotating it up and down changes the temperature mix, at least in theory. From an outside inspection, this design has the same interface as the traditional "uncoupled" faucet design used in the example. The internal mechanism is not immediately obvious but one can expect it to be a linkage or cam adjusting the flow in the two valves. One would guess that this is the ideal configuration.
Unfortunately, this is not the case. From an interface standpoint, this design is clearly superior, but the implementation leaves a lot to be desired. As can be shown in the simple tests in Table 1, the two values are not independent 12 . The question is what is wrong with this faucet or perhaps what could be wrong with the ideal faucet design described? Foley attempted to balance the different hot and cold water pressures (more about that later) using the pressure regulation supply valves coming from the wall. This did not correct the problem, but at least found a consistent set point at one flow rate that gave consistently pleasant water temperature when the temperature was set to the middle.
Suh goes further with this exploration of the faucet design in [1, p120-124] focusing particularly on the design of the valve gates to ensure that the mixed proportion is independent of the total valve aperture. This goes a long way towards improving the practicality of teaching the faucet example, but it is often overlooked.
This type of faucet has an additional time-independent weakness that exposes a teaching moment in the faucet example. It is often assumed that the water pressure in both the hot and cold are very similar and that the hot temperature is not hot enough to give the user a significant burn. Having a similar pressure and temperature gives a wider range of aperture sizes that will provide the desired temperature and flow rate. Both of these assumptions are false in Iceland, where the hot water is 72 • C and comes out at approximately twice the pressure of the cold water. To make matters worse, the pressures and temperatures vary greatly from region to region depending upon how the geothermally heated water was extracted and regulated at the point of entry in the house. This means that a set of apertures as mentioned in [1] would need to be highly customized for Icelandic environments, otherwise the range of outputs would be very limited. A time-dependent element is missing from the example that becomes apparent when something affects the pressure. We often assume that the hot water coming from a supply pipe is already at the maximum temperature; in reality it often takes significant time for the stagnent water in both pipes to reach the expected values. The flushing of a toilet or the filling of a dishwasher can cause the cold water pressure to suddenly drop and burn the user. In the case of the kitchen faucet in Figure 1, activation of the dishwasher caused the temperature to jump from 37 • C to 50.819 • C with n = 23, σ = 0.304 33 • C, and SE = 0.066 41 • C. Needless to say, this can cause a bit of a surprise to someone taking washing their hands or taking a shower, to the point of possibly jumping out at high speed and becoming quite injured. This is a significant enough problem that the US Massachusetts plumbing code 10.10.7.e states: "The water supply to a shower head shall be supplied through a Product-accepted individual thermostatic, pressure balancing or combination thermostatic/pressure balancing valve complying with ASSE 1016. The device shall conform to the following require-  In Foley's bathroom, there is a faucet that is much closer to the Axiomatic Design idea ( Figure 2): a thermostatic mixer. This valve has an active temperature-control element that biases the spring used for mixing the hot and cold water together. A similar mechanism was developed for temperature-sensitive commercial applications such as photographic developing as far back as 1933 [8]. This faucet was able to meet the Axiomatic Design ideal of decoupling the temperature and flow rate, at least from the perspective of the user as shown in Table 2. The temperature was maintained steadily at full flow even when the toilet was flushed with a mean of 44.0594 • C, n = 32, σ = 0.766 58 • C, and SE = 0.135 51 • C.

What happened to the customer?
Interestingly enough, those who are familiar with traditional bathroom sink basins are witness to a different view of this coupling. In traditional English bathrooms, the hot and cold faucets are separate. This is because in the old times, the way to wash one's face was always by mixing water in a bowl, rather than a basin; in some cases, there wasn't any temperature control at all. This shows another element of the customer's need that is often forgotten in the faucet example. It is assumed that the customer desires a precise flow rate Q to be satisfied, or that there even is a flow during use. This is highly unlikely to be the case: most of the time a flow rate just needs to be above a minimal amount. In Axiomatic Design terms, it means that we are misclassifying a Functional Requirement which should really be a Constraint [9,10]. Once this transformation is complete, the two-FR example in Eq. 1 becomes a single-FR (Eq. 3) which can be easily solved by picking an initial value that meets the minimum flow requirement and increasing the other flow until the desired temperature is met. In practice, this is how people often solve the faucet problem, as inferior as a solution it may be.
The other question is why are the clearly "inferior" two separate valve arrangement such as the one in Figure 3 still used? This is a question that is valuable for students to consider; the simple answers are cost and tradition.
What is missing from the way that the faucet is often taught is refocusing back on the customer. What does the customer actually want out of a faucet? El-haik emphasizes this as a critical step and suggests using Quality Function Deployment (QFD) to define Customer Attributes and FRs. [2,5] Ulrich and Eppinger [11, p35] suggest a six-phase approach that starts by first describing the scope of the effort, then gathering raw data from the customer. We should be starting with the Customer Needs, then talking about the coupling in the FRs; otherwise, we might be solving the wrong problem! When teaching the faucet example, Foley starts by posing just such a question and examining the possible responses regarding how the faucet should be used: 1. "Warm water, but not too hot" 2. "38 • C water at 1. and doesn't actually care about the flow rate. This person may have trouble describing what "warm" means and may not have thought about how it will be used. Foley's comfortable temperature ranges for cleaning his hands were between 33-41 • C. The second customer who wants precise temperature and pressure probably wants a carefully calibrated temperature-controlled valve system; hopefully, they are ready for the large cost associated. For this customer, an information analysis is critical to ensure that the tolerances of the designed valve system meet their needs. The third customer is more specific than the first one and has a specific purpose in mind. The last customer is asking for an innovative sterilization system which a normal faucet will probably not fulfill. These are each different design problems! To summarize, to make the faucet example even better, we need to use it to: 1. teach students to evaluate the level of coupling through experiments, 2. work with customer needs and be confident that they are right before proceeding to functional requirements, 3. get a better understanding of the tolerances so that information can be evaluated.
The concepts of information and complexity are often a source of difficulty for students to understand; in the next section, we discuss some tactics to make the subject more approachable.

Information and Complexity in Design Reloaded
The concept of 'Information in Design' is probably even more difficult to explain by example than the concept of Independence; information in design is (i) an elusive understanding as it does not refer to the information about the design but about its behavior, and (ii) it seems to work in reverse with what you would expect, as being informed is usually a good thing and therefore information must be a positive quantity. To understand Information in Design it is good to go back to its origin.

Murphy's fame comes from ignorant designers
Information, as applied in Axiomatic Design, was initially proposed in Shannon's Information Theory [12] that in its turn was inspired by the concept of 'Entropy' as defined by Boltzmann [13]. Boltzmann proposed a scientific relation, the Boltzmann equation for ideal gases, that explains the relationship between the entropy of a certain quantity of gas and the number of ways the atoms or molecules of such a thermodynamic system can be arranged. Boltzmann's definition of entropy and Shannon's definition of information are very similar as was clarified by Weaver in the explanatory introduction of the book 'The Mathematical Theory of Communication' [14]. Weaver explains how information should be interpreted; as he states that 'the word information in communication theory relates not so much to what you do say as what you could say' meaning that information refers to the number of possible states of a particular situation. Applied on the problem of communication, as originally intended by Shannon, it explains the number of ways a transferred message could be interpreted, analog to the Boltzmann equation for the arrangement of molecules. More general, Weaver defines information as 'a measure of one's freedom of choice' and as such information is an indicator for the extent to which an incident or system is defined. This definition of information reduces its elusive character but the intuitively inverse effect remains; it is confusing that, in order to satisfy the Information Axiom, information in design is undesirable and it should be reduced. About this aspect, Weaver's statement; 'a measure of one's freedom of choice' must be viewed from the perspective of the system itself; in Axiomatic Design, that system is the product design. It may seem inappropriate to think of a product design as something being associated with a stochastic characteristic but this is exactly what the information theory aims at; a good design is constrained to good behavior and there is no room left for any undesirable nature, simply because a well structured product design intrinsically eliminates all undesirable states of the design. Structure stimulates desired actions and excludes faulty behavior and therefore misperformance of a product design may be considered a consequence designers dispose of themselves because they do not have their business apart. Murphy's law is the result of underperformance of the designer by leaving a product design underconstrained. Because of this, the product design has options for behavior within a certain 'freedom of choice', and as a result, it will randomly select one of the available options. Some of these options may lead to unwanted behavior. Summarized, freedom of choice within a product design, analog to information in design, will lead to the stochastic revelation of its behavioral options. As not all of these options show a positive outcome (usually there's only a single option with positive outcome), it means that the product design is not able to perform within expectations.

Addressing the 'Lack of Regularities' in design
Further interpretation of information is made by Gell-Mann and Lloyd [15]. Gell-Mann and Lloyd relate information as defined by Shannon to 'Ignorance' or 'Uncertainty' and its cause is found in a 'Lack of Regularities' of the considered system (in our case a product or system design). Given the fact that designers are idealistic people that try to regulate their design as good as possible, and assumed they are provided with enough time and means to do so, the lack of regularities will be reduced as much as the knowledge of the designer permits. It means that acquisition of the right knowledge will lead to further reduction of regularities in design; this consideration makes information inversely related with 'knowledge of the designer'. In a situation where the designer has unlimited time and resources to acquire and implement the right knowledge, the product design will be fully regulated and therefore it will have no freedom of choice in its operation other than the envisioned way by the designer; as a result, information is eliminated from the system and all FRs of the product design will be satisfied. This leads to a more accessible way to deal with information in design. Information in Axiomatic Design is a measure for the lack of regularities in a product design and it leads to uncontrollable behavior of the system; for this reason, the Information Axiom advises to reduce information and as a result, reduce the lack of regularities in the design.

Bringing it together from the perspective of the Axioms
In line with this insight, a similar view may be applied on complexity in Axiomatic Design. Complexity in Axiomatic Design is defined as 'a measure of uncertainty in achieving the specified FRs', and as such, it is the result of a lack of regularities in the design. The four kinds of complexity in Axiomatic Design are (i) Real Complexity, (ii) Imaginary Complexity, (iii) Combinatorial Complexity, and (iv) Periodic Complexity. To understand these four kinds of complexity it is required to have a good overview of the basic role of the Axioms. Axiomatic Design facilitates the designer through two design phases [16,17]: • The 'Conceptual' design phase, by satisfaction of the Independence Axiom making sure that the designer is 'doing the right things'; • The phase of 'Robustness', by the satisfaction of the Information Axiom making sure that the designer 'does the things right'. Now, things get a little tricky; though both Axioms apply regularities to the design, and as such, they both reduce the information in design according to the Shannon definition, however, only the contribution of the Information Axiom addresses 'information in Axiomatic Design'. This is an inheritance of the initial definition of information in Axiomatic design, where information is limited to the Information Axiom [3]. According to good practice in Axiomatic Design, independence in design is adequately addressed by the design matrix. As a result, application of information in design is not practically relevant for the Independence Axiom, and it was not applied for the theory behind it. For the Information Axiom, it indeed was a central theme and it was applied very effectively to address the many little things that address robustness of a product design. The result of these elementary choices is that the definition of information in Axiomatic Design is a subset of information in design according to Shannon and Weaver; in Axiomatic Design, it only addresses robustness, and according to the definition of Shannon, it addresses conceptual rigor and robustness. The same may be said for the definition of information according to Gell-Mann and Lloyd; 'a lack of regularities' is valid for both phases (conceptual and robustness). These different perspectives are inventoried in Figure 4. This concludes the tricky part. Now, let's see how the different kinds of complexity are placed into this context. Imaginary Complexity deals  with a lack of conceptual regularities that directly affects the Design Matrix (or vice versa). Real Complexity deals with a lack of regularities in design that affect robustness and this is equal to information in Axiomatic Design. The other kinds of complexity, Combinatorial Complexity, and Periodic Complexity, are specific versions of real complexity. These last two are 'Time-Dependent' kinds of complexity that, though they are basically the same, they may change as time passes, contrary to Imaginary and Real Complexity that are basically not affected by time. Figure 4 shows the complexity theory of Axiomatic Design and how it can be reloaded.
• Imaginary complexity can be considered as a lack of regularities in composing the design matrix; • Real complexity is related to a lack of regularities in matching the design and system ranges; • Periodic complexity is due to a lack of synchronization of processes; • Combinatorial complexity is a lack of organization of processes that influence each other.
Finally, in theory it is possible to distinguish more forms of complexity, e.g. 'Time-Dependent Imaginary' kinds of complexity, where even the FRs may change, and though they are referred to in literature [18]

Manufacturing System Design Decomposition
Design relationships as represented by the axiomatic design equation using matrix notation is one way to communicate the relationships of a design. For large systems, with multiple levels of decomposition, an alternative to the matrix notation is a graphical illustration of the design in the form of a tree or decomposition. The Manufacturing System Design Decomposition (MSDD) uses axiomatic design to express the multiple FR and DP relationships that must be achieved simultaneously for a manufacturing system to become lean [19][20][21]. Lean is a name for the consequence of implementing a manufacturing system design. The MSDD communicates the manufacturing system design by relating high-level requirements to lowerlevel DPs [22]. This representation of a manufacturing system design provides a framework for innovation and further extension. Extension of the MSDD means the inclusion of additional FR-DP relationships; innovation may require new FRs and DPs. Extension of the MSDD becomes apparent because of the knowledge of path dependency that is depicted in Figure 5. Path-dependent designs are also called partially coupled or decoupled designs [3]. The figure is arranged so that, at a given level of the decomposition, the DP that affects the most FRs is located on the left side, and then the DP that affects the next most FRs is next. The result of this arrangement of DPs is that the implementation sequence of DPs is identified. The benefit to the user is to understand the implementation priority and sequence of implementation of the DPs.
The structure of the MSDD illustrates the FRs that branch from a parent DP. With axiomatic design, a practical rule of thumb is to create a lower level of the design when there are two of more FRs that the parent DP, level above, must accomplish. For example, a DP0 will branch into multiple lower-level FRs. The parent-level DP is a noun that describes a physical solution that encapsulates and amalgamates the FRs defined in the next, lower-level of the design.
The graphical tree structure used to depict the axiomatic design of the MSDD provides a succinct and unambiguous understanding of the flow down of high-level requirements to lower-level requirements and rationale for the choice of the lowest-level DPs.

Conclusion
This paper has presented three different ways that Axiomatic Design teaching can be improved. The independence axiom focus on the standard faucet example has been expanded with a larger "product design" focus to include the customer. It also gives the opportunity to integrate time-dependent complexity as part of the analysis. Next, the challenging topic of "information" in the Shannon sense has been restated in terminology and concepts that are more approachable to students. Finally, we address the often discouraging appearance of the design matrix by restating it as a tree structure that maps design requirements and solutions as developed by the MSDD.

FR-R1
Respond rapidly to production disruptions

DP-R1
Procedure for detection & response to production disruptions

DP-P1
Predictable production resources (people, equipment, info) σ t X t σ p Fig. 5. Upper levels of the MSDD illustrating left to right implementation sequence of DPs [22].