Axiomatic Design Principles in the Context of Systems Engineering (Part 2 of 2)

Read Part 1 here

STAKEHOLDER REQUIREMENTS DOMAIN

The stakeholder requirements domain is characterized by expressing the customer's needs. This domain thus describes the customer needs as the "CN" value of an axiomatic design study. Stakeholders may be interviewed or surveyed to determine the applicable needs that the system must meet [3].

The chief difficulty in ensuring a correctly configured stakeholder requirements domain is that stakeholder requirements may not be the same ones the designated design engineers have picked [3]. As a result, the design team must translate customer needs into system requirements accurately.

These needs may be created accurately by following a process recommended by Buede [3,13]. First, the operational concept must be created for the product. This will include the development of a system boundary. The objectives of the system must be placed in a hierarchy. The stakeholder requirements and system requirements must be created and included in this structure. The feasibility of the proposed structure must be evaluated. The system will be bench-marked to ensure that it meets the expected needs. Finally, everything will be documented accordingly. Documentation may be accomplished via SysML or another modeling system.

FUNCTIONAL ARCHITECTURE DOMAIN

Functions of a design are transformative actions carried out by portions of the design to act upon the system. Functions may transform a material, store energy, or exchange signals as well as many other tasks. Functions are grammatically transitive verbs that act upon an operand. Functions must be solution-neutral and may not presume a technology or solution [3].

The functional architecture domain is the home of the functional requirement. Functional requirements can best be considered a result of inputs from the shareholders regarding the needs of the product. Customer needs can therefore be said to drive functional requirements. All functions of the product must also be functional requirements. Similarly, all functional requirements must correspond to product functions. This ensures that the product does what it is desired to do. Functional requirements are thus mutually exclusive and collectively exhaustive [3].

In some cases, functional architecture exists before the design action. Not all engineering design actions are for new products. Many legacy systems are inherited by design engineers that must be modified to meet new customer requirements. Reverse engineering of an existing product's functional architecture is an acceptable axiomatic design method for inherited products. One method of creating a functional architecture is using SysML to create a model. These models should incorporate activity-based diagrams that show the general purpose of the product. Additionally, models should be created that utilize state machines.

State machines indicate the sequence of responses to stimuli that a given system will produce throughout an input/output cycle. State machines should provide an output for every input with provisions for resetting back to an initial rest state at the conclusion of expected inputs [14]. The final type of diagram that should be created for functional architecture is a use case diagram. These diagrams enumerate and express the interactions external to the product. By combining these tools together, design engineers can ensure that functional requirements are robust and authoritative [3].

PHYSICAL ARCHITECTURE DOMAIN

The physical architecture domain can be said to contain the design parameters used in axiomatic design. Design parameters are vital in understanding how well customer requirements are being met by the design in question. Design parameters are examined in terms of how well they accomplish the functional requirements determined through interviews with the stakeholders of the product as well as market surveys of the area in which the product will be deployed. The physical architecture domain contains the modules and components synthesized into block and parametrized diagrams [3]. SysML contains tools to easily convert design parameter data into block diagrams for use in axiomatic design.

These block diagrams can describe both physical and nonphysical systems. As both types of systems benefit from axiomatic design, systems composed entirely of software can be modeled similarly to physical systems. An example of a block diagram formed using SysML can be found in Figure 2. This block diagram describes the software that drives a music-purchasing website in terms of the design parameters required for operation [15].

This system allows for elements of the physical architecture to be enumerated without resolving the required performance characteristics. This allows for performance characteristics to be defined without placing constraints on the value of said performance characteristics. As this set of characteristics does drive axiomatic design from a linear algebra perspective, physical architecture can be expressed as a weighted square matrix [3].

PROCESS ARCHITECTURE DOMAIN

Process architecture is the axiomatic design domain concerned with the manufacturing processes associated with a design. This domain deals exclusively with manufacturing processes and the relationship of these processes to the product. Process architecture converts manufacturing constraints to a format that can be treated similarly to customer requirements. This ensures that the product can be readily produced [3].

DOMAIN MAPPING

The traditional Design Structure Matrix system can accomplish domain mapping. To cross between domains, a zig-zagging method is recommended. Functional requirements are mapped to design parameters by crossing from the applicable domain and returning. This ensures that all design parameters are appropriately matched to functional requirements. An example of this zig-zagging system can be seen in Figure 3.

