a knowledge acquisition method to model parametric engineering

Int. J. Computer Aided Engineering and Technology, Vol. 4, No. 4, 2012 373

Copyright © 2012 Inderscience Enterprises Ltd.

A knowledge acquisition method to model parametric engineering design processes

Wouter O. Schotborgh* Faculty of Engineering Technology, Department of Design, Production and Management, University of Twente, P.O. Box 217, 7500 AE Enschede, The Netherlands Fax: +31-53-489-3631 E-mail: [email protected] *Corresponding author

Chris McMahon Department of Mechanical Engineering, University of Bath, Claverton Down, Bath BA2 7AY, UK E-mail: [email protected]

Fred J.A.M. van Houten Faculty of Engineering Technology, Department of Design, Production and Management, University of Twente, P.O. Box 217, 7500 AE Enschede, The Netherlands E-mail: [email protected]

Abstract: This paper proposes an interview-style method to create models of engineering design processes intended for design automation. Development of design automation tools often requires a model of the design artefact, design process or design knowledge. However, the knowledge about product development often resides tacitly inside the mind of designers and is difficult to make explicit. The lack of explicit process models creates a challenge for organisations to improve their design processes. A method is proposed to create explicit models of tacit design knowledge of structured design problems. A standardised model of the design process is used to classify sets of information and processes. The content of the model is filled step-by-step through a series of questions. A prescriptive modelling method reduces the required effort for knowledge modelling and allows design processes to be supported more effectively. The method is demonstrated for a design case with tacit knowledge and a further nine cases are used to demonstrate scalability and comparison between design knowledge of mechanical components and complex product systems.

Keywords: knowledge acquisition method; knowledge engineering method; parametric modelling; engineering design; design automation; computer aided engineering.

374 W.O. Schotborgh et al.

Reference to this paper should be made as follows: Schotborgh, W.O., McMahon, C. and van Houten, F.J.A.M. (2012) ‘A knowledge acquisition method to model parametric engineering design processes’, Int. J. Computer Aided Engineering and Technology, Vol. 4, No. 4, pp.373–391.

Biographical notes: Wouter O. Schotborgh is Researcher and Assistant Professor at the Department of Design, Production and Management, Faculty of Engineering Technology, University of Twente. He received his PhD in Mechanical Engineering at the University of Twente in 2009. The research topic is the development process of design automation software and several approaches to improve both the software functionality and the development process. His interests span from design automation to teaching methods for knowledge transfer and standardisation of knowledge. After his PhD, he started a spin-off company to bring the technology to the market and improve the research with feedback from industry.

Chris McMahon is a Professor of Engineering Design in the Department of Mechanical Engineering at the University of Bath, which he joined in 2002 from the University of Bristol. In his early career as an Engineer, he worked in the railway industry and with a consulting engineering company specialising in IC engines. He teaches and researches in engineering design and computer-aided design. He is interested in many aspects of design and computing, in particular how computer aids can assist design in the organisation and management of the information used in design.

Fred J.A.M. van Houten is the Head of the Research Group ‘Design, Production and Management’ of the University of Twente. He graduated in Mechanical Engineering (1977) at the Eindhoven University of Technology and obtained a PhD of the University of Twente (1991). His research topics include scenario based design, synthetic environments, virtual and augmented realities and design for manufacturing and maintenance. He is currently the President of the International Academy for Production Engineering (CIRP), as well as a member of the Berliner Kreis and German Academy of Science and Engineering (acatech).

1 Introduction

In the world around us, we encounter an enormous stream of products with constantly changing features and appearances. The trend of increasing product diversity has a profound impact on companies, teams and individuals that develop these products (Prahalad and Liebertal, 2003). The pressure on product development efficiency is growing and companies are actively searching methods and tools to improve their process efficiency. Decades of academic research have yielded many different forms of support for increasingly complex problems and processes, see Section 2 for more details. It has been noted that the creation of the initial model that describes the problem, derived from the tacit minds of designers, is both costly and difficult (Stokes, 2001; Cagan et al., 2005; Fensel, 1995). A systematic approach is needed for the initial knowledge capturing process. This paper proposes such an approach that prescribes, in a practical manner, what knowledge to capture and how to do this.

The application scope of the method is parametric engineering design with quantitative data, ranging from mechanical components to complex system design.

A knowledge acquisition method to model parametric engineering design processes 375

Suitable design problems are well-structured and with known applications and usage scenarios. The knowledge to be modelled has to be available. The scope includes routine design and improvement design, which is much used in industry (Tomiyama et al., 2009). Special attention is given to the phase of design where initial design solutions are generated: the synthesis phase (Weber, 2005).

The following sections will first address existing methods and theories to demonstrate that prescriptive methods are required for the knowledge acquisition phase, down to the interaction with the specialist. Providing such a method requires a model of the design process with several specific properties, which are described. A design process model is proposed by integrating several established frameworks into a description that explicitly addresses sub-processes and information sets. The sub-processes and information sets are used to prescribe a detailed method to acquire the knowledge content in a modular fashion: not everything at once, but in smaller steps. The interview-style knowledge acquisition method is discussed in Section 4. Finally, an industrial case is used to demonstrate the method and several further cases are compared to illustrate the benefits of the presented method.

