1. INTRODUCTION
Engineering design in today's global and competitive business environment is under increasing pressure to deliver new, high-quality products and services to the market rapidly and cheaply. One approach to assisting designers in this competitive era is to reuse previous design knowledge. Reusing previous designs to meet new requirements can help designers in many ways. For example, reusing a successful existing design reduces efforts and risks at the design and downstream stages, because the proven products preserve the validated design knowledge. In addition, referring to previous unfruitful design solutions reduces repeated design efforts and avoids the same design errors. However, generally the documented knowledge of a design is only a description of the final design itself, such as models, drawings, spreadsheets, reports, and specifications. These results are like “snapshots” of the final decisions (Burge & Brown, Reference Burge, Brown and Gero2000), in which much important implicit knowledge of designers about why the product is designed in a certain way or what design options were considered but rejected is rarely adequately captured (Pedgley, Reference Pedgley2007). This shortcoming hinders the reuse of design knowledge that can be valuable, even critical, to future designers who wish to understand, modify, or recreate the original design. For example, when there is a system defect or a need for design modification, such knowledge can greatly help designers understand and analyze the root cause and diagnose change impacts. Design rationale (DR) can provide designers with such knowledge. It includes all background information, such as the reasons and justifications for a design decision, other alternatives considered, the trade-offs made, and the argumentation that leading to the decision (Lee, Reference Lee1997). Therefore, DR knowledge should be captured and retained in an efficient and effective manner.
How to organize and formalize the enormous amount of diverse contents of the DR and build them into a usable structure is a critical issue (Buckingham-Shum & Hammond, Reference Buckingham-Shum and Hammond1994). The schema for representing DR determines the methods used to capture and retrieve the DR. Thus, developing an appropriate representation schema is therefore important for the study of DR. A design process needs a series of iterative and evolving cognitions because of the generation of new objects and new knowledge. In the evolving cognition, a designer has to justify alternatives, solutions, and even design goals. Thus, DR continuously evolves, and the evolving history of the DR contains a wealth of data and knowledge produced by the evolving design process. Therefore, this paper aims to create an improved representation model to capture and formalize DR and its evolving history to support efficient design reuse. Domain-specific concepts with their relationships and a knowledge representation based on Web Ontology Language (OWL) are explicitly defined to assist designers in documenting design intents, design decisions, design justifications, design operations, related situational information, and their interactive relationships behind design activities. This further allows other designers to easily understand and reuse the knowledge.
The paper is organized as follows. Related work in the areas of DR representation is reviewed in Section 2. An improved intent-driven representation model is defined in Section 3, where its knowledge structure is described in detail and its OWL-based knowledge representation is introduced. Section 4 defines the context of DR to support effective traceability of the design reasoning and to further reduce the complexity of the model. A graphical DR modeling system and its application are introduced through an illustrative example in Section 5. Section 6 concludes the paper by discussing the future research based on the proposed model.
2. RELATED WORKS
Research on DR representation has been conducted since the 1970s (Kunz & Rittel, Reference Kunz and Rittel1970). Much progress has been made since the early 1980s (Regli et al., Reference Regli, Hu, Atwood and Sun2000). The research has ranged from basic observations about the design process (Ullman et al., Reference Ullman, Dietterich and Stauffer1988) to different approaches to capturing the DR. Because a good representation scheme is vital to enable effective design and reuse, much attention has been focused on developing methods and notations for representing rationales. Argumentation-based representation and intent-driven representation are the two main approaches. Although the two representation approaches share similar contents, the most essential differences between them are their points of view about the design process. The argumentation-based approach treats a design in a problem-solving scenario, and the intent-driven approach treats a design as an evolving cognitive process.
2.1. Argumentation-based representation
Argumentation-based representation is currently the mainstream approach to DR representation. It uses a semiformal graphical format (Buckingham-Shum & Hammond, Reference Buckingham-Shum and Hammond1994) to represent deliberations about design decisions, in which a node represents a DR element such as an issue, option, or argument, whereas a link represents a relationship between the elements. In the node-and-link representation, it uses typed links to interconnect typed nodes (Shipman & McCall, Reference Shipman and McCall1997). With argumentation, designers can easily maintain consistency in decision making, keep track of decisions, and communicate with one another about design reasoning (Regli et al., Reference Regli, Hu, Atwood and Sun2000). One antecedent of argumentation-based models is the issue-based information system (IBIS; Kunz & Rittel, Reference Kunz and Rittel1970), which uses issues, positions, arguments, and their relationships to represent DR. The procedural hierarchy of issue model (McCall, Reference McCall1991) broadens the scope of the “issue” in IBIS and replaces all of the traditional IBIS links by the link “serve.” Question, option, and criteria (MacLean et al., Reference MacLean, Young, Belloti and Moran1991) and DR Language (DRL) models (Lee, Reference Lee1989) are also argumentation-based models. Question, option, and criteria focuses on providing a structure for representation of design alternatives. DRL is a language for representing qualitative decision-making processes, which can comprehensively support designers in making decisions when a problem or goal is complete and clear.
The main research content on the argumentation-based representation model focuses on three areas. The first is the application research of the representation model. Shum et al. (Reference Shum, Selvin, Sierhuis, Conklin, Haley, Nuseibeh, Dutoit, McCall, Mistrik and Paech2006) developed the Compendium tool based on the IBIS model to support capturing and recording rationales in the form of text, hyperlinks, and video. Compendium is used by the NASA's collaborative work team. DRed (Bracewell et al., Reference Bracewell, Ahmed and Wallace2004, Reference Bracewell, Wallace, Moss and Knott2009) is also one of the proposed derivatives of the venerable IBIS concept, which can support designers in recording, revisiting, and understanding previous design solutions. It has been applied in aerospace engineering design as a standard product life cycle management tool at Rolls-Royce. The second area of research is the refining and improvement of the DR model structure. Most argumentation-based approaches provide little mapping information among various DRs and their corresponding artifacts. Liu et al. (Reference Liu, Liang, Kwong and Lee2010) proposed an issue, solution, and artifact layer model for DR representation. In this approach, design solutions link up the issue and artifact components, which offer clues regarding the relationship between problems and their corresponding artifacts. The third area of research is the extension of representation capability. Kuaba (De Medeiros & Schwabe, Reference De Medeiros and Schwabe2008) extends the components of the IBIS model. It defines an ontology vocabulary and a set of rules for recording design decisions. In the Kuaba method, a design decision can be integrated with design evidence and product information, making the recorded DR more complete. Burge and Brown (Reference Burge and Brown2008) extended DRL by using argument ontology to represent and reason requirements, candidate solutions, and evidence. The argument ontology is a predefined set of claim types. Designers can explicitly describe their decisions and integrate them with the evidence and corresponding artifact information. Rockwell et al. (Reference Rockwell, Grosse and Krishmanurty2010) developed a semantic information model for capturing and communicating design decisions, aiming to obtain an explicit documentation of DR through design decisions. In their proposed decision support ontology (DSO), design issues, alternatives, criteria, and evaluation information are identified as key decision-making concepts.
The argumentation-based representation approach extracts key elements of the DR and describes the decision-making process succinctly and effectively. Much progress has been made, and some argumentation-based DR models are already being applied to several industrial projects. However, there are several inherent limitations in such models.
In essence, the argumentation-based approach treats the design as a problem-solving process, assuming that the problem is already understood sufficiently and identified to be analyzed using automatic tools or top-down methods. However, many complex design problems can be characterized as “wicked” problems (Rittel & Webber, Reference Rittel and Webber1973), especially at the initial design stage. They cannot be easily defined, are often solution dependent, and require iteration. These problems need a series of iterative cognition, design, and evaluation cycles to be defined. Subsequently, initial designs based on known data, design principles, assumptions, and constraints are evaluated during the design process. The evaluated results are then used to verify or modify the initial design. Conklin (Reference Conklin2005) introduced an example of a wicked problem related to a new car design: the marketing department is asking for a design that emphasizes side-impact safety. One approach to making a safer car would be to add structural support in the doors to make the car safer from side impact. This can be regarded as an initial design problem. However, it turns out that the additional door structure doubles the cost of the door, makes the doors heavier and harder to open and close, changes the fuel mileage and ride, and requires an adjustment to the suspension and braking systems. Making the doors stronger leads to other design problems, which interact with each other and require designers’ iterative cognition to understand and adjust to what the problem is that needs to be solved during the solution developing process. Therefore, every solution that is offered exposes new aspects of the problem, requiring further adjustments of the potential solutions. Thus, there is no definitive statement of “the problem.”
According to Sim and Duffy's (Reference Sim and Duffy2003) design activity model, the existing design agent's knowledge and the initial design goal serve as inputs to a design activity resulting in a design solution that may satisfy some design goals. In addition, 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 in turn justify the design goal and the next design activity to bring the design nearer to the final solution. Similarly, Hatchuel and Weil (Reference Hatchuel and Weil2009) proposed a unified design theory, concept–knowledge theory, which argues that “the generation of new objects and new knowledge” is the distinctive feature of designs rather than the dynamic mapping between required functions and selected structures. It emphasizes the generation of objects unknown at the beginning of the process and whose existence could be guaranteed by knowledge that may be discovered during the process. Thus, with the occurrence of the new knowledge and the new objects, the design process is no longer just a problem-solving process but is an iterative and evolving learning process influenced by actual design operations and current design contexts, where designers modify and shift the problems and solutions over time. The problem solving and learning are tightly intertwined, and this evolving design cycle produces a wealth of data and knowledge that forms the rationale for the final design.
Therefore, the argumentation-based approach cannot handle wicked problems adequately because it only provides designers with static issues, options, and arguments for definite problems. It is only an accumulation of discontinuous problem-solving segments. Lack of the dynamic evolvement of design problems, options, actual design operations, and design contexts limits its expressive ability for a complete DR. Furthermore, during a design process, many design problems depend on and influence each other, as shown in the example of the new car design. The argumentation-based approach ignores interactive relationships among design problems, in which the issue is treated independently. This may inevitably result in the loss of important information about a design problem.
2.2. Intent-driven representation
Design intent describes the objectives, plans, and desires that stimulate and instruct a designer to deliberate a design process. Different from the argumentation-based representation, intent-driven representation treats a design as an evolving cognitive process that can be reflected by the evolution of design intents. Current intent-driven representation models represent design intents explicitly, and a design history can be captured by preserving design intents and their evolving tracks. Ganeshan et al. (Reference Ganeshan, Garrett and Finger1994) proposed a model to represent design intents in which design intents are defined and evaluated as the design process evolves. In the design intent modeling system implemented by Arai et al. (Reference Arai, Okada and Iwata1992), a design process is described by intents, operations, and design flows. An evolving DR driven by the interaction between design intent and design operation can be represented using this approach. The design intent model can also be integrated with product models. A design process language is introduced to record the history of design processes (Arai et al., Reference Arai, Shirase and Wakamatsu1998). However, this approach has some disadvantages. First, although the design process language can reflect the problem finding or understanding process by describing the coevolving process of design intent and design operations, it does not refer to other DR elements, such as other design options considered, justifications for design decisions, trade-offs, and evaluation criteria. Second, it fails to capture the design situational information. The situational information can be summarized as “where you are, when you do, or what you do matters” (Gero & Kannengiesser, Reference Gero and Kannengiesser2004), considering the external environment where the design is executed, such as time constraints and special conditions. The situational information is also critical to the design process because it can interact with and further influence design intents and design operations. Recording corresponding situational information can effectively help us understand why the design is made the way it is. Therefore, the conventional intent-driven representation cannot represent DR completely.
More and more researchers today realize that the DR model based on evolving intents can reflect the cognitive characteristics of a design process more accurately than more traditional approaches. Design intent has become a focus of research. The main research includes how to capture design intents from computer-aided design models (Kim et al., Reference Kim, Pratt, Iyer and Sriram2008; Li et al., Reference Li, Langbein and Martin2010) and how to represent design intent (Liu & Sun, Reference Liu and Sun2008). However, no systematic theory or method has emerged to improve the research on intent-driven DR representation. No representation model that can reflect the design situation, design cognition, design operation, and design evolution process has been constructed.
3. AN IMPROVED INTENT-DRIVEN MODEL
Design activity is an iterative cognitive process during which a designer generates a design concept, makes design decisions, and solves the design problem using expertise, knowledge, and situational information to satisfy design intents. From the literature review, we noted that current DR representation models can hardly step into the nonstatic nature of DR and capture it completely. Therefore, without complete or at least sufficient DR knowledge, current DR representation models cannot effectively support designers in DR reuse. For the purpose of improving DR reuse, an improved intent-driven representation model is created to dynamically capture the DR and its evolving history. It is a more complete knowledge representation, involving all of the DR elements mentioned above and their interactive relationships.
3.1. DR elements
The proposed representation model consists of four submodels: design intent, design decision, design justification, and design operation, as shown in its knowledge structure (Fig. 1). The design process involves a designer's internal thinking and outside world, that is, the product world. The internal world processes information from the product world and in turn makes changes to the product world through design activities. The DR model represents the internal world of a designer, whereas the product world reflects DR in the actual world by describing actual entities of the product (i.e., its function, behavior, and structure). Design operation is shared by the DR model and the product world in the proposed representation. It acts as a bridge between the two worlds. The information on corresponding artifacts can be linked to the DR model by attached documents, hyperlinks, and so on. A detailed description of the DR elements follows.
The knowledge structure of the design rationale mode.
3.1.1. Design intent
Design intent is the core of the proposed DR model. It is the initiation and motivation of a design process, generally representing what a designer wants to do. Ullman (Reference Ullman2002) cited a definition of design intent: “During product design, the intent is the blueprint for the evolution of the requirements into the production specification. This blueprint not only has information about the development of the geometry, but also on the evolution of the product function and behavior, the rationale underlying design decisions and the influence of business activities.” Therefore, design intent is not just a design goal or a design problem. It contains different kinds of information.
According to the different roles it plays in the design process, design intent is classified into six categories: formulation intent, generation intent, evaluation intent, synthesis intent, plan intent, and communication intent. Different categories have different characteristics. Formulation intent decides what to do to formulate a complete design problem. It concerns the formulation process of the design problem structure. As a design process is proceeding, a design intent is derived when the design specification is explicit. Formulation intent is embodied by the “design intents” proposed in the DR model and their decomposition process. Generation intent guides designers to propose design options or decisions that can satisfy the design requirements or resolve the current design task. Evaluation intent instructs designers to compare the proposed design options against some design criteria to come to a decision or it refines the current decision to fit changed design requirements or conditions. If the proposed options cannot satisfy the requirements, designers use synthesis intent to analyze the design options, decisions, and related evidence synthetically in order to obtain a more complete solution. Planning intent decides appropriate design directions where a design needs iteration or modification, such as which intent, option, evidence, or decision should be modified or replaced. Planning intent directs the progress of the design process. With communication intent designers exchange design methods or design results with the external environment or other cooperative partners. Different categories of design intent exist that underlie design activities during a design process. They are implicit but reflected by the contents of the whole DR model.
In the representation model, a design intent can be generated, evaluated, modified, and even eliminated during the design. It can also be decomposed into several subintents (sI), which can be decomposed continually. Dependency relationships among different design intents can be represented by a design intent tree (Fig. 2). The root node of the design intent tree is an initial intent. Elementary intent (eI) is defined as the minimal unit of the design intent that cannot be decomposed further.
The design intent tree.
3.1.2. Design decision
Throughout a decision-making process, a designer identifies design intent, suggests alternatives, establishes criteria, and provides evaluation statements until an explicit decision is made to proceed with a particular alternative. Therefore, a design decision is an ultimate solution that a designer discovers after analyzing and comparing several design alternatives against criteria and trade-offs. It can be the choice of one alternative, the optimization of one alternative, or the integration and optimization of several alternatives. These alternatives are called design options and are generated during the process the designer undergoes to realize the design intent. The main idea of the design decision in this paper is similar to the DSO. However, as in the argumentation-based representation schema, DSO is based on a problem-solving scenario and the decision is addressed only to resolve a specified issue. It also fails to reflect the evolving design cognition process.
3.1.3. Design justification
Design justification explains how the options are generated and why the decisions are made. In the proposed model, three kinds of justification are considered: evidence for generating options, criteria for evaluating different options, and trade-offs that designers make for final decisions. Evidence is an accepted principle or instruction that a designer follows to generate design options for achieving design intent. It may be a physical principle, condition, or constraint in the design requirement, or even a formula in the design handbook. Criteria are the standards against which a designer can judge design options and make decisions. A designer makes trade-offs according to his/her expertise, experience, preferences, and the situational design information to facilitate decision making. To understand why a design is the way it is, it is often more informative to know why something was not included than to know why something was included (Leveson, Reference Leveson2001). The design results derived from any design decisions and the reasons for any difficulties in reaching satisfactory design results need to be explicitly explained. Therefore, in this paper, not only are accepted options recorded in the representation model but also ideas that were rejected are retained along with their justifications.
3.1.4. Design operation
The methods or means that a designer uses to change the state of the inside and product worlds are called design operations. A design operation is an action whose execution can help realize the design intent. A design operation can be an actual operation in the design process, such as using a computer-aided design system to generate solid models of the product, calculating and optimizing the parameters, or communicating with other designers. In contrast, it can be mental information processing activities, for example, creating new options, evaluating proposed options, or making decisions. Sim and Duffy (Reference Sim and Duffy2003) classified a generic set of design activities into design definition, design evaluation, and design management activities. In this proposed model, mental operations include focus, decide, confirm, propose, deduce, define, and analogize. Actual operations include search, depict record, store, communicate, select, calculate, and draw. Design operation expresses the interaction between design intent and the external environment. The execution of the design operation can in turn influence other DR elements and initiate another design intent.
3.2. Relationships of DR elements
The proposed representation model defines seven types of basic semantic relationships among DR elements. DR elements and their relationships are shown in Figure 2 and Figure 3 and detailed in the following:
1. Decomposed-into<intent, intents> is the relationship between an intent (I1) and two or more intents (I2, I3) whereby I1 can be achieved only when I2 and I3 are achieved.
2. Achieved-by<intent, option> means that the option is an alternative proposed to achieve the design intent.
3. Decided-by<option/options, decision> means that the option is selected or several options are synthesized by a designer to be the final decision.
4. Realized-by<decision, operation> is the relationship between decision and operation, meaning that the operation turns the decision into actual activities.
5. Follows<option, evidence> is a relationship that means the option is proposed by conforming to the evidence.
6. Refers-to<decision, criterion/tradeoff> relates a decision to the criterion or trade-off that it refers to for decision making.
7. Initiates<operation, intent> is the relationship that relates an operation to an intent, meaning that the result of the operation will initiate a new intent.
(Color online) The design rationale elements and their relationships.
Taking part of the design process of a gear set as an example, Figure 3 demonstrates the relationships of DR elements. At the beginning of the design, the diameter and breadth of the small gear are proposed in design option O1. O1 follows evidences E1 and E2. During the later design process, after the fatigue strength of the gear tooth surface contact is checked, O1 is reevaluated and the designer finds that O1 is not a suitable option. Then, D1 is made referring to C1 and T1 to increase the diameter of the small gear, namely, the small gear should be redesigned. A new option O2 is proposed and decision D2 is made. Finally, D2 is realized by Op1, and Op1 initiates design intent I2.
3.3. Knowledge representation of DR
Formalizing the DR representation in a consistent manner can improve the expressiveness of the DR model and further help designers easily capture, manage, understand, and reuse the DR. A set of representation rules should be constructed, and the ontology can be employed to fulfill the DR formalization. Ontology provides a semantics-based approach to structure the concepts and their relationships within a given domain. It can be seen as a realization as well as a practical argument for knowledge-based processing (Nirenburg & Raskin, Reference Nirenburg and Raskin2003). In this paper, a preliminary OWL-based knowledge representation is developed to formalize the DR. OWL is a common ontology language for the Semantic Web, developed by the World Wide Web Consortium Web Ontology Working Group. It was primarily devised to represent knowledge (i.e., objects and how objects are interrelated) to be shared and exchanged without disputes as to precise meaning. The OWL-based knowledge representation can be understood and reasoned by computer, which can further improve the computability of the DR model.
In the DR representation, the class and object property in OWL can be employed to represent DR elements and their relationships as mentioned above. Taking the design intent as an example, its expression in OWL is detailed below.
Design_intent has four kinds of attributes: Intent_ID, Intent_name, Intent_description, and Intent_state, which can be represented by the relationships hasIntentID, hasIntentname, hasIntentdescription, and hasIntentstate, respectively. In the proposed DR model, an intent has one and only one Intent_ID, which can be guaranteed by the OWL restriction: owl: qualifiedCardinality. An intent can exist in one of three states: satisfied, unsatisfied, or unconsidered. This can be represented by an OWL enumerated class that is implemented by owl: oneOf. The OWL-based representation of design intent is partially shown in Figure 4.
The knowledge representation of design rationale.
Likewise, other DR elements have their specified subclasses and attributes, which can be represented in a similar way. The relationships between different DR elements and the reasoning rules can also be defined in OWL format.
4. CONTEXT OF DR
Most of the current node-and-link representations can provide indexing services for retrieval of rationales (Shipman & McCall, Reference Shipman and McCall1997). However, in an iterative design cycle, few representational approaches can organize the evolving history of DR in such a way that they can be retrieved and tracked easily. Remedying this situation becomes critical and challenging (Tang et al., Reference Tang, Jin and Han2007). The context of the DR is defined in this section to help capture and organize the evolving DR.
4.1. Definition
Tang and Frazer (Reference Tang and Frazer2001) define a context as a series of design actions initiated by an individual designer or design team. It is regarded as an isolated design environment in which a design action cannot affect other designers’ work in a collaborative design. In this paper the design context is defined as a logical assembly of elements in the DR model that can satisfy the initial intent. It is addressed below.
Figure 5 shows one of the episodes of the iterative design cycle. The DR model is a complex chain of a design cycle, consisting of a series of design episodes to capture the complete and evolving design process. Although designers need to review the whole design process sometimes, more often they need to access certain parts of the process regarding certain DR elements. Dealing with the whole process and looking up specific answers are time-consuming and difficult. Breaking the DR model into episodes can reduce the complexity of the model. An episode starts when a primary intent is generated and ends when decisions have been made or operations have been undertaken to satisfy the intent. For example, Figure 5 shows an episode around I1.
An example of a design episode.
In this episode, there are two kinds of logical relationship among its elements: and and or (Fig. 5). If the relationship among the elements is and, all of them must be satisfied simultaneously to satisfy the initial intent of the episode. If the relationship is or, only one of them needs to be chosen. The dependency relationship of the episode decides that there can be several assemblies of elements that can achieve the intent.
In one episode, there may be more than one design context. For example, a context of the episode in Figure 5 is outlined with dashed and curved shapes in Figure 6a. Based on the dependency relationship of elements, Figure 6b represents another context of the episode when O2 is taken as a decision. Based on the logical relationship among DR elements, the design context can further reduce the complexity of the design episode.
A context analysis.
4.2. Organizing DR with context
Again, taking the gear set design in Figure 3 as an example, when O1 cannot satisfy I1, designers have to redesign and propose O2. This is an iterative process in which O1 evolves into O2 and D1 evolves to D2. Figure 3 sequentially documents the DR according to the design activity, but its iterative and evolving process cannot be represented clearly. The context of the DR can be employed to document the complete DR and its evolving history. Two kinds of relationships of DR elements are added to the DR model:
1. Return-to< , >: Return-to highlights the start and the end of an iterative process in the DR when a designer returns to modify previous DR elements. It consists of return-to<operation, intent/option/decision>, return-to<decision, intent/option/decision>, and return-to<intent, intent/option/decision>.
2. Evolve-to< , >: Evolve-to reflects the modification and evolution of design intent, option, and decision during the design process that is attributable to underlying reasons such as the occurrence of design mistakes, acquisition of new knowledge, and a change of situational information. It consists of evolve-to<intent, intent>, evolve-to<option, option>, and evolve-to<decision, decision>.
The relationships Return-to< , > and Evolve-to< , > retain a complete and clear design and decision history that documents how and why a design has evolved. As shown in Figure 7, Return-to represents what D1 the designer returns to redesign the diameter of the small gear. Then, another DR context is added as shown with the dashed box, O2 is proposed, and D2 is made. Evolve-to represents the evolution track of O2 and D2. Associated reasons for the evolving decisions are explicitly documented in terms of evidence, criteria, and trade-offs. Similarly, I1 can evolve into another intent and D2 can evolve into another decision when it is needed.
(Color online) The context of the gear set design.
Therefore, the explicit representation of the design context can offer a number of advantages in capturing the evolving DR completely and clearly, which might otherwise be unattainable.
First, the design context enables a complete documentation of the DR and its evolving history. It can represent different assumptions about the design episode, such as selecting different options, referring to different criteria or evidences, even choosing different intents to achieve, as shown in Figure 6. Thus, it allows a designer to explore and retain different routes of a design process because the change of elements in a context cannot influence elements in other contexts, even if they share the same intent. When the designer has a new idea, plausible modifications to a part of an episode can be made by creating a new context to observe the influence without necessarily losing any previous DR information, such as adding a branch to a branching tree. The branch inherits the design decisions made in its parent design branch. Furthermore, the reason or justification for the modification can be documented in the new context, and the context of the DR provides an explanatory power to the DR model for evolutionary steps of DR elements.
Second, the context can provide a designer with complete DR knowledge when he or she wants to understand, modify, or reuse a previous design. This can be achieved through three different kinds of trace schema:
1. Forward trace: The purpose of this trace is to support an impact analysis of a design. Given an element in the DR model, all dependent elements downwardly caused and influenced by the given element can be traced. This trace can help designers identify which element would be affected when the given element is modified.
2. Backward trace: The purpose of this trace is to support a root-cause analysis of a design. For a given element, all other elements it directly or indirectly depends on can be traced. This enables designers to understand and analyze elements leading to the given element.
3. Evolution trace: The purpose of this trace is to support an analysis of an evolving DR element. Given an element, the history containing previous versions of it with the cause of the evolution can be retrieved through the relationship evolve-to. This provides designers with a thorough understanding of the design's evolving history.
Therefore, the context of DR not only helps capture and manage the complete DR but also serves a designer with corresponding information effectively and efficiently. Furthermore, OWL-based knowledge representation of the DR enables the context to be understood and reasoned via computer. Some existing rule engines, such as Jess, can be employed to implement the actual tracing task. Jess (Friedman-Hill, Reference Friedman-Hill2003) is one of the widely used light-weight rule engines for the Java platform. It provides an improved Rete algorithm to support reasoning.
5. PROTOTYPE SYSTEM WITH APPLICATION
The prototype system MindDigger, which is based on knowledge representation, was developed to allow designers to model DR when performing a variety of design tasks. The framework of the prototype system is shown in Figure 8. A designer can use MindDigger to construct a DR model by interacting with the graphical or textual interface. The DR model can be parsed into the .owl file through the knowledge representation of DR. The DR manager is responsible for organizing the DR model in the forms of DR episode and context, maintaining the consistency of the DR model base. Outcomes of a design process such as drawings and documents in different forms can be reviewed, annotated, and then attached to corresponding DR elements to facilitate understanding. Furthermore, when a designer meets similar design problems, he/she can search for the matched successful DR models for later reuse.
The framework of the prototype system.
This paper utilizes a partial DR modeling process of a design example to illustrate the system. The task is to design an adjustable bending die equipped with a rebound measuring device, which can be integrated into an electronic universal testing machine to measure the rebound of the bending die. The bending die consists of three parts. The upper part is fixed to the beam of the electronic universal testing machine. The lower part and the rebound measuring device are fixed to the workbench of the universal testing machine. The upper part transfers the pressure on the beam. The lower part supports the workpiece and provides reacting force. The rebound measuring device is used to record the displacement of the measure point of the workpiece during its bending and rebound in real time. A schematic diagram of the structure is provided in Figure 9.
The structure of the bending die.
5.1. Graphical interface
Given the knowledge representation of the DR, it would be a difficult task for designers to learn and record the DR in OWL format manually. A graphical modeling interface is proposed to help designers input the DR. The tool provides graphical symbols for representing the elements and relationships. A designer can express his/her design process simply by dragging corresponding symbols from the toolbox on the upper part of the interface to the modeling region below the toolbox and then linking them. When the designer adds a new DR element or a new relationship between two elements and right-clicks on the item, a dialog box will be pushed out by the system, asking the designer to input the name, status, description, and all other attributes of the item. The system can simultaneously save the DR information in OWL format. When the designer selects one constructed node or relation and left-clicks on it, the property column on the lower left part of the interface can present all of its attributes. On the upper left part of the interface is the hierarchy of the DR. When the designer selects one of the episodes, the tree structure of the selected episode will be unfolded. At the same time, the elements and their relationships in this episode will be presented as nodes and links in the graphical modeling region. Therefore, the graphical modeling will be much more helpful to a novice designer if he/she is unfamiliar with the syntax.
Part of the design process of the bending die is presented in this paper. The main process involves the following steps. The details about the DR elements are explained in Table 1.
1. With the formulation intent, the initial intent can be decomposed into three subintents: sI1 is to design the rebound measuring device, sI2 is to design the upper part of the bending die, and sI3 is to design the lower part of the bending die.
2. With an aim to sI1, four episodes are processed. With the formulation intent, sI1 is decomposed into two eIs: eI11 and eI12.
Explanation for the example
In episode 1 surrounding eI11, to select the measuring method with the generation intent, two options O1 and O2 are proposed with their evidences E1 and E2, respectively. Then, with the evaluation intent, the designer evaluates the options against criteria C1, C2, C3, and C4. Decision D1 is made.
In episode 2 surrounding eI12, to identify the measuring method with the generation intent, two options O3 and O4 are proposed with their evidence. With the evaluation intent, the designer evaluates the options against criteria C4 and C5. Decision D2 is made. However, in the later design stage, the designer finds that C2 is the most important criterion and should be considered prior to C4 and C5. Therefore, with the planning intent and synthesis intent, the designer returns to D2 to redesign the measuring method in episode 3 and changes the decision. D2 evolves into D3 with its justification. The names of episodes 2 and 3 are the same in Table 1 because they are iterative processes to satisfy the same intent: “identify the measuring method.”
After D1 and D3 are made, eI13 is formed in episode 4 to design the placement space for the measuring tool. As with the other episodes, the options are proposed and evaluated to make the decision.
After episode 4, an operation is performed to draw the schematic of the rebound measuring device. Then, a new design intent is initiated in episode 5 to further satisfy sI1. The DR can be recorded as demonstrated in Figure 10, and the associated knowledge representation in OWL format is saved by the system.
The graphical modeling interface.
5.2. Context manager
Based on the description logic of DR knowledge representation, designers can create, modify, and maintain contexts of the DR with the context manager provided by the system. Moreover, the system allows designers to define the start point, reasoning direction, and reasoning depth to retrieve related DR elements. For example, when the designer of the bending die wants to modify the previous decision, he prefers to select O4 rather than O3, according to his justification against the evidence, criteria, or trade-offs; the context manager can help him understand the initial design by providing him with the root cause of D2, downward design process that may be influenced, and different versions of D2 in the design history, if any. Furthermore, the designer can create his design process by constructing a new context in the context manager. For example, the designer can make decision D3 without losing previous versions of D2. Figure 11 shows the evolution trace of D3, explaining why D2 is evolving into D3.
The context manager.
In addition, in each trace scheme, the context can also support classification-based traceability. The designer can limit the trace results to the specified types of DR elements. For example, a trace could traverse only those options proposed for a given intent. Classification-based traceability can reduce information overload when the designer is analyzing trace results.
5.3. Attached document
Designers can upload and annotate related documents of the DR, and the uploaded documents will display when a designer clicks on the relevant node. As is shown in Figure 12, the schematic of the rebound-measuring device can be attached as the reference of eI14.
A schematic of the rebound measuring device.
Therefore, the system can capture, formalize, and manage the evolving DR knowledge in an effective way. It supports designers to record their complete thinking processes and to review, understand, and reuse previous DR knowledge conveniently. It can also ensure that the input DR is grammatically correct in every step of the DR record by pointing out any syntactic or semantic errors.
6. CONCLUSIONS AND DISCUSSION
This paper proposes an improved intent-driven DR model to represent the evolving DR. It consists of four submodels: design intent, design decision, design justification, and design operation. The proposed model can support effective DR reuse. First, unlike the argumentation-based model, the intent-driven model treats a design as an evolving cognitive process. It provides design reuse with more complete DR knowledge in which the interactive relationships among design problems and the iterative and evolving history of DR elements are explicitly represented. Second, nine relationships between DR elements and the OWL-based knowledge representation rule improve the expressiveness of the DR model. This further helps designers easily capture, manage, understand, and reuse the DR. Furthermore, the context in DR is defined to document complete DR information and to support the effective traceability of the model. MindDigger, a graphical DR modeling system, is developed. The illustrative example shows that the proposed representation model can document the evolving history of a designer's thinking effectively and the prototype system can support a designer in modeling and managing the DR succinctly. This research provides an effective method to retain and manage designers’ implicit knowledge, which has great significance in improving the integrated management of product development knowledge and in developing knowledge-intensive design techniques.
The proposed DR representation model is preliminary research on DR. Much improvement can be made in the future. First, the modeling language should be more rigorous to improve the expressiveness and the computability of the model, and the DR reasoning and reuse ability of the prototype system should be strengthened. Second, DR is not an independent system. In practice what is needed is an efficient mechanism to document and manage a complex DR in real time as an integral part of the design process (Hooey & Foyle, Reference Hooey and Foyle2007). Relatively little research has been done on integrating rationale with the design process (Baxter & Gao, Reference Baxter and Gao2007). Therefore, another area for further research is an integrated DR modeling method for engineering design, in which the DR model and the process model are provided in a single framework. Third, most of the DR systems use mechanisms that let designers provide their own expressions about design decisions and reasoning during the design process. However, such tools met with limited success in practice because they require a substantial time investment and may disrupt the designer's normal activities. Therefore, DR information should be a by-product of the design process, and it should be captured without requiring additional effort on the part of the designer. In ADD (Carcia & Howard, Reference Carcia and Howard1992), the system asks the designer for justification only when the designer proposes a value different from the value that the system expected. This approach has the possibility of acquiring the designer's implicit knowledge by not officiously but relevantly asking questions of the designer. Future research may include this approach to promote automatic DR capturing and to make the system more intelligent in supporting decisions.
Jihong Liu is a Professor in the School of Mechanical Engineering and Automation at Beihang University. He received his PhD in mechanical engineering from Tokyo Metropolitan University in 1996. Dr. Liu has published more than 50 journal and conference papers and has served on the scientific boards of two journals. His research interests include complex product engineering, knowledge management and knowledge engineering, and artificial intelligence in design.
Xujie Hu achieved her PhD in mechanical engineering from Beihang University in 2013. Her research interests focus on artificial intelligence in design and knowledge management. Dr. Hu's recent work has involved the application of DR models to the development of computer-aided support tools for capturing, representation, and reuse of DR.