However, this method may be improved upon by utilizing a newer method known as the Engineering Systems Matrix. This allows multiple domains to be simultaneously evaluated in the context of all system drivers, regardless of type. The engineering systems matrix operates as an improved system-level modeling framework. It can be most readily visualized as a multiple domain Design Structure Matrix adaptable to other design tools. This system incorporates a newly developed tool called Qualitative Knowledge Construction [17] to improve engineering design results. An example of an Engineering Systems Matrix can be seen in Figure 4.

In seeking to incorporate qualitative design information into an engineering framework, Bartolomei realized that engineers tend to focus on non-human components of a system. Bartolomei felt this was a major failing of modern design theory. As qualitative information is typically developed through interviews, observations, and surveying, Bartolomei created a method to parametrize this data. Bartolomei converted this information into a text form and coded it based on nodes, relationships, and attributes. This was incorporated into the engineering systems matrix he had developed. Using a database system, the data was loaded into appropriate cells to develop a matrix framework [17].

By converting observational and interview-based data into a quantitative system, it is possible to analyze this data using quantifiable matrices objectively. As information coding allows social scientists to explain data, so too does it allow engineers to synthesize design results to ensure the requirements imposed by the data are met [17]. To systematically code data, the Qualitative Knowledge Construction process should be followed.

The boundaries of the system(s) of interest must be defined. This ensures that the system type is recognized and understood by the designer. Early attempts at modeling the system or understanding the existing model should be made. Data collection should with sufficient rigor to clearly define the system [17].

Next, the objectives to be analyzed must be defined. This must be abstract enough to be readily viewed by the engineer while maintaining enough detail to contain useful information. If necessary, iteration may occur to clearly define the objectives in particularly large systems such as major production lines or especially complex systems [17].

Once the objectives are known, complete data collection must occur. This data collection typically involves interviews with the stakeholders, market surveys, or the collection of engineering data. Existing CAD models, finite element models, and written documentation should be explored fully to ensure a total understanding of the system and the requirements is complete [17].

Once the data collection is complete, it can be coded accordingly. The Engineering Systems Matrix framework allows for six classes of coding to occur. Coding classes are defined for stakeholders, system drivers, activities, functions, objects, and objectives. Coding is accomplished by extracting data artifacts from the data collected previously. For example, an interview with a worker identifying a client would result in the client being coded as a stakeholder.

Each subsequent relationship that the client has would be coded as a related attribute for that stakeholder cell. When the objective of that client is discovered, the objective would be coded as a related objective cell to the stakeholder cell. Other relationships between the original stakeholder and the original objective found with other stakeholders and objectives would then be related accordingly [17].

After completing coding, the model should be audited for mistakes and omissions. Since all systems goals should have at least one corresponding element, omissions should be obvious. Similarly, cells that do not align with any requirement should be evaluated for relevancy to the system. Missing data should be resolved by further research or additional interviews [17]. At this point, multiple domains have been mapped, and the axiomatic design process may continue.

GAPS IN RESEARCH

Axiomatic design is a robust system that has seen substantial refinement over the years. As a result, the majority of gaps present are in the interrelationships between axiomatic design and similar design methodologies. One such set of gaps exists in the Theory of Inventive Problem Solving (TRIZ). TRIZ has had substantial studies in combining TRIZ methodologies with axiomatic design principles. Kim and Cochran conducted a similar review of TRIZ and axiomatic design. They concluded that the differences found in TRIZ and axiomatic design are primarily due to the development focus of the two systems.

Axiomatic design was founded with a central theme of inflexible design axioms. The inductive study of patent databases founded TRIZ. TRIZ cannot calculate the sum of undesirable functions; rather, discerning undesirable characteristics must be resolved using axiomatic design. Similarly, axiomatic design cannot innovate new functional requirements identified mid-design. This is solved in TRIZ by using the law of increasing ideality. This allows for design evolution toward an ideal solution [20].

TRIZ allows for a wide set of tools to be used in design. TRIZ is regarded as a mature design methodology that may be combined with axiomatic design to produce a unified design theory [21]. It has been observed by Mann, however, that the two systems are not fully compatible. Unfortunately, the analytics-based axioms from axiomatic design sometimes conflict with TRIZ. While both design methodologies attempt to codify design metrics, TRIZ attempts a much broader view of engineering design. This causes conflict immediately due to TRIZ focusing on an idealized concept rather than a material resolution. The ideal axiomatic design would include a decoupled solution that meets each functional requirement. The ideal TRIZ concept is a solution that requires no physical manifestation [22].