The research to develop the knowledge acquisition method was done as reflective practise and action research. Briefly explained, the reflective practise research methodology (Schon, 1983) was followed by carrying out experiments to generate new understanding of knowledge and attempt to create computational models that capture the relevant information. Automatable models ensure sufficient information to simulate the original design process. When specialists approach a problem, they automatically divide it up into smaller ‘sub-problems’ and, using their knowledge and experience, intuitively apply a series of standardised decision-making processes. The knowledge acquisition method explores and charts these intuitive decision-making processes. Research questioned addressed the ends to be sought (how complete should the model be?) as well as the means to be employed (how to get the information?). The action research method (Blessing and Chakrabarti, 2009) was applied through multiple cycles of action and research, executed on multiple cases. The cases ranged in complexity from mechanical components to transport networks. Recent research efforts are aimed at studying scalability and broadening the application scope of the method. Statistical evaluation of multiple design cases is expected to further quantify assumptions regarding the use of knowledge in design processes.

2 Background

This section demonstrates that several research domains provide theories and methods to improve the design process, but models of the design process, artefacts or knowledge are often required as a starting point. The research field of knowledge engineering (KE), the creation of computational models of design knowledge, has identified the difficulties of making tacit knowledge explicit.

2.1 Design automation and optimisation

Computational synthesis (CS) is a field of research that generates and optimises designs with topological variety, i.e., the element structure of the design is dynamic (Helms et al., 2010; Antonsson and Cagan, 2001; Chakrabarti, 2002). CS offers support for design


processes ranging from shape driven (architectural) design to electro-mechanical systems (Cagan et al., 2005), with the representation of a design problem as a core issue. It is noted that the setting up of a problem is an activity that has not received much attention in the literature. In addition, the importance of the problem representation is stressed as critical to the richness and sophistication of designs that are generated (Cagan et al., 2005).

The fact that the functionality of design automation software is dictated by the computational model of the design problem is also true for other automation techniques: Barták (2008) provides an overview of the solving technology of constraint programming (CP) to automate design processes and generate multiple solutions. CP offers a method of problem solving that allows declarative specifications of relations among objects. Constraint-based approaches are successfully applied to, e.g., the field of 3D mechanism and linkage system design (Hicks et al., 2006). For the generation of initial design candidates, the constraint satisfaction algorithms are especially relevant and have been available for many years (Kumar, 1992). Constraint satisfaction generates initial solutions that satisfy the constraints, without further solution modification or optimisation. The class of optimisation algorithms generate solutions toward an optimum, defined by an objective function. Multi-objective optimisation is much used for engineering problems (Marler and Arora, 2004; Papalambros and Wilde, 2000), and computational design synthesis research (Helms et al., 2010).

Most, if not all, automation and optimisation tools for engineering design require some model of the design artefact or process. If the software tools are to fit the existing design context, then these models have to be (partially) based on the existing design process: again, there arises the need to model real-life design processes.

2.2 Knowledge engineering

KE is the process of constructing a computational model of knowledge. In general, KE is seen as an activity that requires understanding of both the computational aspects as well as the design case at hand (Raphael and Smith, 2003). Fensel (1995) suggests that perhaps the major difficulty with KE from a human source is the tacit nature of much expert knowledge and the fact that “design experts are experts in problem solving, not in explaining their solutions”. Knowledge-based engineering (KBE) is the automation of computer-interpretable knowledge models to support design tasks. The ‘methodology and software tools oriented to KBE project’ (MOKA) addresses the issues how to standardise and model design knowledge consistently in a KBE context, once it is gathered. The MOKA project found that the largest cost element of building KBE systems occurs during the stages of gathering knowledge, extracting the useful parts and representing that knowledge in a structured way (Stokes, 2001).This paper builds on the frameworks established by Stokes (2001) and Fensel (1995) by proposing a method to support the initial knowledge gathering phase to create a design process model.

3 A design process model for knowledge acquisition

Many models of design processes are available in the literature, each with its intended usage and characteristics. The research described in this paper requires a model with the following properties:


1 Distinct sets of information and sub-processes: By dividing the total design processes into smaller pieces, the knowledge acquisition method can address each individually instead of everything at the same time.

2 The model should be stackable: A design process for one specialist can follow a design process of another specialist. Both specialists execute a similar design process, with interactions as information is addressed in both processes. Complex products can have design processes from the highest level of abstraction all the way down to its components. Modelling these design processes should be possible by starting at any level and then working up and down by attaching new design processes to the existing ones.

3 Common nomenclature: The annotations within the model should be general and not focused on, for instance, the definition of geometry or computational automation.

4 Ability to describe an existing design process, as opposed to a model that describes original or creative design from scratch. The method proposed in this paper should be well matched to the design knowledge that exists in design processes.

The remainder of this section describes design process models that are used to create the underlying model of this paper, discussed in the next section. The theory of axiomatic design (Suh, 1990) is a well-known theory that describes design as a mapping process between a set of function requirements (FRs) and a set of design parameters (DPs). During a product design process, the required values for FRs are achieved by choosing the correct values for the right DPs. The design process of complex products or systems is decomposed into a hierarchy to reduce complexity. The nomenclature from Axiomatic Design is used where possible. McMahon (1994) proposes a model for a design process with distinct sets of information and relationships. Weber (2005) presents a modelling framework for both the product model as well as the process of design: the characteristic-properties modelling and property-driven development (CPM/PDD). Both frameworks (McMahon, 1994; Weber, 2005) are suitable for the goal of this paper, because they describe sets of information that are used distinctly differently during design:

1 information that is externally prescribed

2 information that is directly modified by the design team

3 information that is indirectly influenced.

The indirect information describes the quality of the design and can only be controlled indirectly, by modification of the design parameters. The following section introduces the model that is composed out of the previously mentioned models.

3.1 Design process model

The definitions of axiomatic design (Suh, 1990) are used where possible, combined with the sub-process and information set definitions from McMahon (1994) and Weber (2005). The labels ‘synthesis’ and ‘analysis’ for two phases in the design process are adopted from Weber (2005), because of their complementary role in design: synthesis generates a candidate design solution based on required behaviours, while analysis uses a created design to derive actual behavioural characteristics. These two ‘mirrored’


processes have proven very useful to identify the design parameters: the information precisely in between both processes.

Figure 1(a) depicts a model of a design process as an iterative loop on a single level of hierarchy. The model consists of sets of information and sub-processes that operate upon the information to add new information. Figure 1(b) shows an example of the design process, discussed in Section 5. Each set of information and process is explicitly known on parametric level. The dashed information and processes are not taken into account for the case of Section 5. The design process contains sets of information that contain parameters. Parameters receive a value during the design process. In the case of routine design, the values of the parameters can be different for each new design process, but the parameters remain static. In the case of innovative or creative design, the parameters themselves may change, including the knowledge to generate feasible designs. This paper focuses on routine design.

Figure 1 (a) design process model (b) example case from Section 5

(a) (b)

The information sets are five in total:

1 The requirements contain all parameters used during the design process. A requirement for a parameter relates to its value, which can be a fixed or desired value, or allowed value range. Translating desired product properties into parametric requirements is an activity that the specialist is able to execute.

2 The design parameters state the core of the design process. This set contains the minimum information that describes a design artefact or system, with sufficient level of detail to be analysed. The design parameters are under control of the designer.

3 Scenario parameters describe a usage situation in which the design is placed to determine its quality. Scenarios are externally determined and not considered a degree of freedom for design. An example of a scenario is a load case on a bridge.

4 Performance is the measure of quality, quantified by an analysis method. The performance is used to evaluate the quality of a design and can only be indirectly manipulated by modification of the design parameter values.


5 The solution is the collection of design parameters and values that satisfies all requirements. The information content of the solution depends on the level of detail.

Stating the sets of information explicitly requires the design process to be known. Obtaining the information from a design team is one of the goals of the modelling method described in Section 4. To decide which type a parameters is, the following decision scheme is suggested:

• Design parameters are independent parameters with values that can be manipulated by a designer. Design parameters are grouped into design elements to allow topological variation, such as multiple springs (the design elements) into an assembly.

• Scenario parameters are externally prescribed information about a usage situation. A designer is not allowed to manipulate these parameters freely.

• Performance parameters are information that is quantified after a design is created and analysis performed. Calculated by placing a design into a scenario, the performance parameters cannot be influenced directly.

The design process at a single hierarchical level begins with requirements and ends with a design solution. The level of detail of the design solution depends on the hierarchical level. A design process is modelled as a number of sub-processes, shown in Figure 1(a). The sub-processes are four:

1 Synthesis: the sub-process where an initial design is generated. The input information is the set of requirements and the output is a fully specified design, ready for analysis. Section 3.2 proposes a more detailed description of synthesis knowledge.

2 Analysis: the process that quantifies the performance values, discussed in more detail in Section 3.3. The input of analysis is a collection of design parameter values and scenario parameter values. Analysis methods can only be executed after a scenario is given and a design is produced by synthesis.

3 Evaluation: this process compares the performance values with the requirements and decides what to do next. As shown in Figure 1, three options exist:

a a design seems promising: a modification is made to it, after which it re-enters analysis. An automated loop of analysis, evaluation and modification results in an optimisation process

b a design does not meet the requirements, nor is it expected to. It is abandoned and synthesis is initiated again to create a new design

c the requirements are met and the design is added to the solution list or the design process descends one level in the hierarchy.

4 Modification: Improving a design involves an adjustment process with the goal to better meet the requirements. The difference with synthesis is that both the design and its performance are known. Therefore, the parameters already have a value assigned, which is a different situation than synthesis where not all values are known. The available performance information can be used to steer the


modifications to a specific direction. The knowledge model for modification is outside scope of this paper.

A design process is divided into levels of hierarchy to discriminate between issues of higher or lower importance [Suh, 1990; Oshuga in McMahon and Browne (1998)]. Levels of hierarchy are also used to determine performance information with higher or lower accuracy as well as higher or lower detail. The solution from a previous level forms part of the input (as scenario or requirement), together with a new set of requirements relevant to the design process on the next level. The step-wise refinement continues from initial product requirements to final product description ready for manufacturing. It is possible a design is unacceptable at the lowest level of hierarchy. First, a new design is generated in the synthesis process at that lowest level of hierarchy. If, after several attempts, no solution is achieved, it might be possible to move up one level in the hierarchy and request a new candidate. The reason why the design is unacceptable can be used in the modification process (see Figure 1) to create a more promising candidate. Backtracking up to the highest level, while no acceptable solution is found, can result in the conclusion that a product cannot meet its requirements.

3.2 Synthesis

