2.1. Background

According to design methodology (e.g., VDI, 1997; Pahl et al., 2003), the steps carried out during conceptual design are identification of an overall function, decomposition into a number of subfunctions and a search for solution principles. Solution principles are identified for all functions, according to VDI (1997) with regard to both effects and shapes (see Fig. 1). The figure shows the steps in conceptual design (shown as rectangles), the databases that can provide appropriate input information during the steps (cylinders), and the results of the respective steps (parallelograms). The arrows on the right indicate that iterations back to earlier steps are possible; the arrows on the left show that requirements both affect and can be affected by all steps.

The conceptual design and access to knowledge bases. Adapted from VDI (1997, fig. 3).

Conceptual design thus progresses from requirements to functions, from functions to their subfunctions, and from subfunctions to solution principles (means), which then, after sufficient decomposition, are combined to form overall principle solutions (concepts). This concept synthesis is achieved by combining several effects or mechanisms into an overall principle solution (cf. the arrow from “effects”/“kinematic mechanisms” and “3.1”/“3.2” to “principle solutions” in Fig. 1). The focus in this article is on steps 2.1–3.1.

2.2. Aims

The aim of this work is to provide a model for conceptual design, constituting a partial model for concept development in a larger product model. At present, sophisticated models and support are available for both earlier and later stages, that is, requirement handling and embodiment design [e.g., geometry modeling using commercial computer-aided design (CAD) modelers]. At the transition between conceptual design and early embodiment design, work has also been done on engineering design synthesis, for example, the tool for compositional synthesis of mechanisms FuncSION described in Chakrabarti (2002, chap. 11). On the other hand, apart from some academic or special-purpose systems, no software support is available for innovative conceptual design. In addition, many systems that might be used for conceptual design (e.g., computerized design catalogs as outlined in Birkhofer and Keutgen, 1999, and Franke et al., 2004, Tech Optimizer as assessed in Lindemann et al., 1998, etc.) are powerful when providing solutions, but neither allow the instantiation of suggested solutions, that is, adaptation to the actual task at hand, nor support the continuous synthesis of the suggested solutions into an overall solution inside the system.

Another purpose of this work is to enable a tool that allows explorative, creative conceptual design even when carried out with computer support. Using software to assist with operations such as maintaining information for added means, selecting/deselecting means in concepts, choosing values, and evaluating how the chosen values affect requirements, the time and effort needed to perform routine tasks can be reduced, while the designer can simultaneously carry out creative steps.

One aim of such computer-supported conceptual design is to be able to handle and compare multiple concept variants, which is suggested by design methodology (Pahl et al., 2003, sect. 2.2.4). Using computer support, more alternatives can be evaluated in a given time, and quantitative support permits the degree of requirement fulfilment of several concepts to be assessed. Reaching better-verified concepts is facilitated by performing early calculations on a number of parameters that are of conceptual significance.

Furthermore, a well-defined model and functional representation are prerequisites for meaningful reuse, which can yield additional time benefits.

2.3. Support approach

The basic approach to accomplishing support for conceptual design is to apply the well-known F/M tree for qualitative modeling and combine it with constraint networks for quantitative modeling. An overview of the used elements is given in Figure 2 (for a more detailed description of the elements, see Section 3). The functional decomposition is modeled using a hierarchy of functions (cf. 3.2) and means (cf. 3.3). Parameters (e.g., L and P_i), accounting for the quantitative description, can be assigned to both functions and means. Requirements (cf. 3.1), grouped in dimensioning cases (cf. 3.7), are assigned to the relevant parameters. Relations between parameters are modeled using constraints, shown as dashed lines (cf. 3.5). Operating states (cf. 3.7) can be used to group several functions that are active only for certain time periods or under certain conditions. Concepts are obtained by selecting one means for each function (cf. 3.6). For clarity, only two of the “is contained in” relations between concepts and means are shown (as dotted lines) in Figure 2.

The elements and relations of the support for conceptual design.

The support is also suitable for innovative original design problems, which require a broad variety of alternative means. Both analysis and synthesis steps can be supported. The support is suitable for problems that are possible to characterize by parameters and algebraic constraints between them, that is, static calculations. Tightly coupled systems or dynamic calculations, which, for example, occur in many mechatronic systems, are not efficiently supported unless they can be simplified into static calculations.