Although this may seem counter-intuitive, it can best be explained as an external system taking on the role of solving the problem such that no physical product is required. Using the example of a sink faucet temperature/flow lever, axiomatic design would indicate that the ideal solution is a sink faucet control valve that allows for flow rate and temperature control by one lever. The TRIZ ideal concept would be one where flow rate and temperature control are not required as the problem of improper flow rate, and temperature have been eliminated by an outside source. The sink could always receive water with a regulated temperature with an on-demand flow rate when an individual approaches the sink. This has solved the problem without requiring a sink flow/temperature control lever [22].

Although TRIZ and axiomatic design are sometimes at odds, some researchers have found that some conflicts may be resolved through abstracting design parameters. This abstraction occurs specifically when dealing with coupled axiomatic design parameters. Duflou and Dewulf found that by replacing specific design parameters with generic engineering parameters during the domain mapping phase of axiomatic design, conflicts were eliminated between axiomatic design and TRIZ [23].

Within both the axiomatic design and TRIZ methodologies, there exist irreconcilable conflicts that arise during design. In TRIZ, the primary source of conflicts comes from physical conflicts where an object must exist in mutually exclusive states [20]. This can be defined as a situation where an element must have a property to perform one action. At the same time, it must also have an opposite property to perform a separate, simultaneous action. This can be resolved by separating properties such that conflicts do not arise. These direct contradictions can be eliminated by ensuring that axiomatic design concepts are not permitted. If design parameters are held to constraints, functional coupling is minimized, and design matrices are non-triangular, TRIZ contradictions should not arise [20].

Ogot found that the strength of axiomatic design was chiefly in the problem identification and formulation steps. Ogot compared this to the strength of TRIZ which was in problem identification and concept generation. The conclusion reached by Ogot is that conflicts between TRIZ and axiomatic design can be resolved by utilizing axiomatic design within the context of a TRIZ framework. Specifically, axiomatic design was used for early-stage elaboration up to and including generating an engineering systems matrix and resolving the linear algebra steps inherent to axiomatic design. At this point, Ogot shifted to TRIZ for concept generation and elaboration. By siloing axiomatic design and TRIZ in this way, conflicts were minimized [24].

FUTURE OPPORTUNITIES

Axiomatic design sees frequent use in modern design engineering. It has become so widespread that there has been a conference held every year since 2006 devoted to axiomatic design. The International Conference on Axiomatic Design sees presentations on the modern usage of Suh's axiomatic design principles as applied to today's engineering problems.

One recent submission to ICAD was an Internet of Things-enabled CNC machine teleoperator. This system allowed a remote operator to have virtual control of some CNC system functionality. As this requires a smooth interaction between hardware, software, data flow, people, and manufacturing processes, axiomatic design principles were used to ensure all functional requirements could be met with the proposed design from Oliveira et al. This system used 11 defined customer needs, 5 design constraints, 5 functional requirements, and 5 design parameters spread across two tiers of operation [25]. Without axiomatic design as a design tool, this system may not have been possible.

The axiomatic design has also seen adoption in other design methodologies. Additive manufacturing is a novel method of creating products and components that removes many limitations associated with casting, forging, and injection molding. As a result, design methodologies must adapt to this new technology.

One common problem with modern design methodologies is that they frequently ignore the unique opportunities afforded by additive manufacturing technologies. Thus, costly redesign may occur later in the product development cycle than necessary. To combat this shortfall, Salonitis has proposed incorporating axiomatic design into the emerging field of Design for Additive Manufacturing [26]. By ensuring that axiomatic design practitioners have an existing framework for incorporating AM technologies, Salonitis hopes to improve the adoption of rapid prototyping and additive manufacturing technology in the design space.

Quality Function Deployment and axiomatic design principles have synergistic effects when used together. Quality Function Deployment uses design tools such as House of Quality and relationship matrices. The House of Quality system allows for weighted relationships to be established between customer needs and design requirements as well as mapping attributes from one phase of design to the next in a way similar to axiomatic design [2,27,28].

