- Email: [email protected]
NoDes: kNOwledge-based modeling for detailed DESign process — from analysis to implementation
Automation in Construction 10 Ž2001. 399–416 www.elsevier.comrlocaterautcon
NoDes: kNOwledge-based modeling for detailed DESign process — from analysis to implementation Manolya Kavakli Key Centre of Design Computing and Cognition, UniÕersity of Sydney, Sydney, NSW 2006, Australia Accepted 6 April 2000
Abstract This paper reviews the nature of detailed design process and discusses the implementation of a knowledge-based system ŽKBS. founded on a protocol analysis study. The main objective is to discuss the features of a knowledge-based modeling approach, kNOwledge-based modeling for detailed DESign process ŽNoDes.. This approach was first used for the development of the WIND, which is an interactive KBS for the synthesis of window parts. We take the WIND as an exemplary prototype implementation to demonstrate the abilities and performance of our knowledge-based modeling approach. Besides knowledge analysis and simulation of task execution, this paper also argues the efficiency of the object-oriented programming approach in the system implementation. q 2001 Elsevier Science B.V. All rights reserved. Keywords: Knowledge modeling; Knowledge-based systems; Routine design; Knowledge analysis; Implementation
1. Introduction to a routine design aid The objective of this paper is to discuss the features of a knowledge-based modeling approach, kNOwledge-based modeling for detailed DESign process ŽNoDes.. This approach was first used for the development of the WIND w1x, which is an interactive knowledge-based system ŽKBS. for the synthesis of window parts. It was integrated with a computer-aided design ŽCAD. system and designed to allow the designer to interact through a set of menus and graphical interface tools, to specify the requirements of the desired product. The WIND produces
E-mail address: [email protected] ŽM. Kavakli..
synthesized product models for the critical point details. This paper highlights the interactive and integrated execution of the detailed design tasks with the aid of a KBS. We take the WIND as an exemplary prototype implementation to demonstrate the abilities and performance of our knowledge-based modeling approach. NoDes addresses the needs of firms engaged in the use of computer technology in the design and manufacturing process of aluminum and PVC profiles. In design process, we would like to draw a distinction between cases where the designer is free to innovate, and more routine cases where the designer is working within tightly bound constraints w2x. The former cases indicate Ainnovative designB, while the latter cases indicate Aroutine designB. An example of innovative design would be the design of an indus-
0926-5805r01r$ - see front matter q 2001 Elsevier Science B.V. All rights reserved. PII: S 0 9 2 6 - 5 8 0 5 Ž 0 0 . 0 0 0 7 6 - 5
400
M. KaÕaklir Automation in Construction 10 (2001) 399–416
trial product that requires invention Žsuch as first helicopter. or more modest innovations Žsuch as first twin-rotor.. Both are characterized by the lack of any prescribed strategy for design, and rely on a spark of inspiration. On the contrary, the design of a window assembly composed of manufactured profiles would be an example for routine design. Synthesis of profiles is a critical issue for the profile manufacturers. Preparing proposals involves continuously drafting alternatives including different groups of profile systems in the same database by using the same design rules. These are monotonous and time-consuming routine design problems. Robust synthesis of window profiles requires two main processes: v
v
the selection of parts that correspond to the performance specifications among hundreds of profiles, and, the definition of the different glass sizes, considering a given window layout and given performance requirements.
The experts working in this routine design process have the necessary know-how about the manufacturing process, as well as detailed design. They have a detailed expertise on the product library Žprofiles and their properties. of the firm. The knowledge and know-how about the product library is lost when the expert leaves the firm. The use of a KBS in the routine design brings the advantage of keeping knowledge and know-how in store. In this paper, our purpose is to discuss how a KBS can be applied to detailed design process. Before discussing this, it is important to further clarify the terms Adetailed designB and Aknowledge-based designB as used in this study.
ture. On the other hand, industrial design w3x seeks to rectify the omissions of engineering, and is a conscious attempt to bring form and visual order to engineering hardware where technology does not itself provide these features. In our working definition of detailed design, no distinction is drawn between the technical needs of engineering design and the aesthetic approach of industrial design. Detailed design is described as the process of specifying a description of an artifact that satisfies constraints by using diverse sources of knowledge w4x. A design process leading from a product design specification to the manufacturing stage, may be subdivided into conceptual design, analysis, and detailed design, as specified by Hopgood w2x. Preliminary design decisions are made at the conceptual design phase, with the aim of satisfying a few key constraints. Several alternatives are normally considered. Decisions taken at this stage determine the general form of the product. Key constraints predetermined in conceptual design, constitute the product design specification. Other constraints may evolve as a result of decisions made during the remainder of the design process. At the following analysis and evaluation stage, the conceptual design is refined by placing values on numerical attributes, and its performance is tested for its response to external effects and its consistency with the product design specification. Then, at the detailed design stage, the design of the product and its components are refined so that all constraints are satisfied. Decisions taken at this stage include the layout of the assembly system, the positions of the components, etc. Manufacturing stage follows the detailed design. The success of traditional design projects depends upon three factors:
v
1.1. The nature of detailed design process
v
v
Selection of window and door profiles is one of the key aspects of the detailed design process in architecture. Our definition of Adetailed designB falls somewhere between engineering design and industrial design. Engineering design w3x is the use of scientific principles, technical information, and imagination in the definition of a mechanical object struc-
Gathering of information relevant to the design product and process. Generating of design alternatives. Capturing of the resultant solution.
In this iterative communication cycle, there is always a risk that design cannot be manufactured. Another risk is that budget deadlines may constrain designers to make critical decisions without exploring alternative strategies. This is undesirable, as
M. KaÕaklir Automation in Construction 10 (2001) 399–416
making changes to early decisions may necessitate costly repetition of the steps of the design process. 1.2. The need for KBSs Computers may be useful for exploring alternative strategies to make critical decisions quickly and efficiently. However, today’s CAD systems are intended primarily to assist in drawing a design, rather than directly supporting the design process. Therefore, we still need knowledgeable team members to interpret and assess the design product. Traditional CAD systems do not make decisions, and they are not, in general, knowledge-based. They do, however, frequently make use of object-oriented programming techniques. Each line, circle, etc., that is created can be represented as an object instance w2x. Although they contain geometric information, they fail to explain both knowledge about the properties of product parts and reasoning about the design of an assembly. We cannot avoid increasing the level of knowledge and intelligence in CAD systems to automate design process. A true CAD system should be able to draw from a company’s natural knowledge base, the accumulated experience of the workforce w5x. Thus, the need for deeper knowledge in CAD has led us to develop KBS in detailed design process. There have been many development methodologies suggested for the KBS domain such as structured analysis and generation of expert systems ŽSTAGES. and knowledge acquisition documentation system ŽKADS. w6x. However, there are several disadvantages of using these methods in design. They are neither object-oriented in nature to support an iterative prototyping area such as design w7x, nor easy to use by non-dedicated personnel within the companies using a multi-skilled force w8x. Using a specialized-knowledge engineer may lead to frustration due to the possible ambiguity in the problem representation w9x. It is suggested that systems can be created, modified and used readily by the workforce in the domain area. If this methodology is used, a typical system will evolve over time. In the field of design, researchers have different opinions of how designers work, and it is therefore not surprising that markedly different software architectures have been produced w2x. For example, CYCLOPS w4x and FORLOG w10x systems assume that inno-
401
vative design can be obtained by generating a variety of alternatives and choosing between them. In contrast, DOMINIC w11x uses a systematic approach to innovation, which generates only feasible solutions. EDISON w12x, as a system for designing simple mechanical devices, makes use of meta-rules to steer the design process between the various strategies that are provided by mutation, generalization, and analogy. Both CYCLOPS and EDISON are based on retrieving a previous design from memory and adapting it to the new circumstances. Generalization is the process of forming a generic description from a specific item. In EDISON, for instance, a door might be considered a subclass of the general class of entrances. Generalization achieves the same goal as the deep explanations used in the adaptation mode of CYCLOPS. As we can see in these examples, selection between alternatives forms an integral part of the design problem. Even within the apparently limited domain of material selection w13x, the range of relevant knowledge is so wide and interactions so complex that current systems are rather inadequate.
2. Proposed system architecture The system architecture of the WIND comprises several components in a graphical environment, such as user interface, database, knowledge base, inference engine, and SYNTHESIZER. Performance parameters are the input for the system, while values of the attributes attached to synthesized profiles are the output for cost analysis. The system architecture can be seen in Fig. 1.
Fig. 1. System architecture.
402
M. KaÕaklir Automation in Construction 10 (2001) 399–416
Unlike the other computer tools Že.g., Refs. w5,14x., the WIND does not calculate the values of the parameters of performance requirements, only accepts the variables and coefficients of performance parameters as user input. However, like many other KBSs w5,15x, the WIND’s user interface is integrated in AutoCAD. We preferred to provide the knowledge engineer with an interface through widely available CAD packages. Thus, a range of additional facilities could be provided without additional effort by the implementers of KBSs and the time to learn the interface would be reduced for the end users, as implied by Tate w16x. Some CAD packages provide facilities to enable tailored interfaces to be created. AutoCAD is an example. The user interface of the system provides a convenient and user-friendly way of handling input and output in AutoCAD environment. It is possible to use dialog boxes, pull-down and screen menus, command lines, and text screens. Everything is either handled as a question to the user or provided by means of the graphical representations. AutoCAD presents a good basis for the creation and modification of a design database, especially for window manufacturers. Some attributes can be attached to the profiles in the design database. Then, the values of the attributes can be extracted from the AutoCAD environment as a file in CDF or SDF format and can be used in the database program for a cost analysis. SYNTHESIZER is the core module of the WIND that maps the real product parts onto the rough models by evaluating the rules. This facility that leads to the incremental development and detailed description of parts can also be seen in the other systems w5x. This module interacts with the knowledge base and the inference engine. The collection of domain knowledge of the window manufacturers, is the knowledge base of the WIND. The knowledge base includes an interconnected set of pattern-coded observations and hypotheses, as well as rules and procedures. The knowledge is represented by rule-based methods.
3. Knowledge modeling Knowledge modeling starts with knowledge analysis. In this step, mental processes Žactions. of hu-
man designers are analyzed. The second step is the acquisition and elicitation of the knowledge by means of queries, interviews, transcripts and drawings w1,17,18x. After the knowledge is coded and structured by means of protocol analyses w1,17,19x, it is programmed. The domain knowledge structured in the knowledge model is useful in identifying new computational processes, new divisions of tasks and cognitive functions required to perform the work desired, and new ways of allocating work in the workplace. In this paper, we will discuss some major steps of knowledge modeling from analysis to implementation.
4. Knowledge analysis Knowledge analysis can be categorized in two groups: analysis of concepts, and analysis of process. 4.1. Analysis of concepts Knowledge analysis requires the adequate reconstruction of the concepts of the field, a task that has been tackled under the heading of conceptual modeling w20x. Therefore, concepts related to the semantic structure of a window are analyzed in this part. Window is a composite object made up of components, as shown in Fig. 2. A window element consisting of an assembly of bodies that belong to the same class can be represented by a geometric model. The appropriateness and the quality of the window design are assumed to depend upon the window type, its profiles, the wall in which it is embedded and the nature of the environmental conditions on both sides Žinside and outside.. The edges of a window frame should have different properties depended on its location. The attachments to the wall and to the fixed or movable casements require different strategies to follow. Typically, nodes in a window refer to the problematic points. Plans and sections generated by an expert show the solutions of these problematic points. We will use Ahole-in-wallB type casement windows as a sample. This type is very common in mass housing projects. The Ahole-in-wallB type windows are enclosed by the wall on all sides, and are placed
M. KaÕaklir Automation in Construction 10 (2001) 399–416
403
Fig. 2. Functional decomposition of a window assembly.
in the wall as a whole, like an assembly that is composed of a series of window parts. The concepts related to the Ahole-in-wallB type windows are explained in Table 1.
It is possible to formulate the vocabulary of Ahole-in-wallB type windows as shown in Fig. 2. This vocabulary is based on the window grammar proposed by Baykan and Eastman w21x. According to
Table 1 Vocabulary of a Ahole-in-wallB type window Wall Front frame Frame Sash Muntin Mullion Glazing Sill
Wall is all around the window, enclosing it on all sides. Front frame is an additional part that may be placed to compensate for the faults in the construction system. It is next to the wall, forms a loop enclosing the other window elements. Frame is next to the wall or front frame Žif there is., forms a loop enclosing the other window elements. Sash is the opening part of the window. It is nested in the frame. Muntin subdivides the glazing. It is nested in either the frame or the sash and connected to one of these at its endpoints. It has to be next to glazing on both sides. Mullion is a vertical member in a window frame. Glazing is the transparent part of the window, allowing transmission of light. Sill forms the base of the window, and prevents the wall from the water. It is next to the wall. Sill is divided into two parts as exterior or interior.
M. KaÕaklir Automation in Construction 10 (2001) 399–416
404
this grammar, AwallB includes AwindowB and AsillB. AWindowB includes a Afront frameB Žif exists., AframeB, and AglazingB compound. AGlazingB compound may have AmuntinsB or AsashesB, and other AglazingB compounds Žif muntins or sashes exist in it.. ASashB includes AglazingB compound and other AsashesB. ASillB belongs to exterior andror interior space, and includes only itself. A drawing typically has many possible structural descriptions with instances from a given shape vocabulary and relationships of those instances. 4.2. Analysis of window design process The process of analysis w22x is to decompose a problem into parts until individual parts are recognized as being amenable to known operations, and results are re-assembled into a solution. This process has a peripheral role in design and development of a KBS. The stages of the window design process w18x can be explained as follows. 4.2.1. Analysis Design process in manufacturing firms starts with getting specifications from the architect of a project. The project includes technical specifications, plans and sections, delineation of the elevations, opening directions of the windows, and structural axes. Analysis at this stage can be divided into five main parts w1x: v
v
v
v
v
analysis analysis analysis analysis analysis
of of of of of
performance requirements, information in plans, information in sections, information in elevations, information in structural systems.
refers to the first meta-model related to the assembly drawing of the different intermediate meta-models. 4.2.3. Choosing a profile system The profile system refers to the profile group having some common attributes that belong to the same class. The profile system is selected according to the performance requirements. Additional profiles are used only when they are necessary. The number of the profile systems varies according to the capacity of the manufacturer Žfor example, C¸ UHADAROGLU has 30 different systems and FENIS has three different systems and four different types for each system.. There are some important criteria affecting the selection of profile system, such as water tightness, rigidity, clamping, fitness of joints, wind load, heat insulation, economy, cleaning system, attachments to the wall and the parapet, and exterior surfaces of the profiles for the requirements of stainless steel screws. 4.2.4. Choosing an accessory Window manufacturers have catalogues of profile systems, from which the standard accessories for each system are chosen. The types of accessories generally depend on the system selected Žfor example, each system has its own accessories in FENIS.. 4.2.5. SolÕing a problem node A problem node refers to the connection of a window part to another part or a wall. Problem nodes can be listed as follows:
v
v
v
v
4.2.2. Initial design (fundamental design) Initial design process is related to the setting up of the first meta-model. A meta-model w23x is a model of models. The meta-model refers to the global rough model of the products in a window system, fixing of the temporary design solutions or goals. Rough model is the formal representation of the conceptual mechanisms of a window system and
attachment to a wall or a suspended ceiling, parapet, special corners and finishes, connections.
The samples of important nodes can be seen in Appendix A. 4.2.6. Synthesis of parts (embodiment design) Synthesis of the product parts is accomplished following the solution of a problem node. During the
M. KaÕaklir Automation in Construction 10 (2001) 399–416 Table 2 General stages of window design process
405
4.2.8. Final design (detailed design) After the architect’s approval, the expert designing the window system generates final design. Since the output of the final design is a system detail, it is regarded as detailed design w23x. 4.2.9. Cost analysis The cost of the whole system is calculated in the last stage. Criteria for cost analysis are the material, the global size of the window and opening casements, the location of bars, the number of loops of the rubber fillets, and the number of hinges. General design stages are summarized in Table 2. 4.3. An empirical study on window design process
synthesis of parts, the rough models are replaced with the real product parts. The synthesis of parts requires defining criteria in relation to the combination of the parts and their location in the window. At this stage, the fitness between assemblies Žgroups of profiles and classes. is the most important factor. It is the expert’s duty to synthesize window parts, and produce drafts of the proposals. This stage is also regarded as embodiment design w24x in which the designer determines the layout and shape for all parts and develops a technical product or system according to technical and economic considerations. 4.2.7. ApproÕal of the architect If the result of the synthesis of parts is unsatisfactory, modifications in the Aembodiment designB phase may be necessary w24x. Therefore, the approval of the project architect is required after the synthesis of profiles. The architect of the project can modify a window assembly, if the selected system causes a different elevation in comparison to the fac¸ade initially drawn by the architect.
Interviews with the top four window manufacturers on the detailed design process indicate that the window design process has similar protocols for generating candidate design solutions. We chose one of the firms producing window profiles for the empirical study based on protocol analysis. This was not a contrived situation, but a real design case in the firm FENIS. Operations in the protocol analysis were handled with care and most of the rules were acquired during the experiment. The operations were simulated in the computer program. The sample used was a Ahole-in-wallB type window having three openings and one fixed casement, as can be seen in Fig. 3.
Fig. 3. Window type and point details given in the experiment.
406
M. KaÕaklir Automation in Construction 10 (2001) 399–416
According to the findings extracted from the empirical study, the procedure continues as follows. The expert starts with the elevation of the window Žin the scale: 1r20 cm.. A profile system is defined due to the thermal requirements expected from the window system. A frame profile is chosen in a matrix representation from the profile catalogue of the firm w1x. The need to front frame is searched, and if necessary, frame profile is chosen due to this need. This is used for producing point details 1, 3, 4, 5, 8, and 10. Considering water insulation, a front frame is chosen among profiles in the matrix. Thus, point details 8 and 10 in Fig. 8 are produced. A product part for the interior sill is chosen according to the appropriateness to the frame profile. This is also used for producing point details 8 and 10. A product part for the exterior sill is chosen according to the fitness on the wall, among the profiles. This is also used for producing point details 8 and 10. v
v
v
v
v
v
A product part for sash is chosen according to the gap Ždistance. between the frame and sash, among the profiles. This is used for producing point details 1, 2, 3, 4, 6, 7, 8, 9 and 10. An additional profile is defined to prevent the water infiltration. Thus, point details 8 and 10 are produced. At the end of this step, point details 1, 3 Žsymmetry of 1., 8, 10 Žsame as 8., 4 Žrotation of 3. and 5 are solved. The expert asks if the muntin exists. At that moment, window elevation may be modified after the approval of the architect. Muntin is chosen among the profiles, considering if a vertical line is needed, or if the casement is fixed. If the length of the horizontal or vertical bar is greater than a certain distance, structural calculations for the muntin are made, and the muntin needs to be supported by an additional box profile which is selected considering the wind load calculated according to the norms, such as TSE 498 and DIN 1055. Thus, point details 2, 6 Žrotation of 2., 9, and 7 Žrotation of 9. and 5 have been solved. v
v
v
Fig. 4. Flow chart.
M. KaÕaklir Automation in Construction 10 (2001) 399–416
Main accessories are chosen. Sash fillets, center fillet, exterior glazing fillets and epidien fillets are placed against infiltration. The size of interior glazing fillet and weights of the product parts are calculated. These are used for the cost estimating. Flow chart of the process in this experiment can be seen in Fig. 4. v
407
Table 3 Flow diagram
5. Implementation Unlike the other KBSs, instead of a computer programmer, we used an architect for knowledge engineering and programming. She was not only familiar with developing computer programs in LISP, but also familiar with the nature of design process itself. Thus, the knowledge engineer could probe domain knowledge like an architect who has just started to work in the field, extracting the necessary knowledge from the expert by using AteachbackB approach as a knowledge acquisition method. We believe that knowledge engineers who are familiar with the domain are able to correspond to the demands of the task and the needs of end users more efficiently than the unfamiliar ones. Following knowledge analysis, a knowledge structuring method w1,17,19x was developed as a basis for the implementation. In the knowledge-programming phase, actions of the expert in each design stage were simulated in a computer program. The scenario was developed in the stages shown in Table 3. The structure of the computer program is based on object-oriented methodology. The design problem in the system is solved by defining, creating, and manipulating collections of data and procedures called objects. The terminology behind object-oriented programming relate to how objects are defined, have properties assigned to them, how they interact, and how they are combined to form more complex objects. We adopted object-oriented programming approach for organizing the operations. The knowledge-programming approach, NoDes, breaks down the program into two main parts: plan and section. These parts then decompose further, each stage of decomposition varying the contents of
the nodes. Following this, primitive objects are inserted, and then, replaced by higher level objects that will use the knowledge base to make specific decisions regarding their shape, relationships and attributes. The computer program and the links between the subroutines are arranged in a tree diagram Appendix B. The program runs in AutoCAD environment, which provides AutoLISP, a variant of LISP language that is convenient for developing AI systems. We chose AutoLISP as the programming language, because AutoCAD has been commonly used in the design offices of the firms, and they already had the profile catalogues drawn in the AutoCAD environment. 5.1. Getting input The first step is to state the problem. The user interface of the WIND includes menus, command lines, and dialog boxes to make it easier to enter input. User input can be grouped into two groups. One is about the problem environment and the other is related to performance requirements.
408
M. KaÕaklir Automation in Construction 10 (2001) 399–416
5.2. Drawing the window eleÕation The user of the system draws the window elevation by a mouse click on Awindow elevationB in the pull-down menu as shown in Fig. 5. At the background, this mouse click runs a LISP program called WE.LSP. During the program execution, the system asks the user for the number of casements. Then the subroutine Adrw – caseB is executed in a loop, once for each casement. The user is prompted for the attributes of each casement on the fly. List processing specifies coordinates of casement corners from the given information. Then, the system asks the user to define whether the casement is fixed or movable. If the casement is movable, the opening direction Žleft, right, up or down. is asked and drawn.
Fig. 6. Drawing plane of section.
at the background branches into two main subroutines: 5.3. Specifying the plane of section v
v
In the second step, the user specifies the plane of section by a mouse click on Aplane of sectionB in the pull-down menu, as shown in Fig. 6. The system asks the user if the plane of section is horizontal or vertical. At this moment, computer program running
If the plane of section is horizontal, WP.LSP runs. If the plane of section is vertical, WS.LSP runs.
Both WP.LSP and WS.LSP include similar subroutines to draw the plane of section and ask for the number of point details to be produced. The number of point details is assigned to a variable. This variable controls to run AdetpointB or AdpointB subroutines. 5.4. Specifying fixed r moÕable casements
Fig. 5. Drawing window elevation.
In the third step, the system asks the user to select the point details one by one, and define the characteristics of the adjacent node. Each point detail is a double node that is composed of two adjacent nodes, as shown in Fig. 7. The characteristics of adjacent nodes are stored in AdetpointB subroutine that runs at the background. An adjacent node changes according to the plane of section. If the plane of section is horizontal, the adjacent node is either at left or right. If the plane of section is vertical, adjacent node is either up or down. In both cases, an adjacent node may be either the wall or a fixed or movable casement. Point details with double nodes can be grouped into two parts: attachment to the wall, and junction.
M. KaÕaklir Automation in Construction 10 (2001) 399–416
409
Codes of left and right nodes, such as AFB, AMB and AWB, are assigned to a symbol named pdcode for each point detail. Each pdcode is added to a list named pdlist. Coordinates of each point detail are assigned to a list called detxy. For list processing, WP.LSP repeats AdetpointB subroutine for each point detail. The program runs in the same logic if the plane of section is vertical. A similar subroutine, AdpointB, based on the same method is used, that runs different routines according to top and bottom nodes: Fig. 7. Nodes on the plane of section.
Both of them have different procedures that run according to the node characteristics. The samples of the double nodes can be seen in Appendix A. The procedures are as follows: 1. Attachment to the wall: with or without front frame, with fixed casement Žwf, hf., with movable casement Žwm, hm., with sill Žmj, fj., without sill Žmj, fj.. 2. Junction: with or without muntin, fixed casementq fixed casement Žff, ff2., fixed casement q movable casement Žfm, fm2, mf, mf2., movable casement q movable casement Žmm, mm2..
if the top node is wall, AtnodwB; if the top node is fixed casement, AtnodfB; if the top node is movable casement, AtnodmB, if the bottom node is wall, AbnodwB; if the bottom node is fixed casement, AbnodfB; if the bottom node is movable casement, AbnodmB subroutine is fired.
Codes of left and right nodes, such as AFB, AMB and AWB are assigned to a symbol named pdcode2 for each point detail. Each pdcode2 is added in a list named pdlist2. Coordinates of each point detail are assigned to a list called detxy2. For list processing, WS.LSP repeats AdpointB subroutine for each point detail.
ADetpointB subroutine calls itself recursively for each point detail as left and right node to traverse the tree: if the left node is wall, AlnodwB; if the left node is fixed casement, AlnodfB; if the left node is movable casement, AlnodmB, if the right node is wall, ArnodwB; if the right node is fixed casement, ArnodfB; if the right node is movable casement, ArnodmB subroutine is fired.
Fig. 8. Boxes inserted on the plane of section.
410 Table 4 Sample from the nodes
M. KaÕaklir Automation in Construction 10 (2001) 399–416
M. KaÕaklir Automation in Construction 10 (2001) 399–416
5.5. Drawing rough layout of fixed and moÕable casements
411
Table 5 Procedural tree
All point details have some primitives representing fixed and movable casements. Primitive of fixed casement is called wbox – f and primitive of movable casement is called wbox – m. Subroutines replace these symbols according to their relations to adjacent node in a point detail. The location and rotation angles of the symbols depend on whether the plane of section is horizontal or vertical. Fig. 8 shows a sample of primitive boxes inserted to specify double nodes. 5.6. Inference and explanation of rules To set and explain the rules, a collection of facts including sentences about general facts is recorded. This collection of facts is used for combination of AifB and AthenB sentences. Table 4 shows a sample from the rules in the AutoLISP code. Combination of the sentences in the collection of facts defines the rules. A subroutine called Aset – ruleB in the RULE.LSP file is developed to combine Aif-then-elseB commands in the WIND to set up a rule. As shown in Appendix A, if data about condition 1 ŽDc1. match with fact ŽF1., then fact 1 ŽF1. is the AifB part of the rule ŽI – Dc. and fact 11 is the AthenB part of the rule and Aset – ruleB subroutine runs and a message is prompted. When Aset – ruleB subroutine runs, the AifB part of the rule ŽI – Dc. is added with AifB prefix, and is then combined with the AthenB part of the rule ŽT – Dc., added with AthenB prefix. The rule occurs and is printed on the monitor. Then the rule is added to the beginning of a present rulelist. At the end of the program, RULE.LST file is closed and rulelist is printed for monitoring. In a similar way, it is possible to add new rules by means of Aadd – ruleB subroutine, as can be seen in the LISP code in Table 5. 5.7. Drawing rough layout at nodes By clicking on ARoughB in the ADetailsB pop-up menu, rough layouts of components are placed as shown in Fig. 11. At the background, the system
evaluates the design rules in the knowledge base. ROUGH.LSP calls PLN.LSP or SEC.LSP according to the plane of section. The list of point details codes and the list of x and y coordinates for each point detail are evaluated. If the pdcode is ŽAWB AFB ., AwfB subroutine runs, if it is ŽAFB AFB ., AffB subroutine runs, if it is ŽAFB AMB ., AfmB subroutine runs, if it is ŽAMB AFB ., AmfB subroutine runs, if it is ŽAMB AMB ., AmmB subroutine runs, if it is ŽAFB AWB ., AfwB subroutine runs, if it is ŽAMB AWB ., AmwB subroutine runs, if it is ŽAWB AFB ., AwfB subroutine runs, if it is ŽAWB AMB . AwmB subroutine runs.
412
M. KaÕaklir Automation in Construction 10 (2001) 399–416
Fig. 11. Product library of sill profiles produced by the FENIS. Fig. 9. Rough mechanisms inserted on the nodes.
It is possible to explain SEC.LSP in the same way. The only difference is that the subroutines are applied in a vertical plane and they have different names.
If the pdcode is ŽAFB AFB ., Aff2B subroutine runs, if it is ŽAFB AMB ., Afm2B subroutine runs, if it is ŽAMB AFB ., Amf2B subroutine runs, if it is ŽAMB AMB ., Amm2B subroutine runs, if it is ŽAFB AWB ., AfjB subroutine runs, if it is ŽAMB AWB ., AmjB subroutine runs,
Fig. 10. Product library of frame profiles in FENIS System 52.
if it is ŽAWB AFB ., AhfB subroutine runs, if it is ŽAWB AMB . AhmB subroutine runs.
In these subroutines, some abbreviations are used. For example, h is the head, j is the jamb, w is the wall, f is the fixed casement and m is the movable casement. These subroutines define and place the general relations and locations of the rough graphical representations of the window components. Rough mechanisms in window plan, drawn by PLN.LSP can be seen in Figs. 9 and 13. Fig. 14 is a sample
Fig. 12. Suggested solution for the nodes.
M. KaÕaklir Automation in Construction 10 (2001) 399–416
413
Fig. 13. Assemblies of window parts in plans.
showing rough mechanisms in a section drawn by SEC.LSP. 5.8. EÕolution of components at nodes In the next stage, rough graphical representations of the window components are replaced with the products in the product library in Figs. 10 and 11.
Fig. 14. Assemblies of rough parts in window sections.
E – PLN.LSP transforms the horizontal plane of section, while E – SEC.LSP transforms the vertical one. The key point is the choice of the firm. Each firm produces different kind of products and uses different material. Different subroutines for different firms should be used for producing detail design. For example, the AfenisB subroutine has the rules and relations about FENIS products, while the AcuhB subroutine refers to C¸ UHADAROGLU and ApimasB
Fig. 15. Assemblies of product parts in window sections.
414
M. KaÕaklir Automation in Construction 10 (2001) 399–416
refers to PIMAS. These subroutines replace the rough graphical representations of the window components with the more detailed and exact products of the chosen firm. Fig. 12 is an alternative solution to the nodes on the horizontal plane of section previously shown in Fig. 9. Examples of actual mechanisms in window sections and plans, drawn by PLN.LSP and SEC.LSP, are shown in Figs. 13–15.
6. Conclusion Although the samples in this paper include only window assemblies, NoDes as a knowledge modeling approach is flexible enough to be integrated in other building elements, including system parts, such as doors. Changing the database of the product parts and the design rules in the knowledge base, and using the same logic, NoDes can also be used for producing the point details of industrial design products. If we compare the speed of design process by NoDes with the speed of design process by manual work, it is possible to understand the dramatic superiority of computers in routine design. As we have already mentioned in Section 1, shop drawing is a monotonous process for human designers. It also requires highly specialized knowledge and experience on design domain. Analyzing projects and specifications, searching documents and catalogues, selecting which system to be used, and drafting of final solution take considerable time. Human beings should use this time for creative purposes. Routine work can be efficiently achieved by this computer system w1,17x. In the current case, it takes 15 s to insert rough graphical representations, and 2 min for replacing them with firm profiles. Consequently, NoDes as a knowledge modeling approach is an efficient way to produce point details. It analyses the design specifications, fixes the approximate layout of the design solution at nodes, and synthesizes system parts to obtain final design, fixes meta-models and evolutionary models by replacing rough layout. It is intended to continue development of the WIND, until it is a full commercial product. In the present case, the system has a useful, Žthough incom-
plete. knowledge of how aluminum window profiles can be synthesized. However, even this version of the program could be a valuable tool, showing the abilities of a KBS based on the NoDes approach. Further work is needed on the performance analysis and the cost analysis to extend the program so that it can calculate performance and cost of the proposed system. The program may also be extended to evaluate window fac¸ade, and to suggest ways of improving its appearance andror details, either at the design stage or when a problem is discovered in an existing building. Documentation on on-line help should be available for training of personnel using the program. The graphical nature of the problem forces the developers to devote an unusually large amount of effort to the user interface even though the program’s problem solving ability is at a fairly early stage. It is strongly recommended to use a ready-made CAD package, rather than to develop it in building knowledge-based CAD systems. An interesting aspect of the knowledge representation is that a 2D diagram seems to have been sufficient. Although the experts emphasized that a window design must be considered in 3D, it appears that the so-called 3D analysis, which designers can cope with, is limited with a range of 2D analysis. However, we still need to use 3D representations and diagrams for actual frame junctions, but this is getting into an area where even the experts have difficulty.
Acknowledgements This project was partly sponsored by the State Planning Organization of the Turkish Republic between 1990–95 and the system was developed in the Faculty of Architecture, Istanbul Technical University, Turkey. The WIND is the subject of a PhD thesis supervised by Prof. Dr Nigan Bayazit, whose advice and support played an important role throughout the design process of the system. Author is also grateful to the managers and designers, Mete C¸ ilekar from FENIS and Yenal Oktug from C¸ UHADAROGLU, whose cooperation as AteachbackB in the knowledge acquisition made the WIND possible.
M. KaÕaklir Automation in Construction 10 (2001) 399–416
415
Appendix A. Rules
Appendix B. Rule Generator
References w1x M. Kavakli, WIND: A knowledge-based system for the synthesis of window parts, PhD Thesis, Institute of Science and Technology, Istanbul Technical University, 1995. w2x A.A. Hopgood, Knowledge-Based Systems for Engineers and Scientists, CRC Press, London, 1993.
w3x Open University, PT610: Manufacture, Materials, Design — Unit 7, Open Univ. Press, 1986. w4x D. Sriram, G. Stephanopoulos, R. Logcher, D. Gossard, N. Groleau, D. Serrano, D. Navichandra, Knowledge based system applications in engineering design: research at MIT, AI Magazine Ž1989. 79 pp. w5x C.B. Chapman, M. Pinfold, Design engineering — a need to
416
w6x
w7x
w8x
w9x
w10x
w11x
w12x
w13x w14x
w15x
M. KaÕaklir Automation in Construction 10 (2001) 399–416 rethink the solution using knowledge-based engineering, Knowledge-Based Systems 12 Ž5–6. Ž1999. 257–267. G.N. Blount, S. Kneebone, M.R. Kingston, Selection of knowledge based design applications, Journal of Engineering Design 6 Ž1. Ž1995. 31–38. M.D. Mulvenna, J.G. Hughes, Expert agents in knowledgebased systems — applications and innovations in expert systems, Proceedings of Expert systems 93, The 13th Annual Conference of British Computer Society Specialist Group on Expert Systems, Information Press, Cambridge, 1993. C.W. Church, A business plan for knowledge inclusive systems, research and development in expert systems, Proceedings of Expert systems 93, The 13th Annual Conference of British Computer Society Specialist Group on Expert Systems, Information Press, Cambridge, 1993. W.J. Crowther, D.R. Bull, C.A. Burrows, Knowledge acquisition for enginnering systems using bond graphs, Proceedings of Expert Systems 95, The 15th Annual Conference of British Computer Society Specialist Group on Expert Systems, SGES Publications, Cambridge, 1995, pp. 41–56. T.G. Dietterich, D.G. Ullman, FORLOG: a logic-based architecture for design, in: J.S. Gero ŽEd.., Expert Systems in Computer-Aided Design, North-Holland, 1987. A.E. Howe, P.R. Cohen, J.R. Dixon, M.K. Simmons, DOMINIC: a domain-independent program for mechanical engineering design, International Journal for AI in Engineering 1 Ž1986. 23. M.G. Dyer, M. Flowers, J. Hodges, EDISON: an engineering design invention system operating naively, International Journal for AI in Engineering 1 Ž1986. 36. A. Demaid, J. Zucker, A conceptual model for material selection, Metals and Materials Ž1988. 291 pp. L. Khemlani, GENWIN: a generative computer tool for window design in energy-conscious architecture, Building and Environment 30 Ž1. Ž1995. 73–81. H. Tianzhen, Z. Jinqian, J. Yi, IISABRE: an integrated building simulation environment, Building and Environment 32 Ž3. Ž1997. 219–224.
w16x A. Tate, Interfacing a CAD System to an AI Planner, Artificial Intelligence Applications Institute, University of Edinburgh, AIAI-TR-76, Edinburgh, UK, 1990. w17x M. Kavakli, Knowledge modeling in support of detail design process, in: O. Akin, G. Saglamer ŽEds.., Descriptive Models of Design ’96, Proceedings of 1st International Symposium on the Descriptive Models of Design, Istanbul Technical University, MK, 1996, pp. 1–30. w18x M. Kavakli, A knowledge-based system for the synthesis of parts in a design product, in: K. Ellis, A. Gregory, B.R. Mears-Young, G. Ragsdell ŽEds.., Critical Issues in Systems Theory and Practice, UKSS’95: Proceedings of United Kingdom Systems Society 4th International Conference, Plenum, London, 1995, pp. 149–157. w19x M. Kavakli, N. Bayazit, Knowledge structuring of an expert system developed for the synthesis of parts in industrial design, in: R. Trappl ŽEd.., Cybernetics and Systems’ 94, Proceedings of 12th European Meeting on Cybernetics and Systems Research vol. 1, World Scientific Pub, Vienna, 1994, pp. 531–538. w20x P. Schefe, Expert Systems Present State and Future Trends: Impact on Employment and Skill Requirements ŽAn Assessment., International Labour Office, Management Development Branch, Training Department, Geneva, 1988, pp. 1–55. w21x C. Baykan, C.M. Eastman, An Expert System for Window Performance Analysis, Institute of Building Science and School of Urban and Public Affairs, Carnegie Melon University, Pittsburgh, 1983. w22x A. Bijl, An approach to design theory, in: T. Yoshikawa, Warman ŽEds.., Design Theory for CAD, North-Holland, 1985, pp. 3–31. w23x T. Tomiyama, H. Yoshikawa, Knowledge engineering and CAD, Future Generations Computer Systems 1 Ž4. Ž1985. 237–243. w24x T. Bachman, M. Daniel, G. Pahl, J. Rix et al., Feature-based modeling in support of embodiment design, Computers and Graphics 17 Ž3. Ž1993. 285–294.
NoDes: kNOwledge-based modeling for detailed DESign process — from analysis to implementation Manolya Kavakli Key Centre of Design Computing and Cognition, UniÕersity of Sydney, Sydney, NSW 2006, Australia Accepted 6 April 2000
Abstract This paper reviews the nature of detailed design process and discusses the implementation of a knowledge-based system ŽKBS. founded on a protocol analysis study. The main objective is to discuss the features of a knowledge-based modeling approach, kNOwledge-based modeling for detailed DESign process ŽNoDes.. This approach was first used for the development of the WIND, which is an interactive KBS for the synthesis of window parts. We take the WIND as an exemplary prototype implementation to demonstrate the abilities and performance of our knowledge-based modeling approach. Besides knowledge analysis and simulation of task execution, this paper also argues the efficiency of the object-oriented programming approach in the system implementation. q 2001 Elsevier Science B.V. All rights reserved. Keywords: Knowledge modeling; Knowledge-based systems; Routine design; Knowledge analysis; Implementation
1. Introduction to a routine design aid The objective of this paper is to discuss the features of a knowledge-based modeling approach, kNOwledge-based modeling for detailed DESign process ŽNoDes.. This approach was first used for the development of the WIND w1x, which is an interactive knowledge-based system ŽKBS. for the synthesis of window parts. It was integrated with a computer-aided design ŽCAD. system and designed to allow the designer to interact through a set of menus and graphical interface tools, to specify the requirements of the desired product. The WIND produces
E-mail address: [email protected] ŽM. Kavakli..
synthesized product models for the critical point details. This paper highlights the interactive and integrated execution of the detailed design tasks with the aid of a KBS. We take the WIND as an exemplary prototype implementation to demonstrate the abilities and performance of our knowledge-based modeling approach. NoDes addresses the needs of firms engaged in the use of computer technology in the design and manufacturing process of aluminum and PVC profiles. In design process, we would like to draw a distinction between cases where the designer is free to innovate, and more routine cases where the designer is working within tightly bound constraints w2x. The former cases indicate Ainnovative designB, while the latter cases indicate Aroutine designB. An example of innovative design would be the design of an indus-
0926-5805r01r$ - see front matter q 2001 Elsevier Science B.V. All rights reserved. PII: S 0 9 2 6 - 5 8 0 5 Ž 0 0 . 0 0 0 7 6 - 5
400
M. KaÕaklir Automation in Construction 10 (2001) 399–416
trial product that requires invention Žsuch as first helicopter. or more modest innovations Žsuch as first twin-rotor.. Both are characterized by the lack of any prescribed strategy for design, and rely on a spark of inspiration. On the contrary, the design of a window assembly composed of manufactured profiles would be an example for routine design. Synthesis of profiles is a critical issue for the profile manufacturers. Preparing proposals involves continuously drafting alternatives including different groups of profile systems in the same database by using the same design rules. These are monotonous and time-consuming routine design problems. Robust synthesis of window profiles requires two main processes: v
v
the selection of parts that correspond to the performance specifications among hundreds of profiles, and, the definition of the different glass sizes, considering a given window layout and given performance requirements.
The experts working in this routine design process have the necessary know-how about the manufacturing process, as well as detailed design. They have a detailed expertise on the product library Žprofiles and their properties. of the firm. The knowledge and know-how about the product library is lost when the expert leaves the firm. The use of a KBS in the routine design brings the advantage of keeping knowledge and know-how in store. In this paper, our purpose is to discuss how a KBS can be applied to detailed design process. Before discussing this, it is important to further clarify the terms Adetailed designB and Aknowledge-based designB as used in this study.
ture. On the other hand, industrial design w3x seeks to rectify the omissions of engineering, and is a conscious attempt to bring form and visual order to engineering hardware where technology does not itself provide these features. In our working definition of detailed design, no distinction is drawn between the technical needs of engineering design and the aesthetic approach of industrial design. Detailed design is described as the process of specifying a description of an artifact that satisfies constraints by using diverse sources of knowledge w4x. A design process leading from a product design specification to the manufacturing stage, may be subdivided into conceptual design, analysis, and detailed design, as specified by Hopgood w2x. Preliminary design decisions are made at the conceptual design phase, with the aim of satisfying a few key constraints. Several alternatives are normally considered. Decisions taken at this stage determine the general form of the product. Key constraints predetermined in conceptual design, constitute the product design specification. Other constraints may evolve as a result of decisions made during the remainder of the design process. At the following analysis and evaluation stage, the conceptual design is refined by placing values on numerical attributes, and its performance is tested for its response to external effects and its consistency with the product design specification. Then, at the detailed design stage, the design of the product and its components are refined so that all constraints are satisfied. Decisions taken at this stage include the layout of the assembly system, the positions of the components, etc. Manufacturing stage follows the detailed design. The success of traditional design projects depends upon three factors:
v
1.1. The nature of detailed design process
v
v
Selection of window and door profiles is one of the key aspects of the detailed design process in architecture. Our definition of Adetailed designB falls somewhere between engineering design and industrial design. Engineering design w3x is the use of scientific principles, technical information, and imagination in the definition of a mechanical object struc-
Gathering of information relevant to the design product and process. Generating of design alternatives. Capturing of the resultant solution.
In this iterative communication cycle, there is always a risk that design cannot be manufactured. Another risk is that budget deadlines may constrain designers to make critical decisions without exploring alternative strategies. This is undesirable, as
M. KaÕaklir Automation in Construction 10 (2001) 399–416
making changes to early decisions may necessitate costly repetition of the steps of the design process. 1.2. The need for KBSs Computers may be useful for exploring alternative strategies to make critical decisions quickly and efficiently. However, today’s CAD systems are intended primarily to assist in drawing a design, rather than directly supporting the design process. Therefore, we still need knowledgeable team members to interpret and assess the design product. Traditional CAD systems do not make decisions, and they are not, in general, knowledge-based. They do, however, frequently make use of object-oriented programming techniques. Each line, circle, etc., that is created can be represented as an object instance w2x. Although they contain geometric information, they fail to explain both knowledge about the properties of product parts and reasoning about the design of an assembly. We cannot avoid increasing the level of knowledge and intelligence in CAD systems to automate design process. A true CAD system should be able to draw from a company’s natural knowledge base, the accumulated experience of the workforce w5x. Thus, the need for deeper knowledge in CAD has led us to develop KBS in detailed design process. There have been many development methodologies suggested for the KBS domain such as structured analysis and generation of expert systems ŽSTAGES. and knowledge acquisition documentation system ŽKADS. w6x. However, there are several disadvantages of using these methods in design. They are neither object-oriented in nature to support an iterative prototyping area such as design w7x, nor easy to use by non-dedicated personnel within the companies using a multi-skilled force w8x. Using a specialized-knowledge engineer may lead to frustration due to the possible ambiguity in the problem representation w9x. It is suggested that systems can be created, modified and used readily by the workforce in the domain area. If this methodology is used, a typical system will evolve over time. In the field of design, researchers have different opinions of how designers work, and it is therefore not surprising that markedly different software architectures have been produced w2x. For example, CYCLOPS w4x and FORLOG w10x systems assume that inno-
401
vative design can be obtained by generating a variety of alternatives and choosing between them. In contrast, DOMINIC w11x uses a systematic approach to innovation, which generates only feasible solutions. EDISON w12x, as a system for designing simple mechanical devices, makes use of meta-rules to steer the design process between the various strategies that are provided by mutation, generalization, and analogy. Both CYCLOPS and EDISON are based on retrieving a previous design from memory and adapting it to the new circumstances. Generalization is the process of forming a generic description from a specific item. In EDISON, for instance, a door might be considered a subclass of the general class of entrances. Generalization achieves the same goal as the deep explanations used in the adaptation mode of CYCLOPS. As we can see in these examples, selection between alternatives forms an integral part of the design problem. Even within the apparently limited domain of material selection w13x, the range of relevant knowledge is so wide and interactions so complex that current systems are rather inadequate.
2. Proposed system architecture The system architecture of the WIND comprises several components in a graphical environment, such as user interface, database, knowledge base, inference engine, and SYNTHESIZER. Performance parameters are the input for the system, while values of the attributes attached to synthesized profiles are the output for cost analysis. The system architecture can be seen in Fig. 1.
Fig. 1. System architecture.
402
M. KaÕaklir Automation in Construction 10 (2001) 399–416
Unlike the other computer tools Že.g., Refs. w5,14x., the WIND does not calculate the values of the parameters of performance requirements, only accepts the variables and coefficients of performance parameters as user input. However, like many other KBSs w5,15x, the WIND’s user interface is integrated in AutoCAD. We preferred to provide the knowledge engineer with an interface through widely available CAD packages. Thus, a range of additional facilities could be provided without additional effort by the implementers of KBSs and the time to learn the interface would be reduced for the end users, as implied by Tate w16x. Some CAD packages provide facilities to enable tailored interfaces to be created. AutoCAD is an example. The user interface of the system provides a convenient and user-friendly way of handling input and output in AutoCAD environment. It is possible to use dialog boxes, pull-down and screen menus, command lines, and text screens. Everything is either handled as a question to the user or provided by means of the graphical representations. AutoCAD presents a good basis for the creation and modification of a design database, especially for window manufacturers. Some attributes can be attached to the profiles in the design database. Then, the values of the attributes can be extracted from the AutoCAD environment as a file in CDF or SDF format and can be used in the database program for a cost analysis. SYNTHESIZER is the core module of the WIND that maps the real product parts onto the rough models by evaluating the rules. This facility that leads to the incremental development and detailed description of parts can also be seen in the other systems w5x. This module interacts with the knowledge base and the inference engine. The collection of domain knowledge of the window manufacturers, is the knowledge base of the WIND. The knowledge base includes an interconnected set of pattern-coded observations and hypotheses, as well as rules and procedures. The knowledge is represented by rule-based methods.
3. Knowledge modeling Knowledge modeling starts with knowledge analysis. In this step, mental processes Žactions. of hu-
man designers are analyzed. The second step is the acquisition and elicitation of the knowledge by means of queries, interviews, transcripts and drawings w1,17,18x. After the knowledge is coded and structured by means of protocol analyses w1,17,19x, it is programmed. The domain knowledge structured in the knowledge model is useful in identifying new computational processes, new divisions of tasks and cognitive functions required to perform the work desired, and new ways of allocating work in the workplace. In this paper, we will discuss some major steps of knowledge modeling from analysis to implementation.
4. Knowledge analysis Knowledge analysis can be categorized in two groups: analysis of concepts, and analysis of process. 4.1. Analysis of concepts Knowledge analysis requires the adequate reconstruction of the concepts of the field, a task that has been tackled under the heading of conceptual modeling w20x. Therefore, concepts related to the semantic structure of a window are analyzed in this part. Window is a composite object made up of components, as shown in Fig. 2. A window element consisting of an assembly of bodies that belong to the same class can be represented by a geometric model. The appropriateness and the quality of the window design are assumed to depend upon the window type, its profiles, the wall in which it is embedded and the nature of the environmental conditions on both sides Žinside and outside.. The edges of a window frame should have different properties depended on its location. The attachments to the wall and to the fixed or movable casements require different strategies to follow. Typically, nodes in a window refer to the problematic points. Plans and sections generated by an expert show the solutions of these problematic points. We will use Ahole-in-wallB type casement windows as a sample. This type is very common in mass housing projects. The Ahole-in-wallB type windows are enclosed by the wall on all sides, and are placed
M. KaÕaklir Automation in Construction 10 (2001) 399–416
403
Fig. 2. Functional decomposition of a window assembly.
in the wall as a whole, like an assembly that is composed of a series of window parts. The concepts related to the Ahole-in-wallB type windows are explained in Table 1.
It is possible to formulate the vocabulary of Ahole-in-wallB type windows as shown in Fig. 2. This vocabulary is based on the window grammar proposed by Baykan and Eastman w21x. According to
Table 1 Vocabulary of a Ahole-in-wallB type window Wall Front frame Frame Sash Muntin Mullion Glazing Sill
Wall is all around the window, enclosing it on all sides. Front frame is an additional part that may be placed to compensate for the faults in the construction system. It is next to the wall, forms a loop enclosing the other window elements. Frame is next to the wall or front frame Žif there is., forms a loop enclosing the other window elements. Sash is the opening part of the window. It is nested in the frame. Muntin subdivides the glazing. It is nested in either the frame or the sash and connected to one of these at its endpoints. It has to be next to glazing on both sides. Mullion is a vertical member in a window frame. Glazing is the transparent part of the window, allowing transmission of light. Sill forms the base of the window, and prevents the wall from the water. It is next to the wall. Sill is divided into two parts as exterior or interior.
M. KaÕaklir Automation in Construction 10 (2001) 399–416
404
this grammar, AwallB includes AwindowB and AsillB. AWindowB includes a Afront frameB Žif exists., AframeB, and AglazingB compound. AGlazingB compound may have AmuntinsB or AsashesB, and other AglazingB compounds Žif muntins or sashes exist in it.. ASashB includes AglazingB compound and other AsashesB. ASillB belongs to exterior andror interior space, and includes only itself. A drawing typically has many possible structural descriptions with instances from a given shape vocabulary and relationships of those instances. 4.2. Analysis of window design process The process of analysis w22x is to decompose a problem into parts until individual parts are recognized as being amenable to known operations, and results are re-assembled into a solution. This process has a peripheral role in design and development of a KBS. The stages of the window design process w18x can be explained as follows. 4.2.1. Analysis Design process in manufacturing firms starts with getting specifications from the architect of a project. The project includes technical specifications, plans and sections, delineation of the elevations, opening directions of the windows, and structural axes. Analysis at this stage can be divided into five main parts w1x: v
v
v
v
v
analysis analysis analysis analysis analysis
of of of of of
performance requirements, information in plans, information in sections, information in elevations, information in structural systems.
refers to the first meta-model related to the assembly drawing of the different intermediate meta-models. 4.2.3. Choosing a profile system The profile system refers to the profile group having some common attributes that belong to the same class. The profile system is selected according to the performance requirements. Additional profiles are used only when they are necessary. The number of the profile systems varies according to the capacity of the manufacturer Žfor example, C¸ UHADAROGLU has 30 different systems and FENIS has three different systems and four different types for each system.. There are some important criteria affecting the selection of profile system, such as water tightness, rigidity, clamping, fitness of joints, wind load, heat insulation, economy, cleaning system, attachments to the wall and the parapet, and exterior surfaces of the profiles for the requirements of stainless steel screws. 4.2.4. Choosing an accessory Window manufacturers have catalogues of profile systems, from which the standard accessories for each system are chosen. The types of accessories generally depend on the system selected Žfor example, each system has its own accessories in FENIS.. 4.2.5. SolÕing a problem node A problem node refers to the connection of a window part to another part or a wall. Problem nodes can be listed as follows:
v
v
v
v
4.2.2. Initial design (fundamental design) Initial design process is related to the setting up of the first meta-model. A meta-model w23x is a model of models. The meta-model refers to the global rough model of the products in a window system, fixing of the temporary design solutions or goals. Rough model is the formal representation of the conceptual mechanisms of a window system and
attachment to a wall or a suspended ceiling, parapet, special corners and finishes, connections.
The samples of important nodes can be seen in Appendix A. 4.2.6. Synthesis of parts (embodiment design) Synthesis of the product parts is accomplished following the solution of a problem node. During the
M. KaÕaklir Automation in Construction 10 (2001) 399–416 Table 2 General stages of window design process
405
4.2.8. Final design (detailed design) After the architect’s approval, the expert designing the window system generates final design. Since the output of the final design is a system detail, it is regarded as detailed design w23x. 4.2.9. Cost analysis The cost of the whole system is calculated in the last stage. Criteria for cost analysis are the material, the global size of the window and opening casements, the location of bars, the number of loops of the rubber fillets, and the number of hinges. General design stages are summarized in Table 2. 4.3. An empirical study on window design process
synthesis of parts, the rough models are replaced with the real product parts. The synthesis of parts requires defining criteria in relation to the combination of the parts and their location in the window. At this stage, the fitness between assemblies Žgroups of profiles and classes. is the most important factor. It is the expert’s duty to synthesize window parts, and produce drafts of the proposals. This stage is also regarded as embodiment design w24x in which the designer determines the layout and shape for all parts and develops a technical product or system according to technical and economic considerations. 4.2.7. ApproÕal of the architect If the result of the synthesis of parts is unsatisfactory, modifications in the Aembodiment designB phase may be necessary w24x. Therefore, the approval of the project architect is required after the synthesis of profiles. The architect of the project can modify a window assembly, if the selected system causes a different elevation in comparison to the fac¸ade initially drawn by the architect.
Interviews with the top four window manufacturers on the detailed design process indicate that the window design process has similar protocols for generating candidate design solutions. We chose one of the firms producing window profiles for the empirical study based on protocol analysis. This was not a contrived situation, but a real design case in the firm FENIS. Operations in the protocol analysis were handled with care and most of the rules were acquired during the experiment. The operations were simulated in the computer program. The sample used was a Ahole-in-wallB type window having three openings and one fixed casement, as can be seen in Fig. 3.
Fig. 3. Window type and point details given in the experiment.
406
M. KaÕaklir Automation in Construction 10 (2001) 399–416
According to the findings extracted from the empirical study, the procedure continues as follows. The expert starts with the elevation of the window Žin the scale: 1r20 cm.. A profile system is defined due to the thermal requirements expected from the window system. A frame profile is chosen in a matrix representation from the profile catalogue of the firm w1x. The need to front frame is searched, and if necessary, frame profile is chosen due to this need. This is used for producing point details 1, 3, 4, 5, 8, and 10. Considering water insulation, a front frame is chosen among profiles in the matrix. Thus, point details 8 and 10 in Fig. 8 are produced. A product part for the interior sill is chosen according to the appropriateness to the frame profile. This is also used for producing point details 8 and 10. A product part for the exterior sill is chosen according to the fitness on the wall, among the profiles. This is also used for producing point details 8 and 10. v
v
v
v
v
v
A product part for sash is chosen according to the gap Ždistance. between the frame and sash, among the profiles. This is used for producing point details 1, 2, 3, 4, 6, 7, 8, 9 and 10. An additional profile is defined to prevent the water infiltration. Thus, point details 8 and 10 are produced. At the end of this step, point details 1, 3 Žsymmetry of 1., 8, 10 Žsame as 8., 4 Žrotation of 3. and 5 are solved. The expert asks if the muntin exists. At that moment, window elevation may be modified after the approval of the architect. Muntin is chosen among the profiles, considering if a vertical line is needed, or if the casement is fixed. If the length of the horizontal or vertical bar is greater than a certain distance, structural calculations for the muntin are made, and the muntin needs to be supported by an additional box profile which is selected considering the wind load calculated according to the norms, such as TSE 498 and DIN 1055. Thus, point details 2, 6 Žrotation of 2., 9, and 7 Žrotation of 9. and 5 have been solved. v
v
v
Fig. 4. Flow chart.
M. KaÕaklir Automation in Construction 10 (2001) 399–416
Main accessories are chosen. Sash fillets, center fillet, exterior glazing fillets and epidien fillets are placed against infiltration. The size of interior glazing fillet and weights of the product parts are calculated. These are used for the cost estimating. Flow chart of the process in this experiment can be seen in Fig. 4. v
407
Table 3 Flow diagram
5. Implementation Unlike the other KBSs, instead of a computer programmer, we used an architect for knowledge engineering and programming. She was not only familiar with developing computer programs in LISP, but also familiar with the nature of design process itself. Thus, the knowledge engineer could probe domain knowledge like an architect who has just started to work in the field, extracting the necessary knowledge from the expert by using AteachbackB approach as a knowledge acquisition method. We believe that knowledge engineers who are familiar with the domain are able to correspond to the demands of the task and the needs of end users more efficiently than the unfamiliar ones. Following knowledge analysis, a knowledge structuring method w1,17,19x was developed as a basis for the implementation. In the knowledge-programming phase, actions of the expert in each design stage were simulated in a computer program. The scenario was developed in the stages shown in Table 3. The structure of the computer program is based on object-oriented methodology. The design problem in the system is solved by defining, creating, and manipulating collections of data and procedures called objects. The terminology behind object-oriented programming relate to how objects are defined, have properties assigned to them, how they interact, and how they are combined to form more complex objects. We adopted object-oriented programming approach for organizing the operations. The knowledge-programming approach, NoDes, breaks down the program into two main parts: plan and section. These parts then decompose further, each stage of decomposition varying the contents of
the nodes. Following this, primitive objects are inserted, and then, replaced by higher level objects that will use the knowledge base to make specific decisions regarding their shape, relationships and attributes. The computer program and the links between the subroutines are arranged in a tree diagram Appendix B. The program runs in AutoCAD environment, which provides AutoLISP, a variant of LISP language that is convenient for developing AI systems. We chose AutoLISP as the programming language, because AutoCAD has been commonly used in the design offices of the firms, and they already had the profile catalogues drawn in the AutoCAD environment. 5.1. Getting input The first step is to state the problem. The user interface of the WIND includes menus, command lines, and dialog boxes to make it easier to enter input. User input can be grouped into two groups. One is about the problem environment and the other is related to performance requirements.
408
M. KaÕaklir Automation in Construction 10 (2001) 399–416
5.2. Drawing the window eleÕation The user of the system draws the window elevation by a mouse click on Awindow elevationB in the pull-down menu as shown in Fig. 5. At the background, this mouse click runs a LISP program called WE.LSP. During the program execution, the system asks the user for the number of casements. Then the subroutine Adrw – caseB is executed in a loop, once for each casement. The user is prompted for the attributes of each casement on the fly. List processing specifies coordinates of casement corners from the given information. Then, the system asks the user to define whether the casement is fixed or movable. If the casement is movable, the opening direction Žleft, right, up or down. is asked and drawn.
Fig. 6. Drawing plane of section.
at the background branches into two main subroutines: 5.3. Specifying the plane of section v
v
In the second step, the user specifies the plane of section by a mouse click on Aplane of sectionB in the pull-down menu, as shown in Fig. 6. The system asks the user if the plane of section is horizontal or vertical. At this moment, computer program running
If the plane of section is horizontal, WP.LSP runs. If the plane of section is vertical, WS.LSP runs.
Both WP.LSP and WS.LSP include similar subroutines to draw the plane of section and ask for the number of point details to be produced. The number of point details is assigned to a variable. This variable controls to run AdetpointB or AdpointB subroutines. 5.4. Specifying fixed r moÕable casements
Fig. 5. Drawing window elevation.
In the third step, the system asks the user to select the point details one by one, and define the characteristics of the adjacent node. Each point detail is a double node that is composed of two adjacent nodes, as shown in Fig. 7. The characteristics of adjacent nodes are stored in AdetpointB subroutine that runs at the background. An adjacent node changes according to the plane of section. If the plane of section is horizontal, the adjacent node is either at left or right. If the plane of section is vertical, adjacent node is either up or down. In both cases, an adjacent node may be either the wall or a fixed or movable casement. Point details with double nodes can be grouped into two parts: attachment to the wall, and junction.
M. KaÕaklir Automation in Construction 10 (2001) 399–416
409
Codes of left and right nodes, such as AFB, AMB and AWB, are assigned to a symbol named pdcode for each point detail. Each pdcode is added to a list named pdlist. Coordinates of each point detail are assigned to a list called detxy. For list processing, WP.LSP repeats AdetpointB subroutine for each point detail. The program runs in the same logic if the plane of section is vertical. A similar subroutine, AdpointB, based on the same method is used, that runs different routines according to top and bottom nodes: Fig. 7. Nodes on the plane of section.
Both of them have different procedures that run according to the node characteristics. The samples of the double nodes can be seen in Appendix A. The procedures are as follows: 1. Attachment to the wall: with or without front frame, with fixed casement Žwf, hf., with movable casement Žwm, hm., with sill Žmj, fj., without sill Žmj, fj.. 2. Junction: with or without muntin, fixed casementq fixed casement Žff, ff2., fixed casement q movable casement Žfm, fm2, mf, mf2., movable casement q movable casement Žmm, mm2..
if the top node is wall, AtnodwB; if the top node is fixed casement, AtnodfB; if the top node is movable casement, AtnodmB, if the bottom node is wall, AbnodwB; if the bottom node is fixed casement, AbnodfB; if the bottom node is movable casement, AbnodmB subroutine is fired.
Codes of left and right nodes, such as AFB, AMB and AWB are assigned to a symbol named pdcode2 for each point detail. Each pdcode2 is added in a list named pdlist2. Coordinates of each point detail are assigned to a list called detxy2. For list processing, WS.LSP repeats AdpointB subroutine for each point detail.
ADetpointB subroutine calls itself recursively for each point detail as left and right node to traverse the tree: if the left node is wall, AlnodwB; if the left node is fixed casement, AlnodfB; if the left node is movable casement, AlnodmB, if the right node is wall, ArnodwB; if the right node is fixed casement, ArnodfB; if the right node is movable casement, ArnodmB subroutine is fired.
Fig. 8. Boxes inserted on the plane of section.
410 Table 4 Sample from the nodes
M. KaÕaklir Automation in Construction 10 (2001) 399–416
M. KaÕaklir Automation in Construction 10 (2001) 399–416
5.5. Drawing rough layout of fixed and moÕable casements
411
Table 5 Procedural tree
All point details have some primitives representing fixed and movable casements. Primitive of fixed casement is called wbox – f and primitive of movable casement is called wbox – m. Subroutines replace these symbols according to their relations to adjacent node in a point detail. The location and rotation angles of the symbols depend on whether the plane of section is horizontal or vertical. Fig. 8 shows a sample of primitive boxes inserted to specify double nodes. 5.6. Inference and explanation of rules To set and explain the rules, a collection of facts including sentences about general facts is recorded. This collection of facts is used for combination of AifB and AthenB sentences. Table 4 shows a sample from the rules in the AutoLISP code. Combination of the sentences in the collection of facts defines the rules. A subroutine called Aset – ruleB in the RULE.LSP file is developed to combine Aif-then-elseB commands in the WIND to set up a rule. As shown in Appendix A, if data about condition 1 ŽDc1. match with fact ŽF1., then fact 1 ŽF1. is the AifB part of the rule ŽI – Dc. and fact 11 is the AthenB part of the rule and Aset – ruleB subroutine runs and a message is prompted. When Aset – ruleB subroutine runs, the AifB part of the rule ŽI – Dc. is added with AifB prefix, and is then combined with the AthenB part of the rule ŽT – Dc., added with AthenB prefix. The rule occurs and is printed on the monitor. Then the rule is added to the beginning of a present rulelist. At the end of the program, RULE.LST file is closed and rulelist is printed for monitoring. In a similar way, it is possible to add new rules by means of Aadd – ruleB subroutine, as can be seen in the LISP code in Table 5. 5.7. Drawing rough layout at nodes By clicking on ARoughB in the ADetailsB pop-up menu, rough layouts of components are placed as shown in Fig. 11. At the background, the system
evaluates the design rules in the knowledge base. ROUGH.LSP calls PLN.LSP or SEC.LSP according to the plane of section. The list of point details codes and the list of x and y coordinates for each point detail are evaluated. If the pdcode is ŽAWB AFB ., AwfB subroutine runs, if it is ŽAFB AFB ., AffB subroutine runs, if it is ŽAFB AMB ., AfmB subroutine runs, if it is ŽAMB AFB ., AmfB subroutine runs, if it is ŽAMB AMB ., AmmB subroutine runs, if it is ŽAFB AWB ., AfwB subroutine runs, if it is ŽAMB AWB ., AmwB subroutine runs, if it is ŽAWB AFB ., AwfB subroutine runs, if it is ŽAWB AMB . AwmB subroutine runs.
412
M. KaÕaklir Automation in Construction 10 (2001) 399–416
Fig. 11. Product library of sill profiles produced by the FENIS. Fig. 9. Rough mechanisms inserted on the nodes.
It is possible to explain SEC.LSP in the same way. The only difference is that the subroutines are applied in a vertical plane and they have different names.
If the pdcode is ŽAFB AFB ., Aff2B subroutine runs, if it is ŽAFB AMB ., Afm2B subroutine runs, if it is ŽAMB AFB ., Amf2B subroutine runs, if it is ŽAMB AMB ., Amm2B subroutine runs, if it is ŽAFB AWB ., AfjB subroutine runs, if it is ŽAMB AWB ., AmjB subroutine runs,
Fig. 10. Product library of frame profiles in FENIS System 52.
if it is ŽAWB AFB ., AhfB subroutine runs, if it is ŽAWB AMB . AhmB subroutine runs.
In these subroutines, some abbreviations are used. For example, h is the head, j is the jamb, w is the wall, f is the fixed casement and m is the movable casement. These subroutines define and place the general relations and locations of the rough graphical representations of the window components. Rough mechanisms in window plan, drawn by PLN.LSP can be seen in Figs. 9 and 13. Fig. 14 is a sample
Fig. 12. Suggested solution for the nodes.
M. KaÕaklir Automation in Construction 10 (2001) 399–416
413
Fig. 13. Assemblies of window parts in plans.
showing rough mechanisms in a section drawn by SEC.LSP. 5.8. EÕolution of components at nodes In the next stage, rough graphical representations of the window components are replaced with the products in the product library in Figs. 10 and 11.
Fig. 14. Assemblies of rough parts in window sections.
E – PLN.LSP transforms the horizontal plane of section, while E – SEC.LSP transforms the vertical one. The key point is the choice of the firm. Each firm produces different kind of products and uses different material. Different subroutines for different firms should be used for producing detail design. For example, the AfenisB subroutine has the rules and relations about FENIS products, while the AcuhB subroutine refers to C¸ UHADAROGLU and ApimasB
Fig. 15. Assemblies of product parts in window sections.
414
M. KaÕaklir Automation in Construction 10 (2001) 399–416
refers to PIMAS. These subroutines replace the rough graphical representations of the window components with the more detailed and exact products of the chosen firm. Fig. 12 is an alternative solution to the nodes on the horizontal plane of section previously shown in Fig. 9. Examples of actual mechanisms in window sections and plans, drawn by PLN.LSP and SEC.LSP, are shown in Figs. 13–15.
6. Conclusion Although the samples in this paper include only window assemblies, NoDes as a knowledge modeling approach is flexible enough to be integrated in other building elements, including system parts, such as doors. Changing the database of the product parts and the design rules in the knowledge base, and using the same logic, NoDes can also be used for producing the point details of industrial design products. If we compare the speed of design process by NoDes with the speed of design process by manual work, it is possible to understand the dramatic superiority of computers in routine design. As we have already mentioned in Section 1, shop drawing is a monotonous process for human designers. It also requires highly specialized knowledge and experience on design domain. Analyzing projects and specifications, searching documents and catalogues, selecting which system to be used, and drafting of final solution take considerable time. Human beings should use this time for creative purposes. Routine work can be efficiently achieved by this computer system w1,17x. In the current case, it takes 15 s to insert rough graphical representations, and 2 min for replacing them with firm profiles. Consequently, NoDes as a knowledge modeling approach is an efficient way to produce point details. It analyses the design specifications, fixes the approximate layout of the design solution at nodes, and synthesizes system parts to obtain final design, fixes meta-models and evolutionary models by replacing rough layout. It is intended to continue development of the WIND, until it is a full commercial product. In the present case, the system has a useful, Žthough incom-
plete. knowledge of how aluminum window profiles can be synthesized. However, even this version of the program could be a valuable tool, showing the abilities of a KBS based on the NoDes approach. Further work is needed on the performance analysis and the cost analysis to extend the program so that it can calculate performance and cost of the proposed system. The program may also be extended to evaluate window fac¸ade, and to suggest ways of improving its appearance andror details, either at the design stage or when a problem is discovered in an existing building. Documentation on on-line help should be available for training of personnel using the program. The graphical nature of the problem forces the developers to devote an unusually large amount of effort to the user interface even though the program’s problem solving ability is at a fairly early stage. It is strongly recommended to use a ready-made CAD package, rather than to develop it in building knowledge-based CAD systems. An interesting aspect of the knowledge representation is that a 2D diagram seems to have been sufficient. Although the experts emphasized that a window design must be considered in 3D, it appears that the so-called 3D analysis, which designers can cope with, is limited with a range of 2D analysis. However, we still need to use 3D representations and diagrams for actual frame junctions, but this is getting into an area where even the experts have difficulty.
Acknowledgements This project was partly sponsored by the State Planning Organization of the Turkish Republic between 1990–95 and the system was developed in the Faculty of Architecture, Istanbul Technical University, Turkey. The WIND is the subject of a PhD thesis supervised by Prof. Dr Nigan Bayazit, whose advice and support played an important role throughout the design process of the system. Author is also grateful to the managers and designers, Mete C¸ ilekar from FENIS and Yenal Oktug from C¸ UHADAROGLU, whose cooperation as AteachbackB in the knowledge acquisition made the WIND possible.
M. KaÕaklir Automation in Construction 10 (2001) 399–416
415
Appendix A. Rules
Appendix B. Rule Generator
References w1x M. Kavakli, WIND: A knowledge-based system for the synthesis of window parts, PhD Thesis, Institute of Science and Technology, Istanbul Technical University, 1995. w2x A.A. Hopgood, Knowledge-Based Systems for Engineers and Scientists, CRC Press, London, 1993.
w3x Open University, PT610: Manufacture, Materials, Design — Unit 7, Open Univ. Press, 1986. w4x D. Sriram, G. Stephanopoulos, R. Logcher, D. Gossard, N. Groleau, D. Serrano, D. Navichandra, Knowledge based system applications in engineering design: research at MIT, AI Magazine Ž1989. 79 pp. w5x C.B. Chapman, M. Pinfold, Design engineering — a need to
416
w6x
w7x
w8x
w9x
w10x
w11x
w12x
w13x w14x
w15x
M. KaÕaklir Automation in Construction 10 (2001) 399–416 rethink the solution using knowledge-based engineering, Knowledge-Based Systems 12 Ž5–6. Ž1999. 257–267. G.N. Blount, S. Kneebone, M.R. Kingston, Selection of knowledge based design applications, Journal of Engineering Design 6 Ž1. Ž1995. 31–38. M.D. Mulvenna, J.G. Hughes, Expert agents in knowledgebased systems — applications and innovations in expert systems, Proceedings of Expert systems 93, The 13th Annual Conference of British Computer Society Specialist Group on Expert Systems, Information Press, Cambridge, 1993. C.W. Church, A business plan for knowledge inclusive systems, research and development in expert systems, Proceedings of Expert systems 93, The 13th Annual Conference of British Computer Society Specialist Group on Expert Systems, Information Press, Cambridge, 1993. W.J. Crowther, D.R. Bull, C.A. Burrows, Knowledge acquisition for enginnering systems using bond graphs, Proceedings of Expert Systems 95, The 15th Annual Conference of British Computer Society Specialist Group on Expert Systems, SGES Publications, Cambridge, 1995, pp. 41–56. T.G. Dietterich, D.G. Ullman, FORLOG: a logic-based architecture for design, in: J.S. Gero ŽEd.., Expert Systems in Computer-Aided Design, North-Holland, 1987. A.E. Howe, P.R. Cohen, J.R. Dixon, M.K. Simmons, DOMINIC: a domain-independent program for mechanical engineering design, International Journal for AI in Engineering 1 Ž1986. 23. M.G. Dyer, M. Flowers, J. Hodges, EDISON: an engineering design invention system operating naively, International Journal for AI in Engineering 1 Ž1986. 36. A. Demaid, J. Zucker, A conceptual model for material selection, Metals and Materials Ž1988. 291 pp. L. Khemlani, GENWIN: a generative computer tool for window design in energy-conscious architecture, Building and Environment 30 Ž1. Ž1995. 73–81. H. Tianzhen, Z. Jinqian, J. Yi, IISABRE: an integrated building simulation environment, Building and Environment 32 Ž3. Ž1997. 219–224.
w16x A. Tate, Interfacing a CAD System to an AI Planner, Artificial Intelligence Applications Institute, University of Edinburgh, AIAI-TR-76, Edinburgh, UK, 1990. w17x M. Kavakli, Knowledge modeling in support of detail design process, in: O. Akin, G. Saglamer ŽEds.., Descriptive Models of Design ’96, Proceedings of 1st International Symposium on the Descriptive Models of Design, Istanbul Technical University, MK, 1996, pp. 1–30. w18x M. Kavakli, A knowledge-based system for the synthesis of parts in a design product, in: K. Ellis, A. Gregory, B.R. Mears-Young, G. Ragsdell ŽEds.., Critical Issues in Systems Theory and Practice, UKSS’95: Proceedings of United Kingdom Systems Society 4th International Conference, Plenum, London, 1995, pp. 149–157. w19x M. Kavakli, N. Bayazit, Knowledge structuring of an expert system developed for the synthesis of parts in industrial design, in: R. Trappl ŽEd.., Cybernetics and Systems’ 94, Proceedings of 12th European Meeting on Cybernetics and Systems Research vol. 1, World Scientific Pub, Vienna, 1994, pp. 531–538. w20x P. Schefe, Expert Systems Present State and Future Trends: Impact on Employment and Skill Requirements ŽAn Assessment., International Labour Office, Management Development Branch, Training Department, Geneva, 1988, pp. 1–55. w21x C. Baykan, C.M. Eastman, An Expert System for Window Performance Analysis, Institute of Building Science and School of Urban and Public Affairs, Carnegie Melon University, Pittsburgh, 1983. w22x A. Bijl, An approach to design theory, in: T. Yoshikawa, Warman ŽEds.., Design Theory for CAD, North-Holland, 1985, pp. 3–31. w23x T. Tomiyama, H. Yoshikawa, Knowledge engineering and CAD, Future Generations Computer Systems 1 Ž4. Ž1985. 237–243. w24x T. Bachman, M. Daniel, G. Pahl, J. Rix et al., Feature-based modeling in support of embodiment design, Computers and Graphics 17 Ž3. Ž1993. 285–294.