By introducing means, modeling using solution elements and reuse of earlier realized, well-proven solutions is made possible.

2.4. Requirements on the support

Several requirements with regard to support software, which have been identified in prior research, are also relevant to the present work. Kuttig (1993) mentions the high information turnover in conceptual design, and that a tool therefore must provide abstract visualizations. Shifting between different types of information (e.g. text, geometry, formulae or structure) and several methods for modeling are required. According to Feldkamp et al. (1998), there should be no restriction to a fixed set of components, as technical progress requires extensibility. A graphical editor and a simple user interface that can be used by all engineers are needed. Reuse of larger elements (over and above simple components) should be possible. The working procedure should be interactive and allow structural decomposition into smaller, more manageable subproblems. It must be possible to iterate steps and revoke earlier decisions. In Leemhuis et al. (2002), mentioned requirements are that the tool should reduce costs, accelerate design, allow modularization and reuse, and that it covers all phases from requirements to part modeling. Domain-independent applicability to many products and an incremental, iterative procedure are required. A clear description of interrelations between requirements, function and structure, handling of and free choice between alternative variants, handling of incomplete and inconsistent specifications, and the availability of abstract views of early designs are named as issues. Even here, possibilities to revoke decisions and an arbitrary order of steps are called for, as well as change propagation, decomposition and reuse. In Bracewell and Sharpe (1996), the automatic deduction of exact simulation models using bond graphs is a requirement that was fulfilled, at the cost of functions needing to be standardized and limited to a predefined library.

In this work, the main requirement is to provide a tool for innovative concept synthesis that will enable to both work with principle solution elements and early calculations. The model must be continuous (i.e., relations are possible in several steps from requirements to concepts) and bidirectional (i.e., qualitative and quantitative descriptions are coupled and updated in both directions). Qualitative and quantitative descriptions are integrated: changes in means modeling are, for example, reflected by adding or removing constraints and changed values are reflected by updating properties of means or requirements. The model is separated into partial models, that is, one piece of information is only stored at one location to facilitate modularity and exchangeability. Additional requirements that are of concern are to offer methods for flexible work with solution principles in alternative concepts, reuse of solution principles (not only components), explicit storage of principle variants as concepts, and work with incomplete and inconsistent data at any stage. Another requirement is that the model must be generally applicable to a broad range of products. Functions, means, and parameter types are not limited to a predefined closed set, but can be extended individually.

2.5. Working procedure

To achieve an efficient tool, the design of the tool and the working procedures when using it must harmonize with the users' mental models. To be suitable for conceptual design, the working procedure was therefore chosen to be largely interactive and incremental. The individual steps can be performed in arbitrary order (the only deliberately chosen restriction is that means cannot be added prior to the function they are to fulfill). The major steps in the procedure involve the following:

• task clarification: specification of the task by stating a number of necessary requirements;
• abstraction: the requirements are translated to desired functionality by defining a number of functions and adding them to an initially empty document with only the root function present;
• incremental realization and decomposition: an F/M tree is built using appropriate means and subfunctions;
• quantitative information: once the qualitative structure has been established, quantitative information can be added at any time and for any hierarchy level by describing functions and means using parameters;
• relations: adding constraints between parameters will then enable modeling of the relations and change propagation; and
• concepts: finally, concepts as overall solutions can be chosen from the set of modeled means, and quantitatively detailed by choosing values, which may be concept specific.

These major steps outline an iterative procedure from requirements to quantitatively verified concepts. Inside the major steps, there is a succession of specifying, solving, changing (including change propagation), and assessing operations. It is possible to create, modify, and assess several variants during each step. The major advantage compared to traditional configuration design operating on parts is that even different principle solutions can be modeled by introducing functions and means.

Regarding the envisaged use of the tool by an engineer, it can be stated that the system is intended to constitute an assisting system. The aim is not to provide an automatic system that would allow the synthesis of complete solutions solely from a specified list of requirements. In Table 1, the supported steps and the actions performed manually by the designer as well as the actions automatically performed by the tool are given.