It is no surprise that the two would see simultaneous deployment in design. To demonstrate this, a case study was presented by Gilbert, Omar, and Farid involving lifecycle-based construction of temporary housing.

According to Marchesi, Kim, and Matt, modern architectural design requires a more rational approach concerning appearance, costs, and performance [29]. This is in part due to the growing complexity faced by developers to ensure that all stakeholders are satisfied with the result. Typical design procedures in temporary housing often ignore using formal design methodologies such as QFD and axiomatic design.

As a result, complex designs tend to see cost overruns. This is frequently blamed on failing to ensure that customer requirements are treated systematically to ensure resolution [30]. As a result, the construction industry is increasing its reliance on design tools such as QFD and axiomatic design [31]. Although combining the two processes have been proposed previously, prior proposals have not streamlined the incorporation of both processes [32]. Future civil engineering projects will likely see seamless incorporation of these design methodologies. One such example can be seen in modifying the house of quality to incorporate axiomatic design principles as shown in Figure 7.

The cells from Figure 7 are arranged as follows:

1. Customer Needs (CN)
2. Relative Importance of CN
3. Planning Matrix
4. Technical Requirements
5. Non-Functional Requirements
6. Constraints
7. Functional Requirements
8. Non-functional Requirement Interrelations
9. Constraint Interrelations
10. Functional Requirement Interrelations
11. Non-FR/Constraint Relations
12. Constraint/Functional Requirement Relations
13. Non-functional Requirement/Functional Requirement Relations
14. Direction of Improvement
15. Relationship Between Customer Needs and Technical Requirements
16. Technical Ratings of Technical Requirements
17. Rankings of Technical Requirements

Although complex, this system provides a ground-up redesign of the House of Quality system. By doing this, it allows for seamless switching between axiomatic design and Quality Function Deployment methods. By utilizing this system, designers may find that complex system requirements can be refined to meet customer requirements with a higher degree of accuracy [31].

New linguistic design systems allow the unique application of axiomatic design principles. Knowledge supplier and demander pairing can be accomplished using fuzzy algorithms. These algorithms are used in a knowledge brokering service. Historical versions of these services attempted to make use of numerical matching schemes; however, this was proven to be less effective than linguistic assessments. By imposing Suh's systematic axioms into the algorithm, an improved matching scheme was devised. As a result, proper matching rates were improved in a test case using the improved axiomatic design algorithm [33].

In 2016, a human-driven exoskeleton was discussed at the International Conference on Axiomatic Design. This robotic system was intended to assist in rehabilitating disabled users [34]. This project was built on an earlier work by Tan Zhang. Zhang's work used axiomatic design theory to define multiple use-states for his robot to allow for recovery from damage [35]. This resulted in the robot having a self-healing resiliency characteristic that would later be adopted by Zhu et al. Zhu's work capitalized on the resiliency characteristic of Zhang while adapting the lessons learned into a novel system.

This system translated customer requirements based on the patient's needs into design requirements for lower limb dysfunction correction and assistance. Further use of axiomatic design principles can be found in incorporating customized walking gait features in the exoskeleton. Customer requirements necessitated this ergonomic solution. Additionally, axiomatic principles can be found in features as fundamental as the drive system. Zhu et al. write that determining the sizing of the drive system was based primarily on the bio-compatibility of the device for each user. Due to the sheer volume of requirements of this design, an 11x11 matrix was necessary to map functional requirements to design parameters [34].

Some researchers have proclaimed that axiomatic design exists as one of the most promising methodologies being developed in the area of conceptual design systems. Ashtiany and Alipour state that the ability of axiomatic design in innovation is superior to other methods. They cite the design of an airplane tail section as an example. The Beech Baron 58 tail section was designed using modern engineering methodologies such as Quality Function Deployment, Axiomatic Design, Design for Manufacturing, and several other novel methods. For this project, functional requirements were given such as trim moments and wing vortex generation. Design parameters were composed of component sizing. By utilizing these engineering design methodologies, a redesign was made possible for this aircraft [8].

Incorporating axiomatic design with other modern engineering tools has also shown success. In redesigning a grading bin system in the foodstuffs industry, it was determined that weld joins saw excessive failure. By combining axiomatic design principles with finite element modeling, a new design was created that met the customer needs for a robust, durable transfer bin system [36].