The synthesis phase of the design process generates initial design candidates. The level of detail of the design candidate is dependent on the hierarchical level at which the design takes place. The starting point of the synthesis phase consists of a set of requirements and a knowledge base. During synthesis, parameters are given values and checks are made to verify that the process is moving toward a feasible design. This section discusses a view of synthesis knowledge as a human design mechanism, based on a view from cognitive design research: that design is characterised as a construction of representations, where a ‘representation’ is a (mental) model of the design problem at hand (Visser, 2006).The knowledge base enables the synthesis process to go from the input to the output by:

1 fixing free parameters by specifying a value

2 provide the means to check if the current set of parameter values is allowed or conflicting.

Fixing a parameter value can be done by solving a mathematical relation, but also by a more general determination of a value. The fixing methods range from mathematical relations to logic reasoning, random guesses or estimations. The result of applying such a method is always: one or more parameters receive a value and are fixed. Summarising, the entities required to model a synthesis process are:

1 information entities: parameters

2 methods to resolve, or fix, a free parameter value, labelled R-rules

3 methods to limit, or constrain, the allowed range of parameter values, labelled C-rules.

The model of the design process and specifically this description of synthesis knowledge is labelled PaReCo: Parameter, Resolve and Constrain. Constructing a PaReCo model with topological degrees of freedom requires one additional modelling entity: design elements. A design element, or element, is a group of parameters together with their


R- and C-rules. Elements correspond to parts of the design artefact in combination with the knowledge to specify it. When differentiating between design space and solution space, one design element can produce multiple solution elements which have identical parameters, but with different values. A third type of knowledge rule is introduced to expand topological trees: X-rules. An X-rule is executed when sufficient information is known to connect the sub-element(s) to existing elements. After the expansion, each element will be self-supporting and knows its place within the topology.

The knowledge rules are organised using the object-oriented paradigm (Bento et al., 1997), where the objects are the parameters: parameters become self-sustaining agents with their own knowledge rules. It is important to note that these rules are the same for every element, i.e., two compression springs possess the same knowledge. Knowledge rules consist of three parts:

1 object: the parameter or element to operate upon

2 conditional set: the set of parameters that is required to have a (specific) value before the rule can be executed

3 action: the explicitly described operation on the object(s).

The general layout of each rule is given in Table 1. Table 1 General rule layout

Rule General form

R-rule if(< condition >) then < parameter value > = < action > C-rule if(< condition >) then < parameter value > is valid if: < action >

if(< condition >) then 1 create sub-element instances 2 connect to existing design

X-rule

3 add to parent element

Models obtained by the PaReCo method can be automated by an algorithm consisting of three basic steps:

1 step forward: gather executable X and R-rules, then select and execute one rule

2 check: execute the C-rules

3 in case of a conflict, reverse one or several steps and try a different route.

The steps are similar to the Role-Limiting Method (Studer and Benjamins, 1998) and Backtracking from constraint satisfaction (Kumar, 1992), but are now explicitly defined in PaReCo terms. The algorithm follows the Gaussian-sweep approach, where the parameters are fixed sequentially (Schotborgh et al., 2008).

Under and over constrained situations can occur during the synthesis process. With PaReCo models, no direct relation is present between parameters and equations, because the R-rules are in between. In addition, R-rules are allowed to have estimations, discontinuities or random generation procedures. An under-constrained situation implies that no parameter can be fixed by executing an R-rule. To prevent this, a special R-rule is introduced that designers also use: a random value assignment to a (random) free parameter: the random R-rule. The random R-rule is a backup option to keep the


synthesis process moving toward a solution. An over-constrained situation can also occur during synthesis: a parameter is specified by more than one R-rule (excluding the previously mentioned random R-rule). If multiple R-rules are executable during synthesis, a system of equations (SOE) is present.

Unless an algorithm is included to deal with systems of equations, a real danger exists that parameter values are assigned incorrectly. However, whether or not a SOE is encountered during synthesis can depend on the order in which parameters are assigned. As this is a random process, it is possible that another solving order might get around the SOE. To prevent incorrect solutions being created, a synthesis run is aborted if more than one R-rule is available for execution during synthesis run-time.

3.3 Analysis

In general, an analysis method quantifies a performance parameter. Two sets of information (design and scenario) are required to determine a third (performance), leading to a generic representation of an analysis method: performance = f(design, scenario). The separation of the parameters into the different types is an important step of the knowledge acquisition method, discussed in Section 4. Analysis methods occur in different types, such as formulas, simulations, intuitive judging and experimental methods. The generic representation is recognisable in the different types, discussed briefly.

Formulae are explicit relations between parameters. An analysis formula explicitly contains a performance parameters, plus design and scenario parameters. However, mathematical expressions can be rewritten algebraically (inverted) to have other left and right hand sides. From observation only of an equation, it is not unambiguous what the input (design + scenario) is and what is the output (performance). The context of the design process is sometimes required to reveal the performance, design and scenario parameters. An analysis formula can be used during synthesis to fix a design parameter value, if the formula can be re-written in the proper form.

Simulations are used to reveal performance issues by computation, such as material stresses or process dynamics. Before a simulation is executed, a description of the design has to be fully specified. Depending on the hierarchical level at which the analysis is used, the level of detail can be higher or lower. For example, a two-dimensional wire frame model to represent a bridge, or a detailed three-dimensional model of the same bridge. Simulations have a clear and explicit relation between the input and output: the input has to be defined, after which a simulation reveals the performance output. The input/output information is used directly to distinguish between the performance information and scenario and design information.

