Since the 1960s, the idea of externalizing design from human designers and constructing executable design systems has been explored. Currently computers are used in the design field primarily for graphic representation, solid modeling, product modeling, optimization of design solutions, and simulation. Use of computer technology (Computer-aided design and manufacturing – CAD and CAM – and many software analysis tools) has significantly reduced the time required for developing new products and solutions.
Since computers are becoming ever more powerful and cheaper, they should also be used in design to store codified information and to augment human capabilities. More recently, the formalization, representation, and manipulation of knowledge in computers have made it possible to construct knowledge-based design (KBD) systems. Such systems have the potential to produce both fundamentals changes in design and better designs [Coyne et al., 1990].
The objective of KBD is to facilitate effective product design and manufacturing activities through the whole lifecycle of product. To achieve this long term goal, various types of knowledge on products, their manufacture, use, maintenance, and other life- cycle activities should be turned into reusable resource, and the resulting life-cycle knowledge should be deployed during the product development and manufacture, particularly during the early design stages (conceptual design) [Mäntylä, 1996].
KBD systems require a large-scale design repository in which design knowledge is intensively and systematically stored so that efficient search and retrieval of deign knowledge could take place. Design knowledge has two categories; i.e., design object knowledge (such as geometric and product modeling) and design process knowledge. For example, a mechanical engineering design process requires various kinds of design object models, such as geometric model, kinematic model, and finite element model. Design
knowledge must be systematically formalized, made computable, and organized in order to achieve flexible, efficient, effective reuse and sharing of knowledge.
Knowledge representation and manipulation languages or formats, such as Knowledge Intensive Engineering Framework, KIEF [Yoshioka, 2000], Knowledge Interchange Format, KIF [Genesereth and Fikes, 1990], and Knowledge Query and Manipulation Language, KQML [Finin, McKay, and Fritzon, 1992], are used to formalize and make knowledge computable. The objective of this type of languages is to establish a unified language/format to represent knowledge so that different agents, such as software tools, designers, and databases, can express, share and reuse existing knowledge by searching and retrieval.
Since product development lifecycle is a process in which designers use various kinds of knowledge, it is difficult to collect, store and prepare all necessary knowledge before design. Also, the necessary knowledge is largely fragmental, scattered, and stored in different format and different places. This makes the communication and exchange among design experts, tools or design agents difficult. Therefore, it is an essential to develop and use advanced computer environment, which has the capabilities such as; good data and knowledge representation, efficient programming features, adequate mechanisms for storage and concurrency control and good communications with other software systems, and providing mutual communications among those involved in every stage of the product life cycle. Therefore, unified or standard knowledge representation languages or formats, such as KIF, KQML, and DKSL, are an essential part of any KBD system.
There are various software tools that are used in product development lifecycle to help manage and coordinate the different phases and activities of the lifecycle as well as to develop, store, and retrieve lifecycle knowledge such as requirements, design parameters, test cases, etc. Presented below is a list of some of the available tools and their use.
Table 2.9 – Software tools for design and development lifecycle
Tools Usage
Acclaro DFSS http://www.axiomaticdesign.com/
Acclaro DFSS software implements axiomatic design technology for product and systems development with a complete suite of DFSS tools to reduce development risk, reduce cost and speed time to market.
Teamcenter http://www.ugs.com/
Teamcenter’s PLM digital enterprise backbone allows you to manage all of the diverse processes throughout your extended enterprise, as well as across the planning, development, manufacturing, and support domains of your product lifecycle.
Product Development System (PDS)
http://www.ptc.com/products/product_development_system.htm
PTC‘s Product Development System (PDS) delivers precise management of digital product data along with every aspect of the product development process.
MS Project http://www.microsoft.com
Project management, scheduling, and resource planning. Cradle http://threesl.com/
Cradle is a multi-user, multi-project, systems engineering environment that spans the entire systems and software development lifecycle. Cradle provides a suite of tools that integrate all project phases, activities and deliverables within a single, configuration managed, access controlled framework.
Rational® RequisitePro®
http://www-306.ibm.com/software/awdtools/reqpro/
The IBM® Rational® RequisitePro® solution is a requirements and use case management tool for project teams who want to improve the communication of project goals, enhance collaborative development, reduce project risk and increase the quality of applications before deployment.
CORE Systems Engineering Tool
Vitech Corporation ( http://vitechcorp.com )
The CORE product family provides a flexible combination of modeling and simulation tools supporting product and process engineering.
GoldSim Pro GoldSim
Technology Group ( http://www.goldsim.com/software )
GoldSim Pro is a general-purpose simulator suitable for modeling any type of business, scientific, and engineering system that can be expressed mathematically.
CHAPTER III
III AXIOMATIC PRODUCT DEVELOPMENT LIFECYCLE (APDL)
The AD method provides a robust structure and systematic thinking to support PDL activities; however, it does not support the whole product development lifecycle [Tate and Nordlund, 1995]. The same logic and scientific thinking can be used and extended to capture, analyze, and manage the product development lifecycle knowledge. The Axiomatic Product Development Lifecycle (APDL) model utilizes the systematic nature of the AD method in order to provide a systematic approach for product development lifecycle activities and management.
The APDL improves the AD in the area of domain entity description and management and takes the AD method one step further to support the test domain of the product development lifecycle.
The AD provides two axioms and many theorems and corollaries to evaluate the quality of design solutions. The first axiom also influences the selection and formation of the functional requirements so that they can be achieved independently by the proposed design solution. However, the AD does not provide guidance on determining the quality of the requirements. The AD also does not provide any guidance or standardization for description of the requirements.
Although the constraints are defined to be in the Functional Domain, only the FR characteristic vector exists in this domain in the AD method, the constraints are not captured in a characteristic vector. Moreover, the relationships between customer needs (CNs) and FRs and between CNs and constraints are not captured in matrix form in the AD method.
The AD does not specifically support testing and verification activities. Testing and verification activities and concerns are generally not considered to be a factor in deciding the quality of design. However, keeping testing and verification concerns in
AXIOMATIC PRODUCT DEVELOPMENT LIFECYCLE (APDL)
mind makes sure that the requirements are verifiable and the design activities are performed to meet these verifiable requirements. Verifiability should be one of the quality factors for functional requirements.
In the AD, the domain that contains the DPs is called the physical domain; however, the DP hierarchy does not necessarily represent the physical structure of the system. A component can provide the design solution expressed in more than one DP or multiple components can be required to achieve the design solution represented by a DP [Tate, 1999]. The DP hierarchy can be totally different from the component hierarchy as in the case of the beverage can example given in Suh, 2001 pg. 17. Thus, the AD does not capture the true physical architecture of the system.
The APDL model is developed to over-come these short-comings of the AD method as far as the product development lifecycle is concerned.