Interplay of the tool and the designer using it

The tool is thus based on the assumption that the computer is used to assist by automating routine tasks, such as constraint propagation or activation/deactivation of subfunctions, depending on the chosen means. The complex decision steps (e.g., identification of suitable interelement constraints) are not automated but carried out by the designer, although there are opportunities for further automated steps (e.g., automatic combination and evaluation as outlined in Wilhelms & Derelöv, 2004).

3.1. Requirements

Requirement objects describe functional requirements or restricting requirements. Functional requirements are assigned to a function's parameter, in this way declaring the function responsible to deliver the required flow, for example, to create a certain output torque. Restricting requirements limit a parameter value, for example, the largest possible motor size given by the available space, into which the mounted motor must fit.

The requirement contains a value for the desired value, and the design model (function) provides a value for the actual value the design in its current state delivers. In this way, requirement fulfilment can be checked.

Requirements of different types (exact value, interval) and strengths (desire, requirement) can be modeled (Pahl et al., 2003, chap. 5).

3.2. Functions

As widely recognized (Kuttig, 1993; VDI, 1993; Leemhuis et al., 2002; Pahl et al., 2003), functional modeling is an essential part of conceptual design and is a prerequisite for modularization, varying the solution principle using more abstract function information and reuse. The functional representations used here are both a hierarchic decomposition and a flow-based function structure. Functions express purposes of the artefact by stating desired or required behavior.

According to VDI (1993), a function is the relationship between the input and output flows and the state variables of a system, described independently of a particular solution. The quantitative representation here uses a function object with connected flows. Each flow, either input flow, output flow, or internal parameter, is represented by a parameter object connected to the function. A textual description of the function by verb and noun is also possible. The qualitative representation is achieved by assigning a set of means capable of fulfilling each function to it.

3.3. Means

A means is here used to model one way of achieving functionality. Means also have assigned parameters, and internal constraints are used to quantitatively describe the effect on which a means is based (e.g., the relation of input and output torque for a pair of gears).

As different means may require different subfunctions, means can contain links to specific subfunctions, that is, subfunctions that are only active when the means is selected into the current concept.

The basic idea is that using a division into functions and means, only those parameters can be modeled that are of conceptual importance for the actual task. As not all of the properties of means that might be modeled are equally important, the parameters that were chosen when modeling the functions determine which of the means' parameters are exposed to the environment, a selective approach similar to Langlotz (2000, pp. 90–91).

3.4. Parts

Parts are objects that serve as placeholders for externally modeled geometry, for example, in CAD systems. Even here, parameters such as geometric dimensions can be connected to the constraint network.

3.5. Constraints

Constraints are applied to model quantitative relations to enable early calculations. As in Leemhuis et al. (2002), constraints span across different partial models from requirements to concepts and geometry. Five different types of constraints are used to interconnect the elements (see Fig. 5).

The constraint types available in the tool for modeling relations.

Value assignments (constraint type 1) are used to assign a definitive value to a parameter. These value assignments are concept specific; the same means can thus have different parameter values when they occur in different concepts. Constraint type 2 connects requirements and function parameters. Internal constraints (type 3) are used to describe the physical effects a means is based upon. External constraints model flow between different functions (type 4a) or collect properties from a means' subfunctions (type 4b). All these constraints are added manually and subsequently activated or deactivated automatically, depending on the chosen means. In contrast, constraints of type 5 are set automatically and model the identity of a corresponding function and means parameter.

3.6. Concepts

Leemhuis et al. (2002) state the need to explicitly document concepts, and they note that available commercial software offers no satisfactory support for concept modeling. For this reason, concepts are a central part of the information model presented here.

A concept is an object that encapsulates a number of means choices and a number of value choices. In this way, concepts can be used for a parametric description of an overall principle solution to the design task.

3.7. Operating states and dimensioning cases

The constraint network is used to describe relations between parameters. To facilitate modeling of products that are more complex, compound objects can be constructed by grouping several objects, which then can be treated as a single entity. An example of this is to group several functions into operating states or several requirements into dimensioning cases (cf. Fig. 2). When doing so, a whole group of requirements can be activated or deactivated by simply changing the dimensioning case under consideration.

