Matrices and Axioms in Axiomatic Design Principles (Part 2)

MATRIX OPERATIONS
In Axiomatic Design, matrix operations are used to analyze the relationship between customer needs and design parameters. Functional requirements are defined by weighting factors for each design parameter as shown in Equation 1. Weighting factors may be a Boolean True/False, integer value, or any other method of relating the variables.

Equation 1 – Axiomatic Design Matrix

Many designers opt to use Boolean values to relate design parameters to functional requirements. This simplifies calculations as false results provide a zero result. An example of using Boolean values in the design matrix for a Beech Baron 58 tail-cone redesign can be shown in Figure 1 below [8].




Figure 1 – Design Matrix for Beach Baron 58 [8]
By decomposing design domains into hierarchical Functional Requirements and Design Parameters, a relationship can be formed between customer and design requirements after conducting the design matrix operation. Care must be taken to ensure that functional requirements are correctly defined at the correct level hierarchy otherwise confusion in the mapping process may result [8] A list of example functional requirements and design parameters can be seen in Table 1.

The ad-hoc nature of decomposition lends itself to unreliable results. Insufficient decomposition will lead to errors. Similarly, too much decomposition results in violation of the Information Axiom which invalidates the result. A method of zigzagging between adjacent design domains is recommended to reduce errors and ensure that functional requirements, design parameters, and process variables are created in each major design domain [9].

Table 1 – Functional Requirements and Design Parameters for Chess Playing Robot [10]
INDEPENDENCE AXIOM
The Independence Axiom states that functional requirements must be independent from each other. This means that functional requirements must be both mutually exclusive and collectively exhaustive. The requirements of the design goals must be fully captured by the functional requirements [11].

By maintaining the Independence Axiom, no functional requirement mandates the inclusion of another functional requirement. Similarly, the converse is true. No functional requirement may exclude another functional requirement through requiring exclusive features [11].

As an example of the Independence Axiom in use, consider a supermarket. Two items that are typically bought are bread and milk. These items are placed on the opposite far ends of the supermarket. This maximizes the time spent in the store which has the net effect of maximizing exposure to other products. If the functional requirements were to minimize walking time while maximizing time spent in the store, these functional requirements would violate the independence axiom. It can be inferred that maximizing time in the store was not a functional requirement. Instead, the functional requirements could be to simply maximize exposure to products while minimizing walking time [12].

INFORMATION AXIOM
The Information Axiom requires that the informational content of a design be minimized. This is accomplished by minimizing the ranges of potential design parameters. These parameters can be considered as x-direction ranges on a Gaussian curve where the probability of a set of ranges forms the dependent variable. The goal of the Information Axiom is to minimize the applicable area of the Gaussian curve [3].

To continue the supermarket analogy, a simple design tends to work best. In order to have the simplest design for the customer, a supermarket could be arranged like a Kanban work cell where the entrance and exits are on opposite ends of the building. A valet service moves the customer’s car from the entrance lot to the egress lot. The path the customer takes maximizes their exposure to products to purchase while minimizing the chance of having to circle back. This would minimize the complexity of the customer path length [12].

Page 1
Page 3
Page 4

Leave a Reply