Similarly, system decomposition principles have been combined with axiomatic design principles to create novel designs. In 2016, an electromechanical steering system was developed by Schuh, Rudolf, and Breunig by way of decomposing the system into mechatronic function modules. Due to the difficulty of integrating disparate fields of technology together into one coherent package, the axiomatic design was married together with the mechatronic function module system to achieve a product. This allowed for the creation of a function-oriented product that made use of modular systems [37].

In engineering design, reliability engineering supports the longevity of products while ensuring that they are properly tested and maintained. Because axiomatic design leads to improving design concepts, treating reliability as a customer need allows for improvement in the product's lifespan. Shao, Lu, Zeng, and Xu analyzed traditional reliability engineering and axiomatic design principles [38].

Traditional reliability design considers a systematic analysis of life-cycle limiting items. One drawback of this system that was discovered was that reliability engineering does not lend itself well to the original design of a system. To combat this shortcoming, Shao, Lu, Zeng, and Xu recently developed the axiomatic quality and reliability methodology as shown in Figure 8.

This system utilizes Quality Function Deployment, axiomatic design, conceptual design methods, and parametric-based design to accomplish the goal of providing the customer with a long-lived solution [38]. By considering the implementation of axiomatic design into other engineering sub-disciplines, the engineering field can be developed.

CONCLUSIONS

Axiomatic design has proven itself to be an invaluable tool for design engineers seeking to design complex systems efficiently. Through new developments in the field such as SysML and TRIZ incorporation, the ability to describe functional requirements of large, complex systems has blossomed into an entire field of study. New technologies are constantly being developed that readily incorporate axiomatic design such as software APIs and robot firmware. With the expansion into other engineering disciplines such as civil and biomedical engineering, axiomatic design sees a bright future ahead of it. As design engineers continue to expand upon the field through new developments, axiomatic design will continue to be adopted as a standard engineering practice to ensure customer requirements are met by the design.

REFERENCES

[1] Suh, N. P., 1998, “Axiomatic Design Theory for Systems, Res. Eng. Des., 10(4), pp. 189-209.

[2] Pahl, G., Beitz, W., Feldhusen, J., Grote, K., 2007, Engineering Design: A Systematic Approach, Springer, London.

[3] Farid, A. M., and Suh, N. P., 2016, Axiomatic Design in Large Systems.

[4] Brown, C. A., and Henley, R., 2016, Metrics for Developing Functional Requirements and Selecting Design Parameters in Axiomatic Design, Procedia CIRP, 53, pp. 113-118.

[5] Hazelrigg, G. A., 1999, An Axiomatic Framework for Engineering Design, J. Mech. Des., 121(3), p. 342.

[6] Hazelrigg, G. A., 2009, The Cheshire Cat on Engineering Design, Qual. Reliab. Eng. Int., (25), pp. 759-769.

[7] Suh, N. P., Cochran, D. S., and Lima, P. C., 1998, Manufacturing System Design, CIRP Ann. - Manuf. Technol., 47(2), pp. 627-639.

[8] Ashtiany, M. S., and Alipour, A., 2016, Integration Axiomatic Design with Quality Function Deployment and Sustainable Design for the Satisfaction of an Airplane Tail Stakeholders, Procedia CIRP, 53, pp. 142-150.

[9] Tate, D., 1998, A Roadmap for Decomposition: Activities, Theories, and Tools for System Design, MIT.

[10] Ãmarsttir, F. Y., lafsson, R. B., and Foley, J. T., 2016, The Axiomatic Design of Chessmate: A Chess-playing Robot, Procedia CIRP, 53, pp. 231-236.

[11] Suh, N. P., 1995, Axiomatic Design of Mechanical Systems, J. Mech. Des., 117(B), p. 2.

[12] Black, J., 1991, The Design of the Factory with a Future, McGraw-Hill, New York

[13] Buede, D., 2009, The Engineering Design of Systems: Models and Methods, Hoboken.

[14] Roth, Charles, Kinney, L., 2014, Fundamentals of Logic Design, Cengage, Stamford

[15] Freidenthal, S., Moore, A., Steiner, R., 2012, A Practical Guide to SysML: The Systems Modeling Language, Elsevier Ltd, Amsterdam.

[16] Castro, J. F. B., Alencar, F. M. R., and Cysneiros Filho, G. A. de A., 2000, Closing the GAP Between Organizational Requirements and Object Oriented Modeling, J. Brazilian Comput. Soc., 7(1), pp. 5-16.

