Towards an ontology of generic engineering design activities

Abstract

This paper argues that there is no shared understanding (i.e. an ontology) of the design activities that designers perform in the design process. Hence the purpose of the paper was directed towards identifying and classifying a generic set of design activities from published literature into what are referred to as design definition activities, design evaluation activities and design management activities. In an attempt to achieve a shared understanding of these activities, a set of consistent and coherent definitions of these activities are deliberated and presented. A knowledge level representation based on Newell’s Knowledge Level hypothesis governed by the Principle of Rationality is used to represent a design activity that is motivated by a design goal of that activity through which input knowledge is changed into output knowledge by the design agent’s knowledge. The ontological completeness, clarity and coherence of activities are evaluated through a protocol analysis and the design process in the domain of electronic design (in particular System-on-a-Chip designs (SoC)).

1 Introduction

The design process as a phenomenon has been a topic of design research resulting in a number of models and theories of design. Yet, there is no consensus and widespread application of them in industry (Maffin 1998) as these models and theories do not depict the reality of design (Hales 1987). In a survey of artificial intelligence in design (AID) research, Smithers (1996) derived a similar conclusion that there was no usable theory (or theories) of the design process. Researchers who view design as a cognitive process have proposed cognitive theories of design. Smithers argues that, since cognitive science as a discipline does not have any well-established theoretical understanding of the cognitive capabilities used during design, the development of cognitive theories of design is untenable at the moment. He advocated the need for a knowledge level (KL) (Newell 1981) theory of the design process as a practical alternative to the need for a cognitive theory of designing. Maffin (1998) provided several reasons as to why there is limited use of these models in industry (Birmingham et al. 1997). What is common among these models is the depiction of the design process as consisting of conceptually distinct stages or activities (Birmingham et al. 1997; Maffin 1998) that transform the design from a set of requirements to a final design solution. But these models do not explicitly define the design activities but rather the different stages of the design process (Hansen 1995). The reason offered here is that there is no consensus of the shared understanding (i.e. an ontology) of what constitutes these distinct stages or activities, and whether these models describe or prescribe the complete extent and the nature of these activities that designers perform. What is needed is an ontology of design activities so that proponents of models or theories of design and practitioners have a shared understanding of what each specific design activity entails. This paper thus presents one perspective of such an ontology of design activities, which is corroborated through studying a designer at work. The ontology of activities of team design is considered an avenue of future research.

Ontology is the branch of philosophy concerned with the meaning of existence in the broadest sense (Ziman 1984) by articulating the nature and structure of the world (Wand and Weber 1993). The subject of ontology is the study of the categories of things that exist or may exist in some domain (Sowa 2000). Uschold and Grundinger (1996) define ontology as referring to the shared understanding of some domain of interest that may be used as a unifying framework to solve problems. Uschold (1998) suggests that there are in general two types of ontology, namely, problem solving ontology and domain ontology. While the problem solving ontology involves the activity of identifying, formulating and obtaining a solution to the problem, the domain ontology focuses on the subject matter that corresponds to the domain as distinct from the problem or tasks in that domain. Using the classification of Uschold, the ontology presented here is that of a highly informal problem solving ontology. Hence, the ontology is one particular perspective and is by no means the only one, or necessarily general enough, to capture all aspects of designing. It is, however, considered to present a contribution towards defining a design ontology.

Hubka and Eder (1996) consider design activity as the level of abstraction that the rational cognitive activity in designing can be decomposed into. The perspective taken here is that designing, as a rational cognitive activity, occurs at the knowledge level (Newell 1981). The knowledge level facilitates the prediction and understanding of design behaviour, without having an operational model of the cognitive processing that is actually being done by the agent (i.e. the designer) (Newell 1981). Newell argues that although the agent’s cognitive activities are internal to the agent, they are relatively stable characteristics that can be inferred from the behaviour and can be conveyed by language. Hence, the approach taken here is to develop the ontology of generic design activities using the knowledge level as the level of abstraction. By defining the ontology at the knowledge level it can provide a basis for a more robust shared understanding of the design process.

The purpose of an ontology is a systematic account of existence of the domain under study and the organisation of reality (Simoff and Maher 1998). Ontology addresses issues such as categorical structure of reality. Sowa (2000) observes that the two sources of ontological categories are observation and reasoning. Observation provides knowledge of the physical world (i.e. the world of designing), and reasoning makes sense of observation by generating a framework of abstractions. Hence, the questions that were addressed are: “What are the design activities?” and “Can these be classified into various categories?” To achieve a consistent categorical structure of reality, there is a need to establish a set of concepts (e.g. entities, attributes and processes), their definitions and their interrelationships; this has been referred to as conceptualisation. A conceptualisation is an abstract, simplified view of the world that we wish to represent for some purpose (Gruber 1993). Therefore the key steps taken towards deriving an ontology of design activities are:

• 1. Conceptualisation of a generic design activity, its definition and its relationships.

• 2. Identification of design activities.

• 3. Classification of categories of design activities.

• 4. Definitions of related design activities using the conceptualisation derived in 1.

Section 2 presents a conceptualisation of a generic design activity and suggests that designers evolve the design by applying knowledge during the design process. Hence, the generic design activity is conceptualised at the knowledge level based on Newell’s Knowledge Level Hypothesis and notions of rationality. Simoff and Maher (1998) observe that a design ontology is characterised by the notion of change, the change in design knowledge as more experience is gained, and the changing model or perception of a design while designing. A generic design activity is described here in terms of the design goal, input knowledge and output knowledge to depict the change in design knowledge. Section 3 describes the identification and classification of design activities. The classification of these activities into three categories is based on the manner in which these activities characterise design in general. The categories are design definitions, evaluation and management.

Ontologies should minimise misunderstandings and miscommunications by establishing a coherent set of definitions. Based on the definition of a generic design activity, Sects. 4, 5 and 6 present the taxonomic relationships of activities in the three categories and attempt to define each activity by deriving a coherent understanding of its usage in the published works in design research. Section 7 discusses the presented ontology in terms of its ontological completeness, clarity and coherence and suggests further work in terms of deriving a suitable computable description of the ontology. The evaluation suggests that the ontology presented can serve as a foundation for developing a shared ontology of the design process.

2 Conceptualisation of generic design activity

An ontology is an explicit specification for a conceptualisation (Gruber 1993). Embodied in a conceptualisation is a body of formally represented knowledge consisting of the objects, concepts and other entities that are assumed to exist in some area of interest and the relationships that hold among them (Genesereth and Nilsson 1987). By suggesting that the design activity can be abstracted at the knowledge level (Sect. 2.1), Sect. 2.2 presents a definition of a generic design activity in terms of knowledge change due to that activity. A conceptualisation of the design activity in terms of input knowledge, output knowledge and design goal(s) is given in Sect. 2.3.

2.1 Granularity of design activities

It has been shown that, as with any concept, it is possible to describe design activities at a number of different levels of abstraction (Duffy et al. 1995). Hubka and Eder (1996) describe designing as a rational cognitive activity that can be decomposed into smaller (design) steps, stages and/or phases. The level of abstraction is to match the nature of the design problem. Hubka (1982) has derived a hierarchy of design activities. In this hierarchy, Hubka has used different names to describe the design activities (e.g. design operations, basic operations, elementary activities, elementary operations). Each activity in a given level comprises sub-activities in the next lower level. Included in the list of elementary operations is a variety of activities such as calculating, measuring, drawing, analysing and synthesising. Hubka and Eder (1996) define a design activity as a change of the state of information by means of a design method.

In Gero’s model of design (Gero 1990), design is considered to consist of a number of distinct activities that are carried out between different design states. In this model, it is the set of design activities that transforms an initial design state through a series of successive refinements into a final design state. The initial design state is described by a set of design functions (F) and a related set of expected behaviours (B _c ). The design activities transform the design in which the design structure (S) becomes more clearly defined until finally a satisfactory structure is obtained in which the predicted behaviours (B _s ) approach the expected behaviours (B _c ). The role of design activities in Gero’s model is that of transforming the state of the design expressed in terms of its function, structure and behaviour. However, Sim (2000) shows that design and learning activities as cognitive activities can be described at the knowledge level. By abstracting designing at the knowledge level, the concept of a generic design activity is based on the knowledge of the designer in the context of the evolving design. This is distinct from relating the design activity to the state(s) of the design according to Hubka and Eder (1996) and Gero (1990).