4.1. General architecture and product model

The general architecture of the prototype is shown in Figure 6. The product model of the conceptual design modeler is realized as an object-oriented C++ document-object model in primary memory. It is visualized using the Microsoft Foundation Class library. Persistent storage of models is made possible through serialization, and independently of this, a design library in the form of a relational database enables storage of means for reuse. The product model can be exported into and imported from an XML document, and views of the product model can be saved as bitmap or vector graphics.

The architecture of the prototype.

The applied constraint solver is DeltaBlue (Freeman–Benson et al., 1990), an incremental constraint solver well suited for working with incomplete, possibly contradictory concepts. Constraints are entered in symbolic, implicit form (e.g., a = b + c), and external commercial symbolic algebra software is used to solve the necessary explicit forms of the equation for each variable (e.g., solve for b = a − c).

The constraint network is used to model the quantitative relations between parameters. Different strengths are used to model constraints. The strength “required” is applied to link a requirement variable to a function variable, for definitive user-made value assignments, user-defined formula constraints, and automatically set identity constraints between corresponding parameters of function and the selected means. The strength “preferred” is applied for facultative user-made value assignments. “Weak default” is used to set initial values. The structural, qualitative relations in the model, for example, that a number of means belong to a specific function, are realized using pointers between objects.

4.2. Manipulation methods and operations

The C++ objects described offer a number of manipulation methods for the product model. All objects offer the usual adding/removing/accessing member routines for their child objects, for example, accessing the means belonging to a function.

In addition, concept objects (cf. Fig. 4) offer a more complex event handler that is called when a concept is to be activated or deactivated upon user request (functions OnActivate() and OnDeactivate() in class CConcept). This routine will activate or deactivate the necessary means (by forwarding the call to Select/Deselect() in the CMeans class) and set or remove the necessary identity constraints between corresponding function and means parameters (using Create/DestroyConnectionConstraints() in the CRealization class). When a subfunction during this operation is deactivated, the external constraints of the function are moved to a list of inactive constraints and removed from the constraint network. Upon reactivation, these constraints are restored from the list and written back to the constraint network. When a means is deactivated, its current parameter values are stored in a list for future reference when it is reactivated (using Save/RestoreParameterValues() in class CRealization). In this way, even parameter values that have no definitive value assignment are preserved. Furthermore, all means and subfunctions below the actual function are recursively activated or deactivated.

4.3. Storage to database, search, and reuse

Hirtz et al. (2002, appendix A) provide a taxonomy for functions and flows. Flows are divided into categories such as liquid flow, effort flow, or pneumatic air flow caused by pressure. The design library in the present work is based on similar thoughts, but for constraint networks to be applicable, the flows are expressed by a set of standardized parameters. For this purpose, the 24 IQ quantities from Roth (1994, fig. 5.2) were chosen as parameter types (see Table 2).

IQ quantities

Roth (1994) defined IQ quantities as the physical quantities that determine power (denoted as intensity, “I”) or amount (quantity, “Q”). IQ quantities are used as functional parameters that define the physical facts of the task, that is, constitute parameters describing input and output of the desired functions. The desired relation of IQ-quantities on a function's input and output is thereafter actually achieved by choosing suitable design parameters, defined as a realized design solution's physical quantities that describe the direct relation between its IQ quantities. For a desired function “Convert force to linear movement”, with input IQ-quantity force (F) and output IQ-quantity displacement (s), the principle solution “linear material elasticity” could be chosen, with the material stiffness (c) as the design parameter that connects force and displacement, giving rise to the internal constraint F = c · s.

For this notation and the case that one of the 24 IQ quantities is converted to another, a matrix of physical effects known to perform these conversions is available in Roth (1994, sect. 5.5.2), and VDI (1997, sect. 4.2.2; see Fig. 7). Effect is hereby defined as physical, chemical, or biological law, relation or phenomenon with which a desired function can be performed. The effects in the matrix constitute an initial basis for the design library. The IQ quantities are intended for use when connecting functions' input and output flows, but do not constitute a complete set that is able to express all necessary parameters. For internal parameters describing the design quantities, additional types may be used by adding user-specific types, for example, the transmission ratio for a gearbox.