Designers often do not use calculations or simulations to judge the quality of a design. Instead, it is done with an ‘expert’s eye’ to intuitively decide to proceed, abort or adjust a design. Still, a certain amount of detail is required in order to make the assessment. The inner workings of a tacit method may be difficult to make explicit, but the information input and output can often be specified. Although tacit analysis methods can be hard to quantify, they are still useful to describe and model the design process. The information input and output can be divided into the three types nonetheless. Once the performance information is known, one asks ‘how’ this is determined. The answer from the expert contains the scenario and design information. Similar to formulas, the


goal is to obtain a description of “performance is determined by …”, where the right-hand side contains scenario and design information.

4 Knowledge acquisition method

This chapter describes a method to construct a PaReCo model of a design process. The method aims to aid the ‘what to look for and how to get it’ – aspect of knowledge acquisition. In case of a human knowledge source, the knowledge engineer acts as a facilitator to make the expert’s knowledge explicit. The modelling process starts when the expert’s processes are still tacit. The first goal is to obtain an overview of the design activities and identify the levels of hierarchy.

During design, the role of knowledge is perhaps not completely clear, but Wittgenstein is said to have used the phrase: ‘To know means to know how to go on’, interpreted as ‘To know means to know how to take the next step from requirements to solution’. When the Wittgenstein view is combined with Raphael and Smith’s (2003) observation that design experts are very good in executing a design process, rather than explaining it, this leads to the notion that the knowledge acquisition method should ask ‘how’ questions, rather than ‘why’. The models that result from the acquisition method will contain procedural knowledge rather than justifications and rationale, which can be added later.

The knowledge acquisition method uses the analysis phase as guiding concept to decompose a design process into sub-processes and information sets. The analysis phase is chosen because the ability to predict the performance of a design is an essential activity and the expert will have thorough understanding of it. Interviewing about the analysis method, rather than ‘knowledge’, ‘product’ or ‘process’ enables the expert to focus on what he/she is an expert on.

4.1 Analysis-oriented decomposition

Decomposition means to divide a process into multiple sub-processes with multiple sets of information. Instead of one big model with all parameters and constraints, one creates smaller models that each contain fewer parameters and constraints. A five step decomposition method is proposed where identification of the hierarchical levels is done using the performance information. For each hierarchical level, the sub-processes and sub-sets of information are found using the analysis method.

Step 1 Identify the performance parameters: This can be done by asking an expert to describe the quality of a design, or how good it is. Give a design to an expert and ask how ‘good’ it is: what aspects does he/she consider? Give two different designs to an expert, and ask which design is the better one: again, what aspects are considered? What information decides if a design is not approved? These questions are asked at several moments during the design process. A list is made of performance information. Examples are cost, weight, maximum stress, optimal speed, first eigen frequency, dynamic response, stability, etc.

Step 2 Identify the levels of hierarchy during a design process: The performance identifiers are used to divide a total design process into levels. Intuitively, the aspects of higher importance are identified early on in the design process: on


higher hierarchical levels. Group the performance parameters with equal importance together to form the levels.

Step 3 Analysis method: Formalise the analysis methods of one distinct level of hierarchy: determine ‘how’ each performance identifier is determined. Using the analysis method as decomposition instrument requires the input and output information to be made clear. Describe the input and output information as parametrically as possible. Name each analysis method and its input/output information throughout the design process.

Step 4 Design parameters and scenario parameters: For each analysis method, identify the design and scenario parameters. The decision scheme from Section 3.1 is suggested as guideline. Design and scenario parameters of multiple analysis methods (from the same hierarchical level) are grouped.

Step 5 Auxiliary information: Expand the level of detail of a model to include other aspects mentioned by the expert. Dependent combinations of parameters can create multiple additional parameters that do not increase the number of design parameters, but to add information. The design parameters always form the core of the design process, but additional auxiliary information can be added to make design easier and capture ‘design intent’. For instance, characteristic ratios can be used to judge a partially constructed design before it is complete. Removing these parameters from the model might not change the design artefact description that is required for analysis, but does aid the decision making process.

After the information has been typed, the analysis methods and the design descriptions are combined to give a design model on a single level of hierarchy, with the layout of Figure 1. The next step is to focus on the synthesis process.

4.2 Synthesis knowledge

The set of design parameters are used to reveal the synthesis knowledge as R-, C-rules and finally the elements and X-rules. To obtain the R-rules for a parameter, one determines the condition statement and the action procedure for each way to fix a parameter value. The condition and action statements are acquired by formulating an explicit answer to the following questions:

1 Condition: When can you determine a value for this parameter?

2 Action: How do you determine the parameter value?

The condition part tells when a rule can be executed: what information must be known? Are there specific combinations of parameter values when a rule is executed? The action part states the method to fix the parameter to a specific value, such as an equation, logic or random value generation. Part of the condition follows from the content of the action part: all information that is mentioned must be known before it is used. Multiple R-rules are stated if a parameter can be fixed in more than one way: if a parameter occurs in multiple equations, each equation can provide in an R-rule.

The C-rules are found by inquiring, for each parameter, if the value is always good and never needs validation. If the value is checked somewhere during the synthesis