2.2 Definition of generic design activity

A cognitive system at the knowledge level can be referred to as an agent (Newell 1981; DasGupta 1994). At the knowledge level, cognition is described or explained in terms of goals, actions, knowledge and intended rational behaviour. Hence, the main entities with which an agent is concerned are goals, actions and knowledge (which include facts, beliefs, rules, laws, theories and values).

The principle of rationality, the law of behaviour at the knowledge level by Newell (1981), says that actions are selected to attain the agent’s goals. The Principle of Rationality (PR) states that:

If an agent has knowledge that one of its actions will lead to one of its goals then the agent will select that action.

The weakness with PR is that it makes the assumption that the agent has the requisite knowledge and that a particular action will lead to the desired goal. In general an agent may possess incomplete or partial knowledge concerning the appropriate action to take in response to the goal. The capacity of the agent to take appropriate action (i.e. make a rational choice) is dependent on the tacit knowledge (i.e. experiential knowledge) of the design agent and explicit knowledge (see Sect. 2.3.1). Thus, a better characterisation of the behaviour of an agent is expressed by the Principle of Bounded Rationality (PBR) (Simon 1982) which states that:

Given a goal, an agent may not possess perfect or complete knowledge of, or be able to economically compute or access, the correct action (or sequence of actions) that will lead to the attainment of the goal.

So ideally, an agent’s behaviour at the knowledge level is governed by PR. But in reality, in the context of design, it is constrained by PBR. Thus, it is reasonable to suggest that any design activity the design agent chooses in order to attain the design goal represents a hypothesis that the action(s) may lead to some design solution. In the process the design agent overcomes the lack of knowledge of the design problem by learning from the result of the action taken. The learning process leads to an updating of the design knowledge on the part of the agent; this is referred to as a knowledge change of the designer in this paper.

Smithers and Troxell (1990) view design as a process of identifying incompleteness, inconsistency, imprecision, ambiguity and impossibility in requirements statements, modifying and refining these to well-formed problem statements from which to generate good solutions. Hence, designing as a problem-solving process can be abstracted at Newell’s knowledge level as a knowledge process. The definition of design activity by Hubka, Eder and Gero is based on the state of information of the design. Here the definition of a design activity is seen as a knowledge process in which rational action is taken by the design agent to achieve a design goal. Hence, in this paper, a design activity is defined as follows:

A design activity is a rational action taken by a design agent to achieve a knowledge change of the design and/or its associated process (i.e. sequence of actions) in order to achieve some design goal.

2.3 A concept for generic design activity

By defining a design activity at the knowledge level, the input and output to the activity are basically design knowledge that can be represented by some symbolic structures which we shall refer to as input knowledge and output knowledge, respectively. The input knowledge to the design activity is influenced by the agent’s perception of the design context. The input knowledge is also influenced by the tacit and explicit domain knowledge of the design agent. Subject to the PBR, a goal prompts an action that entails the selection of relevant tacit and explicit domain knowledge of the design agent. The output of a design activity may be some symbolic structure believed by the design agent to represent a solution (or a partial solution) to the original goal. However, because the design agent is governed by the PBR, no such solution may be produced; instead, a new (possibly more tractable) goal results. This output goal prompts a new design activity to be invoked and so the design process proceeds. In general, a design goal may cause several design activities to be performed in sequence, or in parallel. The process terminates when the original design goal is achieved or there is no further action being performed by the agent. Hence, the basic elements of a design activity may consist of:

• Existing design knowledge as input knowledge, I _k

• Design activity, A _d

• Design goal, G _d

• Output knowledge, O _k

It is suggested that the basic elements of designing may be related as shown in Fig. 1. In this figure, the design agent’s knowledge and the design goal serve as input to a design activity that results in a design solution that may satisfy some design goal. The design agent’s knowledge consists of the tacit and explicit domain knowledge and knowledge of the current design context. The general goal of the design activity is to deal with the complexity of the design problem until a design solution(s) is finally achieved.

Fig. 1.

Formalism for a design activity

2.3.1 Input knowledge

The input knowledge can be categorised into tacit and explicit knowledge (Nonaka and Takeuchi 1995). Tacit knowledge is personal, context-specific and therefore hard to formalise and communicate. In general, there are three types of tacit knowledge which broadly can be classified as declarative knowledge (know what), procedural knowledge (know how) and causal knowledge (know why). In the domain of engineering design, the three types of knowledge have been commonly referred to as design object knowledge, design process knowledge and design rationale knowledge, respectively. Collectively, it is also known as experiential knowledge. Explicit or “codified” knowledge, on the other hand, refers to knowledge that is transmittable in formal, systematic language. This would include scientific and technological knowledge. Whilst the concept of knowledge at Newell’s knowledge level was just one undifferentiated body, the concept of knowledge adopted here is similar to that of Smithers (1998); that is, knowledge can be differentiated and structured into different types for different design activities.

2.3.2 Goal of design activity

The design problem has been described as a goal-directed (Dym 1995) or a goal-oriented process (Fricke 1996), although the initial goals are not well-defined (Smithers and Troxell 1990). The goals can be specified or derived. Specified goals are goals inferred from the design requirements that must be complied with. Derived goals are goals invoked in the course of the design process. This may lead to a goal sub-goal hierarchical relationship. For example, the goal of a decision-making activity may be to select the optimal design concept. Before a decision can be taken, there is a need to perform an evaluation of these concepts. This gives rise to the sub-goal of evaluating the various concepts based on a set of criteria. Here the goal of the design activity will be influenced by the nature of the activity being considered. The nature and description of the goal for each of the activities are given in the description of each activity (see Sects. 4, 5 and 6).

2.3.3 Output knowledge

The output knowledge, O _k , from the design activity stems from the application of the appropriate activity based upon the input knowledge, to enable the design to progress towards the design goal and hence towards the ultimate goal, the design solution. The output of each design activity therefore contributes to a change in the knowledge of the design. As such, the design agent acquires additional knowledge of the design. With the acquired knowledge the design agent may act rationally or competently by invoking the next activity that may bring the design nearer to the final solution. The nature of the output knowledge is therefore dependent on the design activity and the evolving design solution. The nature and description of the output knowledge is given in the description of each activity (see Sects. 4, 5 and 6).

3 Identification and classification of design activities

The notion of the existence of generic design activities is derived from the study of four sources that describe the activities of designing. They are:

(a):

Different systematic models of various design processes: engineering design (Hubka 1982; Pahl and Beitz 1996), product design (Pugh 1991; Suh 1990; Ulrich and Eppinger 1995), mechanical design (Ullman 1992).

(b):

Conference and journal papers that provide a repository of knowledge relating to design activities and design research.

(c):

Protocol analysis of design experiments in different design domains: architectural design (Chan 1990), mechanical design (Stauffer et al. 1987; Stauffer and Ullman 1988; Ullman et al. 1988; Takeda et al. 1990; Visser 1992).

(d):

Case studies of large complex electromechanical artefacts (Crabtree et al. 1997).

Table 1 shows a list of generic design activities identified from (a) and (b). This list has been further corroborated by (c) and (d) so that a consistent and coherent meaning for each activity was established (see Sects. 4, 5 and 6 for details). Although the nature of design problems in the domains represented may be different, each of the activities identified has characteristics typical of that activity. Each identified activity is considered generic because it is identified from (a), which represented different and varied design domains and diverse sources of published works in design research. Furthermore, by having a consistent and coherent definition of what the specific activities are to achieve, it is reasonable to suggest that design activities identified are generic design activities.

Table 1. Identification and classification of generic design activities from sources on design processes

3.1 Categories of design activities

