|
Implementing Axiomatic Design in the Systems Engineering Process: An Axiomatic Design Capability Maturity Model
Hintersteiner J. D., Zimmerman R. C.
1st International Conference on Axiomatic Design, 2000
Since its inception, Axiomatic Design has been applied to a wide variety of both engineering and non-engineering problems in numerous disciplines. Recent theoretical developments have further expanded its ability to represent complex engineering systems. The scope of Axiomatic Design usage, however, has traditionally been limited to particular applications or projects. Axiomatic Design, however, can be most useful as a design management tool applied across an engineering organization’s Systems Engineering processes. The benefits of this approach would be both in technical areas related to the quality of the organization’s designs as well as financial benefits in the effectiveness of Axiomatic Design in decreasing the organization’s time to market and ultimately increasing customer satisfaction with more functional and more reliable products. The success of such an implementation effort requires not only integrating Axiomatic Design methodology into all aspects of engineering practice, but also measuring and tracking the organization’s capability and effectiveness in Axiomatic Design, in order to continuously refine and improve the integration efforts. To this end, an Axiomatic Design Capability Maturity Model has been developed, in order to provide a roadmap for implementation as well as coherent metrics that can be applied to determine which activities are successful and which activities may require improvement.
|
|
A Treatise On System Reliability and Design Complexity
Trewn, J., Yang, K.
1st International Conference on Axiomatic Design, 2000
The quality improvement process of reliability assessment and improvement is often a post design exercise that is traditionally practiced on the component level of products as a post design validation exercise. This article defines system reliability from a function delivery perspective that lays the foundation for reliability improvement in the concept design stage.
|
|
Addressing Changing Customer Needs By Adapting Design Requirements
Hintersteiner, J. D.
1st International Conference on Axiomatic Design, 2000
One of the most important aspects of the product development process is to develop an understanding of the true needs of the customer that must be satisfied by the design. While fine in principle, this understanding is very difficult to achieve in practice, as there is usually not a one-to-one correlation between the stated needs of the customer and the corresponding requirements that the design must satisfy. Accordingly, great effort must be made by product designers to translate the needs and desires of the customer into appropriate functional requirements and constraints for the design. Because customer needs often change during the product development cycle, the requirements of the design may change dynamically. For a design to be a success, therefore, it is vitally important for designers to understand the impact of changing customer needs on the design requirements.
|
|
Concept Level Naval Surface Combatant Design in the Axiomatic Approach to Design Framework
Whitcomb, C. A., Szatkowski, J. J.
1st International Conference on Axiomatic Design, 2000
The design of ships is an inherently complex process. This complexity is significantly increased when the particular ship being designed is a naval surface combatant. Naval combatant designers, or more appropriately, design teams, must not only address the factors common to all seagoing vessels such as hull form, propulsion, and maneuverability, but additionally must consider the selection, placement, and interaction of sophisticated weapons systems and sensors. The ship design process is traditionally viewed as a highly coupled collection of interrelated physical attributes often determined in an ad hoc fashion. Therefore, lack of understanding and documenting the design progression frequently necessitates modification of a completely developed, functionally acceptable portion of the ship because of its adverse effect on other functionally unrelated parameters. This paper proposes a methodology based on axiomatic design principles that strives to eliminate the currently accepted iterative nature of concept level ship design. By implementing this approach, the ship design process follows a repeatable structured format in which functional relationships between physical parameters are mapped, documented, and controlled. The AAD method is applied to a ship synthesis model, and a new ship design process is defined and coded to illustrate the utility of the method.
|
|
System Definition for Axiomatic Design Aided by Object-Process Methodology
oderborg, N., Crawley, E. F., Dori, D.
2nd International Conference on Axiomatic Design, 2002
This paper suggests ways to improve formulation of Functional Requirements and Design Parameters in Axiomatic Design based on the contention that adequate descriptions of both function (WHAT) and architecture (HOW) require a combination of objects and processes. We describe how the definitional framework and expressive power of Object-Process Methodology can be used to represent system function and architecture. We introduce Object-Process Methodology templates for describing function and architecture, and apply these templates as an example to a simple system.
|
|
On Learning and Executing Axiomatic Design in The Engineering Industry
Bathurst,S.
3rd International Conference on Axiomatic Design, 2004
The principles of Axiomatic Design, although logical, often do not match conceptual design methods of engineering industry. Most engineering organizations try to inspect quality into the design process in the form of gate review processes with corrective change actions taken when problems observed. Iterative design cycles are common in industry. The Axiomatic design process attempts to form a rational design synthesis intended to eliminate iterations and produce the desired result in one design cycle. In order to fully take advantage of the organizational and analytical benefits of Axiomatic Design high level restructuring of an organization’s design process can be required. This restructuring effort requires a large commitment of resources and energy. This process can be extremely difficult if the engineers involved have an incomplete understanding of the methods of applying Axiomatic Design. This paper draws on experience gained teaching Axiomatic Design principles to engineers in industry. It summarizes some of the problems engineers commonly have with the Axiomatic Design learning process and it also presents suggested methods for effectively conveying an understanding of Axiomatic Design. It includes ways in which functional requirements are often misunderstood by engineers in industry as well as what parts of the axiomatic approach are most important to be communicated and understood completely. This paper discuses how important it is for a student of Axiomatic Design to apply its principles to design examples relevant to the students current design activities and offers suggestions about how engineers can adapt their existing design systems to make them compatible with coupling analysis.
|
|
A Fractal Representation for Systems
Hintersteiner, J. D.
Tech Papers
Proceedings of the 1999 International CIRP Design Seminar, Enschede, the Netherlands, March 24-26, 1999. To facilitate the design of evolving systems, tools are needed to capture all performance issues and evaluate design ideas and proposals quickly during the conceptual stage, so that better designs can be generated. By using such tools, engineers can quickly identify and understand how their design decisions impact and are impacted by choices made concerning other components in the system. Thus, rational design decisions will be made during conceptual design, minimizing if not eliminating the need to address design problems during implementation.
|
|
Integrating Software into Systems: An Axiomatic Design Approach
Hintersteiner, J. D. and Nain, A.
Tech Papers
Proceedings of the 3rd International Conference on Engineering Design and Automation, Vancouver, B. C. Canada. August 1-4, 1999. Today’s increasingly complex electromechanical systems require extensive use of software control to achieve necessary functionality. However, software design efforts for complex systems tend to be made only after most, if not all, of the hardware has been defined. As a result, the software often bears the burden of achieving the system’s desired functionality. While software is more flexible than hardware, the software design can often be greatly simplified with minor changes to the hardware design, if the software and hardware designs are done concurrently. Such unnecessary software complexity can have detrimental effects on the system in terms of safety and reliability under unusual operating conditions, as well as complicating upgrades and product redesigns. This paper proposes a methodology, based upon Axiomatic Design, for facilitating the design of software control systems in conjunction with their corresponding hardware systems. In the Axiomatic Design framework, a system is defined in a hierarchical structure known as a system architecture, where the specifications for the command and control logic, which is typically implemented in software, appear at each level of the design hierarchy. Thus, the design of the system software is distributed throughout the design of the system hardware. To apply this technique, programming terms are defined and their roles are explored in the Axiomatic Design framework. Next, a template is developed that represents system software and serves to highlight the functionality required to control and coordinate the various activities of the system hardware. A case-study example of a robot calibration routine is examined to illustrate these methods.
|
|
Command and Control in Axiomatic Design Theory: Its Role and Placement in the System Architecture
Hintersteiner, J. D. and Tate, D.
Tech Papers
Proceedings of the 2nd International Conference on Engineering Design and Automation, Maui, HI. August 9-12, 1998. This paper describes how system command and control may be integrated into a system architecture. There are two key questions addressed: First, how does command and control fit within the decomposition- on which branches and at what levels are its functional requirements (FRs) and design parameters (DPs)? Second, what are the functions of command and control algorithms at different levels of the design hierarchy- what are their inputs and outputs? Our conclusions illustrate that the decisions about hardware components are made as part of the processes to which they belong; thus, the hardware components (DPs) that are controlled are distributed among several branches of the design hierarchy. Additionally, each module within a process has local software algorithms associated with it for its control. At higher levels of the design hierarchy, there are other algorithms responsible for coordinating the modules below it. Thus, software control algorithms exist at multiple levels of the design hierarchy. By properly structuring the design hierarchy in this fashion, design choices can be made about system command and control in a non-iterative manner and remain consistent throughout multiple levels of the design hierarchy.
|
|
System Architecture Template
Hintersteiner, J. D. and Friedman, G.
Tech Papers
White Paper. Last revision: April 22, 1999. This document provides the standard templates for system architecture tables, along with complete descriptions, for hardware systems3. The following template should be used when applying Axiomatic Design (AD) to a system design project. This template is intended to provide a consistent format for the system architecture (SA), which can be used as a standard format for representation and design reviews.
|
|
A Roadmap For Decomposition: Activities, Theories, and Tools for System Design
Tate, Derrick
Tech Papers
Thesis, Massachusetts Institute of Technology, February 1999. Many design theories lack scalability to systems with many elements. They provide guidance to designers about specific facets of a design task but are too cumbersome to apply thoroughly from conceptual to detailed design. Thus the opportunity for rational design is missed. Axiomatic design (AD) seems ideal for directing the design of large systems because it proposes general principles and a recursive design process. AD provides a fundamental basis for understanding decision making during design. It contains representations for the design object (a hierarchy of functional requirements, design parameters, and design matrices) and the design process (decomposition and zigzagging) combined with rules for decision making (the independence and information axioms). Challenges remain, however, in implementing the theory to large system designs.
|