phase, this signals the existence of one or more C-rules. The condition and action statements are acquired by formulating an explicit answer to the following questions:

1 Condition: When can you check the validity?

2 Action: How do you check validity?

An example of a C-rule is the check if a value exceeds a certain minimum ratio, such as a ≥ b. An example of a non-algebraic C-rule for parameter ‘material’ is when certain materials are excluded for specific environments. The condition of the C-rule is true if the environment is known. The action part will exclude all materials from a set that are sensitive to corrosion.

Identifying design elements is done by grouping parameters. The question at this point is: what parameters belong together? The product that is being designed can be used to determine the element as physical entities, such as springs, belt drives, X-ray tube and detector. Elements can also be defined according to different functions they perform in a design. For example, an optical chamber (Section 5) has two diaphragm sets: one on the left side of the sample and one on the right side, see Figure 2(b). Both have a different function and are configured and designed differently. As a result, the PaReCo model has a design element ‘diaphragm set – left’ and ‘diaphragm set – right’, each with different knowledge rules.

Figure 2 XRF spectrometer and design representation (see online version for colours)

(a) (b)

Note: Copyright PANalytical BV

X-rules are revealed as the process that is executed to expand the topology of the design with new elements. Once the elements are identified, the X-rules are formulated to add them. The condition statement of the X-rule must check for the existence of other (parent) elements and the required information to connect the sub-elements to the partial design.

An example of an X-rule is the addition of N diaphragms in an optical instrument. The parameter N has been fixed using an R-rule, but the actual addition of the diaphragms to the design topology is done with an X-rule. The action statement of the X-rule first decides to distribute the diaphragms evenly or to place them at the extreme positions, and secondly actually instantiates the diaphragm elements and adds them to the topological tree of elements. The separation of the parameter N and the action to add the diaphragms is done to allow N to be fixed by other methods (e.g., user specified, random guess or calculated) and also to wait with execution of the X-rule until other parameter


values are available (e.g., preferences such as maximum brightness, minimum spot size). Separating parameters and topological expansion helps to keep the knowledge base modular.

5 Case

The method is applied to an engineering case within the domain of optical physics. Only a few experts have sufficient (tacit) knowledge to generate designs, with little explicit documentation about their process or engineering knowledge. The case concerns the optical chamber design for an X-ray fluorescence instrument (see Figure 2). This chamber is the heart of the instrument that determines the chemical composition of a sample material. Figure 2(b) shows the construction principle: the X-ray tube radiates the sample material through a diaphragm aperture, and the sample expels characteristic photons into a detector. This in turn reveals the chemical composition of the sample. A solid casing encloses the optical chamber to shield the environment from radiation.

The components should be positioned in such a way that the tube radiates the sample brightly, and the detector ‘sees’ only the radiated section of the sample. Unfortunately, the diaphragms and casing cause unwanted fluorescence that negatively influence the measurement quality. The behaviour depends on the component configuration, but also on the materials used and energy settings of the tube.

5.1 PaReCo model

The knowledge acquisition method is applied to experts of the design team: a senior mechanical engineering and a leading specialist of optical physics. The analysis-oriented decomposition is used to decompose the design activities and model the design in distinct layers of hierarchy. The resulting PaReCo model is automated into a design automation tool. First, the steps of the method are described after which the software is presented and evaluated.

Step 1 Performance: The performance of the optical chamber is specified in terms of its price, size and measurement quality. The measurement quality is mainly determined by two performance parameters: signal-to-background ratio and sensitivity. Signal-to-background ratio describes the relative amount of sample radiation that the detector receives, and the sensitivity represents the absolute amount.

Step 2 Levels of hierarchy: The design process of the optical chamber is described in three levels of detail: system level, physics level and mechanical level. The requirements for the measurement quality are specified on system level, forming part of the input for the design process on physics level. The physics level determines the signal-to-background and sensitivity parameters, which are of equal importance. The mechanical level uses the physics design as input to integrate with other sub-systems and prepare the design for manufacturing. The product performance is largely determined on the physics level, so this level is chosen for further modelling and automation. Figure 1(b) depicts the design process model in the physics level.


Step 3 Analysis method: The performance parameters are signal-to-background ratio and sensitivity. The performance of a particular design is determined by an expert’s eye and several analytical estimations. Little software analysis is used during the design process, so the analysis method is a relatively tacit one. Interviewing the expert ‘how’ he determines these parameters revealed a description of the input for the analysis method (and also led to the development of simulation software).

Step 4 Design and scenario: The analysis method requires a design model with 22 parameters to describe the geometry, position and orientation of the components. The scenario is determined on the system level and contains four parameters: sample material, the tube material and size and detector size.

Step 5 Auxiliary: Discussing the design model with the expert, and how this is created, revealed 18 auxiliary parameters to capture the design intent of the X-ray application and several geometric construction parameters.

The synthesis knowledge was acquired from the design parameters. The R-rules contained a mix of equations, logic reasoning and estimations within bounds set by other parameters. The majority of C-rules was a series of goniometric expressions to prevent, e.g., the tube and detector from touching the casing. Several other C-rules check the material choices, based on maximum energy levels. A total of three X-rules were formulated, together with 19 R-rules and 20 C-rules. Examples of R-rules are given in Table 2. Table 2 Examples of R-rules