The first category of design activities considered here deals with the design problem. Design problems have been considered as complex problems to solve (Lewis et al. 2001). Simon (1970) describes the complexity of design problem as being ill-structured because of the lack of knowledge or ignorance on the part of the designer. As the designer learns, the problem that was initially ill-structured becomes well-structured through the process of decomposition of the problem into sub-problems. To Rittel and Webber (1973), problem formulations are considered “wicked” in that they are often solution dependent; it is difficult to formulate a problem statement without being implicitly or explicitly influenced by the solution. Wicked problems (including design problems) are defined by a number of characteristics. Unlike ill-structured problems that become well-structured with decomposition, wicked problems have no definitive or exhaustive formulation. Schon (1987) contends that designers overcome problem formulation through a process of framing and reframing the problem. The process of framing and reframing is the designers’ decision concerning what the problem is. Logan and Smithers (1990) conclude that the fundamental objective in design is therefore to understand the structure of the problem, with a major part of the effort in design directed at structuring problems and only a fraction of this effort directed at solving them once they are structured. The different views of what constitute design problems and how they ought to be solved suggest that the designers are preoccupied with the issue of how a design problem can be re-defined so that it can lead to some potential solution. Underlying the different views on how the design problem is reformulated so that it is more amenable to a solution is the notion of exploring and understanding the problem (i.e. learning); that is, knowledge is gained of the design situation. It is reasonable to suggest that there is a category of design activities that designers engage in that will lead to an increasingly clearer definition of the evolving design. This category of activities is called design definition activities.

The second category of activities deals with the potential design solutions. These activities are concerned with the analysis and evaluation of the potential solutions in satisfying the design requirements. Maffin (1998) observed that the different models of engineering design adopt either the problem-focused approach or the product-focused approach in characterising the sequence in which the design stages and activities are planned or executed. The problem-focused approach concentrates initially on analysis of the problem followed by a systematic concretisation process, during which a number of possible solutions are generated and progressively evaluated and refined in order to converge to the best solution. The product-focused approach is characterised by the use of solution conjectures to generate a solution concept so as to gain further insights and improve the definition of the problem. Further analysis and evaluation steps lead to refinement and development of the solution. The common phase that the evolving design solution(s) is subjected to in both approaches is the analysis and evaluation of the solution(s). Hence, there exists a category of design activities that analyses and evaluates the performance of design solutions against some criteria. This category of design activities is called design analysis and evaluation activities or design evaluation activities.

The third category of activities to be considered deals with the interrelationship between activities in the design process. Designers need to be able to influence a design process by strategic considerations (Brazier et al. 1998). Expert knowledge and experience play a role in the selection of a strategy. There are many different kinds of strategy in use at all of the different levels in an organisation, and at different levels of details in its processes (Fentem et al. 1998). Strategic knowledge is a basis for expertise in domains where the management of problem solving depends on the choice of actions to be taken. This choice is problematic and, therefore, a matter of considerable human expertise (Candy 1998). It is the knowledge that enables the formation of strategies; plans of action determining what kinds of knowledge and tactics should be employed in different problem contexts. Given this, there exists a category of design activities that govern the choices of actions taken by designers to manage the progress of the design process. This category of activities is called design management activities. So, the criteria for classifying the category of activities is based on the knowledge gained in the management of the design process.

In summary, the generic design activities identified are classified into three categories as follows:

• Design definition activities: these activities seek to manage the complexity of the evolving design while increasingly defining it, until it has all the details required for production.

• Design evaluation activities: these activities seek to analyse and evaluate the feasibility of potential design solutions and, by discarding infeasible solutions, reduce the design solution space.

• Design management activities: these activities seek to manage the complexity of co-ordinating activities related to an evolving design and its process.

4 Design definition activities

The apex of the design definition activities is synthesis. Synthesis is considered here as a compound activity as it involves search, exploration and discovery of design solutions, and composition and integration of these solutions. To Hall (1995), the building blocks of synthesis are parts, aggregation, connection, integration and system.

Figure 2 presents a taxonomy of design definition activities in which synthesising is the result of abstracting and generating design concept(s) and structuring concepts to form a whole. Figure 2 is adapted from the graphical model of Andreasen (1991) and Hansen and Andreasen (2002) which has two axes labelled as abstract/concrete and undetailed/detailed. Along the axis undetailed/detailed the number of a design’s characteristics or attributes vary. Along the axis abstract/concrete the number of the characteristics that have been given a value vary. Hence synthesising is shown as a compound activity comprising the activities shown in the figure, transforming ideas/abstractions initially represented by its function(s) into a concrete entity represented by its structure. The activity of generating is supported by decomposing known solutions, associating ideas/concepts and composing them into overall design concept(s). Feasible design, initially undetailed, becomes detailed and concrete through activities such as defining, detailing and/or standardising. Synthesising is considered to be the conglomeration of the design definition activities and hence will be described first followed by the other activities. Using the concept of a generic design activity, each activity is described in terms of the knowledge input into the activity, the design goal and the knowledge output as a result of that activity.

Fig. 2.

Taxonomy of design definition activities

4.1 Synthesising

Several researchers (Alberts 1993; Flemming et al. 1992; Ivezic and Garrett 1994) have described synthesis as a mapping of dependencies between function, behaviour and form. But synthesis is more than just a mapping of dependencies. Pahl and Beitz (1996) describe synthesis as putting together of parts or elements to produce new effects and to demonstrate that these effects create an overall order. Synthesis as a design activity entails configuring entities of a domain to construct a realisable system structure that satisfies design requirements (Kannapan and Marshek 1996). Synthesis when applied to the designing of artificial products or systems entails the integration of parts/systems such that the physical laws of the domains involved when acting together in a given environment give rise to a desired behaviour and performance. Hall (1995), in his book entitled The Age of Synthesis, states: “All of these systems¹, whether small or large, involve complexity, interconnectivity, interfacing and integration that are the handmaidens of synthesis.”

The primary aim of the synthesis activity is to integrate concepts or parts into a whole (components to assembly/sub-system, sub-systems into systems) so that the desired function of the design is achieved. Tomiyama et al. (2000), on the other hand, view synthesis as an abductive process where entities and their properties are determined to fulfill the desired function (Tomiyama, 2000). In short, as Roozenburg and Eekels (1995) put it, synthesis is aimed at the totality of the entity to be designed, not only for a specific aspect.

In mechanical design, synthesis is seen as a systematic construction of designs based on generic elements. According to Hansen (1995), synthesis of a design from generic elements given a required function consists of:

• Decomposition of the function into sub-functions.

• Finding (assemblies of) elements that can perform these sub-functions (concept generation).

• Combining these (assemblies of) elements into a more complex assembly that implements the total function (concept combination).

The synthesis process iterates through these steps, which are interleaved with evaluations and the corresponding adjustments to the resulting design descriptions (see Table 2).

Table 2. Synthesising—details of the elements of the design activity and knowledge change

Methods to aid designers in the synthesis activity at different levels of abstraction have been developed by various researchers. These methods are amenable to be developed into computer software to enhance the capability of design support systems. These methods include schematic synthesis by Ulrich and Seering (1989) and functional synthesis by Chakrabarti and Bligh (1994).

Describing designs in terms of schematics has been a common practice in various domains of design (e.g. pneumatic circuit design, hydraulic circuit design, electrical circuit design, piping circuit design). Generating a schematic description in response to a specification of desired device behaviour is schematic synthesis. Once the schematic description is right, the synthesis of an efficient physical implementation can proceed. For example, in an electrical network, synthesis is defined as the problem of constructing a network of basic electrical elements in such a way that the resulting behaviour includes the particular function that the network must perform.

Design for X (DFX) is considered as a method in the activity of synthesising in which the designer integrates desirable features and properties in the design throughout the design process. DFX can be generally defined as a knowledge-based approach that attempts to design products that maximise all desirable characteristics—such as high quality, reliability, serviceability, safety, user friendliness, environmental friendliness, short time-to-market—in a product design while at the same time minimising lifetime costs, including manufacturing costs (Bralla 1996).

4.2 Abstracting

