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:

1. a quantitative PDS can provide an important preformatted design constraint set (DCS) for design problem solving;
2. 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;
3. they require well-established constraints defined by users and will face a problem with PDS that is difficult to be converted into constraints; and
4. they do not adequately support designer's exploration of design solution space, particularly life-cycle design.

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.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 = (x₁,…, x_n), x₁, x₂,…, 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. f_i(i = 1 to p) functions define the equality constraints, whereas g_m (m = 1 to q) and h_n (n = 1 to r) are inequality constraints.

The above set of constraint representation can be converted to DCS (2) by introducing slack variables s = (s₁,…, s_q) and t = (t₁,…, t_r). 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 = {f₁(x₁,…, x_n) = 0,…, f_p(x₁,…, x_n) = 0} be a given multivariate polynomial equation set and G be a GB of F. Then, ∀(x_i)∃(g ∈ G){ht(g) has a form of x_i^α_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 x_i1,…, x_im are represented as a projection of the algebraic surface on x_i1,…, x_im subspace. Extracting relationships is therefore equivalent to projecting the algebraic surface Eq. (3) onto x_i1,…, x_im 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 x_im+1,…, x_in, s₁,…, s_q, t₁,…, t_r 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 x_i1,…, x_im represent design parameters of a problem, explicit equality relationships of these parameters are derived as follows:

1. Compute the GB G of DCS 2 under the block ordering x_i1,…, x_im <_lex x_im+1,…, x_in, s₁,…, t₁,…, t_r, where <_lex represents the lexicographic ordering (Cox et al., 1997).
2. Polynomials that do not contain any of x_im+1,…, x_in, s₁,…, s_q, t₁,…, t_r 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 t₁ ≥ 0,…, t_r ≥ 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 x_i1,…, x_im, t₁,…, t_r <_lex x_im+1,…, x_in, s₁,…, s_q, where <_lex represents the lexicographic ordering (Cox et al., 1997).

2. Polynomials that contain some of t₁,…, t_r and do not contain any of x_im+1,…, x_in, s₁,…, s_q are selected from G. Make the selected polynomial to be zero to form a set of the equations E = {e₁(x_i1,…, x_im,t₁,…, t_r) = 0,…, e_l(x_i1,…, x_im,t₁,…, t_r) = 0}.

3. E is then divided into subsets E₁,…, E_k so that the following conditions are satisfied:

a. E = E₁∪ ··· ∪E_k

b. ∀(i ≠ j)∀(e_i ∈ E_i)∀(e_j ∈ E_j){There is no common slack variable t_a (1 ≤ a ≤ r) in e_i and e_j.}

Suppose E_j is represented as

where r_j is the number of slack variables t_a (1 ≤ a ≤ r) appearing in E_j, and p_j is the number of equations contained in E_j.

4. The design solution space is then projected onto x_i1,…, x_im subspace as shown by

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

Applying QE to Eq. (5), the inequality relationships among design parameters x_i1,…, x_im are extracted by eliminating t₁,…, t_r. 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(x₁, x₂ ···), where x₁, x₂ ··· represents generalized design parameters for the function. The rational function is defined as a quotient of two polynomial functions.

where P(x₁, x₂ ···) and Q(x₁, x₂ ···) 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.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 S_e for source of effort, S_f 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.

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.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/m² 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.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.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 A_s 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:

1. The upper limit of the hot water temperature is shown as 318 K or 44.85°C.
2. 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 T_c increases, the evaporation temperature T_e (K) and the discharging pressure of the compressor P_d (Pa) also increase almost linearly.
• As the T_c increases, the compression ratio of the compressor decreases slightly.
• The mass flow rate of refrigerant Q_r (kg/s) is almost unchanged.
• As the T_c increases, the heat transfer area of the condenser A_c (m²) decreases nonlinearly. Conversely, the A_c 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.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:

1. “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.)
2. “I have never seen such a system that can represent solution space of arbitrary two design parameters.”
3. “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.