Rule Action part Description R-rule ( ),min ,max,p pNp random N N= The number of diaphragms at the primary side

(tube side) is randomly fixed between a minimum and a maximum (set by the user).

R-rule In(0.01)Round Up TenstDμ ρ

⎛ ⎞= ⎜ ⎟− ⋅⎝ ⎠

The thickness of a diaphragm is calculated by requesting a factor 100 attenuation of radiation, rounded up to tens of millimetres. The symbols μ and ρ represent derived diaphragm material properties.

Figure 3 Design automation tool (see online version for colours)


The PaReCo model allows enough freedom to generate different designs. Figure 3 shows a cloud of designs in the left hand side, plotted in a graph with signal to background ratio versus sensitivity. Each dot is a fully specified design. The graph shows the generated solutions in a solutions space: an overview of what is possible. The right hand side shows the selected design that has a high value on both axis in the graph.

5.2 Validation

Validation of the software was done by testing several scenarios and by studying the parameter sensitivities. The design expert compared the simulated results with expected values from experience, and found the results being proportional to expectations. This means the software can be used to rank design solutions relative to each other, which was in accordance with the intended use of the tool. The expert expected a significant reduction in design time when these tools would be available in future design processes. More details on the validation of PaReCo models is found in Schotborgh (2009).

5.3 Multiple case comparison

Multiple design problems from both literature and expert engineers have been modelled in PaReCo, a brief summary of which is given in Table 3. PaReCo enables these seemingly different cases to be compared on a knowledge level. Table 3 PaReCo comparison multiple cases

Case Description

Para

met

ers

Elem

ents

R-ru

les

C-r

ules

X-ru

les

Optical chamber (expert)

Positioning and orientation of five to eight components.

44 8 19 20 3

Baggage handling system (expert)

Logistics network of 19 components.

204 51 120 0 46

Runner gate* (expert)

Geometry of flow channel for injection moulding.

13 1 13 7 0

Belt drive Rotating power transmission. 18 1 27 23 0 Compression spring (basic)

Compression spring geometry. 11 1 23 21 0

Compression spring (extended)

Compression spring with multiple materials and end finishes.

24 1 46 33 0

Extension spring Extension spring with multiple materials and end finishes.

24 1 43 27 0

Torsion spring Torsion spring with multiple materials and end finishes.

18 11 30 10 0

Flexure element Circular flexure element geometry and materials.

10 1 13 4 0

Mass spring damper*

Mass spring damper dynamic response on a ramp input.

11 1 19 0 0

Note: *Done by masters students


One way to characterise the knowledge models is to evaluate the size of the model with the amount of ‘deterministic’ knowledge: the number of parameters versus the amount of R-rules. The comparison is graphically represented in Figure 4. Two groups of cases are indicated: explicitly documented and industrial cases from an expert engineer. Although no systematic evaluation is made, it appears that the design problems from human source have relatively fewer R-rules per parameter. This is attributed to the fact that the context (input and output) of the design problem is known and relatively fixed. As a result, the synthesis process has a known path from beginning to end and the R-rules provide the means to generate designs along that path. The knowledge that is described in literature, on the other hand, has a more unpredictable usage and provides flexibility as the set of fixed parameter values may vary. Multiple paths from an input set to a fully described design are provided by using algebraic equations to resolve different parameters. This results in more than one way to fix a parameter, e.g., more R-rules per parameter.

Figure 4 PaReCo comparison, multiple cases (see online version for colours)

6 Discussion

The presented method was applied to nine different design cases and was found to enable modelling of the design processes quickly and systematically. Even when the design case was about an unfamiliar field of expertise, the method was applied and resulted in a clear process model. Each of the models was sufficiently concrete to be automated and developed into a design automation tool.

Scalability is indicated by applying the method to cases ranging from components to the design of systems. The efficiency with which the method is applied requires further scientific study. Systematic validation of the method, as well as the models themselves, requires the method to be applied by a range of engineers in different domains.

A standardised description of design processes improves knowledge transfer from specialists to new designers. Learning new knowledge is done in modules, rather than all parameters and relations at once. A graphical representation of the process also aids the communication between knowledge domains and between specialists and management.


7 Conclusions

A method is proposed that captures knowledge of tacit, experience-based design processes and creates a model with explicit parameters and processes. The method prescribes how non-experts gain overview and understanding of expert design processes and derive an explicit model from tacit knowledge. The person to apply this method is not required to possess the expert’s knowledge in order to model it, but rather acts as a facilitator for the expert to state the content of the model.

Decomposing a design process into distinct layers of abstraction and sub-processes reduces the complexity of the parametric model. The results are agreed upon by the experts and serve as a starting point for software development or further modelling of the design process. Knowledge acquisition is becoming a methodological activity that standardises synthesis knowledge for parametric routine design.

Acknowledgements

The authors gratefully acknowledge the support of the Innovation-Oriented Research Programme ‘Integral Product Creation and Realisation (IOP IPCR)’ of the Netherlands Ministry of Economic Affairs, Agriculture and Innovation, as well as Frans Kokkeler, Hans Tragter and Juan Manuel Jauregui-Becker for their support during the underlying research. Furthermore, the authors would like to thank Professor Tetsuo Tomiyama (TU Delft) and Professor Christian Weber (TU Ilmenau), as well as the anonymous reviewers of IJCAET, for their valuable feedback, discussion and contribution.