The functional parameter matrix (above) and excerpt of the solution database for field 1.2 converting force to displacement (below).

The design library is structured as a relational database with seven tables (see Fig. 8).

The database schema as Unified Modeling Language class diagram.

Storage to the database is performed by issuing a “store in database for reuse” command on a means after it has been modeled in the graphical environment. When processing the command, the modeled functions and means will be entered into the database together with their parameters. Internal constraints and external constraints within the scope of reuse (i.e., from means to subfunctions and between subfunctions) will be added to the database. Identifiers and pointers will be translated to the database keys. The chosen method of data collection thus corresponds to online knowledge capturing as described by Jensen (1999, p. 192), but with the advantage that the stored models conserve their functionality (constraints continue to operate even in reused models) and also allow reasoning to some extent (even if directly creative steps are not supported).

Upon later reuse, which is initiated by issuing a “search means” command on a function, a search for suitable means will be specified using the input and output flows of that desired function. For a function “multiply torque,” a search could, for example, be specified by stating that the desired function has a torque both as its input and its output; a free text search for the word “torque” could also be specified. This query is entered interactively in a dialog box and then automatically translated to the Structured Query Language (SQL) statement shown in Figure 9. The resulting means are then presented to the designer as a list of suggestions. The corresponding F/M tree segment that includes the assigned constraints can be opened and viewed for each suggestion.

The generated SQL statement querying the design library.

4.4. User interface

As already stated, functional modeling and computer supported conceptual design have been a research concern for a long time. As pointed out in Kuttig (1993), because of the progress in technical development, the provided computer support evolved from alphanumeric, difficult to handle systems to more suitable interactive modeling with graphical user interfaces. This prototype also uses abstract graphical views to let the designer interact with the underlying product model.

The user interface was implemented using a splitter window, divided horizontally into three areas. In the section on the left (see Fig. 10, left, which shows the example described in more detail in Section 5), requirements are listed with desired and actual values. The section to the right gives access to a list of suggestions for reuse from the design library. In the middle section, one of several views can be chosen to visualize and modify the product model. At present, two views are available: a flow-based function structure view (see Fig. 10) and a hierarchical F/M tree view (see Fig. 11). The function structure view contains functions and the flows interconnecting them. The functions and constraints are drawn automatically, whereas the designer is free to place the functions at the desired positions. The F/M tree view is rendered fully automatically. In this view, drag and drop operations are used to move functions and means. When moved in this way, the model relations are updated accordingly, for example, that a means receives another function as its parent function. Both views provide access to the methods of the individual functions or means using a context menu with different menu entries depending on the actual object (e.g., reuse only for functions).

A screen layout of the prototype with requirements (left) and function structure view activated (middle).

A screen layout with function/means tree view activated (middle).

Concepts can be generated flexibly by double clicking on means in the tree view; the selected means will then be displayed with a red border. If means have specific subfunctions (i.e., subfunctions that are only active for a particular means), then the tree will be redrawn to show these subfunctions. With the combo-box element in the toolbox at the top, the designer can easily change between a set of alternative concepts. Here, too, the tree will be redrawn to reflect the selections of another concept.

If the constraint network is affected by any of the operations, it will be updated. As means are selected or deselected, internal constraints will thus be activated or deactivated and identity constraints be set or removed. Value assignments will be set or removed depending on the chosen concept. Requirement fulfilment is checked by comparing required value (stored in the requirement) and achieved value (provided by the function in the design) and will be displayed using a color code (green for fulfilled requirements/wishes, yellow for violated wishes, or red for violated requirements). During all steps, constraint propagation will be performed to forward any changes.

Requirements and parameters are displayed as lines in grid controls (cf. Fig. 10, left). For parameters, values can simply be changed by entering a new value, which will then be kept as a weak default (and may change until the designer chooses to constrain it with a definitive value assignment). Even here, color coding is used: values that are determined by other constraints and are not editable are displayed in grey. Fulfilled constraints are shown in green, violated ones in red.