1. INTRODUCTION
Engineering design is a complex, diverse and knowledge demanding process, during which thousands of decisions, sometimes highly coupled, have to be made under a high number of constraints and restrictions. This intellectually challenging process has attracted many researchers to derive more effective approaches aimed to help the engineering designers to produce an optimal design solution for a given problem within available resources and before a deadline. The research work on design process and associated support tools carried out so far can be categorized as follows:
- Experience-based and extracted methodological approaches that aim to prescribe a rigorous design process model for the engineering designers to follow. These approaches are typified by the widely accepted Pugh's model (Pugh, 1991), Pahl and Beitz model (Pahl & Beitz, 1996), Andreasen's theory of domain and design methodology (Andreasen, 1991a, 1991b), French's design process model (French, 1999), and a recent integrated product development process model (Andreasen & Hein, 2000). These models were developed by generalizing previously used and proven methods and procedures from various industrial practices and case studies;
- Computation-based reasoning approaches and knowledge-based systems, typically represented by systems such as expert systems, knowledge-based, and knowledge intensive computer-aided design (CAD) systems (Bracewell et al., 1995; Sekiya & Tomiyama, 1997), case-based reasoning (Kolodner, 1993), and constraint-based reasoning systems (Medland et al., 1996; Lottaz et al., 1998; Bowler et al., 2001; O'Sullivan, 2002). These approaches take the advantage of computational power and aim to support designers to tackle complex design problems by automating a design process in a designer-controlled manner and externalizing highly correlated design parameters with reasoning and visualization techniques. It is noted that these approaches have potentials to provide much richer and dynamic support for engineering design.
Among the second category of research work, the constraint-based design modeling and solving approach has been shown as a promising actively researched technique.
Focusing on the extensive exploration and advancement of this technique in engineering design, this paper presents a novel underconstrained problem modeling and solving framework, consisting of a method and associated tools. The proposed framework can empower the designers in producing life-cycle oriented and optimized design solutions at both conceptual and embodiment design. The basis of this approach is the provision of insights, in the form of extracted and visually represented relationships, into a vast number of coupled relationships among many design parameters through the use of a generic underconstrained problem modeling and solving technique (Sawada, 1998). The underlying relationships of design parameters can be extracted by this technique and the Design Constraint Solver (DeCoSolver) prototype system has been implemented to demonstrate the principles and feasibility.
Section 2 discusses the typical engineering design process by focusing on the design problem understanding stage where a product design specification (PDS) is generated. This understanding provides a strong foundation for the new life-cycle constraint-based design approach proposed in Section 5 and demonstrated in Section 6. The research work conducted so far in engineering design is also reviewed briefly in Section 2 to establish the foundation of underconstrained design modeling for a suitably defined PDS. This, in turn, facilitates the conversion of a PDS into a set of constraints, which can then be used as the basis to solve design problems. Section 3 describes the theoretical foundation of this research. First, the PDS identification and conversion into constraint are discussed. Second, an introduction to Gröbner base (GB) and quantifier elimination (QE) is given to provide the basis of developing new techniques for insightful design support. Third, conversion of nonalgebraic constraints into algebraic ones is illustrated to generate a set of constraints, which complies with the requirements of a GB theory-based solver. Fourth, the underlying relationships of design parameters found in commonly used mechatronic components are introduced to provide a library of constraint set for these components. Algebraic constraint formalism is introduced in Section 4 to facilitate the constraint-based representation and solving. Section 5 describes a framework based on a novel method using the underconstrained problem solver to tackle design problems. In order to demonstrate the use of the approach and its effectiveness, Section 6 details a case study using DeCoSolver. An evaluation of the approach was undertaken by a combination of application of DeCoSolver in two real design problems, and questionnaire based user evaluation. Section 7 briefly discusses the results of this evaluation.
2. ENGINEERING DESIGN AND CONSTRAINT-BASED DESIGN AND PARAMETERIZATION
This section briefly reviews the relevant work in engineering design and the constraint modeling. In Section 2.1, the paper argues the requirements of generating a more quantitative and much wider set of design constraints specified in an important design document (PDS) in order to facilitate a life-oriented design approach. The feasibility of using constraints has been demonstrated in the systems and relevant work reviewed in Section 2.2. A constraint-based design view is highlighted in Section 2.3 and the application and needs of this technique into life cycle is also reviewed in Section 2.4.
This research aims to combine the requirements for full design exploration and feasibility of deriving a generic constraint-based framework to tackle a wider design problem with more life-cycle considerations and provide a bigger scope for design exploration of solution spaces. The framework can also be used for both incremental and innovative design, being able to tackle single-phase design problems as well as product design with life-cycle consideration.
Although several different design process models have been proposed and prescribed to engineering designers, Pugh's model has been widely accepted because it provides both the breadth and the flexibility in dealing with various engineering design problems. It broadly divides an engineering design process into Task Clarification, Conceptual Design, Embodiment Design, and Detail Design stages. This model is therefore used in this research as the basis of tackling design problems. It is well known from almost all design process models that after the initial market research, the process of generating engineering design solutions starts from task clarification resulting in a PDS (Pugh, 1991), which is a formalized document of needs that the product must fulfill. These product requirements have been categorized into many headings and in Pugh's model there are 32 categories of requirements listed. These include the definitions of the product performance, behavior, legal, packaging, life cycle, and the environment in which the product will be used, and so forth. Appendix A shows part of a PDS for an energy-saving heat-recycling system used in this paper to demonstrate the nature and use of a PDS in a solution generation process.
2.1. PDS as a design problem definition documentation
Further investigation into these definitions and the process of defining them reveals that a PDS is a dynamic documentation and it contains both qualitative and quantitative product requirement definitions. The design process including the PDS generation is usually of an iterative and evolutionary nature. A typical PDS evolves during a design process and becomes a much more refined design document when the designers have more understanding of the design problem. A PDS can be evolved when the design solution space is fully explored. This increased understanding and newly explored solutions often lead to the modification or even dramatic change of the initial PDS. A PDS may change during the design process due to additional specifications, a better understanding of a design problem, and customer's change of their requirements.
It is evident from many students and industrial projects that the initial PDS contains more customer-oriented specifications if the design problem is triggered by them. Techniques such as quality function deployment (QFD; Roozenburg & Eekels, 1995) have been used to define the “voice of the customer” in terms of technical requirements. QFD enables users to make important comparisons about their needs and hence supports better decision making (Crow, 2002). More importantly, these techniques can help designers to precisely define the requirements and convert them into quantitative statements. Hence, a PDS evolves from being vague and qualitative with fewer specifications to concise, quantitative, and more definitions. It is worth noting that the conversion of customer's needs to technical requirements cannot be conducted without a concept of design (Suh, 1990). This implies that to convert a statement in a PDS a conceptual solution is required to put the statements in a context. The above discussion has illustrated that a PDS is an important evolutionary document and should contain mostly quantitative specifications of the product.
2.2. Constraint paradigm
Because of their concise and declarative representations as well as their potential for solving problems, constraint-based design approaches have been employed in many attempts to formalize a design problem as a constraint satisfaction problem (CSP). A constraint in these approaches is defined as a restriction or a declarative representation that does not specify the direction of flow of information. The majority of the approaches reported in the engineering design literature so far have been applied to the embodiment of design, particularly the detailed geometric modeling and configuration of products.
Constraints are used to represent the product geometric model in the computer-aided design embodiment tool (CADET) system (Thornton, 1994; Thornton & Johnson 1996). The IDIOM system (Lottaz et al., 1998) demonstrates the use of constraints in geometric representation and their (de)activation in a layout configuration design. The COCOS system uses an extended CSP model in large-scale system configuration design (Stumptner et al. 1998). FDL (Imamura, 1992, 1995) showed an application of constraints in embodiment design using constraint-based object oriented language. Geometric constraint solving based approaches have been one of the key techniques for parametric modeling. Galileo3 (Bowen & Bahler, 1992; Bahler et al., 1994) illustrated an application of constraints in conflict resolving and management for life-cycle engineering, whereas Redux & CM (Petrie et al., 1995, 1996) proposed an agent-based constraint approach for conflict management in distributed working as is the case for ParMan (Kuokka & Livezey, 1994). Active Semantic Network (Kopsch et al., 1997) demonstrated the use of constraints in CAD models. O'Sullivan (1999) demonstrated the application of Galileo-based constraint modeling in conceptual design and synthesis. Many methods have been proposed and developed for geometric representation and reasoning of engineering design problems to strengthen the geometry dominated CAD system functionalities in both two and three-dimensional space (Mullins & Anderson, 1998; Gao et al., 2006; Sitharam et al., 2006). These approaches, however, only deal with geometrical analysis of design and they do not support life-cycle design considerations and solution exploration in design synthesis.
Constraint satisfaction approaches have also been used to optimize engineering design solutions. In the CADET system, a set of constraints derived from the prestored component library is solved as an optimization problem. CADET essentially converts the CSP into an optimization problem for embodiment design. This approach has demonstrated the power of constraint problem solving in optimization by using the simulated annealing technique. CYCLOPS (Navinchandra, 1991) treated the constraint problem as Pareto Optimal A* combinational search problem to avoid combinational explosion. These optimization approaches, however, tend to give only optimized results, rather than explain the insights to the design problem. This leaves a designer to blindly accept these optimized results without much understanding of the rationale.
From the above brief review, it is clear that constraint-based approaches have mainly been applied in the embodiment design phase and configuration design, focusing on predominantly geometric aspects of engineering design, although there have been limited attempts in applying them in conceptual and life-cycle design (Bowen & Bahler, 1992; O'Sullivan, 2002). In addition, extending its use into optimization does not provide adequate support for designers to explore the design solution space as it solves the problem with a point solution. These approaches are often limited by a strict requirement of user's good understanding of the modeling language or associated techniques before constraint techniques can be used in a real design. There are no user-friendly interaction and interface between most of these systems and the user.
2.3. Constraint-based view of engineering design
As an effective computational approach, constraint-based design tackles engineering design problems by using rigorous constraint satisfaction techniques to generate a feasible design solution space, in which an optimum design solution can be found. This research uses an axiom that design-related considerations for a given design problem can be represented by a number of design parameters from different aspects of design, as often illustrated by previous designs (Imamura, 1992, 1995; Thornton & Johnson, 1996; Kopsch et al., 1997).
The engineering design process is therefore to determine the values for these design parameters satisfying constraints. During this constraint satisfaction process, the design solution space is contracting if a concrete value has been assigned to a parameter, or a new solution space is being revealed and expanded if more design parameters are introduced to define the artifact further or extend its scope. Thus, the design solution space undergoes expansion and shrinking throughout a design process. Using this thinking, engineering design is therefore a process in which the designers are searching an optimum solution within an n-dimensional solutions space, where n is the number of design parameters identified. This concept can be extended to the life-cycle design, in which an artifact meets a number of phases or systems such as manufacturing, assembly, and maintenance (Mortensen & Andreasen, 1996).
Designers are facing increasing difficulties in gaining an insight into the relationships among many parameters, which form a complex design problem. Frequently the designers may have to rely on their intuition or use the trial and error method to determine the values of these parameters. Any design decision made under this circumstance very often results in less optimal design solution, and therefore inferior products manufactured. This challenge will obviously hinder the designer's ability to predict the behavior of the product due to a lack of insights into its solution space.
2.4. Life-cycle and functional design through constraint exploration
Life-cycle consideration of product design becomes increasingly important aspect of today's product development, and has been only partially researched using constraint-based techniques. Design for X tools have been developed to address life-cycle issues for a nearly completed design solution. As argued by Borg et al. (2000), these traditional approaches and associated techniques are typically applied after conceptual design; hence, consideration is “late” as the solution is already generated, and only used for limited life-cycle phases, hence “segmented.” It is important that the life-cycle impact or consequences of design decisions should be considered at the conceptual design stage. If functional, structural, behavioral, as well as life-cycle design requirements are simultaneously considered and explored at conceptual design, a life-cycle oriented design solution is more likely produced. Therefore, the insights into the design parameters' influence on the performance of a design solution are critical for the designers to make informed decisions.
Insights into the potential positive or negative life-cycle consequences (Borg et al., 2000) caused by the decisions made at the early design stage on the design parameters are equally important in the designer's decision making. An early revelation of any negative impact caused by a design decision on any life-cycle phase can prevent a less life-cycle oriented solution produced or rework caused by a lack of life-cycle considerations. These insights and associated tools can therefore support providence and exploration with either least or specific design decision commitments.
Limited research work has been reported in literature on addressing life-cycle issues in design using constraint-based approach (O'Sullivan, 2002). The only work briefly reported is by O'Sullivan on a method to include material recycle requirement in a bicycle design using Galileo. A qualitative design requirement for the bicycle to be recyclable was modeled in a conceptual design demonstration (O'Sullivan, 2002). However, it is not clear how this actually influences the design decision making and the final outcome.
The following key conclusion points from the above literature review are summarized:
- a quantitative PDS can provide an important preformatted design constraint set (DCS) for design problem solving;
- the application of constraint-based problem solving is effective, but the majority focuses on the late design stage-embodiment design, in particular on the geometric aspect of the design;
- they require well-established constraints defined by users and will face a problem with PDS that is difficult to be converted into constraints; and
- they do not adequately support designer's exploration of design solution space, particularly life-cycle design.
3. THEORETICAL FOUNDATIONS FOR PDS CENTERED AND UNDERCONSTRAINED PROBLEM SOLVING BASED DESIGN SUPPORT
This section provides a theoretical foundation to the proposed work. A new framework will be introduced first. The following sections then describe natures of constraints in design in Section 3.2, followed by new Gröbner-based techniques in Section 3.3 and the conversion techniques in Section 3.4, derived to facilitate a new constraint-based design problem solving. As an example, this approach was used to model mechatronic components to form a library illustrated in Section 3.5.
3.1. A new framework proposal
Based on Section 2, this research proposed a new interactive underconstrained problem solving framework to provide insights, at conceptual design, into the holist relationships among many design parameters that have impact on the product performance and cause the life-cycle consequences for the product. It is with these insights shown through extracted parameter relationships that the designers will be empowered to predict more accurately the behavior of a design solution and foresee more life-cycle consequences. New techniques have been investigated to extract parameter relationships to show important design insights into design parameters, including life-cycle and multidisciplinary parameters. This approach is therefore fundamentally different from the traditional optimization-based approaches, where only the optimum solution is given for defined objective functions and there is no freedom for designers to investigate and explore the relationship between design parameters.
In contrary to the existing approaches, this new framework consists of two key techniques. First, a systematic conversion of free form (qualitative descriptive statement) PDS into a constraint-based design problem is proposed. Second, an algebraic underconstrained problem solver based on GB theory (Buchberger, 1985) is developed by researching two key techniques used to detect constraint conflicts and extract design parameter relationships.
By integrating the PDS conversion techniques and Gröbner-based underconstrained problem-solving technique, the proposed approach thus collectively provides an extensive and powerful framework allowing the simultaneous consideration of many life-cycle and multidisciplinary design parameters.
3.2. The natures of constraints in engineering design and their conversion
Even though Pugh's approach encourages designers to quantify the requirement specifications to provide unambiguous definitions of the need, this is not always the case. Issues related to the functional, structural, behavior, and life-cycle aspects of the design specifications can all be converted into a set of algebraic constraints. It may not be possible to generate exhaustively all PDS statements in a quantitative form at this point of time in research, in particular, considering the legal and service-related requirements. It is believed as an axiom that the more quantifiable statements in a PDS, the clearer the design requirements. Based on the above argument, engineering design is defined as a process of converting design specifications into constraint-based representations and subsequently determining the suitable values for all parameters. The formal establishment of a suitable PDS is therefore critical to the constraint-based design in this research.
Two stages of conversion, as shown in Figure 1, are proposed to convert the initial PDS statements to constraint-based design definitions:
- Identify quantifiable PDS statements from free format PDS statements and group them into quantitative PDS (QPDS); group the other into qualitative PDS, which are for human validation and checking after design solutions are generated. The QPDS statements are then converted into the technical requirements.
- These technical requirements are then converted into constraint-based design representations, which require special consideration of converting several types of nonalgebraic constraints into algebraic constraints, which are discussed in Section 3.3.

PDS formalization and transformation from initial customers' needs to a constraint-based design problem representation. [A color version of this figure can be viewed online at www.journals.cambridge.org]
The identification of QPDS and conversion into constraint expressions are detailed first.
3.2.1. Identification and grouping of PDS for technical requirement conversion
Techniques such as QFD, common sense logic, designer's knowledge, and their experience-based intuition may be applied in identifying suitable initial PDS into technical requirements. For example, the life-cycle requirement at the installation phase of the PDS in Appendix A states “The system is to be installed under bathtubs.” Further investigation of the customer/service oriented life-cycle requirement indicates that it must be fitted within a rectangular box of 50 × 20 × 30 cm. Similarly, the performance PDS statement “The heat extraction should be as efficient as possible” can be converted into a quantitative statement, “The heat extraction should be in the range of 45 to 100%.”
Common sense knowledge can also tell one how to convert a customer requirement into a technical requirement. For example, the statement “the product is to be used in the USA” can be converted into “The power supply voltage to the system is 110 volts,” or more universally, “The power supply voltage to the system is 110 volts, 240 volts or 220 volts.”
A further study of PDS categories prescribed in Pugh's models reveals that the majority of performance and behavioral related specifications can be quantified using similar methods. Specifications in the other categories such as packaging, life cycle, and so forth, can be converted into suitable technical requirements. Based on the above illustrations, it is clear that by applying common sense engineering knowledge and further investigation of design problems, engineering designers can identify and rewrite many technical but qualitative PDS statements into quantitative specifications for further conversions into constraint expressions.
3.2.2. Conversion from technical requirement into design constraints
For QPDS statements, design requirements have been clearly defined by both a parameter name and a value specifying a point or range boundary for the parameter. These statements can therefore be converted into algebraic constraint expressions. For example, the technical requirement for the installation illustrated in Section 3.1.1 can then be expressed as
- SystemLength_Installation ≤ 50 cm;
- SystemHeight_Installation ≤ 20 cm;
- SystemWidth_Installation ≤ 20 cm.
As these size constraints are from installation point of view, hence “_Installation” is added to distinguish them from those from other design requirements. Similarly, many QPDS statements can be converted into algebraic expressions.
3.3. GB theory and QE-based underconstrained solving
To facilitate the understanding of a design problem and its dynamic solution space, new constraint-solving methods based on GB theory (Cox et al., 1997) and QE techniques have been derived to provide a comprehensive set of support tools. Two new methods have been proposed and developed in this research to extract fundamental relationships among design parameters, and detect conflicts among algebraic constraints. Due to space limits, only the first new method is introduced in this paper, following the introduction to GB theory and QE.
3.3.1. GB theory and QE and their application
This section illustrates new techniques developed to determined if a constraint set has a finite or infinite number of solutions, that is, well structured or ill structured. Many design problems fall into an ill-structured constraint set. An approach to analyzing ill-structure solutions has been developed to calculate possible design parameter values in this research. Unlike traditional tedious trial and error method in which known design parameter values are increased by assigning some sensible values to certain design parameters, this research developed an algebraic method for this type of problems based on the following.
Let DCS (1) be a constraint set of a design solution space. The set typically consists of a number of equality and inequality constraints represented in the following generic form:

where x = (x1,…, xn), x1, x2,…, represent design parameters identified either through a QPDS as shown in Section 3.1.1 or component specific design parameters generalized from studied components as shown in Section 3.4. fi(i = 1 to p) functions define the equality constraints, whereas gm (m = 1 to q) and hn (n = 1 to r) are inequality constraints.
The above set of constraint representation can be converted to DCS (2) by introducing slack variables s = (s1,…, sq) and t = (t1,…, tr). In this way all the polynomial inequalities in DCS (1) are converted into polynomial equations.

In this research, two categories of constraints are defined to facilitate the discussion. A constraint set is classified as well structured constraint set, if and only if the constraint set results in a finite number of solutions to a given design problem. A constraint set is ill structured if and only if the constraint set has an infinite number of solutions. Algorithms have been developed and implemented in this research to determine if a design problem is a well- or ill-structured constraint set, based on a GB property detailed below. Applying the following GB property (see Cox et al., 1997; Weispfenning, 1997, for more details):
Let F = {f1(x1,…, xn) = 0,…, fp(x1,…, xn) = 0} be a given multivariate polynomial equation set and G be a GB of F. Then, ∀(xi)∃(g ∈ G){ht(g) has a form of xiαi} [hArr ] F has a finite number of solutions, where ht(g) is the head term of a polynomial g, which is defined as the highest term of the polynomial g.
The method generates numerical solutions to DCS 1 by minimizing certain objective functions under the conditions of DCS 1. An objective function u(x, s, t) is introduced to determine the minimum value of the function u(x, s, t) in the boundary or region of A, which is defined by DCS 2 in n + q + r dimensional space. Region A is expressed as

3.3.2. Extracting relationships among design parameters
Relationships among design parameters hold vital design information and can be extracted to help designers to gain insights into these relationships. A set of design solutions is represented as an algebraic surface Eq. (3) in (x, s, t) space, where relationships among design parameters xi1,…, xim are represented as a projection of the algebraic surface on xi1,…, xim subspace. Extracting relationships is therefore equivalent to projecting the algebraic surface Eq. (3) onto xi1,…, xim subspace, represented as

QE techniques can be used to extract explicit relationships among design parameters. However, it is noted that they are computationally very inefficient as a large number of iterations of QE are required to eliminate all the variables of xim+1,…, xin, s1,…, sq, t1,…, tr before explicit relationships can be established. This research proposes a new approach to extracting explicit relationships by combining QE techniques with GB. Relationships among design parameters can be classified into equality and inequality relationships. An equality relationship defines a locus of design solutions, which is a set of points defined by governing design parameters. For a two-dimensional problem, it is represented as a line or curve, whereas in a general n-dimensional problem, it is a (n − 1) dimensional surface. An inequality relationship specifies an area in which design solutions exist.
Assuming that xi1,…, xim represent design parameters of a problem, explicit equality relationships of these parameters are derived as follows:
- Compute the GB G of DCS 2 under the block ordering xi1,…, xim <lex xim+1,…, xin, s1,…, t1,…, tr, where <lex represents the lexicographic ordering (Cox et al., 1997).
- Polynomials that do not contain any of xim+1,…, xin, s1,…, sq, t1,…, tr are selected from G and made to be zero to form a new set of equations, which define the underlying relationships among these design parameters.
For inequality relationships, they are directly or indirectly derived from inequalities t1 ≥ 0,…, tr ≥ 0 shown in DCS 2. The following procedure has been developed to extract explicit relationships:
1. Compute the GB G of DCS 2 under the block ordering xi1,…, xim, t1,…, tr <lex xim+1,…, xin, s1,…, sq, where <lex represents the lexicographic ordering (Cox et al., 1997).
2. Polynomials that contain some of t1,…, tr and do not contain any of xim+1,…, xin, s1,…, sq are selected from G. Make the selected polynomial to be zero to form a set of the equations E = {e1(xi1,…, xim,t1,…, tr) = 0,…, el(xi1,…, xim,t1,…, tr) = 0}.
3. E is then divided into subsets E1,…, Ek so that the following conditions are satisfied:
a. E = E1∪ ··· ∪Ek
b. ∀(i ≠ j)∀(ei ∈ Ei)∀(ej ∈ Ej){There is no common slack variable ta (1 ≤ a ≤ r) in ei and ej.}
Suppose Ej is represented as

where rj is the number of slack variables ta (1 ≤ a ≤ r) appearing in Ej, and pj is the number of equations contained in Ej.
4. The design solution space is then projected onto xi1,…, xim subspace as shown by

Here, E is divided into the subsets of E1,…, Ek and the above logical formula can be equivalently converted into the following formula:

Applying QE to Eq. (5), the inequality relationships among design parameters xi1,…, xim are extracted by eliminating t1,…, tr. Dividing the equation set E into subsets in Step 3 of the above procedure simplifies a large problem into smaller ones and enables the QE to be carried out separately for these subsets, thus providing a possibility to avoid unnecessary computation. In addition, this dividing establishes a clear relationship between each subset and the equation set E, enabling a quick identification of an acceptable design solution area with regard to a small and specific inequality constraint subset. This combined effect is the reason of the new approach being computationally more efficient. This dividing also enables one to trace back to the initial inequality, which defines an area of valid or invalid solutions. This information is vital as they can help designers to identify the inequality constraints, which either overconstrain the design solution space when an error occurs or provide too large a solution space. These relationships therefore provide insights to the design problem defined by these constraints.
Conflicts in an algebraic constraint set can also be detected through the algorithms developed in this research. This essentially involves the identification of a set of inequalities in Eq. (3) that cannot be satisfied simultaneously. Further information can be found in Sawada (2001).
This research adopted an algebraic underconstrained problem solver entitled Risa/Asia and it is based on GB theory (Buchberger, 1985). An interface to the adopted constraint solver has been implemented to access the basic functions available from Risa/Asia. Further information about Risa/Asia can be found in Noro and Takeshima (1992).
3.4. Conversion of nonalgebraic constraint into algebraic ones
The GB theory-based algebraic underconstrained problem solver requires that all constraints must be expressed as algebraic polynomial expressions. This research, hence, has developed the approaches to converting nonalgebraic expressions into algebraic ones. These techniques are also used to convert all design constraints including those derived from the governing physical laws and experiment results into constraint-based definitions. The following sections briefly illustrate how generic nonalgebraic constraint expressions are converted into algebraic polynomial expressions.
3.4.1. Rational function conversions
Engineering design is governed by many theoretical laws/expressions as well as experimental relationships. Many of these expressions are expressed as a rational function F(x1, x2 ···), where x1, x2 ··· represents generalized design parameters for the function. The rational function is defined as a quotient of two polynomial functions.

where P(x1, x2 ···) and Q(x1, x2 ···) are polynomials.
A rational equation or inequality expression can be converted into a polynomial expression as shown below:

3.4.2. Trigonometric function conversions
Trigonometric functions such as sine and cosine are frequently used in engineering design. It is important to develop a method to convert these functions into polynomial expressions. The following conversion has been adopted in this research:

Within the above conversion, the designers can easily find required angles once they know the values of v and u, which can be a box spatial envelope for the heat-recycling system shown in the case study, where v and u represent the ratio of the depth and height of the box. Drawing a diagonal line of the box to form the opposite and adjacent side of a triangle and α represents the angle between the base and the diagonal line.
3.4.3. Data table and discrete value conversions
Engineering designers often rely on a number of information sources in the form of data tables or discrete values from a table or experiments. In these cases, it is necessary that a data regression method such as least-squares method be used to derive a quadratic polynomial. By using these methods, design information are then represented into polynomial constraints.
3.5. Bond graph theory based constraints for mechatronic components
Bond graph theory provides a unified representation of physical systems spanning five energy application domains (mechanical translation, rotation, electrical, hydraulic, and pneumatic energy domains), by graphically depicting a system using unified symbols (Karnopp et al., 1990). Bond graph theory generalizes all energy variables in two covariables, namely effort and flow. It also generalizes system components into one and two port elements. One port elements include Se for source of effort, Sf for source of flow, R for resistor, C for capacitor, and I for inertia. Two port elements are TF for transformer and GY for gyrator. A linking thick line between elements is called a bond, depicting the energy flow from one element to another. Bond graphs underlying mathematical equations governing each element can greatly facilitate the establishment of constraints between input and output energy variables of many energetic system components.
For example, a DC motor can be generalized as an energy conversion device that converts electrical energy into rotational energy. It has the following design parameters: InputVoltage, InputCurrent, OutputTorque, OutputAngularSpeed, TorqueConstant, InternalResistance, BackEMF, Mass, Weight. The bond graph theory-based constraint relationships for its two input coenergy variables and the two output coenergy variables can be expressed as

Altogether this research has studied about 20 mechatronic components and identified corresponding sets of constraints for these components. They have been parameterized and stored in the Mechatronic Component Library for reuse. They can help designers to describe product design solutions in the form of algebraic constraints. In this approach, when a product is constructed by combining several components, an algebraic constraint set for the solution is formed by merging the algebraic constraint sets of the selected components and interface conditions between them. Therefore, a library holding such algebraic constraint sets enables the reuse of proven design partial solutions. The above merged constraint set is then used to extract relationships and detect conflicts, following the procedures described in Section 3.3.
With generated algebraic constraint sets from the library and users, the next section describes the algebraic constraint formalism, which is required for constraint manipulations and operations for design problems developed in this research.
4. ALGEBRAIC CONSTRAINT FORMALISM
An algebraic constraint in this research is expressed as a polynomial equation or inequality of design parameters. The operands considered mostly in engineering design include scalars and three-dimensional vectors. Single variable names are used to represent scalars, whereas vectors are defined by using array dimensional square bracket [], for example, Velocity[].
Traditional engineering operations, such as addition (+), subtraction (−), multiplication (·), division (/), power function (∧), inner product of vectors (,), and so forth, are used in an algebraic representation. Logical comparison relations operators, such as equals (=), greater than (>), less than (<), greater than or equal to (≥), less than or equal to (≤), and not equal (≠), are adopted in this formalism.
The logical OR “|” operator is used to express discrete values in engineering design. It can also be used with inequality relational operators as shown in the following examples.
Example 1. “Diameter = 10|15|20” means the diameter of a hole in a design “Diameter = 10” or “Diameter = 15” or “Diameter = 20”. █
Example 2. “PipeDistance − 150|PipeDistance − 5 · PipeDiameter ≥ 0” means the
- “distance of a hydraulic pipe to the casing PipeDistance minus 150 ≥ 0” or
- “distance of a hydraulic pipe to the casing PipeDistance minus the pipe diameter PipeDiameter times 5 ≥ 0.” █
Two additional operators, the incremental operator (+=) and the decremental operator (–=) are introduced in this research to model the operations where the right-hand side of a relationship is added to or subtracted from the left-hand side, respectively. These operators work in the same way as the += and –= operators in object oriented programming language C++. The following examples show how they work. They can be overloaded depending on the values passed to them (Deitel & Deitel, 2005).
Example 3. If an assembly of a product consists of two subassemblies and the weight of the assembly is the sum of the weight of the subassemblies, the incremental operator is used in the following to work out the product weight:

Using the above-mentioned algebraic constraint representations, design constraints for a problem can be presented as a hierarchical structure of the algebraic constraint sets, with each set at a node of the hierarchy representing a component and many sets forming the representation of a product or subassembly solution. This structure clearly shows the configuration of the product employing its subassemblies and components and it is analogous to a traditional product hierarchical structure. By employing these constraint sets, this research derived a representation that satisfies the requirements of deploying an algebraic underconstrained solver Risa/Asia. More importantly, it provides a formalism to model complex relationships among design parameters as shown in the examples. The next section gives a detailed description of the framework proposed in this research.
5. A FRAMEWORK FOR THE CONSTRAINT DESIGN SUPPORT SYSTEM
Based on Section 3.1 and the establishment of formalism in Section 4, an architecture for an engineering design support system, DeCoSolver, is proposed and described in this section.
5.1. Framework structure
Figure 2 illustrates the overall structure of the approach. The Product Explorer is the design solution holder where partial design solutions and design alternatives generated by the designers are kept for constraint-based evaluation and analysis.

The architecture of a constraint-based design support system DeCoSolver. [A color version of this figure can be viewed online at www.journals.cambridge.org]
The Concept Decomposer is a mechanism that facilitates the generation of the design solution concepts by decomposing the functions specified through a PDS and then mapping suitable means or implementations onto the chosen functions (Rehman & Yan, 2005). A design concept refers to the conceptual design solution to a design problem and typically consists of many subconcepts formed by the instances of components in the library. Each design concept is expressed as a set of constraints, which encapsulates the PDS via its algebraic constraint expressions. All these constraints are inherited from the parent product design to the child in an object-oriented manner. An example concept shown in Figure 3, which shows the screen captures of various implemented modules of the system, consists of three subconcepts, namely, a left-hand robot finger, a top robot motor, and a motor at the bottom of the robot. The Concept Decomposer supports the designers to generate more alternative design concepts and defines associated constraint sets for exploration.

A montage of the screen captures of the implemented DeCoSolver modules used in designing a robot.
For each of the subconcepts in the Concept Decomposer, further investigation and detailing is undertaken to develop these subconcepts. In this research, a constraint holder for subconcept level development has been generated in the form of a tree structure and is called a context tree, which stores and shows is-a relationships between a subconcept and intermediate design solutions. All these new design partial solutions up to component level are classified and represented in a context tree. For example, the context tree for the left robot finger in Figure 3 shows the constituent components for the subconcept LeftFinger. Each context tree is defined for the corresponding committed product subconcept defined in the Product Explorer as shown in Figure 3. This context tree enables the designers to access to all design alternative concepts and add new context specific design constraints to a chosen design concept. This greatly facilitates the exploration and comparison of multiple design concepts in one design session.
The Constraint Editor is used to define concretely the constraints of the design parameters of a reusable component. It can also be used to define new parameters and constraints for new components and design considerations. This acts as the interface between a set of generic algebraic constraint expressions and meaningful engineering design parameters. Design parameters and their constraints such as kinematic, energetic, and so forth can be defined and modified through this interface. Once a solution is defined by generating a set of constraint expressions, the Constraint Solver Handler is then employed to solve a constraint-based design problem. Having defined the problem, this mechanism acts as the interface between the designers and the Underconstrained Solver engine Risa/Asia.
The results from the solver are displayed to help the designers to visualize and explore the results in the Insight Visualizer. Rather than providing a point solution to a design problem, the underconstrained solver provides a set of solutions as the design solution space. This is then generated in the visualizer so that the designers are able to visually interrogate the influence of a design parameter. Thus, the designers are provided with insights to the design problem and solutions generated in form of visual relationships. This approach therefore applies the Least Commitment Design principle, by which a design commits as fewer design decisions as possible to allow the designer to explore a bigger design solution space, to allow designers to use the insights fully before committing to a specific design solution.
5.2. Design process using the framework for exploration and component reuse
The proposed framework enables multipoint entry and interactive design process. A designer can start a new design session from the Product Explorer, use available components in the Mechatronic Component Library as means for the specified functions and generate several design concepts (Fig. 2). The designers make instances of typical components to form a node in a concept solution. The designer can also start to define a new set of constraints for a new component or means for later use via the Constraint Editor. Alternatively the designer can start to reuse a previous design concept stored in the Concept Tree. Whichever route the designer takes, an underconstrained design problem is always solved for evaluation by activating the Constraint Solver through the Constraint Solver Handler. Unlike other approaches, this solver provides more trend information about a chosen product design solution rather than simply giving an optimum design solution. The solved results are shown in the Insight Visualizer through the solver handler (Fig. 3).
It is worth mentioning that when a product design is modified by adding a new constraint, a new node that reflects the modification is generated and inserted into the appropriate position in the context tree. Figure 4 shows the mechanism of adding a new constraint, modifying or removing a constraint node to the context tree. By using this mechanism, the system maintains the history of a product design process and a designer can go back to review or reexamine any partial solution if necessary.

The generation of a new context-tree node.
DeCoSolver can support both conceptual design as well as embodiment and detail design. This is basically because DeCoSolver has enabled the engineering designers to model a number of component/subconcepts as a set of algebraic constraints. As long as these design meaningful parameters and constraints can be converted into a set of algebraic constraints, the system can solve them and provide underlying relationships among the parameters. The system provides a visual display of these relationships and the trends of changes in the form of curves for equation constraints and feasible areas for inequality constraints.
6. CASE STUDY USING DeCoSolver
DeCoSolver has been implemented in this research and used in two full case studies. It has proved to be effective in providing insightful engineering design support as reported by both industrial and academic users (Sawada, 2001). This section describes a case study to illustrate how DeCoSolver would operate in a real design scenario. The example used in this paper is to design a real energy-saving heat-recycling system and its main PDS is shown in Appendix A. This case study will illustrate how DeCoSolver helps designers to understand the parameter relationships, determine design parameter values, synthesize life-cycle design, and gain insights into the design problem and its solution space.
6.1. Design problem description
Figure 5 shows a concept design scheme for an energy-saving heat-recycling system design. This concept consists of well-proven design modules that are used to provide a robust design solution. Namely, the concept is composed of a condenser, a compressor, an expansion valve, and an evaporator. The refrigerant evaporates at the evaporator and collects heat from the water. It is then adiabatically compressed by the compressor and becomes the gas of high pressure and high temperature. The refrigerant is then condensed in the condenser to release energy to heat up the water. It then goes through the expansion valve and expands into the mixture of saturated gas and liquid. The above working principle in terms of refrigerant flow is shown in Figure 5. The refrigerant used for this study is Freon-22 (R-22) and the overall heat transfer coefficient of the condenser and evaporator is 1000 W/m2 K.

An example of an energy-saving heat-recycling system design.
Water flows from a hot source to a drain via a bath. The water is heated up from 30 to 45°C at the condenser and thereafter supplied to a bath. The drain water is cooled down from 20 to 5°C at the evaporator. The heat-recycling system therefore provides an energy-saving solution. This solution has been used in an actual heat-recycling system designed for a tourist hotel in Japan.
6.2. Design problem definition and complexity
For the above design problem, 79 design parameters have been identified. They include the same property parameters for the four key components of the system: the compressor, condenser, expansion valve, and evaporator. These parameters are Heat Transfer Areas for the Condenser and Evaporator; Coolant Specific Heat for the Condenser and Evaporator; Discharge Entropies of the Compressor, Condenser, and Evaporator; three sets of Enthalpy Coefficients of Refrigerant for Gas and Liquid, for all four respective components; Suction Enthalpies; Discharge pressures, Saturated Vapor Pressure Coefficients of Refrigerant, Mass flow rates, Mass flow rates of Refrigerant; and Coolant Input Temperature. Additional parameters include Discharge Temperature of the Compressor and the Expansion vale; Condensation Temperature of the Evaporator; Mean Temperatures of the Condenser and Evaporator; Coolant Output Temperature of the Condenser, Suction Temperature of the compressor, and the Expansion Valve; Compressing Power of Compressor; and Exchange Heat Value of the Condenser and Evaporator.
This research also identified 97 constraints for the above concept scheme. These include constraints derived from fundamental physical laws about heat exchange as well as constraints identified between the interfaces of various components of the system. Specifically these are Discharge Enthalpy constraints, Compressing Power relationship, Boundary limits of pressures and temperatures, and heat exchange relationships and so forth. For further information, see Sawada (2001).
Key to the design, the parameters' values in Table 1 have to be determined by the designers in order to satisfy the design brief and known boundary parameter values for the chosen concept.
Key design parameters for the heat recycling system design

A further investigation of the design problem reveals that the concept is highly coupled in terms of energy flow. This loop structure of the heat-recycling system and nonlinearity of thermodynamic properties makes it difficult to understand the underlying relationships among these 79 design parameters. Conventionally, the designers have to determine the design parameter values by using a long and tedious trial and error approach.
6.3. New design process: Constraint-based support system using DeCoSolver
DeCoSolver was deployed to provide an alternative design approach to evaluate the effectiveness of the system in helping the designers to gain insights into the underlying relationships.
6.3.1. Constructing the product model
As the first step of designing such a system using DeCoSolver, a product model is constructed to consist of the components models of the compressor, the condenser, the expansion valve, and the evaporator. These models can be selected and dragged and then dropped into the Constraint Editor from the Component Library. These models contain underlying mathematical constraint relationships among the design parameters of each component. In addition to these inherent parameters and constraints, for this design problem, the following constraints are defined to provide interfaces between these components:
- The thermodynamic properties of the refrigerant are identical.
- The input and output mass flow rates, pressure, enthalpy, and temperature of the refrigerant are identical.
Having established all constraints, we can store the product model in the Context tree consisting of three nodes: Concept node, Configuration node, and Specification node. The Concept node acts as the root node for this concept and is the overall representation for this particular concept as other concepts such as Concept 2, and so forth, may be developed later. The Configuration node holds a set of constraints defining the configuration or the structure of the energy-saving heat-recycling system. The Specification node is a child node of Configuration node and it contains constraints of all components in terms of their specifications such as the overall hear transfer coefficient, water's specific heat, mass flow rate, and input/output temperature at the condenser and evaporator. The above model construction process is shown in Figure 6. Once these are fully defined, they can be passed to the algebraic underconstrained solver for solving.

The product design concept modeling process for a heat-recycling system design.
6.3.2. Solving the constraint-based design model
The process of deriving the underlying relationship is relatively straightforward in using DeCoSolver. The Constraint Solver Handler sends the algebraic constraint solver a command with pure algebraic formulae via a Window message. In response to the Windows message, the Risa/Asia shell window starts the algebraic underconstrained problem solver program and derives results, which are fed back to the Handler for display. The underlying procedure for solving is based on the description in Section 3.
6.3.3. Underlying design parameter relationships for increased understanding
Using DeCoSolver graph generation functions, the computational results of a under constrained problem from the Constraint Solver are used to generate underlying relationships among design parameters and plotted in a graph form, or in the form of maximum/minimum values for certain parameters. Figure 7 shows the relationship between the condensation temperature and the total heat transfer area of the condenser and compressor. Conflicts among design parameters and the numerical solutions are also shown. The shaded areas in the Insight Visualizer and the color or gray dotted lines show the invalid design solution space where constraint violations exist.

Minimizing the total heat transfer area through gaining insights.
6.3.4. Determining the design parameter values based on increased understanding
The following illustrates how one can gain insights into a coupled design problem such as this one by increasing the understanding of the relationship between condensation temperature Tc (K) and the total heat transfer area of the condenser and the evaporator. Normally designers focus their attention on a single component of a system when they design such a system. For example, they will try to optimize the design of the condenser or evaporator. It is often the case that cross component and system level relationships are not readily available to the designers and it is difficult for them to gain these insights.
Figure 7 shows the process of design exploration using DeCoSolver. As the design progresses, the designers may wish to explore the high-level relationship between the total heat transfer area of both the condenser and the evaporator and the condensation temperature to see if the area collectively determines the temperature. In supporting this, an additional design parameter, the total heat transfer area (As), is introduced to investigate the relationship between it and the condensation temperature. This additional parameter is not the most obvious one that the designers would consider, unless a system level design is explored. To explore this and gain insights to this system level relationship, the following constraint is introduced As = Ac + Ae into the existing constraint set. As shown in the Insights Visualizer in Figure 7, this new parameter does collectively determine the condensation temperature. The temperature reaches its lowest point when the Tc is 323 K. Selecting this design solution point thus gives rise to the minimized total heat transfer area of these two components and the reduced system cost. It is clear from this example that with an increased understanding of the design parameter relationships by showing visually the insights into the key design relationships and exploring them, the designers can make more optimized and better informed design decisions on critical design parameter values. DeCoSolver helps designers to establish these relationships, some of which are not always obvious and readily available. Based on the above, the Tc is chosen to be 323 K and this gives a minimized total heat transfer area of 29.76 m2. It is also worth mentioning that this approach also provides flexibility and scope for the designers to explore the design solution space by introducing other new design parameters at the system level or cross component, for example, As, to help the designers to foresee the overall heat exchange surface area as the material cost of copper used is a key consideration for the design.
6.4. Life-cycle synthesis using the insights to the design problem
The constraint-based design approach has also been applied into life-cycle consideration of the heat-recycling system design. Once the value of the total surface area As is made concrete, there are other design parameters which the designers may change. In this study, the life-cycle consequences caused by these other design parameter values include the impact on the environment due to the waste of energy resulted from excessive hot water from the bath straight into the drain, and the high running cost of the hot water supply system.
In order to determine the system's ability to supply hot water and the environmental impact, a relationship between the drain water temperature and the hot water temperature supplied for the condenser is extracted from all the available constraints. Figure 8 shows the process of generating life-cycle oriented constraints and the resulting graphs. First, a new environment constraint set is introduced by modifying the constraint set of “Specification” in the context tree. Constraints with fixed values, which represent the environment considerations including inflow and outflow water temperatures are relaxed in order to provide a new solution space for exploration of a life-oriented solution. This thus produces a new constraint set called FixedProperty.

Life-cycle consequence exploration for life-oriented design solutions.
Second, a new variant concept in the analysis tree, named Concept2, is generated, and FixedProperty is assigned to the new concept. This constraint set is sent to the solver handler. Through the handler, additional constraints are defined to provide environmental considerations. In order to prevent the water pipe from being frozen, the outflow water temperature of the evaporator is therefore set to be no less than 0°C. Furthermore, hot water at constant 30°C is economical and easily deliverable. These two additional constraints thus define the boundary for the designers to explore life-cycle consequences caused by the decisions made on the values assigned to the other parameters.
Third, exploration of the relationship between the drain water and the supplied hot water temperatures can reveal the following insights to this design concept:
- The upper limit of the hot water temperature is shown as 318 K or 44.85°C.
- When the drain water temperature falls below 283 K or 9.85°C, the water temperature in the evaporator will decrease to subzero temperature.
The first insight suggests that the hot water supply system should not supply overheated water above 44.85°C. This upper limit satisfies the life-cycle consideration in principle as it implies that the running cost will be maintained at a low level and the environmental impact will also be limited. The implication of this is the requirement for an additional heating system such as a boiler to supply hot water at a preferred constant temperature. The second insight suggests that the heat-recycling system with the above set of values will not work when the drain water temperature falls below 283 K or 9.85°C.
6.5. Insights to the design problem and its solution space
In addition to the above life-cycle related insights, the general insights to this design problem are also vital to reduce the design lead time and help the designers to make informed decisions in determining the values for the key design parameters in Table 1. The other general insights derived from the study shown in Figure 9 from the solver are the following:
- As the Tc increases, the evaporation temperature Te (K) and the discharging pressure of the compressor Pd (Pa) also increase almost linearly.
- As the Tc increases, the compression ratio of the compressor decreases slightly.
- The mass flow rate of refrigerant Qr (kg/s) is almost unchanged.
- As the Tc increases, the heat transfer area of the condenser Ac (m2) decreases nonlinearly. Conversely, the Ac increases.

Insights visualization by plotting several relationships between key design parameters.
Applying these insights in determining the parameter values, the designers can minimize the sum of the heat transfer areas of the condenser and evaporator. This decision results in a smaller heat-recycling system, which is a desirable feature for this design as the space is a premium in Japan and is often limited for in the hotels. With all the insights derived and the exploration undertaken in this case study, a dominant solution set, which is better than that from the traditional approach, is finally determined and presented in Table 2.
A dominant solution set

It is argued that although design problems require different degrees of consideration of various requirements, including life-cycle issues, the exploration criteria can be product performance, function, cost, quality, single life phase, or life cycle related. The details of design exploration with regard to a specific requirement are beyond the scope of this paper. In a related research project (Rehman & Yan, 2005), a template has been developed to assist designers to evaluate the fulfillment of a solution against different design requirements, taking consideration of 10 categories of life-cycle requirements to a different level in a single category or combined manner, including User Requirements, Components' Material Properties, Quality of Solution during use, Pre/Post and during Production Requirement, Production Equipment Requirement, Quantity of Product Required, Achievable Production Rate, and so forth. Such a template can guide systematically a designer in exploring design alternative solutions.
7. EVALUATION
Using DeCoSolver and two fully developed case studies, an evaluation of the approach and DeCoSolver has been undertaken. Twenty-six industrial and research designers from Japan, Germany, and the United States were invited to participate in the evaluation. They all have practical experience in designing products/systems in their fields. The background of these evaluators are 6 control and mechanical researchers and engineers, 5 manufacturing researchers and designers, 10 robotic designers, and 5 general engineering designers. The purpose of the evaluation was to establish if the approach and the developed prototype system could do the following:
- handle multidisciplinary design problems,
- provide wide range insights during design process for several phases of product life-cycle oriented design, and
- support alternative design solution exploration by revealing the design solution space and insights to the influence of these solutions.
The two case studies used were the energy-saving heat-recycling system design example discussed in this paper, and the design of a robotic arm system (Sawada & Yan, 2000, 2004). The evaluation was undertaken through a demonstration of the use of DeCoSolver to several groups of engineers and designers at different locations. An eight-question questionnaire was designed to collect the views of the evaluators, and the results are discussed in the next section.
7.1. Questionnaire results
Questions 1–4 in Figure 10a–d asked the evaluators' view on the design scenario, the approach using DeCoSolver, and the design tasks specified for each evaluator.

Evaluation results for questions 1–4 about the design scenarios.
It is clear from the pie chart results that 92% of the evaluators clearly understood the design procedure and the design tasks shown in the demonstration as shown from the results for question 1 in Figure 10. Although only 46% of the evaluators accepted the design scenarios as adequate, a further investigation and discussion with these participants revealed that 50% of the evaluators who selected the “Don't know” option do not have experience in designing a robotic arm system. It is important to note that 67% of experienced engineering and control system (mechatronic) designers considered the design scenarios as perfectly appropriate. This figure certainly can validate and proved the design task and design procedure of the evaluation undertaken. The results of question 3 indicate that 77% of the evaluators did understand this is a new approach based on the constraints supported design and enables design solution exploration, which is not the case for the conventional design method. The results of question 4 indicate that 81% of the evaluators appreciated the functionalities demonstrated by the DeCoSolver system. This clearly shows that they appreciated that the system can help them in gaining insights into both the design problem and solutions space and exploring design alternatives even at the conceptual design stage.
Questions 5–8 (see Fig. 11) were designed to gain more understanding of the evaluator's view of the functionalities of DeCoSolver.

Evaluation results for questions 5–8 with regard to the functionalities and novel design support for the insightful design of DeCoSolver.
As indicated in the results for question 5, 73% of the evaluators believe that the component library is a useful tool to reduce the workload in constructing a model. Generally, they found it difficult to generate and list all constraints governing the components used for either of the two case studies. The Bond Graph-based approach for mechatronic components (Bracewell et al., 1995; Yan & Sharpe, 1996) complimented by components geometry-based constraints did provide a systematic approach to generating all these governing constraints and relationships among component energy variables. The evaluation results for question 6 show that 77% of the evaluators thought that the context tree is useful structure for the comparison of alternative solutions as they set the context of the design problem and the solutions. It is suggested that in the case of too many alternative solutions available, the system should prioritize alternative solutions in the order of importance. Although it is clear that the designers often neglect unpromising solutions, it is important to store all generated solutions to promote an extensive optimal targeted design (Pugh, 1991; Dym & Little, 2000).
It is important to highlight that 69% of the evaluators for question 7 found that the algebraic underconstrained problem solver supported by the insights visualization tool is a very useful tool to understand the design problems and gain critical insights into the design solutions. Similarly, 65% of the evaluators thought the system provide adequate result storage and retrieval shown in question 8. These collectively help the designers make informed design decisions. It is also worth noting that the evaluators commented the power of DeCoSolver in extracting the relationships between two or three arbitrary design parameters. This function can benefit the designers to explore the relationship of any two parameters, and hence provide a very powerful and useful enabler to allow the full exploration of the solution space. The visual display of the extracted relationships further advances the visualization of these explicit or implicit relationships graphically. Any trends shown graphically can provide the designers with insightful understanding of the design problem and its dynamic solution space. The following respondent comments are particularly worth noting:
- “This system represents violated constraints and their causes, which are quite useful for conducting design.” (This refers to the system's algorithm and functionality in detecting conflicts among all constraints. The systems can suggest minimal set of inconsistent constraints that result in that all constraints cannot be satisfied simultaneously.)
- “I have never seen such a system that can represent solution space of arbitrary two design parameters.”
- “The graphical function is quite impressive.”
Comments about the quality of component library and the number of components stored in the library were made to raise the issue of scaling up DeCoSolver.
8. DISCUSSION
Aimed at deriving a new constraint-based design approach to helping the engineering designers make informed design decisions, this research developed the DeCoSolver framework. The designers can use the framework to define constraints either by selecting a component and its associated constraints or defining new interface constraints or others, solve underconstrained design problems by calling the constraint solver, visualize the partial solutions space to investigate the impact of design parameters on the performance of a solution or other design criteria to increase the understanding of the design problem, and finally gain insights to the problem and solution space.
The application of the approach was not limited to the mechanical system design. It has been extended into mechatronic system design and product life-cycle design. Design parameterization of these design problems represents a feasible step towards the fuller design parameter and constraint-based design problem definition. Once a design problem is parameterized and constrained by constraints defined, increased design problem understanding becomes possible. More importantly, the underconstrained problem solver in conjunction with the Insight Visualization tool implemented in DeCoSolver provides the designers with many insights of the design parameter influences from different perspective. These insights strongly supports exploration of the solution space with either least or specific synthesis decision commitments, this without the need for designers to make decision commitments in a specific order.
This contributes to the concurrent synthesis of multiperspective and life-cycle design consideration, which is considered important in concurrent engineering. This is a significant step towards faster and better design process using the effective and insightful constraint-based system, DeCoSolver. It is also important for implementing constraint-based systems aimed at supporting Design for Multiple X or more importantly Synthesis for Multiple X. The ability in coping with highly coupled design parameters enables designers to significantly reduce the number of iterations of trial and error as often experienced by the designers of these types of systems.
However, future research work is still required to address various issues, including the following:
- The expansion of the constraint formalism: This research has demonstrated that statements in a PDS can be converted into constraint-based design problem solving in many cases. There is, however, a need to formalize further these conversions and research more effective conversion methods for the qualitative statements in a PDS.
- The solving efficiency of underconstrained problem solver: The improvement on the problem-solving efficiency of the algebraic underconstrained problem solver has also required further research. As the problem is getting more complex and the number of design parameters increases, it can take a long time to solve or extract relationships among design parameters, as the GB method and QE are generally inferior to conventional numeric methods in terms of computational efficiency (Sawada, 2001). However, the proposed approach does not present an exponential computation complexity problem. Because only an average computer with a Mobile Pentium III 500-MHz CPU and 320 MB of memory was used for the calculation, it is believed that as the computational power increases rapidly and more efficient methods of symbolic algebra are introduced, this is seen as a less difficult problem.
9. CONCLUSIONS
The computational constraint-based new design framework and its implemented prototype system presented in this paper provides a real effective alternative computer-based design method to harmonize and integrate systematically the constraint-based and conventional design process model-based design methods. It standardizes the representation of constraints of various aspects of product design by converting them into algebraic representations, which are application neutral and life-cycle phase independent. This holistic approach to tackling the design problems including their life-cycle considerations uses a constraint-based framework approach and a powerful algebraic underconstrained problem solver, thereby broadening the application of constraint-based reasoning into a new and complex level. The underconstrained problem solver brings the benefits of enabling the designers to explore a design solution space fully and increase their understanding of the design problem. This is visually enacted by the visualization tools and relationship plotting facility developed in DeCoSolver.
Combining the insights into the design problem and the support of design solution space exploration makes this approach fundamentally different from static design process, in which design parameters introduced and values are assigned by trial and error with the many iterations, without knowing the impact of these committed design decisions. It is observed that the DeCoSolver approach does show the trends, directions where the design performance or other critical design criteria are moving to, whereas the conventional design approaches are more like a blind search based on trial and error. It is this difference that the approach distinguish itself from other design methods and brings many associated benefits.
An application of the DeCoSolver approach into the life-cycle design of the energy-saving heat-recycling system design demonstrated that the approach is design phase independent and is indeed generic in providing engineering designers with a powerful insightful design approach. It is worth noting that the approach has also been applied in the design of a mechatronic robotic arm system, where design parameters span from mechanical system related ones to electronic ones. By applying the constraint-based approach into both complex application domain and multiple life-cycle design, the authors have demonstrated the application of algebraic underconstrained design problem definition, solving, and exploration of relationships to a new level for both the conceptual and embodiment design stages.
As discussed, future work is, however, required to study the conversion of a PDS into as many quantitative statements as possible so that they can be converted to constraint-based design requirement representation. Material-related design requirements could be relatively easily reinterpreted in the technical requirements by converting their properties into algebraic constraints. Descriptive statements such as maintenance, installations, or legal ones remain as a challenge. Nevertheless, it is felt that the proposed algebraic underconstrained problem solving approach makes a significant contribution towards the fuller constraint-based design problem solving and design solution exploration.
ACKNOWLEDGMENTS
We thank the Cannon Foundation for its support in carrying out some of the work. We thank Dr. Barry O'Sullivan, Guest Editor, for his support and patience, and Mr. David Stevenson for proofreading.
APPENDIX A: A PDS FOR AN ENERGY-SAVING HEAT-RECYCLING SYSTEM DESIGN
Performance
- The heat energy extracting/pump system is to extract heat energy from the warm wastewater that will be released into a drain during a shower,
- it is expected to extract heat energy from the wastewater up to 5°C at a rate of no less than 2.5 L/s,
- the normal water supply to the system is 30°C at a rate of no less than 3.5 L/s, and
- the heat extraction should be as efficient as possible.
Environmental requirement
- The working temperature range is 0–60°C,
- wastewater can be dirty and corrosive,
- the product may experience humid condition with humidity to up 95%, and
- the product should not disturb the water system and will not cause excessive noise.
Size and weight
- The product size should be as small as possible to be accommodated a bath underneath (maximum space < 0.4 × 0.5 × 0.6 m).
Installation
- The system is to be installed under bathtubs, and
- the installation should be carried out without any changes to the current bath design.
Materials
- The material is to be light weight and heat efficient,
- easy for manufacture, and
- free from rust or corrosion to wastewater.
Maintenance
- The material is to be easy to maintain by qualified maintenance engineers and
- ensured to have smaller number of parts/subassemblies to make it easy to maintain.
Product life span
- The life span of the product should be no less than 10 years.