[17] Bartolomei, J., 2007, Qualitative knowledge Construction for Engineering Systems: Extending the Design Structure Matrix Methodology in Scope and Procedure, Massachusetts Institute of Technology.

[18] Ulrich, K., 1995, The role of product architecture in the manufacturing firm Res. Policy, 24(3), pp. 419-440.

[19] Weilkiens, T., 2006, Systems Engineering with SysML/UML: Modeling, Analysis, Design, Elsevier Ltd, Heidelberg.

[20] Kim, Y. S., and Cochran, D. S., 2000, Reviewing TRIZ from the perspective of Axiomatic Design, J. Eng. Des., 11(1), pp. 79-94.

[21] Borgianni, Y., and Matt, D. T., 2016, Applications of TRIZ and Axiomatic Design: A Comparison to Deduce Best Practices in Industry, Procedia CIRP, 39, pp. 91-96.

[22] Mann, D., 2002, Axiomatic Design and TRIZ: Compatibilities and Contradictions, Proc. ICAD2002, 44(1225), pp. 1-7.

[23] Duflou, J. R., and Dewulf, W., 2011, On the complementarity of TRIZ and axiomatic design: From decoupling objective to contradiction identification, Procedia Eng., 9, pp. 633-639.

[24] Ogot, M., 2011, Conceptual design using axiomatic design in a TRIZ framework, Procedia Eng., 9, pp. 736-744.

[25] Oliveira, L. E. S., and Álvares, A. J., 2016, Axiomatic Design Applied to the Development of a System for Monitoring and Teleoperation of a CNC Machine through the Internet, Procedia CIRP, 53, pp. 198-205.

[26] Salonitis, K., 2016, Design for additive manufacturing based on the axiomatic design method, Int. J. Adv. Manuf. Technol., pp. 1-8.

[27] Olewnik, Andrew, Lewis, K., 2005, Can a House Without a Foundation Support Design?, IDETC/CIE, pp. 1-11.

[28] Hauser, J. R., and Clausing, D., 1988, The house of quality, Harv. Bus. Rev., pp. 63-73.

[29] Marchesi, M., Macello, V., and Matt, D. T., 2013, Application of the Axiomatic Design Approach to the Design of Architectural Systems, ICAD.

[30] Dikmen, I., Talat Birgonul, M., and Kiziltas, S., 2005, Strategic use of quality function deployment (QFD) in the construction industry, Build. Environ., 40(2), pp. 245-255.

[31] Gilbert III, L. R., Omar, M. A., and Farid, A. M., 2016, An Application of Quality Function Deployment and Axiomatic Design to the Conceptual Design of Temporary Housing, Axiomat. Des. Large Syst. Complex Prod. Build. Manuf. Syst., pp. 216-240

[32] Taglia, A. Del, and Campatelli, G., 2006, Axiomatic Design & Qfd: a Case Study of a Reverse Engineering, Proc. ICAD 2006 4th Int. Conf. Axiomat. Des., pp. 1-6.

[33] Chen, X., Li, Z., Fan, Z. P., Zhou, X., and Zhang, X., 2016, Matching demanders and suppliers in knowledge service: A method based on fuzzy axiomatic design, Inf. Sci. (Ny)., 346-347, pp. 130-145.

[34] Zhu, A., He, S., He, D., and Liu, Y., 2016, Conceptual Design of Customized Lower Limb Exoskeleton Rehabilitation Robot Based on Axiomatic Design, Procedia CIRP, 53, pp. 219-224.

[35] Zhang, T., Zhang, D., Gupta, M. M., and Zhang, W., 2015, Design of a General Resilient Robotic System Based on Axiomatic Design Theory.

[36] Gerhard, K., and Foley, J. T., 2016, Redesign of the SureTrack Grader Transfer Bin Using Axiomatic Design, Procedia CIRP, 53, pp. 267-272.

[37] Schuh, G., Rudolf, S., and Breunig, S., 2016, Modular Platform Design for Mechatronic Systems using Axiomatic Design and Mechatronic Function Modules, Procedia CIRP, 50, pp. 701-706.

[38] Shao, J., Lu, F., Zeng, C., and Xu, M., 2016, Research Progress Analysis of Reliability Design Method Based on Axiomatic Design Theory, Procedia CIRP, 53, pp. 107-112.