1. INTRODUCTION
Design knowledge reuse (DKR) is an effective approach for design organizations to develop robust artifacts in short time and with low cost. However, existing computer-aided design (CAD) and product life cycle management software, which are primarily developed for designers to manage geometrical information, cannot provide effective support for DKR. Therefore, DKR has attracted considerable attention from the engineering design community in recent decades. For example, Gero (Reference Gero1990) has developed the function–behavior–structure model for organizing the conceptual knowledge about a design prototype; Szykman et al. (Reference Szykman, Racz, Bochenek and Sriram2000) have developed a web-based approach for modeling the conceptual knowledge of existing artifacts for reuse; Baxter et al. (Reference Baxter, Gao, Case, Harding, Young and Cochrane2007) have developed an integrated DKR framework for the early design stage through bringing together best practice reuse, design rationale capture, and knowledge-based support; Goel et al. (Reference Goel, Rugaber and Vattam2009) have developed the structure–behavior–function (SBF) model for representing conceptual design knowledge; and Bracewell et al. (Reference Bracewell, Wallace, Moss and Knott2009) have extended the issue-based information system for capturing design rationale in a more effective manner. Witherell et al. (Reference Witherell, Krishnamurty, Grosse and Wileden2010) have developed a first-order-logic-based approach to improve design knowledge management. Our previous research has developed a knowledge-based approach for reusing multidisciplinary principle solutions through design synthesis (Chen, Liu, et al., Reference Chen, Huang and Xie2012).
However, existing DKR research is primarily for modeling and reusing early (e.g., conceptual) design knowledge, with very little dealing with detailed design knowledge. Here, detailed design primarily refers to a mechanical design process for determining the forms and dimension of mechanical parts. According to Pahl and Beitz (Reference Pahl and Beitz2007), detailed design should consider not only the functional and embodiment requirements generated in upstream stages but also various life cycle (e.g., manufacturing, assembling, transportation, maintenance, etc.) requirements in downstream stages. Therefore, it is a complex decision-making process that requires all life cycle knowledge from both upstream and downstream stages. In addition, since detailed design is often experience dependent, much reusable knowledge often exists. Therefore, it is of great value to study how to model and reuse detailed design knowledge.
This paper will introduce a formal approach for modeling detailed design knowledge, which is the cornerstone of our DKR research. Section 2 introduces how the original SBF model (Goel et al., Reference Goel, Rugaber and Vattam2009) is extended to represent detailed design information. Based on the extended SBF model, Section 3 then proposes a formal approach for modeling detailed design knowledge. With a fixture design case, Section 4 briefly illustrates how the proposed design knowledge modeling approach is implemented. Finally, Section 5 concludes this paper.
2. AN EXTENDED SBF MODEL
Engineering design researchers usually agree that a technical artifact is primarily related to three basic concepts: function, structure, and behavior. These three concepts and their relations can be used to model design knowledge. One of the representative works is the original SBF model for representing conceptual design knowledge (Goel et al., Reference Goel, Rugaber and Vattam2009). In this research, we have extended the original SBF model for representing detailed design information, as shown in Figure 1.
Fig. 1. An extended structure–behavior–function model.
2.1. Structure
Structure refers to the physical appearance of an artifact. The structural representation here has both a composition representation and a form representation. The composition representation employs bills-of-materials to describe what entities (i.e., parts or assemblies) an artifact has, as well as the assembly relationships among them. Each entity (part or assembly) in the composition representation can be conceptualized as a binary group, <id_name, {attributes}>, where id_name describes the ID (identification) name of the entity, while attributes are physical attributes, for example, density and rigidity.
To support detailed design, the original SBF model has been extended to include the form representation, which describes the geometrical forms and the related dimensions of each part. Our form representation takes a descriptive feature-based approach, which employs geometrical features and location relation parameters between those features to represent the geometrical information of a part. Each geometrical feature is further represented with a set of parameters. Note that the form representation of a part is also associated with a parameterized CAD model to facilitate its integration with commercial CAD software.
2.2. Behavior
The behavior of an entity refers to its own state change in its life cycle periods—for example, the rotation of an axle or the deforming of a spring. Unlike the original SBF model, which usually deals with the causal behaviors for achieving a desired function (Goel et al., 2009), the extended SBF model also involves those behaviors in various life cycle (e.g., manufacturing) periods of an entity, as well as some side behaviors that are unrelated to the entity's functions. This is because designers should also consider such life cycle behaviors in detailed design.
A behavior here is quantitatively represented with a 5-ary tuple, <id_name, aff_entity, beh_param, caus_obj, remarks>. Here, id_name stands for the ID name of a behavior, aff_entity refers to what entity (i.e., part or assembly) the behavior is affiliated to, beh_param is a quantitative parameter for describing the degree of the state change, caus_obj describes the objects that stimulate the current behavior, and remarks are informal explanations. It is evident that the behavioral representation here is different from that in the original SBF model, where a behavior has been qualitatively represented as a causal state transition.
2.3. Function
Based on our recent research (Chen, Huang, et al., Reference Chen, Liu and Xie2012), a function in the extended SBF model is defined as an intended relation that one entity has (i.e., subject) with another (i.e., object) in any of its life cycle periods. The concept of function here is therefore more like affordance, a novel design methodology concept developed by Maier and Fadel (Reference Maier and Fadel2009), rather than that in the original SBF model, which primarily refers to the input–output state transitions. This affordance feature also makes our extended SBF model different from the CPM2 model (Fenves et al., Reference Fenves, Foufou, Bock and Sriram2008).
Functions can be classified as two types: internal functions and external functions. An internal function means that both its subject and its object belong to the artifact being designed. Internal functions can be further classified as static functions and dynamic functions. In a static function, the object is usually regarded as a static entity. For example, when the gearbox is said to have a function of containing gears, the gears are regarded as static objects. A static function can be conceptualized as a 5-ary tuple, <sub, verb, obj in, func_param, remarks>. Here, sub denotes the subject, verb is a verb describing the functional relation, obj in refers to the internal object (i.e., a part) that is related to the subject, and func_param is a functional parameter. A dynamic function is focused on the change of the object's dynamic behavior. It can be orally described as to do the behavior of something. A behavior-focused function can be conceptualized as a 6-ary tuple, <sub, verb, obj in, func_param, foc_behav, remarks>. Here, the symbol foc_behav refers to the object's focused behavior to be processed by the function.
An external function means that its object is not a part of the artifact being designed. Similar to an internal function, an external function can be conceptualized as a 5-ary tuple, <sub, verb, obj ex, f_param, remarks>, where obj ex refers to the external object that is acted on. Compared with existing CAD or product life cycle management tools, modeling external functions has a major advantage, that is, the external objects considered in various life cycle periods of an artifact can be captured as functional information. Therefore, it can help designers better understand a detailed design. For example, various tools for machining parts and assembling them (e.g., milling machines, wrenches, etc.) can also be modeled in external functions, which enables designers to understand how such tools influence the result of a detailed design.
3. MODELING DETAILED DESIGN KNOWLEDGE
Detailed design is primarily aimed at assigning values to the geometrical parameters of an entity. The knowledge that supports such decision-making processes is regarded as detailed design knowledge, which can also be called tacit knowledge in existing research (Haug, Reference Haug2012). Just like design rationale, detailed design knowledge can also be further classified as issue knowledge and solution knowledge.
3.1. Modeling issue knowledge
It is acknowledged that issues considered during designing are the most important contextual knowledge about a design solution. They allow designers to understand and learn what issues have been considered in a design solution. In this research, detailed design issues are represented as three kinds of design constraints: structural constraints, behavioral constraints, and functional constraints.
3.1.1. Modeling structural constraints
A structural constraint usually refers to a constraint on a geometrical parameter of an entity. It may come from multiple origins (e.g., external working environments, industrial standards, and ergonomics). In addition, structural constraints can be classified as simple constraints and complex constraints.
A simple structural constraint merely deals with an allowable value range of a geometrical parameter. It can be represented as a 5-ary tuple, {o(p s), v b, u, r, rmk}, where p s is the related geometrical parameter, o the object to which the geometrical parameter belongs, v b its boundary value, u its measure unit, r the relation between the parameter and the boundary value, and rmk the informal remarks about the constraint. For example, assume there is a structural constraint on a car, that is, its width should be smaller than 3.5 m. This structural constraint can be represented as, {Car(car_feat(w)), 3500, “mm”, “<”, …}. Here, the entity is Car, which has only one complex feature, car_feat, with a geometrical parameter, w, for width.
A complex structural constraint often deals with a complex constraining relation among multiple geometrical parameters belonging to multiple entities. In this research, a complex structural constraint is represented as, {[o(p s)i], v b, u, r, rmk}, where [o(p s)i] refers to a polynomial composed of the related geometrical parameters associated with their ontological representations. How to represent a polynomial will be illustrated later.
3.1.2. Modeling behavioral constraints
A behavioral constraint refers to a constraint on the dynamic behavior of an entity to be designed. For example, a designer may impose a behavioral constraint on an economic electrical car, that is, its maximal speed should be smaller than 150 km/h. Similar to structural constraints, behavioral constraints can also be classified as simple constraints and complex constraints.
A simple behavioral constraint refers to the allowable value range of the related behavioral parameter, which can be represented with a 5-ary tuple, {o(p b), v b, u, r, rmk}, where o represents the subject of the behavior and p b the corresponding behavioral parameter. For example, the behavioral constraint mentioned above can be represented as, {Car(v max), 150, “km/h”, “<”, …}. A complex behavioral constraint refers to the constraining relation among multiple behavioral parameters and can be represented as, {[o(p b)i], v b, u, r, rmk}, where [o(p b)i] is a polynomial composed of multiple behavioral parameters.
3.1.3. Modeling functional constraints
Although the engineering design community usually agrees that engineering design is a function-centered activity, the role of function in detailed design has not been clarified in previous research. We have identified an axiom, the functional constraint (FC) axiom, to help designers derive quantitative constraints from functional descriptions (Chen, Huang, et al., Reference Chen, Liu and Xie2012). The FC axiom is the following:
If an entity S (subject) is said to have a function on an entity O (object), then some design parameter(s) of S will be fully or partially constrained by some design parameter(s) of O.
Here, design parameters can be functional, behavioral, or structural. The FC axiom exists and holds in each successful design case. For example, if a seat is designed to hold an adult, then its geometrical parameter, width, will usually be constrained by the average width of adults. Therefore, based on the FC axiom, it is possible to derive many quantitative constraints from the functional descriptions of an entity. A detailed approach for deriving functional constraints from functional descriptions can be found in our recent research (Chen, Huang, et al., Reference Chen, Liu and Xie2012), and is therefore not elaborated here.
A functional constraint can be conceptualized as a 5-ary tuple, {p s, p o, r, f s, rmk}, where p s stands for a design parameter of a functional subject, p o for a design parameter of a functional object, and f s for the identifier(s) of the corresponding function(s). Based on the above representation, the aforementioned functional constraint on the seat can then be represented as, {Seat(seat_feat(w), Adult(w), “>”, ID to-hold-an-adult, “…”}. Note that a functional constraint must be associated with the corresponding function(s) in the above representation, which at least has two advantages. One is that it can record the argument for a functional constraint, which can make the constraint easily understood by other designers. The other is that it can help a designer judge whether a functional constraint should be reused or not when the corresponding design solution has been reused.
3.2. Modeling solution knowledge
After the structural, behavioral, and functional constraints have been modeled, a critical task then emerges as how to solve these constraints to help designers determine the feasible value range of each design parameter. The constraints-solving knowledge can be called solution knowledge and can be classified as either model knowledge or computation knowledge. Represented with informal remarks, the model knowledge describes what physical model (i.e., principle) can be used to solve a constraint (e.g., a cantilever model).
The computation knowledge is a formal representation that manages the computation formulae for assigning values to design parameters. The proposed model for representing a formula is conceptualized as a 4-ary tuple, {p t, P p,r, o c}. Here, p t is a target (i.e., constrained) parameter, whose feasible value range should be determined; P p represents a polynomial including multiple constraining parameters; r refers to the value relation between the target parameter and the polynomial; and o c denotes the original constraint of the current formula. The polynomial (P p) is further represented with the genetic programming approach (Koza, Reference Koza1992), which can be conceptualized as a triple, {n l, o, n r}. Here, n l and n r represent the left-hand node and the right-hand node of a subtree, respectively, which can be a variable, a constant, or a mathematical operator, whereas o is the parent node of the node, which can merely be a mathematical operator. Note that each parameter in the genetic programming representation is defined in the extended SBF model.
For example, assume the main shaft in a wind turbine has a round cross section with two design parameters, that is, diameter (d) and length (l). Due to the gravity of the turbine's blade assembly, the maximal deflection (v m) of the shaft must be smaller than a prescribed value [v m]. With the cantilever-based solution model, this deflection constraint (a behavioral constraint) can be further transformed into a structural constraint on parameter d as in
$$d \gt P_{\rm p} = \root { 4} \of {\displaystyle{{64G_{\rm b} l^3 } \over {3{\rm \pi} E\lsqb v_{\rm m} \rsqb }}} \; .$$Here, E is the Young modulus and G b is the weight of the blade assembly. The above formula can be formally represented as {Mainshaft(cylinder_feat(d)), “>”, P p, …}. Here, P p is a polynomial, which has a genetic programming representation shown in Figure 2.
Fig. 2. A genetic programming representation case.
4. IMPLEMENTATION
With Microsoft Visual Studio and Microsoft SQL Server, the proposed detailed design knowledge modeling approach has been implemented as a detailed design knowledge modeling system (DDKMS). A DDKMS is primarily composed of the artifact information modeling subsystem for designers to model an existing design with the extended SBF model and the design knowledge modeling subsystem for designers to model the issue knowledge and the solution knowledge. A DDKMS has been deployed in a mechanical fixture design group for test. A senior designer with about 10 years experience was invited to use a DDKMS to model the detailed design knowledge of a mechanical fixture. The primary process was as below.
First, the designer developed the structural representation for the fixture design, which primarily involved the part composition representation of the fixture and the form representation of its parts. As a result, a structural representation has been built, which comprises 18 parts and about 90 geometrical parameters. Figure 3 shows the part (composition) list and a user interface for managing it.
Fig. 3. (Color online) The part list and the user interface for managing it.
Second, he defined the behavioral representation for each part. As a result, he has collected some behavior(s) of the fixture parts, for example, the translation and the rotation of the double-head-bolt part, and the translation of a T-bolt part for clamping the fixture to the drilling machine. Some side behaviors have also been identified, for example, the flexible extension of the double-head-bolt part when clamping a turbocharger shell and the deflection of the base-board ([BB]) part when it is drilled. Note that such side behaviors are usually not captured in the original SBF model because they are unrelated to the functions of the part.
Third, the designer defined the functional information for each part. About 60 functions have been defined, which involve not only the internal functions but also the life cycle external functions. For example, the [BB] part not only has internal functions, such as supporting the shell-seat part and fixing the position of the shell-seat part, but also has some external life cycle functions, such as holding the cutter of a milling machine and occupying the operating platform of a machine. Note that such life cycle functions also cannot be captured in the original SBF model. The left part of Figure 4 shows some functions, while its right part is a user interface for defining a function shown in the left.
Fig. 4. (Color online) The function list and the related management user interface.
Fourth, the designer modeled the issue knowledge of a fixture. This process primarily involves building the structural, behavioral, and functional constraints on the related entities. For example, since the department standard prescribes that the thickness, H, of the [BB] part should be equal to 30 mm, a geometrical constraint can then be modeled as {[BB](BB_Feat(H)), 30, “mm,” =, “Department Standard”}, where BB_Feat refers to the geometrical feature of the [BB] part; since the [BB] part should fulfill the functions of “semicontaining a turbocharger shell (TS)” and “supporting pillar shelf (PS)” at the same time, which are both related to the width, B, of the [BB] part, then another issue knowledge item can be modeled as: {[BB](BB_Feat(B)), [TS(width), [PS](PS_Feat(width))], >, [F[TS], F[PS]], “The [BB] part should fulfill these two functions …”}, where “[TS(width), [PS](PS_Feat(width))]” is a list of related design parameters, TS(width) and [PS](PS_Feat(width)).
Fifth, the designer then modeled the solution knowledge for the fixture design. Here, the most important work is to model the computation knowledge. As a result, about 120 computational formulae have been obtained. For example, according to the issue knowledge about the width of the [BB] part mentioned before, a computation knowledge item can then be modeled as, [BB](BB_Feat(B)) > (0.5 × TS(width) + [PS](PS_Feat(width))) × 2; because the [BB] part has another function of occupying the operation platform of the machine, then another computation knowledge item can be modeled as [BB](BB_Feat(B)) < operational platform(width). Compared with the original SBF model, which does not deal with quantitative constraints, such computation knowledge is also a major extension for detailed design. Based on these two constraints, a designer can then determine a suitable value for the width parameter of the [BB] part. Figure 5 shows some computation knowledge items and a user interface for editing a computation knowledge item.
Fig. 5. (Color online) The solution knowledge and the managing user interface.
The results of the test are encouraging. With the aid of a DDKMS, the designer can formally model various detailed design knowledge (especially the life cycle design knowledge) about a detailed design. For example, a designer can use a DDKMS to model the knowledge about how the cutter of a milling machine can impose a functional constraint on the [BB] part, as explained before. Therefore, designers now can not only employ CAD models to keep detailed design results but also use a DDKMS to store the detailed design knowledge hiding behind those results. An interview with novice designers discloses that they are also content with a DDKMS, because they can easily learn what issues (especially those implicit issues) have been considered in a detailed design and how these issues are addressed with related solution models. This can largely shorten the time for a novice designer to learn how to design a regular mechanical fixture.
5. CONCLUSIONS
This paper attempts to develop a formal approach for modeling detailed design knowledge for effective reuse. The primary works are as follows.
First, the original SBF model has been extended to represent the structural, behavioral, and functional information in detailed design. A notable feature of the extended SBF model is that it allows designers to employ external functions to capture various life cycle objects that should be considered in a detailed design.
Second, based on the extended SBF model, an issue- and solution-based approach has been developed to model detailed design knowledge. It enables designers to model the knowledge about what issues (especially those implicit life cycle issues) have been considered and the knowledge about how they have been addressed with suitable solution models. This approach at least has two salient features. One is that it provides a method to derive quantitative functional constraints from qualitative function descriptions with the FC axiom. The other is that a genetic programming-based approach has been employed to represent the computation knowledge so that designers can input quantitative design constraints freely, rather than rely on knowledge engineers to encode them. Since such detailed design knowledge also belongs to tacit knowledge, the proposed approach also demonstrates that tacit knowledge can also be modeled in a structured manner.
Third, a DDKMS has been developed based on the proposed approach, which has also been implemented in a fixture design group for test. It is shown that a DDKMS allows a designer to formally model structure-, behavior-, and function-related detailed design knowledge, which usually remains implicit behind the CAD models. Based on the modeled design knowledge, it is also convenient for (novice) designers to understand how design results (i.e., CAD models) have been achieved, that is, what issues have been considered and how they are addressed, and to reuse them in an effective way.
ACKNOWLEDGMENTS
This research is supported by the Science and Technology Commission of Shanghai Municipality, China (No. 09QA1402800), the Natural Science Foundation of China (Nos. 50975173, 50935004, and 51205247), and the Ministry of Science and Technology of China (No. 2008AA04Z108).
Yong Chen is an Associate Professor of engineering design in the School of Mechanical Engineering at Shanghai Jiao Tong University. He received his bachelor and PhD degrees from Zhejiang University. Yong joined Shanghai Jiao Tong University as a postdoc in 2004. He has been a visiting scholar in the IMPACT Laboratory at the University of Southern California for 1 year. Dr. Chen is interested in many aspects of engineering design research, in particular conceptual design, creative design, design knowledge reuse, and computer-aided design.
Jian Huang is currently a PhD student in the School of Mechanical Engineering at Shanghai Jiao Tong University. He received his bachelor degree in 2008 from Wuhan University. Jian's research interests include knowledge-based design and computer-aided design.
Youbai Xie is a Professor in the School of Mechanical Engineering at Shanghai Jiao Tong University. He is also the Director of the Institute of Modern Design at Shanghai Jiao Tong University. Youbai is an academician of the Chinese Academy of Engineering. His research interests include engineering tribology, design science, and knowledge management. He has over 200 publications in Chinese and international journals.
Zhinan Zhang is currently a postdoc in the School of Mechanical Engineering at Shanghai Jiao Tong University, from which he received his PhD degree in 2011. Dr. Zhang's research interests include design theory and methodology, knowledge management, and engineering tribology.