Abstracting as a generic design activity is to ignore what is particular or incidental and emphasise what is general and essential (Pahl and Beitz 1996). Pahl and Beitz consider abstracting as an activity to find higher-level interrelationships (i.e. which are more generic and comprehensive). To Hoover et al. (1991): “Abstractions are more than simplifications of behaviour and form; they are the result of cognitive decisions to ignore classes of behaviour and portions of the design object. Useful abstractions must capture the important relations between behaviour and form to enable designers to make good design refinements.” As a result, designers use abstractions and models to focus on various characteristics of a design and to simplify the complex relationships between function and form, and form and behaviour. The most useful abstractions are those which enable a designer to understand and predict the relationship between a required behaviour and the physical attributes of the design object. Both Ullman et al. (1988) and Goel and Pirolli (1989) have hypothesised that abstractions are required because of cognitive limitations and problem complexity. Therefore, the goal of this activity is to simplify the complexity of the design object (Pahl and Beitz 1996).

Designers use various kinds of abstraction during the evolution of the design. In the conceptual stage, the abstraction could well be just sketches, diagrams or data structures. In the analysis stage, the abstraction can be in terms of some models such as geometric, finite-element or flow models. It is therefore not surprising that the use of abstractions has been documented in the protocol analyses of various design processes (Chan 1990; Ullman et al. 1988; Takeda et al. 1990). Here, a distinction is made between abstraction, models and their related design activities (i.e. abstracting and modelling). Abstraction is seen as a means by which designers generate design solutions. Models serve as a more well-defined and compact representation of the abstraction (Barzel 1992) by which designers communicate, control and predict the performance of the design solution. Hence, the input knowledge to the activity is the types of abstractions typical of that domain and the output knowledge is an appropriate description of the design object using particular abstraction(s). The knowledge change is a simplified definition of the design object.

In summary, Table 3 shows the input knowledge, the output knowledge, the goal of the design activity of abstraction and the knowledge change.²

Table 3. Abstracting—details of the elements of the activity and knowledge change

4.3 Generating

Generating concepts or concept generation is a generic design activity to satisfy functional requirements that are usually derived from customer requirements or a perceived need. The design activity closely associated with concept generation is concept association and/or concept combination. Concept generation is therefore a compound design activity in that it is composed of the activities of generating and composing or combining design concepts. Individual concepts are generated for each function in the function sub-function hierarchy. To derive the design solution(s), these concepts must be combined into a single design solution. This may result in many possible design solutions. The goal of generating many potential concepts is to satisfy specific sub-functional requirements, while the aim of combining these individual concepts is to fulfill the overall functional requirement.

As the information available in concept generation is limited, inexact and incomplete, the concepts generated are usually described qualitatively rather than quantitatively. Concept generation involves any one of the following transformations:

(i):

The process of mapping function (F) to structure (S) (i.e. F → S mapping) for routine designs through the use of a morphological matrix or chart (Roozenburg and Eekels 1995; Pahl and Beitz 1996).

(ii):

The mapping of function to structure via different “working principles” (physical principles and phenomena) advocated by Freeman and Newell (1971), Kota and Lee (1990) and Pahl and Beitz (1996).

(iii):

The mapping from function requirements (F) to design parameters (DP) as advocated by Suh (1990).

(iv):

The mapping of function (F) to behavior (B) to structure (S) (i.e. F → B → S mapping) for non-routine designs advocated by Welch and Dixon (1994), Bozzo and Fenves (1994) and Qian and Gero (1996).

Prior to concept generation, the functional requirement(s) expressed in the form of a functional structure or hierarchy is obtained through the function decomposition activity. The input knowledge to the concept generation is expressed in terms of function requirements. Through the various transformations it can be seen that the activity of concept generation increases the knowledge of the design in terms of mapping between function, behaviour and structure, in terms of the definition of the working principles, or the design structure expressed in terms of form or design parameters (see Table 4).

Table 4. Generating

4.4 Decomposing

Decomposing is a common problem-solving activity whereby a complex problem and/or object is solved by first breaking (i.e. decomposing) it into a set of smaller problems of lower complexity that can be easily handled (Pimmler and Eppinger 1994). Thus, it can be defined as a process that breaks down a task/problem/object into a set of independent entities. In general, the activity of decomposing can be applied to the design process or the design problem to reduce their complexity. Decomposing itself increases complexity through adding greater detail, parts and interrelationships. But, for the design of complex products involving hundreds or thousands of parts or components, the complexity of the design problem is simplified by decomposing through focussing upon the decomposed element (Duffy et al. 1995; Persidis 1989). The advantage of process decomposing is that it reduces the complexity of the process (Kusiak 1999). For the discussion on process decomposition into tasks and sub-tasks, see task decomposition in Sect. 6.8.

Researchers in design have identified different types of decomposition to address different types of design problems or perspectives faced by designers. However, they may have used different descriptions to refer to the same concept of decomposition. For example, structural decomposition (Kusiak 1999) or object decomposition (Challa and Fadel 1995) refers to decomposition of the product (or system) into assemblies, sub-assemblies and parts to show the dependencies between assemblies, sub-assemblies and parts. If the product is a repeat or a variant design, structural decomposition of existing similar products will expedite the design process especially for complex products involving hundreds/thousands of parts/components, sub-systems and systems.

Unlike structural decomposition, decomposition by product modularity (Kusiak 1999) is based on the independence of components making up the product. It exploits the independence between physical components of the product to promote standardisation and interchangeability. Another type of modular decomposition known as aspect decomposition (Challa and Fadel 1995) deals with the decomposition of a problem into the various aspects of knowledge or disciplines involved (e.g. mechanical, electrical and software).

Most systematic design processes (Suh 1990; Ulrich and Eppinger 1995; Pahl and Beitz 1996) use decomposition by function as a basis for developing the design without reference to existing or known designs. Function-oriented decomposition relies on the notion that a design has a main function that can be broken down into its constituent sub-functions (Hansen 1995; Pahl and Beitz 1996). The purpose is to identify the necessary supplementary functions to achieve the functionality of the composite system. Pahl and Beitz (1996), Ullman (1992) and Ulrich and Eppinger (1995) advocate functional decomposition based on the understanding of the design problem in terms of the flow of types of energy, material and information. To Hubka (1982), function-oriented decomposition of a mechanical system is based on the law of Hubka which states that there exist causal relationships between functions and means in which functions are achieved by means or working principle(s) to derive a function–means tree. Suh’s concept of functional decomposition relies on the mapping of functional requirements (FRs) to design parameters (DPs) (Suh 1990). To satisfy these FRs, a physical embodiment characterised in terms of DPs must be derived. Therefore, decomposition is seen as a mapping process from the functional space to the physical space such that both FRs and DPs can be decomposed into a functional hierarchy and physical hierarchy, respectively (see Table 5).

Table 5. Decomposing

4.5 Associating

Designers relate ideas and concepts through the cognitive activity of associating. Associating groups related ideas together, giving rise to a perception which usually remains fixed unless being revised by subsequent activity (Ash 1949). Association theories consider association as a process within which links (associations) between contents of thought are established (Roozenburg and Eekels 1995). For example, a picture comprising a round shape and a red colour is first registered and then associated with the concept of a tomato. This hypothesis was supported by Ash (1949) from his observations that the formation of pictures is responsible for the construction of the image by perception. Links that are new or novel are considered as indications of the designer’s creativity. Thus, the goal of associating is to generate novel ideas and concepts through association of concepts and their links.

A well-known method to generate a flood of ideas and concepts through associating is brainstorming (Osborn 1963). Brainstorming stimulates the production of strongly divergent associations by encouraging a number of people to work together in a certain way (Roozenburg and Eekels 1995). The input knowledge is methods of generating ideas and domain knowledge, and the output knowledge is a pool of ideas and concepts that can be associated with one another. The knowledge change is the novel way in which ideas or concepts can be linked that were not envisaged before (see Table 6). So, although associating leads to an apparent increase in complexity in the number of ideas or concepts generated, it nevertheless seeks to advance the design problem a step nearer to the design solution through the concepts defined by associating.

Table 6. Associating

4.6 Composing

Combining or composing design concepts or modules into complete conceptual design (Ullman 1992) or modular products (Pahl and Beitz 1996) is an important sub-activity of concept generation. When used in conjunction with combination tables, the space of solutions concepts can be explored systematically and suitable combination or composition of working principles or concepts satisfying certain functional requirements can be achieved (Pahl and Beitz 1996). The key issue to resolve in such compositions is the need to satisfy physical and geometrical compatibility that in turn ensures the smooth flow of energy, material and signals (see Table 7).

