Introduction to Axiomatic Design Concepts
Used by individuals as well as Fortune 100 development teams, axiomatic design processes bring value to development organizations in diverse industries including software, business processes, automotive, aerospace, semiconductor, medical, government and consumer products.
Axiomatic design technology reduces product development risk, reduces cost and speeds time to market by:
- Formalizing the conceptual design process into a continuous and measurable activity driven by requirements.
- Communicating the state of the design to all stakeholders at the earliest possible moment, well before traditional CAD documentation.
- Improving quality of design by analyzing and optimizing design architectures.
- Providing explicit traceability from Customer Needs to Requirements to Design Logic to Design.
- Clearly documenting and communicating the logical ‘How and why’ of a design, not just the ‘What’ of CAD documentation.
- Permitting design issues to be identified early and resolved without the cost of design-build-test-redesign cycles.
- Providing project management with the dependency structure of the design, enabling optimal scheduling and risk mitigation.
Axiomatic Design Concepts
Whether the design solution is a tangible product, service, software, process, or something else, designers typically follow these steps:
- Understand their customers’ needs
- Define the problem they must solve to satisfy these needs
- Create and select a solution
- Analyze and optimize the proposed solution
- Check the resulting design against the customers’ needs
The axiomatic design process guides designers through these same steps. They can use all of their existing design tools and software and efficiently arrive at a successful new design, or diagnose and correct an existing design.
There are four main concepts in axiomatic design:
- domains
- hierarchies
- zigzagging
- design axioms
The fundamental concept of axiomatic design is that of domains, one for each kind of design activity:
For each pair of adjacent domains, the left domain represents “what we want to achieve,” while the right one represents the design solution of “how we propose to achieve it.” The contents of each domain are:
Customer | The benefits customers seek |
Functional | Functional requirements of the design solution |
Physical | Design parameters of the design solution |
Process | Process variables |
For example, in the customer domain, suppose the customer needs to preserve food. There are several means to accomplish this in the functional domain, such as canning, dehydrating, or cooling the food. From these choices the designer selects cooling and then decides on a refrigerator in the physical domain. The process domain describes how to manufacture the refrigerator.
Definitions associated with the domains in axiomatic design are:
Functional requirement | Functional requirements (FRs) are a minimum set of independent requirements that completely characterize the functional needs of the design solution in the functional domain. |
Constraint | Constraints (Cs) are bounds on acceptable solutions. |
Design Parameter | Design parameters (DPs) are the elements of the design solution in the physical domain that are chosen to satisfy the specified FRs. |
Process variable | Process variables (PVs) are the elements in the process domain that characterize the process that satisfies the specified DPs. |
Decisions in one domain are mapped into the domain on its right. In the earlier example, the need in the customer domain for preserving food was mapped into cooling the food in the functional domain, then this functional requirement was conceptualized as a refrigerator in the physical domain. This shows how the “What” in the left domain is mapped into the “How” of the right domain: Food preservation (“What”) maps to cooling (“How”); in turn, cooling (“What”) maps to refrigerator (“How”); and lastly, refrigerator (“What”) maps into the manufacturing process (“How”).
The mapping is represented by a design matrix which shows the relationships between FRs and DPs, and between DPs and PVs. This is an example of a design matrix:
DP1 | DP2 | DP3 | |
FR1 | X | O | O |
FR2 | X | X | O |
FR3 | X | O | X |
An X or O in a cell indicates whether the column’s DP affects the row’s FR or not. In this matrix, DP1 affects all three FRs, while DP2 affects only FR2, and DP3 affects only FR3. Instead of a simple X or O, each cell can contain the mathematical relationship between the FR and the DP. Design matrices contain a wealth of information about the design and are central to the application of axiomatic design.
The second main concept of axiomatic design is hierarchies, which represent the design architecture. Beginning at the highest level, the designer selects a specific design by decomposing the highest-level FRs into lower-level FRs. This can be done once the highest level DPs are chosen. Decomposition proceeds layer by layer to ever lower levels until the design solution can be implemented. Through this decomposition process the designer establishes hierarchies of FRs, DPs and PVs.
Continuing the refrigerator example, the highest-level FR, FR1, is cooling the food. Since the highest-level DP is a refrigerator, the next-level FRs would be:
FR1-1 | Keep the food within a specified temperature range, T±DT |
FR1-2 | Maintain a uniform temperature within the box |
The third main concept of axiomatic design is zigzagging that describes the process of decomposing the design into hierarchies by alternating between pairs of domains. In the previous paragraph, FR1 (cooling food) decomposed into FR1-1 (keeping food within ?T) and FR1-2 (keeping temperature uniform). These lower-level FRs are valid only for the DP we chose, a refrigerator; if, instead, we had chosen to can the food, the lower-level FRs would be different. Therefore, the designer follows a procedure of zigzagging between the “What” and “How” domains to the lowest level of the hierarchies, as the arrows indicate in the figure above.
The fourth main concept is the two design axioms:
Axiom 1 The Independence Axiom | Maintain the independence of FRs: In an acceptable design, the DPs and the FRs are related in such a way that a specific DP can be adjusted to satisfy its corresponding FR without affecting other FRs. |
Axiom 2 The Information Axiom | Minimize the information content: Among alternative designs which satisfy Axiom 1, the best has the minimum information content which means the maximum probability of success. |
Designs which do not satisfy the Independence Axiom are called coupled. An everyday example is a typical water faucet. The two FRs are “control the temperature” and “control the flow rate.” The two DPs are the hot- and cold-water handles. This design is coupled because it is impossible to adjust either DP without affecting the other FR: Each handle affects both temperature and flow rate. | |
Designs which satisfy the Independence Axiom are called uncoupled or decoupled. The difference is that in an uncoupled design, the DPs are totally independent, while with a decoupled design, at least one DP affects two or more FRs. As a result, the order of adjusting the DPs in a decoupled design is important. In the above example, the two FRs- “control the temperature” and “control the flow rate” are independent. One DP does not effect the other so this design is uncoupled. |