References Antonsson, E.K. and Cagan, J. (2001) Formal Engineering Design Synthesis, Cambridge

University Press, ISBN 0-521-79247-9, Cambridge, UK. Barták, R. (2008) ‘Principles of constraint processing’, in Vlahavas, I. and Vrakas, D. (Eds.):

Artificial Intelligence for Advanced Problem Solving Techniques, pp.63–106, ISBN: 978-1-59904-705-8, Idea Group, Hershey, USA.

Bento, J., Feijó, B. and Smith, D.L. (1997) ‘Engineering design knowledge representation based on logic and objects’, Computers & Structures, Vol. 63, No. 5, pp.1015–1032, Elsevier Science Ltd., Great Britain.

Blessing, T.M. and Chakrabarti, A. (2009) DRM, a Design Research Methodology, ISBN 978-1-84882-586-4, Springer-Verlag, London.

Cagan, J., Campbell, M.I., Finger, S. and Tomiyama, T. (2005) ‘A framework for computational design synthesis: model and applications’, Journal of Computing and Information Science in Engineering, Vol. 5, No. 3, pp.171–181, ASME.

Chakrabarti, A. (2002) Engineering Design Synthesis: Understanding, Approaches and Tools, ISBN 185-2-33492-4, Springer-Verlag, London.

Fensel, D. (1995) The Knowledge Acquisition and Representation Language, KARL, Kluwer Academic Publishers, Boston.

Helms, B., Shea, K. and Hoisl, F. (2010) ‘A framework for computational design synthesis based on graph-grammars and function-behavior-structure’, Proceedings of the ASME International Design Engineering Technical Conferences and Computers and Informatics in Engineering Conference 2009, DETC2009 8 (Part B), pp.841–851.


Hicks, B.J., Medland, A.J. and Mullineux, G. (2006) ‘The representation and handling of constraints for the design, analysis, and optimization of high speed machinery’, Artificial Intelligence for Engineering Design, Analysis and Manufacturing, Vol. 20, No. 2, pp.313–328, Cambridge University Press.

Kumar, V. (1992) ‘Algorithms for constraint satisfaction problems: a survey’, AI Magazine, Vol. 13, No. 1, pp.32–44.

Marler, R.T. and Arora, J.S. (2004) ‘Survey of multi-objective optimization methods for engineering’, Structural and Multidisciplinary Optimization, Vol. 26, pp.369–95, Springer-Verlag.

McMahon, C.A. (1994) ‘Observations on modes of incremental change in design’, Journal of Engineering Design, Vol. 5, No. 3, p.195, Taylor & Francis Ltd.

McMahon, C.A. and Browne, J. (1998) CAD/CAM Principles, Practice and Manufacturing Management, 2n ed., ISBN 020-1-17819-2, Addison-Wesley Longman Ltd., Harlow, England.

Papalambros, P.Y. and Wilde, D.J. (2000) Principles of Optimal Design – Modeling and Computation, Cambridge University Press, Cambridge, UK.

Prahalad, C.K. and Lieberthal, K. (2003) ‘The end of corporate imperialism’, Harvard Business Review, Vol. 81, No. 8, pp.109–117.

Raphael, B. and Smith, I.F.C. (2003) Fundamentals of Computer-Aided Engineering, Wiley, Chichester, UK.

Schon, D. (1983) The Reflective Practitioner, ISBN 0-465-068782-2, Basic Books Inc., New York. Schotborgh, W.O. (2009) ‘Knowledge engineering for design automation’, PhD thesis,

ISBN 978-90-365-2801-6, University of Twente. Schotborgh, W.O., Tragter, H., Kokkeler, F.G.M., Bomhoff, M. and van Houten, F.J.A.M. (2008)

‘A generic synthesis algorithm for well-defined parametric design’, Proceedings of the 18th CIRP Design Conference 2008.

Stokes, M. (2001) Managing Engineering Knowledge: MOKA, MOKA Consortium, Professional Engineering Publication, Suffolk, UK.

Studer, S. and Benjamins, V.R. (1998) ‘Knowledge engineering: principles and methods’, Data & Knowledge Engineering, Vol. 25, Nos. 1–2, pp.161–197, Elsevier Science, available at http://www.sciencedirect.com/science/article/pii/S0169023X97000566.

Suh, N.P. (1990) The Principles of Design, Oxford University Press, Oxford. Tomiyama, T., Gu, P., Jin, Y., Lutters, D., Kind, Ch. and Kimura, F. (2009) ‘Design

methodologies: industrial and educational applications’, CIRP Annals – Manufacturing Technology, Vol. 58, No. 2, pp.543–565.

Visser, W. (2006) ‘Designing as construction of representations: a dynamic viewpoint in cognitive design research’, Human-Computer Interaction, Vol. 21, No. 1, pp.103–152, Lawrence Erlbaum Associates Inc.

Weber, C. (2005) ‘CPM/PDD – an extended theoretical approach to modelling products and product development processes’, Proceedings of the 2nd German-Israeli Symposium on Advances in Methods and Systems for Development of Products and Processes, TU Berlin/Fraunhofer-InstitutfürProductionsanlagen und Konstruktionstechnick (IPK), pp.159–179, Fraunhofer-IRB-Verlag, Stuttgart.

a knowledge acquisition method to model parametric engineering

Documents