Table 7. Composing

4.7 Structuring/integrating

A product can be described in terms of functional and physical elements (Baya and Leifer 1996). Functional elements are usually described in schematic form before implementing them in specific technologies, components or physical working principles. The physical elements (i.e. parts, components and sub-assemblies) that ultimately implement the product’s functions are typically organised into several major physical building blocks called chunks or modules (Hansen 1995). Hansen views chunks as more easily designed than a composite artefact because of their lower complexity. Because these chunks could interact with one another in many ways, to facilitate integration Ulrich and Eppinger (1995) identify two categories of interaction between chunks, namely fundamental and incidental interactions. Fundamental interactions are explicitly represented by the schematic showing the clustering of elements into chunks. Incidental interactions are due to the geometric arrangement of the chunks. By identifying chunks with high interactions early in the design process, a design team can choose an architecture that minimises the complexity of the co-ordination and communication required to develop the system (see Table 8). Pimmler and Eppinger (1994) present a methodology to cluster functional elements into chunks based on the quantification of interactions between the elements. Knowledge of the incidental interactions can be documented using schematic and interaction graphs or matrices (Ulrich and Eppinger 1995).

Table 8. Structuring

4.8 Detailing

Detailing evolves a design that meets the functional requirement to be more specific. It leads to a design prepared for production in that the arrangement (i.e. system sub-system structure, part structure and all the parts), form dimensions and tolerances, material and surface properties of all the individual parts are finally specified, and all the drawing and production documents produced (Pahl and Beitz 1996). The eventual output from detailing is the complete manufacturing information; typically detail drawings, part lists and instructions for assembly, testing, adjustment, maintenance etc. (Hubka and Eder 1996). Pugh (1991) points to the importance of good and sound detail design in relation to good and sound conceptual design. This is because a poor or indifferent detail design can ruin a good, even brilliant concept; conversely, brilliant detail design will never rescue a poor or ill-conceived concept. Hence, detailing as an activity evolves a design concept until a final detail design is achieved.

In general, the goal of the detailing activity is to remove ambiguity and uncertainty in the interpretation of the product description to facilitate the manufacturing and testing of the product. Typically, this requires the input domain knowledge relating to manufacturing, assembly and testing of the product that satisfies the design requirements. This results in the output knowledge of the product expressed in detail drawings and documentation specifying procedures for assembly, testing, etc. (see Table 9).

Table 9. Detailing

4.9 Defining

Defining is a generic activity used throughout the design process (Thomson 1996); from defining the purpose of the artefact, the design problem, design specification³ and design tasks, to the details of defining relationships of concepts/components, and dimensions of design objects. The outcome of this activity provides information for downstream design activities and ultimately for creating the desired artefact (Thomson 1996). But defining is often preceded by analysis and evaluation. For example, in order to define the design specification, customer surveys may be analysed and evaluated. In defining which size and type of structural member to use, strength analysis is performed to derive the required moduli and different structural sections evaluated.

The goal of defining is to make definitive statements or descriptions of the design so as to remove uncertainty (i.e. vagueness, imprecision and incompleteness) in the description. The commitment ensures that other downstream activities can be pursued. The input knowledge is dependent on the current description of the design. For example, it may be a commitment to comply with a particular regulation or international standards or to specify the use of a material in the design. The output knowledge is various statements of specifications relating to the design. This results in reducing or removing uncertainty in the description of the design (see Table 10).

Table 10. Defining

4.10 Standardising

Standardising is a special kind of selecting activity that is peculiar to the detail design phase and may be considered as one of the design strategies in an organisation. The choice is guided by the principle of uniformity provided functional and performance requirements are satisfied. Designers should attempt to utilise as many of the existing parts and components as possible in the design to promote uniformity. Ulrich and Eppinger (1995) refer to this as internal standardisation. External standardisation occurs when designer(s) use externally supplied component(s) and part(s) that are commonly used by manufacturers of similar product lines. This will lead to standardisation of manufacturing and assembly processes. Standardisation has many advantages. Bralla (1996) lists benefits such as elimination of development costs of new components, reduced start-up costs of equipment and machinery, reduced lead time, reduced tooling costs (since tools are already available from previous manufacture of similar parts) and higher production quantities leading to economies of scale. Just-in-time arrangements are made easier due to larger usage quantity and reduction in number of parts/components.

Standardising can be considered as a sub-activity of detailing in that it seeks to define the details of a design through the principle of uniformity in order to minimise manufacturing time and cost. Hence, it is considered as a design definition activity. Given the detail design of the product and the knowledge of catalogues of standard components and parts as the input knowledge, standardising will result in output knowledge of standard components and parts selected and the rationale for the choice (see Table 11). Through standardising the complexity in terms of number of parts and components used will be reduced, especially for large engineering projects.

Table 11. Standardising

5 Design evaluation activities

The aim of design evaluation activities in general is to reduce the complexity of the design solution space. Through activities such as evaluating and decision making, infeasible or less optimal solutions are ruled out, hence leading to a reduction in the search space of the design solution. The design evaluation activities are related as shown in Fig. 3. Decision making is a compound activity that involves the activity of evaluating alternatives and the act of choosing one or more alternatives (i.e. selecting) based on some design criteria. Modelling and simulating are activities used to represent the design solutions in terms of their function and/or structure so that their performance in terms of behaviour can be analysed, evaluated through testing in a real world of full-size or scale models, or simulated in possible worlds. The arrows indicate the typical sequence of the activities.

Fig. 3.

Design evaluation activities and their relationships

5.1 Decision making

Eekels (1990) defines decision making as an activity of choosing among a number of alternative possibilities. There are two basic types of design decisions. The first type is process oriented; that is, the decisions are made to advance the design. The second type is product oriented; that is, decisions are made to effect changes to the state of the design.

Throughout a decision-making process, the designer identifies issues, establishes criteria and provides evaluation statements, until an explicit decision is made to proceed with a particular alternative. Dwarakanath and Wallace (1995) observe that many decisions taken were determined by a single dominating factor⁴. This factor (real or imaginary) has to be identified to understand the influences that affect the decision-making chain. They identify two main types of decision-making process. In the first type, several alternatives are generated and compared against a set of criteria to arrive at a decision. This type of parallel comparison of alternatives was observed only in the early phase of the design process. In the second type of decision making, an alternative was evaluated as and when it was generated, which was subsequently modified or a new alternative generated. This was a strongly coupled process of generate and evaluate.

Good progress towards the design goal occurs when design agent(s) make quality design decisions and act upon them. Quality decisions are those that minimise uncertainty in the design process and are crucial to the success of the design project (Starkey 1992). These decisions have effects that have far-reaching consequences in that they predetermine many of the constraints that will be placed upon future decisions, as yet unmade. Starkey called these fundamental decisions, from which large numbers of dependent, relatively less important decisions (called intermediates) may spring forth. Following these intermediate decisions will come a vast quantity of almost unimportant decisions, each springing from decisions already made. Fundamental decisions can be identified as those that are irretrievable without catastrophic redesign. Intermediate decisions are extensions and supplementary to fundamental decisions that have significant impact on the design should they be retrieved, usually leading to significant redesign in associated areas. Relatively, minor decisions are usually concerned with design details. They cover decisions with regards to component geometry, materials, finishes, processes, tolerances, etc. Their retrieval therefore has less impact on the design.

The goal of decision making is to choose the best alternatives based on a set of criteria. Given the knowledge of design requirements expressed as design criteria, knowledge of the alternative designs and knowledge of appropriate methods of analysis, the output from a decision-making activity is the best design chosen or the most appropriate method of analysis. The knowledge gained by the designer is the design rationale (see Table 12). Decisions made regarding the design object reflect the design rationale of the designer (Mostow 1989; Mostow et al. 1992). The information recorded in a design rationale includes the alternatives, the evaluation criteria, the pros and cons and the decision made. The knowledge of the design decisions becomes crucial for design reuse or design modification/refinement.

Table 12. Decision making

5.2 Evaluating

Evaluating as a design activity is concerned with assessing the suitability of design(s) to satisfy the aims and objectives of the design specification. This is a compound design activity that involves the activity of identifying, measuring and comparing. Reasons for evaluating include checking to make sure that the proposed system is unlikely to fail, comparing proposed systems to find the best for the situation, and/or comparing a candidate system to an “ideal” to establish its potential quality (Hubka and Eder 1996). In some cases, evaluation is only possible through full-scale testing. The result of the evaluation process may initiate other activities such as modifying, standardising and optimising.

Evaluating needs criteria: statements about acceptable performance related to the desired properties—tolerable limits, maxima or minima (Hubka 1982). Some objective criteria for evaluating will consist of values or mathematical relationships expressing limits of physical phenomena (e.g. critical buckling strength of plate, the resonance frequency of a structure), but others will be (more or less) subjective, depending on human judgement. These sets of design criteria differ in scope and content for the different phases of design (McGinnis and Ullman 1992; Dwarakanath and Wallace 1995). In order that important criteria are not omitted, Pahl and Beitz (1996) summarise two separate checklists for evaluation during the conceptual design and embodiment design phases.

In the conceptual design phase, evaluation of concepts is qualitative in nature using methods such as concept screening (called Pugh’s concept selection (Pugh 1991)). During concept screening, rough initial concepts are evaluated relative to a common reference concept using a screening matrix (Ulrich and Eppinger 1995). Concept scoring is used when increased resolution will better differentiate among competing concepts. By weighing the relative importance of the selection criteria, the concept scores are determined by the weighted sum of the ratings (Pahl and Beitz 1996). Because of the need to assign influence values and weight to the evaluation criteria based on arbitrary scales, the evaluation is to some extent subjective (Hubka and Eder 1996).

In the embodiment or detail design phase, evaluation of the design goes beyond meeting the functional and performance requirements. In adopting the DFX approach, many additional aspects of the design have to be considered in the design and manufacture of the product. The design properties considered and integrated during the synthesis activity for the product must be evaluated in accordance with the requirements adopted in the DFX approach.

The primary goal of the evaluation activity is to determine (measure) either qualitatively or quantitatively the quality or value of a design solution with respect to a given objective or set of criteria. Given the appropriate method of evaluation, the input knowledge of the design specification and objectives, evaluating will result in the output knowledge of performance of the alternative design solutions including the optimal solution(s) against a given objective or a set of criteria (see Table 13).

Table 13. Evaluating

5.3 Selecting

Selecting is a design activity that involves choosing a design object that satisfies design requirements from a specified set of alternatives. The term object is used in a general sense, covering, for example, the selection of a working principle for a device, a material type, a component from a catalogue (Ullman et al. 1988), a functional module, a completed design, or a design goal (Chan 1990). However, selection is usually preceded by evaluation. Selection occurs in all phases of design. Design selection requires the knowledge of attributes of the alternatives, attribute-defining requirements and the choice criteria to define optimality in selection (Kannapan and Marshek 1996) (see Table 14).

Table 14. Selecting

5.4 Analysing

Analysing as a design activity involves the use of models of physical phenomena to answer questions about an engineering product—typically about its behaviour. Gero (1990) defines analysing as the means by which the behaviour of a design structure can be predicted.

Finn (1993) considers analysis as consisting of three interrelated activities, namely modelling, simulating and evaluating. Modelling involves reasoning about a design structure (or physical system) with the aim of abstracting an analysis model. This model provides the basis for the simulation activity, the mechanism by which qualitative or quantitative results that describe the behaviour of the physical system are obtained. Evaluating is the activity by which these results are verified with respect to the analysis model and validated with respect to the physical system. For example, in finite element analysis, the model of the structure to be analysed is first constructed of arrays of finite elements. The behaviour of the model subjected to various loading under different environmental conditions is then simulated using the finite element method (FEM) to calculate the stress–strain behaviour of the structure. The stress–strain behaviour can then be validated against a set of design criteria to determine its acceptability as a feasible design solution.

Although one would normally associate analysis with quantitative aspects of the design, analysis encompasses both qualitative and quantitative aspects. In fact, Finn (1993) classifies analysis techniques into three categories: qualitative techniques, approximate techniques and detailed techniques.

Qualitative analysis is generally motivated by the need for a behavioural or functional understanding of a physical system. The type of reasoning used can range from shallow surface reasoning using engineering heuristic knowledge and experiential knowledge to deeper reasoning based on engineering laws and first principles.

Recognising that the nature of the information provided by qualitative analysis techniques may be inadequate to advance the design further, approximate analysis can provide the additional quantitative information but avoiding the complexities associated with detailed analysis. Essentially, approximate analysis involves the use of engineering formulae and correlation (and all their inherent assumptions) to give quantitative estimations of the expected magnitudes of the phenomena being analysed (Duffy 1986; Kerr 1993).

Detailed analysis techniques are generally numerical techniques that are performed to give precise solutions at a fine level of granularity over a domain. As in approximate analysis, detailed analysis can provide sufficient information to permit a design to be reformulated should the need arise.

The goal of analysis is to predict the behaviour of a design. In order to perform an analysis, the input knowledge includes the knowledge of the physical phenomena and theories on these phenomena, the assumptions made and the accuracy required, the methods of analysis to be applied, the structure/form of the design and the working environment of the design. The output knowledge is the behaviour of the design subjected to various scenarios of working environment that the design is likely to encounter. This leads to a better understanding and definition of the design in terms of structure and behaviour (see Table 15).

Table 15. Analysing

5.5 Modelling

The activity of modelling pervades throughout the design process. Duffy et al. (1995) view models as central to current design methodologies as they allow a de-coupling of the experimentation process from the artefact itself, provide a means of communication, control and prediction of the performance of a design and, most importantly, serve as an abstract representation of the design. A model is therefore a means by which designers represent some aspects of the intended product to focus their attention on. Designers can use many different models to represent the state of the design. A model starts out as some cognitive notion (a mental model) (Johnson-Laird 1983) that is eventually developed into a concrete entity. Through different types of design activities, the mental model is transformed into various other models (e.g. functional, behavioural or structural models). Functional and behavioural models are needed to reason about the function and behaviour of a system or product. Physical modelling involves the application of modelling idealisations so that a representative physical model can be created. Mathematical modelling involves describing the physical model in terms of mathematical equations or theories to reflect physics that support the determination of a design’s predicted behaviour. The modelling activities described by Finn (1993) addressed the evaluation of the behaviour of the product or system when the structure or form of the product is known.

The goal of the modelling activity is the abstract representation of the design to serve as means of communication, control and prediction of the performance of a design. Given the input knowledge of the appropriate modelling techniques for the types of analysis required, the modelling will result in knowledge of a specific model of the design that is required for the activity of analysis (see Table 16).

Table 16. Modelling

5.6 Simulating

Roozenburg and Eekels (1995) define simulating as forming an image or imitation of the behaviour and properties of the artefact by reasoning, and/or testing models preceding the manufacture and actual use of the artefact. It leads to expectations about the actual properties of the new artefact in the form of conditional predictions. Where applicable in a design process, simulation comes between synthesis and evaluation. Depending on the behaviour under study, there is a wide variety of simulation models, from mathematical models to true-to-nature material replicas of its original in its environment. Typically, the conditional predictions are evaluated against the design specification (see Table 17).

Table 17. Simulating

5.7 Testing/experimenting

Most designs require some form of testing either during the design process, e.g. model testing of hull resistance, or after manufacture. Products for the consumer or engineering markets usually require a factory test to verify the quality of the product and its compliance with the design specification (Pugh 1991). Unlike the activity of analysis, in which the behaviour of the design is derived through simulation, in testing/experimenting the behaviour of the design is derived through measuring the various parameters describing the behaviour.

The goal of testing or experimenting is to measure and verify the actual behaviour in terms of some design parameters (e.g. speed) against some predicted or specified parameters (e.g. contractual speed). Hence, the input knowledge to the activity is some specific design specification that the design must comply with and the output knowledge is the outcome of meeting the design specification (see Table 18).

Table 18. Testing/experimenting

6 Design management activities

The design management activities (DMA) can be further classified into two groups: activities that manage the evolution of a design problem into design solution(s) and activities that manage the design process as the design evolves. The key activities identified in managing the evolution of a design problem are constraining, identifying, information gathering, exploring, resolving and selecting. The management of the design process involves scheduling, which has four sub-activities of decomposing, prioritising, selecting and planning of tasks. These activities that manage the complexity of the design problem pervade throughout the design process. Therefore, the purpose of design management activities is to streamline the design process to meet design time constraints and to manage the complexity of the design solution space. Figure 4 shows the co-evolution of the design problem and the corresponding design solution. Through activities of identifying, information gathering, exploring and searching, an initially ill-defined or ill-structured problem is transformed into a well-defined and well-structured problem for which design(s) can be generated through the synthesis activities (described in Sect. 4). Through the activities of resolving conflicts and constraining the design solution space in which there could be many potential solutions, a few or one final solution may be selected. It also shows the typical activities used to manage the design process especially for large design projects.

Fig. 4.

Taxonomy of design management activities

The selecting activity can be considered as a special activity that occurs throughout the design process. For example, in the detailing design phase, the selecting activity may be used to select a particular component to implement a design concept or a particular manufacturing process to shape the ultimate form of the product. The selecting activity is also a sub-activity in the decision-making process (see Fig. 3). Thus, the activity of selecting that affects both the design definition activities and the design evaluation activities is included under design management activities.

6.1 Constraining

The aim of the constraining activity is to limit the exploration of the design solution space. Constraints imposed by the design agent could arise from design requirements (Pahl and Beitz 1996; Ullman 1992), engineering codes and standards, design office procedure (Chan and Paulson 1987), knowledge and experience of the design agent or design decisions made during the design process (Ullman 1992). Pahl and Beitz (1996), however, warned against applying constraints during the problem formulation phase of the design process as it may lead to fixation of design solutions. However, as the design is being evolved, it is inevitable that constraints are being applied in order to cope with the complexity of the design by ensuring that the design solution is always kept within the bounds of feasibility (Chan and Paulson 1987). Constraints introduced based on well-informed design decisions are dependent on the designer’s knowledge and experience. Methods of constraining include enforcing hard⁵ constraints at all times and relaxing soft constraints should there be any violations.

The goal of the constraining activity is to reduce the complexity of the design solution space by setting limits of the space to explore. The knowledge of the design specification that determines what are the hard constraints to enforce and what are the soft constraints to relax serves as input knowledge to the activity of constraining. The output knowledge is the knowledge of specific types of constraints that are applied for the given problem and the rationale of applying these constraints (see Table 19).

Table 19. Constraining

6.2 Exploring

Reitman (1994) noted that in many open-ended practical problems like design, the start states, the goal states and the transformation functions are radically under-specified. Because of the ill-structured nature of the design problem space, exploring as a design activity helps designers to define the structure of the problem space and the potential design solutions (Smithers and Troxell 1990). This is achieved through decomposing the space of possible design solutions into sparsely connected modules and developing each of them incrementally, but without any need to make irrevocable commitment to a particular solution (Goel 1994). The development of a design solution has several distinct phases. Goel makes a distinction between the problem structuring/problem framing and problem solving. The aim of exploring is to structure the design solution space (Smithers and Troxell 1990). Problem structuring is the process of drawing upon knowledge to compensate for missing information and using this knowledge to construct the problem space (Goel 1994). From protocol analyses involving architectural design, mechanical design or instructional design, the problem structure is associated with how the artefact may be used and what resources are available to form it. Problem solving is associated with the specification of the function and form of the artefact (Goel 1994). On the one hand, designers need to keep their options open as the design emerges, so as not to crystallise too soon. They also need to make, record and propagate commitments so as to bring the design to closure. The client and design briefs are important sources of knowledge during problem structuring. This is consistent with the purpose that problem structuring is to bring new information into the problem space. This is done through the “add and propose” mechanisms (see Table 20).

Table 20. Exploring

6.3 Identifying

Designers manage the complexity of the design problem by identifying the relevant domain knowledge required, any past design cases relevant to the current design problem and the type of product (i.e. repeat design, variant design, innovative or strategic design). They identify which aspects of the design to focus on during the current state of the design problem (e.g. identifying customer needs and wants (Bruce and Cooper 2000), success factors for new product development (Bruce and Cooper 2000), essential design problems (Pahl and Beitz 1996), interactions of sub-systems and constraints). They also identify what design methods or methodology to use for the activity of analysis and evaluation, or what computer software or tools to use (Araujo and Duffy 1997).

The goal of the activity of identifying is to mark the relevant and essential in order to manage the complexity of the design problem and the relevant means (i.e. design methods, tools or software, etc.) to manage the problem. The input knowledge consists of the domain knowledge and knowledge of past designs or methods used. The output knowledge is the relevant domain knowledge, design case or method, or issue that can lead to a better management of the design problem (see Table 21).

Table 21. Identifying

6.4 Information gathering

In any design task, information relevant to the task has to be gathered from a variety of sources (Cross and Cross 1996). It has been shown that engineering designers spend as much as 30% of the time searching for and accessing engineering design information. In trying to reduce this “non-productive time”, engineering designers tend to use the information that they already possess. This may result in designs being generated without the benefit of information that does exist within the enterprise, but is too time consuming to find, or exists within the domain of the supplier which is even more time consuming to track down. This may ultimately lead to a reduction in productivity. Worse still, crucial design decisions will be based on incomplete data and assumptions, and are therefore likely to be sub-optimal. Hence, the need for relevant and up-to-date information is crucial to the design and development of new products and systems. Information gathering is thus seen as an important design activity that enables designers to keep up with new technical developments that have impact on their design(s). Information transformation that may take place concurrently with information gathering is an activity whereby meaning is assigned to the information gathered, thereby transforming it into knowledge (Bruce and Cooper 2000).

The goal of information gathering is to provide designers with up-to-date information that leads to the improvement of the design or speed up the design process. The input knowledge comes from the in-house or vendors’ depository of information/knowledge but the search is guided by the goal of the activity, i.e. the acquisition of information/knowledge to be used for a downstream activity (see Table 22).

Table 22. Information gathering

6.5 Resolving

Conflicting interest, requirements and viewpoints are inherent in design. Conflicts exist in individual agent’s design or in a collaborative design effort (Brazier et al. 1995; Oh and Sharpe 1995). Conflict resolution or resolving conflicts is an important design activity that pervades throughout the design process. Brazier et al. (1995) posit that detecting, resolving and managing conflicts requires extensive knowledge of conflict management strategies. Brazier et al. classify four conflict types based on manipulation of requirements, design object description, single agent’s design process and the design process co-ordination between the agents and individual agents’ design process. Oh and Sharpe (1995) identify technological or task-level sources of conflict for interdisciplinary design to manage and exploit them effectively (see Table 23).

Table 23. Resolving

6.6 Searching

Searching is similar to the exploring activity but with an expected end result (Thomson 1996) within a well-defined solution space. Successful searching is usually accomplished by search strategies applied to identify search fields. Ulrich and Eppinger (1995) classify the search activity into two categories, external search and internal search. External search for solutions is essentially an information-gathering process and the sources include lead user interview, expert consultation, patent searches, literature searches and competitive benchmarking. Internal search involves a process of retrieving a potentially useful piece of information from the designer’s memory or that of a team of designers and adapting that information to the problem at hand (see Table 24). In searching for design solutions, Hubka (1982) suggests two methods, namely, discursive methods (e.g. analogies, aggregation, similarity laws, structuring, inversion method) and intuitive methods (e.g. brainstorming, synectics).

Table 24. Searching

6.7 Decomposing

Often associated with a design project is a document reflecting a project plan which defines the tasks that need to be completed in order to solve the design problem (Ullman 1992); that is, the design problem is decomposed into tasks and sub-tasks. Each task/sub-task with definite goal(s) and time constraints is assigned to appropriate design agent(s). Hence, a design task represents a design effort that must be performed in order to achieve key milestones in a design process. A task or sub-task may require a sequence of interrelated activities. Task decomposition simplifies the design process and allows one to determine a potential group of tasks that might be performed simultaneously.

These tasks are organised to decrease the product development life cycle by analysing the interdependency between design activities. Kusiak and Wang (1993a) represent the relationships among the design activities using an activity–activity incidence matrix and the corresponding directed graph. By analysing the nature of the incidence matrix using a triangularisation algorithm, design activities can be categorised into uncoupled matrix, de-coupled matrix and coupled matrix. Knowing the de-coupled activities leads to reduction in the number of iterations in the design process.

Using the incidence matrix to represent relationships among tasks, Kusiak and Wang (1993b) presented a methodology for decomposition of a design task resulting in minimum interaction density among groups of design tasks. The interaction density is defined as a measure of dependency among groups of tasks. A cluster identification algorithm is used to recognise groupings among tasks. Two types of dependency, serial dependency and interdependency, were investigated. Knowledge of the interdependency of related tasks and their sequencing will enable management of the design project to assign appropriate resources for timely completion.

Here, the goal of decomposition is to deal with the complexity of the problem/process by decomposing these into smaller but manageable problems. The input knowledge is the knowledge of interrelated activities, their precedence orders and the knowledge of algorithms for clustering activities. The output knowledge is the knowledge of the coupled and decoupled activities which may lead to better management of parallel and sequential tasks (see Table 25).

Table 25. Decomposing

6.8 Prioritising

Duffy et al. (1995) consider prioritising as the ordering of goals on the basis of their importance to and general strategies for the solution process. The inputs to this activity are:

• The knowledge of the relative importance of goals, the implications of not achieving them and the effect they have on limiting the possible solutions.

• The information requirements of each sub-task and its resource.

The output is an agenda of goals in order of priority. The knowledge change is a knowledge of a specific ordering of goals and sub-goals for a given design task/project (see Table 26).

Table 26. Prioritising

6.9 Planning

The planning activity organises resources for the design process in terms of the order of tasks, the assignment of personnel and tools for each task (Thomson 1996) and also the activities related to the manufacturing of the product such as purchasing, production, logistics etc. For repeat and variant designs, such plans may be available for reuse with some modification. For innovative and strategic designs, decomposition of the design problem into design tasks and ordering these tasks can be achieved by using the triangularisation method of Kusiak and Wang (1993a) (see Table 27).

Table 27. Planning

6.10 Scheduling

Scheduling differs from planning in that actual time stamps and time duration (starting and ending time) are specified for each task. Time-sensitive tasks that lead to a critical path can be identified using critical path analysis (Coates et al. 2000; Whitfield et al. 2000) (see Table 28).

Table 28. Scheduling

7 Discussion

The process of deriving the ontology of generic design activities has been based on an evaluation of published literature on design and corroborated by design practice as recorded in case studies and protocol recordings. The main difficulty in identifying generic design activities lies in the level of abstraction of these activities. By defining the level of abstraction at the knowledge level, the generic design activities identified are rational actions that design agents take to achieve design goals resulting in a knowledge change of the design.

7.1 Evaluation of the derived ontology

The criteria for evaluating ontology should include ontological completeness, clarity and coherence (Wand and Weber 1993; Uschold and Gruninger 1996). Hence, these criteria in relation to the ontology derived in this paper are discussed below.

7.1.1 Ontological completeness

Two approaches were used to evaluate the ontological completeness of the ontology presented here. In both approaches, the design domains involved were not part of the design domains covered in the literature of published works.

The first approach involved the analysis of a protocol recording (2 h 45 min) of a ship designer at work. Using the definitions given in Sects. 4, 5 and 6, design activities performed by the ship designer were identified in the protocol recording. Table 29 shows a comparison between the ontology of design activities in the three categories and those identified in the protocol analysis (Sim 2000).

Table 29. Design activities identified in the protocol analysis

The comparison shows that some of the design activities are not identified in the protocol recorded, namely abstracting, modelling, testing/experimenting and scheduling. This may be due to the fact that the video recording was taken of a designer engaged in a particular type of design task, in this case that of general arrangement⁶ of a ship design. Unlike conceptual design in which abstracting of ideas or concepts is used in generating designs, for general arrangement or configuration design, the systems, sub-systems and design objects have been predetermined. So, the design task was how to achieve an optimal layout or arrangement of spaces and equipment that can satisfy all the design requirements. This may be the reason that design activities such as abstracting have not been identified in the protocol recording of this particular case study.

The second approach was to review the design process in the domain of electronic design (in particular System-on-a-Chip designs (SoC)). A SoC design involves the synthesis of tens of millions of transistors on a chip. The synthesis involves the integration of reusable hardware and software macros addressing interconnect issues, floor planning and timing design to satisfy the requirements for clock speed, power and area. The design activities for SoC based on a Reuse Methodology Manual (Keating and Bricaud 1999) are identified and compared with the ontology of design activities presented here (see Table 30).

Table 30. Design activities identified in the SoC design

Whilst most of the activities listed in the ontology can be found in the design methodology of SoC, the activity of verification (i.e. system verification) is not listed in the ontology. System level verification is the one fundamental activity of the design of SoC. It involves block-level verification, interface verification, data and behavioural verification, and functional verification. The purpose of system verification is to find conceptual, functional and implementation errors before the design is committed to silicon. Verification can be considered as a sub-activity of testing.

The evaluation of the ontological completeness involving different design domains, from what have been used in its derivation, shows that the ontology presented in the paper is sufficiently expressive in eliciting the shared meaning of the design activities. Hence to some extent it verifies the ontological completeness of the ontology presented in this paper. An ontology should also be extensible so that one can define new terms for special uses based on existing vocabulary (Gruber 1993). Hence, verification as an activity in SoC design is an example of extensibility in the ontology.

7.1.2 Ontological clarity

Ontological clarity is concerned with the interpretation of meaning of the design activities. By categorising these activities gleaned from the published works in design research and design practice, the aim of this paper has been to derive a shared understanding of the meaning of each of the design activities identified. This has been achieved by comparing and contrasting the descriptions given by different authors and resolving ambiguity that arose, and as a result we derived a consistent definition of each activity.

7.1.3 Coherence

The design activities identified have been classified into different categories, depending on the main role these activities have been seen to play in resolving the complexity and uncertainty related to the design and associated process. By describing the taxonomical relationships of these activities for each category (i.e. design definition, design evaluation and design management activities), it is intended that the meaning of each activity has been clearly and consistently defined and the relationships between the activities identified. Hence, it is reasonable to suggest that the ontology of design activities presented here displays ontological coherence.

7.2 Future work

Uschold and Gruninger (1996) have identified key phases of a methodology for developing an ontology as purpose and scoping, capture, representation, evaluation and documentation. The focus of this paper has been primarily on ontology capture in order to achieve the ontological purpose of a shared understanding of design activities. Further work envisaged should focus on identifying and evaluating a suitable grammar of representational model(s) for coding of the design activities in order to derive a computational model. The grammar for ontological representation of design activities should be evaluated for its ontological expressiveness. For example, Weber and Zhang (1996) are able to evaluate the ontological expressiveness of various representational models (entity–relationship model (ERM), data flow models (DFD) and Nijssen’s Information Analysis Method (NIAM)) for generating conceptual schema diagrams, using the ontological model proposed by Bunge–Wand–Weber (Wand and Weber 1990). The Bunge–Wand–Weber model is a modification and extension of the ontological model developed by Bunge (1977, 1979). Wand and Weber had evaluated alternative ontologies and chose the Bunge’s model for three reasons. First, they contend that Bunge’s model is better developed and better formalised than any competing ontology they have encountered. Second, it models the world as a world of systems using concepts that are fundamental to computer science and information systems domains. Third, they argue that they have been able to use Bunge’s ontology to produce useful theoretical and practical results (Wand and Weber 1993). Similar evaluation of the ontological expressiveness of various representational models using the Wand–Weber–Bunge model or alternative representation ontologies can be performed so that a good representational grammar can be derived for a computational model.

8 Conclusion

This paper has presented an ontology of generic design activities based on published literature and corroborated by design practice. It categorises the activities as design definition, evaluation and management. The ontology of generic design activities is seen as providing a consistent and coherent description of the interpretation of typical design activities upon which design education, system developers and design researchers can further work in design research and practice. More specifically, the ontology can contribute to the development of effective and efficient design support systems and hence promote design reuse and design productivity, and act as a base to develop a shared ontology of the design process.