unified feature definition for feature based design

UNIFIED FEATURE DEFINITION FOR FEATURE BASED DESIGN AND FEATURE BASED MANUFACTURING

Reinholt Geelink, Otto W. Salomons, Fjodor van Slooten Fred J.A.M. van Houten and Huub J.J. Kals University of Twente Department of Mechanical Engineering Laboratory of Production and Design Engineering Enschede, The Netherlands

ABSTRACT In this paper, interactive ”constraint based feature definition” is used to drive both feature based design and feature recognition. At present, hardly any feature based CAD or CAPP system does offer adequate facilities to easily define application specific features. Feature definition by means of programming is an error prone and difficult task. The definition of new features has to be performed by domain experts in the fields of design and manufacturing. In general they will not be programming experts. This paper elaborates on interactive feature definition, aiming at facilitating the definition of features by non–programming experts. The interactive feature definition functionality is implemented in a re–design support system called FROOM. It supports feature based design. Feature definition is also used in a Computer Aided Process Planning system, called PART, for the definition of features to be recognized. Conceptual graphs are used as an aid in the definition of features and for the representation of the features. The conceptual graphs are automatically transformed into feature recognition algorithms. Degrees of freedom (DOF) analysis is used for support during feature definition and for solving geometric constraints related to the feature to be defined.

1. INTRODUCTION Most new generation CAD and CAPP systems are feature based. The CAD systems should support design feature class definition in order to allow end–users to model geometry by instantiating pre– defined design features. CAPP systems, if they cannot handle feature based product models as an input, need feature definition functionality in order to support the creation of templates for recognition of manufacturing feature instances. The recognized manufacturing features can then be used in the subsequent process planning steps. Feature based CAD systems generally do not offer a facility to easily define design features and CAPP systems hardly allow definition of manufacturing features. CAD or CAPP systems which do offer

a facility for feature definition, usually provide some kind of programming interface to the geometric modeler. Often, the programming interface has limited access to the geometry processing functions of the modeler. So–called Knowledge Based Engineering (KBE) systems, like ICADTM, have a better programming interface and easier access to the geometric modeler in comparison with ”traditional” CAD or CAPP systems. Nevertheless, even within KBE systems, feature definition remains difficult and error prone. It requires in–depth programming skills. The person in charge of defining new features usually can be regarded as a domain expert in the field of design or manufacturing or both. Present feature definition functionality requires this person to be a programming expert as well. In practice, this is seldom the case. Therefore, language based approaches such as mentioned in for instance (Krause et al., 1991a,b), (Laakko and Mäntylä, 1992) and (Sreevalsan and Shah, 1991) should not be preferred in the current context. This paper elaborates on interactive feature definition, thus facilitating the definition of features without programming. It aims at providing domain experts (non programming experts) a tool with which feature definition can be performed relatively easily. The interactive feature definition is applied in a prototype of a re–design support system, called FROOM, to support feature based design. It is also applied in the PART process planning system for the definition of manufacturing features. There are some differences between the definition of features for design and recognition purposes. For design purposes, the feature’s behaviour is important, e.g. in case of instantiation or modification. In feature recognition, it is important to be able to relax the definitions of features in order to cope with many different kinds of possible feature intersections. The paper shows that by means of a proper feature representation and constraints specification functionality, both problems can be solved. The definitions of the manufacturing features are automatically converted into feature recognition algorithms. Conceptual graphs are used for the definition and representation of the features. In the following introductory subsections we will elaborate on

Incomplete feature model

Feature Completion

Manufacturing feature model

Feature Based Design

Feature mapping

Manufacturing feature model all recognized

Design feature model Feature Recognition Non feature based/ Conventional solid modeling

?

Non–feature model

Process plan– ning

Feature Identification Feature Definition

CAPP

CAD feature model info FIGURE 1 : THE CENTRAL ROLE OF FEATURE DEFINITION IN A CAD–CAPP LINK, DRIVING FEATURE BASED DESIGN AND FEATURE RECOGNITION. features (section 1.1), FROOM (section 1.2) and PART (section 1.3). Finally, an overview of the remainder of this paper is provided (section 1.4). 1.1 Features Features are being widely used in advanced CAD and CAPP systems. However, still a lot of different meanings for the word ”feature” exist. Shah defined 4 requirements that a feature should fulfil at the minimum (Shah, 1990). A feature: – has to be a physical constituent of a part (component). – should be mappable to a generic shape. – should have engineering significance. – must have predictable properties. For an overview of research in feature based CAD, reference could be made to (Salomons et al., 1993a). A deficiency of today’s feature based CAD systems, is that they focus too much on designing single components using generic built–in features. These systems allow the users only to parametrically modify the geometry of the features (parametric design). Topology and/or non–geometry related information can often not be defined as part of the feature. Therefore, in present CAD systems, features cannot be related (or are hard to relate) to a particular application domain. In Knowledge Based Engineering systems, like ICADTM, it is possible to define application dependent features. However, these systems lack ease of feature definition due to laborious programming. An example of the use of features in CAPP can be found in (van Houten, 1991), describing the PART system. Presently, the feature

recognition algorithms of PART implicitly cover the definition of manufacturing features: it is both a feature definition and a feature recognition language. In CAPP, the feature definition should be separated from the feature recognition algorithm. Often the ”difference” between design features and process planning features has been indicated, e.g. in (Hummel and Brown, 1989). This difference in view of designers and process planners on features is known as the ”multiple views problem”. However, in an observational study, conducted by some of the authors, the multiple views problem has been relativized somewhat (Salomons et al., 1993b). It was found that the differences in views on form features by designer and process planner were only minor. It was suggested that naming conventions of both features and feature attributes could help in overcoming the multiple views problem. This means that by performing the feature definition well, the multiple views problem could, to some extent, be overcome, or at least reduced. Figure 1 illustrates the possible role of features in the link of CAD and CAPP. In feature based design components can be modeled using incomplete (abstract) features, design form features or manufacturing form features (see figure 1). An incomplete feature model needs completion before process planning of the component can be undertaken. Feature completion should preferably take into account process planning knowledge (design by least commitment). If components are modeled using manufacturing features, feature recognition for process planning can be skipped, provided that the features have been validated. Feature validation, although not shown, is an

essential function for all feature model information flows in figure 1. Feature validation, feature recognition and feature mapping make use of similar geometric reasoning functionality. In case components are modeled using design form features, either feature mapping or feature recognition can be applied to derive a manufacturing feature model. When a conventional solid modeling system (non feature based) is used, then feature recognition has to be performed. Figure 1 reflects the major role of feature definition in the link of CAD and CAPP as it drives both feature recognition and feature based design.

1.2 FROOM The FROOM system is a prototype of a re–design support system, currently under development. The development of FROOM has been motivated by the following facts. Firstly, in mechanical engineering design, a high percentage of all the design tasks can be considered as re–design tasks. For these tasks proper computer support tools are not yet available. Secondly, tools that integrate well with automated process planning (CAPP) systems are not yet available. FROOM is an acronym for Feature and Relation based Object Oriented Modeling. FROOM is a feature based system, allowing the modeling of both components and assemblies. Features in the FROOM context can be design form features, manufacturing form features and even abstract features. FROOM employs conceptual graphs for knowledge representation. Features, components and assemblies (concepts) as well as (conceptual) relations play a central role in FROOM. Section 1.2.1 elaborates on the conceptual graphs as used in other modules of FROOM and in the feature definition module. FROOM addresses the functionality of the left of figure 1 while PART addresses the right side functionality (see section 1.3). Two different kinds of users are distinguished: end–users and system manager users. End–users are the designers who design assemblies, components etc.: they perform the actual design tasks. System manager users customize the FROOM system to a certain application domain, company and user (group). They define the features to be used, the catalogues from which selections can be made and other information that can be useful for the end–users. For the two different user groups, different user interfaces are available. Another important part of FROOM is the modeling module in which both components, assemblies and constraints can be modeled. This module has access to the kernel modeler, which offers the basic geometry processing functionality. In FROOM, the ACISTM kernel modeler is used for this purpose. In (Salomons, 1995a) a complete and up to date overview of FROOM is provided.

1.2.1 Feature representation in FROOM using conceptual graphs. Conceptual graphs, or conceptual structures, have been proposed for use in natural language processing and for representing mental models by Sowa (Sowa, 1984). However, the number of applications of conceptual graphs in other domains is increasing, for instance in the field of CAD/CAPP. Conceptual graphs are graphs with two different kinds of nodes: concepts and conceptual relations. Conceptual graphs are therefore called bipartite. Sowa defines a conceptual graph as follows (Sowa,

1984): Assumption: a conceptual graph is a finite connected bipartite graph : – The two kinds of nodes of the bipartite graph are concepts and conceptual relations. – Every conceptual relation has one or more arcs, each of which must be linked to some concept. – If a relation has n–arcs it is said to be n–adic and its arcs are labelled 1,2..n. The term monadic is synonymous with 1–adic, dyadic with 2–adic and tri–adic with 3–adic. – A single concept may itself form a conceptual graph, but every arc of every conceptual relation must be linked to some concept. The deviations of the conceptual graphs as applied in FROOM compared to Sowa’s original approach (Sowa, 1984) are the following (Salomons et al., 1994b) : – Assemblies, components, features and feature elements (like faces, edges etc.) are the only concepts which are shown in the graph. Attributes for instance, are part of the object oriented descriptions of concepts and relations and are usually not shown in the graph. That is, unless the constraint network of parameter constraints is shown. – The relations used in FROOM are only monadic, dyadic or tri– adic. – Directed arcs, are only used when necessary. Often relations just denote a general connection relation like ”component/face A is connected to component/face B”. Usually also ”component B is connected to component A” holds equally well, so that arcs could have been directed in both directions. In these cases directed arcs are omitted. – In the graphical notation of concepts and relations, sometimes other symbols are used than the small rectangles or circles.

1.3 PART PART (acronym for Planning of Activities, Resources and Technology) is a Computer Aided Process Planning system, tuned to perform process planning for prismatic parts that require 2.5 D machining operations like milling, drilling, tapping, boring etc.. Although PART is an automatic process planning system, the user is offered several tools to inspect and edit generated (intermediate) proposals. The process planning functions which PART can perform are placed in functional modules (van Houten, 1991). Some of these are described next. The CAD interface module takes care of conversion of the solid B–rep input model (e.g. STEP, Pro–EngineerTM) to the internal format (ACISTM). In case tolerances are not yet specified on the input model, the tolerance modeling module of PART can be used. After the feature recognition has been performed, the so–called manufacturing feature model is ready. It is input for the down stream process planning modules of PART. The previously mentioned modules make PART a modeler independent CAPP system. For further details see (van Houten, 1991). In PART, like in FROOM, two main types of users are distinguished: end–users and system administrator users. The system administrator users of PART are comparable with the system manager users of FROOM: both have the permission to make the system application specific: they are, amongst others, allowed to define features. In the following, system manager users and system adminis-

{1} PATTERN pocket_round_straight ( 101 ) : { Pattern to recognize straight round pockets } {2} FOR b = Faces_of ( model ) DO {3} VARIANT 1 : {4} Plane_surface ( b ) { Bottom of pocket } {5} c = Curves_of ( First_of ( Edges_of ( Outer_contours_of ( b ) ) ) ) {6} NEXT_IF ( Concave ( Edges_of ( Inner_contours_of ( b ) ) ) ) {7} Circular_arc ( c ) {8} FOR e = Edges_of ( Outer_contours_of ( b ) ) DO {9} Identical ( c, Curves_of ( e ) ) {10} Perpendicular_concave ( e ) {11} FOR x = Faces_of ( e ) - b DO {12} z = Edges_of ( Outer_contours_of ( x ) ) - e {13} Concave_smooth ( z ) {14} FOR y = z - Smooth ( z ) DO {15} Convex ( y ) {16} END_FOR {17} END_FOR {18} RETURN ( Faces_of ( e ) - b ) {19} END_FOR {20} RETURN ( b ) {21} RECOGNIZED {22} END_FOR {23} END_PATTERN

FIGURE 2 : POCKET ROUND STRAIGHT (BLIND HOLE) IN FDL, REDRAWN AFTER (VAN HOUTEN ET AL., 1989). STATEMENTS ENCLOSED IN {} BRACKET REPRESENT COMMENT TEXT, E.G. THE NUMBERS OF THE LINES.

trator users are referred to as ”system users”. 1.3.1 Feature definition and recognition in PART. The PART system employs a feature recognition language called FDL (Feature Definition Language), which is based on a combination of ideas by Kyprianou (1980) and Choi et al. (1984). The CAM–I John Deere feature hierarchy (Butterfield et al., 1986) has been used as the basis for the initial taxonomy of the PART features. However, interactive feature definition as presented in this paper allows for defining any feature taxonomy. In PART, features are recognized from a B–rep solid model. The feature recognition algorithm is a kind of recipe (i.e. pre–defined feature template), in which the requirements of the entities belonging to a specific feature class are described. The entire B–rep model is searched for sets of entities that fulfil those requirements. Verification of the convexity/concavity of edges forms an important part of the recognition algorithm. An example of a piece of FDL code is given in figure 2. Apart from the pattern description as shown, a parameter description is available to determine the values of the feature parameters (dimensions, tolerances, etc.), but this is omitted due to space limitations. In the example of figure 2 the keyword ”VARIANT 1” is used. The variant mechanism is introduced to define features with a slightly different topology and geometry but which still are members of the same feature class. For example, a slot rectangular variant 1 without a bottom–radius and variant 2 with bottom–radius not equal zero, see figure 3. The variant mechanism can be used to deal with feature intersections. In PART distinction is made between ATOMIC features and COMPOUND features. An atomic feature is the most elementary appearance of a feature (van ’t Erve, 1988), like simple holes, pockets and slots. Nested and or combined atomic features are called compound features (see figure 4). Each feature in PART, whether it

variant 1

variant 2

FIGURE 3 : SLOT RECTANGULAR VARIANTS.

3 atomic features

1 compound feature

FIGURE 4 : ATOMIC AND COMPOUND FEATURES (2D VIEW). is a simple one or a very complex one, is said to be a compound feature. ”Horizontally” touching, intersecting or partially overlapping atomic features (adjacent features) are grouped as members of one compound feature. The hierarchy of compound features is based on the ”vertical” (parent/child) geometric hierarchy of the atomic features in the product model (van Houten et al., 1989). Figure 5 shows

cf1

af1

af2

af3

cf2

af4

cf3

af5

af6

FIGURE 5 : FEATURE HIERARCHY FOR AN EXAMPLE COMPONENT IN PART (REDRAWN AFTER (VAN HOUTEN, 1991)). an example of a part and its PART feature representation. Note that in this paper combinations of atomics that delete substantial geometrical elements of atomics are called intersections. A combination of 3 atomics like in figure 4, is a regular compound feature and is not treated as an intersection. Compound features consisting of atomics such as holes, pockets, as well as slots, steps, notches and bosses can be recognized and process planned (see figure 6). PART

Free shaped axial groove

Free shaped slot u–shaped

FIGURE 6 : NESTED ATOMIC FEATURES WITH A BOSS. is able to automatically select proper machining methods for situations like in figure 6. This can be done based on the set of atomics and their hierarchy, in combination with a machining method selector (van Houten, 1990) In PART distinction is made between so–called regular and free shaped features. A feature is called regular if its geometry can be described fully parametrically. Free shaped features in PART are allowed to be sweeps of a free shaped 2D contour along a free shaped curve. A restriction is that a resulting feature should be able to be machined by 2.5D operations. Examples of free shaped PART features are given in figure 7.

FIGURE 7 : FREE SHAPED PART FEATURES During the determination of the feature hierarchy the accessibility of the atomic features is checked. The orientation of the cutting tool is represented by the d–orientation, one of the default parameters of an atomic feature. The accessibility is verified by extending the d–orientation in its negative direction starting from the feature of interest. By means of this operation intersections can be detected with other parts of the model than the feature itself. For more details on FDL reference is made to (van Houten et al., 1989). The PART–S system, also developed at the authors’ laboratory, is an equivalent of PART, focussing on sheet metal products. To define sheet metal features, like bends and punches, FDL is also used. FDL has proven to be an adequate language to define and recog-

perpendicular concave edge blind hole A

FIGURE 8 : A : B :

B

FEATURE INTERSECTION GENERIC SHAPE OF ATOMIC FEATURE SLOT PARTIAL (4 PLANAR AND 2 CYLINDRICAL FACES) INTERSECTION OF AN ATOMIC SLOT WITH AN ATOMIC BLIND HOLE WHICH CAUSED THE DELETION OF THE PERPENDICULAR CONCAVE EDGE

nized sheet metal feature as well. For further details on the PART–S system reference is made to de Vries et al. (1995). FDL has successfully been used to pre–define about 60 different types of manufacturing features. Although FDL is already a ”high level” programming language (it prevents the user from programming low level C code), some drawbacks were encountered during intensive use. The drawbacks can be split into two groups : drawbacks on feature definition level and drawbacks on feature recognition level. Shortcomings on feature definition level are caused by the fact that a feature is defined by programming the recognition algorithm, using FDL. It requires programming skill and experience to program/define valid features. It is preferable to separate the feature definition from the specification of the feature recognition algorithm. Shortcomings on feature recognition level refer to non– recognitions due to feature intersections. The recognition algorithm can operate on a too low level of topology (on vertex and/or edge level) which usually indicates an insufficiently flexible feature definition. Intersection of two or more features can cause deletion of important portions of geometry. For instance: in a feature recognition algorithm a perpendicular concave edge is required, connecting two faces, but this edge could have been deleted by intersection with another feature (see figure 8). In figure 2 the side faces of a pocket round straight are searched by looking for connecting perpendicular concave edges (FDL code lines 10 and 11). A proposal for solving the intersection problem can be found in section 3.3.4. For FROOM it has not been possible to use the feature representation of PART. The reason is that the PART feature representation is based on surfaces, being the entities to be created by machining operations. Modeling (designing) with sets of surfaces is difficult, especially when material has to be removed (depression features). In feature modeling, volumes are therefore more useful (e.g. (Pratt, 1988 and 1990)). Nevertheless, whatever feature representation is used in FROOM, it has to be ensured that it can easily be converted into the PART feature representation. Especially, this holds when the features are essentially the same. In FROOM the feature repre-

sentation and feature definition module are based on conceptual graphs: see sections 1.2.1 and 3.

1.4 Organization The organization of the remainder of this paper is as follows. Section 2 briefly summarizes related literature. Section 3 elaborates on the design of the interactive feature definition module for driving feature based design in FROOM and feature recognition in PART. Section 4 describes the present implementation of this module. Finally, in section 5 conclusions and recommendations are presented.

2. RELATED LITERATURE A distinction is made between feature representation literature (section 2.1), feature definition literature (section 2.2) and feature recognition literature (section 2.3). Feature definition and feature representation are two closely related subjects. Feature definition is considered here as defining how a feature should look like, how it should behave, what its characteristics are etc.. Feature representation is regarded as how all this feature information is stored computer internally: representing both the individual (form) features and the relations between the individual features that constitute a component. Often the way features are represented, determines the way in which they can be defined and therefore these two subjects are often treated as equivalents. As this paper will show, feature recognition is closely related to both feature representation and feature definition. 2.1 Feature representation literature Pratt (1988 and 1990) proposed a non–manifold feature representation based on the belief that B–rep is the preferable solids representation scheme and that features should be volumetric. Pratt also introduced the notion of implicit and explicit feature representations. In the explicit representation, all geometric details of the feature are fully defined. In the implicit representation sufficient in-

formation is supplied to define the feature, but the full geometric details have to be calculated when required. Shah and Rogers (1988) used a hybrid CSG/B–rep feature representation scheme for their feature based modeling system. Wang and Ozsoy (1991) also propose a hybrid representation scheme. Joshi and Chang (1990) proposed the use of an attributed adjacency graph for feature representation. Fu et al. (1993) propose a graph grammar for feature representation. Van Emmerik (1990) used a CSG approach based on half spaces. A more detailed discussion of these and other feature representation approaches will not be considered here due to space limitations.

2.2 Feature definition literature Billo et al. (1989a and 1989b) tried to bring some more rigour into feature definition by using conceptual graphs. By doing this, feature recognition and feature mapping or conversion would be made easier. A simple example of feature transformation to Group Technology coding is given in Billo et al. (1989a and 1989b). The feature definition used by Billo et al., in case of prismatic features, consists of face concepts and adjacency relations between them. The face concepts are part of the general feature concept. However, it is not fully clear whether other relations between faces are also possible such as perpendicular, concave, convex, parallel etc.. Other features are defined using conceptual graphs for sweeps and ruled surfaces. It is not clear in what respect the concepts have been elaborated in order to realize interactive feature definition. Sheu and Lin (1993) present a definition scheme that is suitable for representing and operating on form features. Five basic constituents: B–rep solid components, measure entities, size, location and constraints are used to represent a single form feature. However, although the concepts are promising, it seems that an interactive feature definition functionality has not been realized. Duan et al. (1993) employ generalized sweeping techniques for feature definition. A feature is defined as a parametric shape–unit. It consists of a geometric description, attributes and application oriented mapping methods for design and manufacturing purposes. The geometry of a 3D feature is defined by sweeping a 2D shape along a guideline, which is variational–geometric and dimension driven. The solid model definition that Duan et al. use is a hybrid B–rep/CSG representation scheme. A unification of form feature definition methods for integrating feature based design, automatic feature recognition and interactive feature identification has been discussed by Sreevalsan and Shah (1991). Features for use in design are written in terms of their generic properties, construction procedures etc.. Feature templates are used to interactively identify features. A set of standard functions is used to synthesize feature recognition algorithms in order to formalize features to be recognized. An interpreted feature language has been developed for expressing both the feature templates and recognition algorithms. Some problems were noted with regard to the unification of the three modes of feature definition. These problems are related to the lack of dynamic interfaces to geometric modelers and the restricted access to the functions and data of geometric modelers. According to Sreevalsan et al., the problems can be alleviated by the use of open architecture geometric modeling kernels like ACISTM.

In recent papers Shah et al. (1994a and 1994b) provide a method of feature definition which is very similar to the one presented in this paper. In their approach, called declarative feature modeling, they apply constraint based feature definition using an adapted form of degrees of freedom analysis by Kramer (1992). The main differences of the current paper with respect to the work by Shah et al. are: – a greater focus on the interactive user interface functionality. – a somewhat different use of degrees of freedom analysis. – the automatic extraction of feature recognition rules.

2.3 Feature recognition literature In the area of feature recognition many papers have been published, dealing with this complex problem. It is beyond the scope of this paper to present a complete and in–depth overview of all possible recognition techniques, developed systems and their problems. In Joshi and Chang (1990) a detailed overview can be found. In this section emphasis is put on the feature intersection problem. Marefat and Kashyap (1990) developed a graph based recognition technique, a modified version of the Attributed Adjacency Graph of Joshi and Chang (1988). Their graph consists of nodes, representing faces, and links representing connecting edges. To deal with intersections, virtual links are introduced. These virtual links are a substitute for edges that have been deleted due to feature–feature intersections. The links are determined by extending faces virtually. Some drawbacks are that their system deals only with polyhedral depressions and allows no interactive feature definition. Vandenbrande and Requicha (1993) make use of two techniques to deal with intersections. First a candidate feature is extended in specified directions, looking for candidate feature faces and non–stock faces. Second, in the feature definition template ’required’ and ’optional’ portions are specified. Interactively defined feature types are not supported, neither for design nor for recognition purposes. Vandenbrande and Requicha (1993) state that they ”do not know how to produce automatically (or even with user assistance) the rules and procedures needed to recognize a new, user–defined feature class”. The latter problem is indeed addressed in this paper. Finger and Safier (1990) use graphs for feature representation. A graph grammar is used for defining features. Feature recognition is based on graph matching. However, features are not defined interactively and they are only defined for feature recognition purposes. Another way to deal with intersections is a volume decomposition approach which has recently been applied by Sakurai and Chin (1994), Shah et al. (1994c) and Tseng and Joshi (1994). In these approaches the volume to be machined is decomposed into delta volumes. Decomposition is followed by a phase that combines the delta volumes again, based on rules. The next step is an association of machining operations to the combined volumes. A major disadvantage of this approach is the limited applicability to the volume removal domain only. For instance sheet metal features, like bends, and injection molding features cannot adequately be recognized. Furthermore it is not clear how properties of the original product model, like roughnesses, screwthreads and tolerances, are ”projected” on the volume to be removed. Kim (1994) and Menon and Kim (1994) use the convex hull method to determine volumes to be removed. This method seems

Design Object Knowledge Design Process Knowledge Process Planning Knowledge Basic Shape Elements Basic Features

Customized Features

Existing Customized Features

Customized hierarchy

Feature hierarchy

Recognition algorithm

FIGURE 9 : BLACK BOX DESCRIPTION OF THE INTERACTIVE FEATURE DEFINITION FUNCTIONALITY. to suffer from the same disadvantages as the decomposition methods mentioned above. Henderson et al. (1994) try to tackle the intersection problem by using neural networks. The system has to learn from a number of examples how to recognize atomic features. In these examples several types of feature interactions should be offered in order to learn the system how to deal adequately with feature interactions. This approach differs from the ”first–time right” feature definition method as advocated in the current paper. 3. DESIGN OF THE INTERACTIVE FEATURE DEFINITION MODULE The Interactive Feature Definition (IFD) module as designed for FROOM has been described by Salomons et al. (1994a) and Salomons (1995a). In the following the feature definition module is addressed for defining features for design (FROOM) and for recognizing features for process planning (PART).

3.1 Problem definition The problem can be defined as the design and implementation of a capability to interactively define features. The requirements to be met are the following: – Interactive form feature definition (as little programming as possible). – Geometry and non–geometry definition (constraints, tolerances, materials etc.). – Definition of the behaviour of the feature (important for feature based design purposes). – The feature definition functionality must provide for relaxation of the feature definition ( to be of use for recognition purposes). – The feature representation should be convertible into the PART FDL and/or a standard format like a STEP format. Apart from these requirements, for implementation sake, it would be desirable to adhere to the FROOM data structures (conceptual graphs) and modeler (ACISTM). Also, it would be desirable if the system would allow extension to the definition of abstract features. In figure 9 the feature definition module is described as a black box. Inputs are the basic shape elements and the basic (standard) features which can be used to define new features. Also, use can be made of existing previously defined features and the feature hierarchy (assuming an object oriented application). The system user has the responsibility to define features that make sense: the features should be of use in either CAD or CAPP applications or both. The system user brings in design object knowledge, design process

knowledge and process planning knowledge which is related to the feature to be defined. Outputs are the newly defined features, an updated feature hierarchy and a feature recognition algorithm.

3.2 Conceptual design of the IFD module During the conceptual design, the black box of figure 9 has been detailed into functional modules. Operating principles have been selected for these sub functions. The decomposition which has been derived in (Salomons, 1995a) is shown in figure 10. Each distinguished sub function is briefly described in the following. 1 Naming: the feature to be defined has to be given a proper name to be able to identify it later. This holds especially for feature based design purposes. Naming includes placing the feature somewhere in the feature hierarchy and thus inheriting properties of the parent feature. 2 Feature element retrieval: features, feature elements and feature hierarchies have to be retrieved from storage. 3 Constraint specification: topology and geometry definition can both be seen as constraint specification. The definitions of topology, constraints and geometry are closely related. Topology describes the number and types of feature elements (faces, edges and vertices) and how they relate to each other. Geometry constraints determine the actual shape, the dimensions. Constraints are regarded as desired relationships between two or more objects. The following geometry and topology constraint types are distinguished: feature internal constraints, feature external constraints and feature tolerance constraints. An example of feature internal and feature external constraints is provided in figure 11. Useful feature internal constraints are: adjacent (convex, concave and tangential), parallel, perpendicular and co–axial (Salomons et al., 1994a). These constraints merely address feature topology. Feature internal constraints, however, also can address feature dimensions (geometry). These are important in order to give the end–users of a feature based design system useful parameters with which they can control feature size. Feature external constraints were addressed in (Sheu and Lin, 1993). These constraints are important for instantiating features and for defining their behaviour. Most often, feature external constraints can only be defined after a significant portion of the geometry and the topology of the feature have been defined. Tolerance constraints (feature internal variational geometry constraints) are also important for the definition of the feature’s default tolerances. These constraints will not be addressed further in this paper

transform to FDL code (10)

Shape elements Basic features Existing features Feature hierarchy

feature presentation (9)

user action

user

feature constraint satisfaction (4)

feature constraint specification (3)

Customized features feature representation (8)

storage (7)

Customized hierarchy Recognition algorithm

solidify (6)

naming (1) user action

auxiliary (5)

feature (element) hierarchy retrieval (2) FIGURE 10 : A FUNCTIONAL DECOMPOSITION OF THE FEATURE DEFINITION FUNCTION.

pocket_rectangular_feature

f.i.e.

f.i.e.

f.e.e.: feature external element f.i.e.: feature internal element

f.i.e.

f.e.e.

FIGURE 11 : FEATURE INTERNAL GEOMETRIC CONSTRAINT (LEFT) AND FEATURE EXTERNAL GEOMETRIC CONSTRAINT (RIGHT) : GEOMETRY IS SHOWN ON TOP WHILE THE CORRESPONDING CONCEPTUAL GRAPH REPRESENTATION IS SHOWN BELOW.

TABLE 1 : MORPHOLOGICAL OVERVIEW RELATED TO THE FEATURE DEFINITION FUNCTIONS IDENTIFIED IN FIGURE 10. A GREY FILLED BOX INDICATE A SELECTED ALTERNATIVE. Working principles

Function Naming & classification

Logical names & classification

Logical names

Feature constraint specification Geometric constraints CAD geometry operations like sketching, extruding etc.

Programming

Non-geometric Textually & algebraicalconstraints ly

Algebraically

Auxiliary specification

Icon

Topological tree & visual Geometry operations & programming (van Emgraph manipulations & merik,1990) identification on a solid

Icon & help text

Icon & help text & affinity relations

Feature constraint satisfaction Geometric constraints DOF method

Simultaneous approach

Non-geometric Simultaneous approach constraints Feature presentation

Lines of code

Graph

Graph & geometry

Feature representation

Conceptual graph

Language (Express)

Shah and Rogers (1988b)

Solidify

Automatic

Interactive

Interactive & automatic

Retrieval

Query database

From files

From RdB & files

Storage

Express format

Conceptual graphs in RdB

Conceptual graphs in RdB & files

Transform to FDL

Interactive

Automatic

as it is part of the tolerance specification functionality of FROOM (Salomons et al., 1995b). 4 Constraint satisfaction: the definition of constraints implies that these have to be satisfied sooner or later. 5 Auxiliary definition: this comprises the definition of all other non–geometry related information such as affinity relations which features may or may not have with other features or components, icons, help texts, manufacturing information etc.. Thus, this functionality is mainly important for feature based design purposes. 6 Solidify: to create a solid model from the feature elements. This is required for feature based design purposes. 7 Storage: to store the defined feature in the proper format. 8 Feature representation: the way all the feature information is stored in the computer memory. 9 Feature presentation: how the feature information is presented to the user. 10 Transform to FDL: transforming the computer internal feature representation into FDL code.

3.2.1 Morphological overview. In this section the selection of alternatives for fulfilling the above functions is explained. The alternatives considered are listed in table 1 (a grey filled box indicates a selected alternative). Conceptual graphs have been selected

Wilson and Pratt (1988)

for the feature representation in the feature definition module. The reasons were the following. First, conceptual graphs allow for a representation that is both relatively easy to understand by humans and can easily be processed by computer (Billo, 1989b). Another reason was the already existing incorporation within FROOM of conceptual graphs for assembly representation (Salomons et al., 1994b). Furthermore, conceptual graphs do not significantly differ from the attributed adjacency graphs and other graphs commonly used for feature representation. The choice for using conceptual graphs has been influenced by its ability to represent the different kinds of feature constraints by means of conceptual relations. Conceptual feature graphs can be used to represent volumetric features, necessary in feature based design, as well as face based features used in PART. Also, they allow for both implicit and explicit feature representations. For the specification of geometric constraints, it has been decided to use sketching and other direct CAD geometry operations like sweeping. In a way this is similar to Duan et al. (1993). In the case of sketching, geometry and topology constraints can be specified easily and quickly. During sketching, the system must automatically make assumptions about the feature internal constraints, intended by the system user. The set of the feature internal constraints can easily be extended. A common aspect of feature internal constraints is that they generally denote associations between faces and faces,

edges and faces, edges and edges etc.. These constraints become part of the conceptual graph: they are represented as conceptual relations. However, it may sometimes be necessary that the system user operates on the conceptual graph directly, e.g. when the system has inferred the wrong constraint or when constraints have to be added or relaxed in order to prevent feature recognition to fail. This can happen when some parts of the feature are missing due to feature intersection. Identification of feature elements on a solid has been perceived as a third method of feature definition. This method may be used advantageously for CAPP when certain features are not recognized automatically. Features can also have algebraic constraints and symbolic constraints, not necessarily relating to geometry. These constraints should also be included. Thus, a constraint editor for relating feature parameters is necessary. The feature external constraints are similar to the feature internal constraints as far as the geometry is concerned. They generally denote face associations and dimensional constraints related to these face associations. Most of the geometry related constraints are designed to be managed in a unified way in FROOM and the feature definition module. This unified geometry constraint management in FROOM is implemented by a combination of degrees of freedom analysis as proposed by Kramer (1992), Liu and Nnaji (1991) and face association domain knowledge, similar to the approach applied to tolerances by Clément and Rivière (1993). This subject is part of FROOM’s constraint management module. Therefore, it will not be elaborated here in detail: the subject of constraint management in FROOM is discussed by Salomons et al. (1995a and 1995c). For the auxiliary feature definition functionality, a number of possibilities were considered. Textual input was considered to be most suitable for the definition of the intent of a feature. Sometimes icons may be required for the identification of the features which are defined. This can be done by deriving icons automatically from the previously defined topology and geometry or by drawing icons manually with some computer tool. Affinity relations can best be selected from a feature hierarchy. Solidification can be performed automatically, using some of the ACISTM functions like moving a face incrementally until it coincides with some edges or by manually selecting the elements of a feature and ”stitching” them together to form a solid. The combination of these two methods was seen as most favourable. The storage of a feature can be performed in a number of ways (see table 1 for alternatives). It has been decided to store the features as conceptual graphs because the graphs provide for a modeler independent feature representation. The use of a relational database for the storage of a conceptual graph seems very suitable. However, most kernel modelers have a file system for storing geometry. Therefore, it has been decided to make use of both a database and a file system. Transformation of the conceptual feature graph into FDL can be performed manually by offering the user pieces of FDL code which can be put together using a software support tool. However, this still requires knowledge of FDL. Thus, a fully automatic transformation of the graph into FDL is the only way to protect the user from programming. Therefore this option was selected, how it works is detailed in section 3.3.5.

3.3 Embodiment and detail design of the IFD module: a session of the IFD module In the following subsections details are given on geometric constraint specification and satisfaction in feature definition, envisaged from a system user perspective. Each subsection focuses on one of three envisaged modes of feature definition: by sketching, graph editing and identification. Special attention is given to the design of the user interface that is to be provided to the system user. Finally, some details on how to apply the graph transformation to FDL are provided.

3.3.1 Defining a feature by sketching. Sketching seems to be the most adequate way to interactively define (implicit as well as explicit) features. Conventional CAD techniques like sweeping could be used in addition to sketching techniques, like in (Duan et al., 1993). Figure 12 shows an example of a user interface that has been designed for feature definition employing a sketching mode. This user interface design was inspired by the existing FROOM user interface, see e.g. (Salomons et al., 1993a and 1993b). The left side of figure 12 shows the work space while the right side shows the corresponding graph which should be inferred automatically from the sketch. The degrees of freedom of the entities in the sketch can be kept up to date by a degrees of freedom approach similar to Kramer (1992) or to Arbab and Wang (1989) who addressed the 2D case.

3.3.2 Defining/modifying a feature by graph editing. If a feature which has been defined by sketching needs some changes or if the sketch facilities are not sufficient, a feature can be defined/ modified by conceptual graph editing. The design of a user interface for this mode of feature definition is shown in figure 13. The work area is the right side of the figure in which graphs can be edited. In the area on the left, geometry is automatically generated, based on the modifications of the graph. The degrees of freedom have to be updated when doing this in order to allow for changing from one mode of feature definition to the other while keeping the underlying feature representation consistent.

3.3.3 Defining a feature by identifying edges and faces from a solid. After automatic feature recognition has been performed, it is possible that not all geometry of a product model has been assigned to manufacturing features. Because there is a complete product model, it makes no sense to define the non–recognized feature(s) from scratch. Therefore, geometric entities which were not assigned to a feature, can be identified interactively by picking their faces, edges etc.. Then a conceptual graph representation of the feature can automatically be derived, making use of routines that are also used for the sketching mode and feature recognition (like detecting convex/concave edges). The graph representation of the feature in turn can subsequently be transformed into the FDL feature recognition language (see for details section 3.3.5). 3.3.4 Feature definition for feature recognition. In this subsection, feature definition will be discussed from a recognition

Feature visualization

Graph

Feature visualization

Graph

Face types planar Relationscylinder. conic ...

ce3

se1

ce1

se3

se2

ce2

Parameters par_1: par_2: FIGURE 12 : DESIGN OF A USER INTERFACE FOR DEFINING A NEW FEATURE BY SKETCHING.

view point. The main question is: is the proposed feature definition suitable for deriving recognition rules ? As a test case, a representative sub set (23 of 60) of the PART features has been used. The PART feature categories are shown in table 2. In brackets the number of features of each subcategory is given, followed by the number of the selected features. It turned out that the proposed conceptual graph is suitable for recognition purposes. However, the following extensions were necessary: – Additional feature internal relationships like: opposite, same surface and neighbour faces. – Additional concept types and attributes like: torus, protrusion, depression, missing, closed and open. For instance, for recognition purposes it might be necessary to know whether a set of faces together form a closed set or to test whether two faces are opposite each other (see also figure 14).

TABLE 2 : FEATURE CATEGORIES AND SUBCATEGORIES USED FOR PART. IN BRACKETS THE NUMBER OF FEATURES OF EACH SUBCATEGORY IS GIVEN, FOLLOWED BY THE NUMBER OF THE SELECTED FEATURES. Category

Subcategory

protrusion

boss ( 7, 2 )

depression

hole ( 5 , 2 ) , pocket ( 8 , 2 ) , slot ( 11 , 5 ) , partial slot ( 6 , 2 ) , corner notch ( 5 , 2 ) , non corner notch ( 3 , 0 ) , side notch ( 4 , 2 ) , inside profile ( 3 , 2 ) , outside profile ( 3 , 1 ) , radial groove ( 1 , 1 ) , axial groove ( 2 , 1 )

slab

surface ( 2 , 1 )

...

pf1

cf1

Parameters par_1: par_2: FIGURE 13 : DESIGN OF A USER INTERFACE FOR DEFINING A NEW FEATURE OR CHANGING AN EXISTING ONE BY GRAPH EDITING. Feature recognition is in fact nothing more than looking for a set of faces which together fulfil certain requirements. The searching process starts with one face, looking for adjacent faces. In PART formerly the adjacent faces were only found when they were connected by an edge, but absence of such an edge, like in figure 8, caused non–recognition. One solution to that problem could be: a new recognition algorithm (= new variant of that feature) for every possible intersection. However, this results in a combinatorial explosion of the number of variants. The solution must be found in a relaxation of the feature definition, in such a way that on the one– hand the intersections will not cause non–recognition anymore, but on the other hand the definition should still be meaningful, i.e. it should be avoided that all faces of a model are assigned to all features! To deal with deleted edges recognition on edge level should be avoided. Adjacent faces should not be found by means of connecting edges. Therefore, a ”neighbourhood” relation is introduced which checks the normals of and distances between faces. This neighbourhood relation is represented in the graphs by the symbol . This technique can be seen as an equivalent of the virtual links of Marefat and Kashyap (1990). However, the determination of their virtual links is hard coded, the neighbourhood relation presented here can be influenced by the system user. While defining a feature the system user can specify what is ”in the neighbourhood”, as an attribute of a neighbourhood relation. In the presented interactive feature definition module it is not only possible to deal with missing edges but in principle it is possible to deal with ”missing faces” as well, see figure 15. 3.3.5 Transforming the conceptual graph into FDL code. Transformation of the graph into FDL can be performed automatically. The only user action required is to start the transformation process. In general the transformation from one ”representation” (conceptual graph) into another ”representation” (FDL) is influenced by the characteristics of both. The conceptual graph is a widely known representation but FDL is a proprietary language and therefore it is

⁄⁄ ↔

pf3

Slot rectangular

pf4

L l

⁄⁄

ă

ă

⁄⁄

O d

⁄⁄

cf2 depr

w D

⁄⁄

pf1

cf5 depr

Pocket free shaped straight

D

L O

pf1

ă

⁄⁄ : parallel ↔ : opposite ă : perpendicular : neighbour

pcf2

closed depression

pf1 : planar face 1 cf1 : cylindrical face 1 pcf1 : set of planar and cylindrical faces

FIGURE 14 : EXAMPLES OF MANUFACTURING FEATURE DEFINITIONS

obvious that no ready–made solutions (= conversions) were available in literature. Determination of general rules on which the transformation has to be based, has been the first step towards automatic transformation. A representative sub set of PART features (regular shaped, like pocket rectangular, slots rectangular and corner notch, as well as free shaped, like hole free shaped) have been transformed in FDL manually. During this process, rules which are generally applicable have been determined. The general validity of the rules can be verified after testing in practice and can be adapted if necessary. Transformation rules : 1. transform the graph concept by concept: per concept, the attributes and relations with other concepts are determined. In this way per concept a block of FDL code is generated. Each concept has a unique concept ID. Code generation starts from the concept with the highest ID to the concept with the lowest ID. 2. the generated blocks are merged together in the final recognition program, which has a nested structure. See also figure 16 for an example. Redundant code (like a double check whether face 1 is perpendicular to face 2 and face 2 is perpendicular to face 1) is avoided by making the contents of each subroutine dependent on the order of the concept IDs: when generating sub routine 3, the contents of sub routine 4 are already known. Concept IDs and their sequence seem therefore important because they influence the FDL code. However, they do not influence the recognition results. In case of two identical graphs which only differ in the concept IDs, two different FDL recognition algorithms will be generated, but these two will both recognize the same features. This is due to a different nesting of different sub routines.

4. IMPLEMENTATION OF THE INTERACTIVE FEATURE DEFINITION MODULE In the feature definition module, both the concepts and the conceptual relations of the conceptual graphs have been programmed as C++ objects. The concepts which have currently been implemented as part of the interactive feature definition module are planar face, cylindrical face and conical face. For each of these concepts, a class definition has been programmed from which the system user can create his own instances. This also holds for the relations: currently implemented relations are adjacent (convex, concave or tangential are attributes of the relation), perpendicular, parallel and co–axial. Because these relations can associate different concept types, e.g. planar face adjacent to planar face or planar face adjacent to cylindrical face, many different conceptual relations have to be implemented. Presently, only the most common relations have been implemented in the prototype. Similar to the concepts, the relation objects contain attributes and methods. The methods of the relation objects are able to instantiate relations and to delete them. They are also used for updating the degrees of freedom of the concepts which are part of the association. The conceptual graphs are stored in a relational database (OracleTM). The ACISTM modeler stores its models in files. Therefore, the features which have been defined in the interactive feature definition module are stored in a hybrid way using both a database (for the modeler independent conceptual graphs) and the files that contain the modeler dependent geometric information. Figure 17 gives an example of the user interface that has been realized for the graph editing mode of feature definition, according to the design shown in figure 13. Figure 17 shows how features can currently interactively be defined by the system user. This is done

cf5 depr

cf3 depr

⁄⁄

pf4

⁄⁄

⁄⁄

ă

ă

ă

ă

pf1

ă

pf6

ă

ă

ă

⁄⁄

pf8

⁄⁄

cf7 depr

pf2

⁄⁄ cf9 depr

⁄⁄

⁄⁄

FIGURE 15 : EXAMPLE OF CONCEPTUAL GRAPH REPRESENTATION OF A POCKET RECTANGULAR FEATURE OF WHICH A FACE (CF5) IS ALLOWED TO BE MISSING. by defining a conceptual graph representing the feature. The user instantaneously gets sample geometry in the geometry window. This is considered to be very important because system users usually will have geometry in their mind of which the graph is an abstraction. At the moment it is possible to define relatively simple features (like a pocket rectangular straight) within a few minutes using the graph editing approach. Using a sketching mode of feature definition, the time needed to define a feature could be reduced further. Note from figure 17 that the pocket feature has been defined redundantly: pf#2 (planar face no. 2) is perpendicular to pf#3 which is perpendicular to pf#4, which is the same as pf#2 being parallel to pf#4. The reason why redundant feature definitions are allowed, is that in case of recognizing a feature based on a redundant feature definition, also possible intersections should be taken into account. In case of intersections, one or more of the feature’s faces could become deleted as a result of which the previously redundant relations may be required in order to unambiguously define (recognize) the intersected feature. The top and bottom faces of the pocket are not shown in the conceptual graph of figure 17. Currently, a first implementation of a 2D sketcher for feature definition has been developed (Heikens, 1994). Linear sweeps can be applied subsequently similar to Duan et al. (1993). Apart from a degrees of freedom approach for handling the geometric constraints, the sketcher provides for ”points of interest” in combination with

snap dragging as originally proposed in (Bier, 1988). Feature definition by identification of faces, edges etc. is under development. At the moment only graphs of regularly shaped features can be converted completely automatically to FDL code. The computer internal representation of a graph is parsed by a routine which directly fills a file with FDL code. That file is further processed by the existing FDL to C++ converter of PART. Finally the C++ code is compiled and linked to generate an executable. The conversion into FDL is performed within seconds. The most important extensions to the syntax of FDL as presented by van Houten (1989) are the addition of the ”FOR_GOTO” and ”END_FOR_GOTO” statements to deal with the automatically generated FDL code and statements to extract tolerances, roughnesses and screwthreads from the product model. Furthermore, some additional geometric reasoning functionality has been implemented, like: – the ”Find_neighbour_face” function in figure 16. – functions to check whether a set of faces is a ”closed” or an ”open” set. – functions to check whether a set of faces is ”opposite” another set of faces. Future extensions will have to be made to the available concepts. For instance, the 7 elementary face types as identified by Clément and Rivière (1993) should be supported. The definition of free shaped features (complex sweeps, ruled surfaces etc.) and abstract features will have to be accounted for as well. One of the main difficulties of defining geometrically complex features is that they often depend on some piece of geometry that should be created by the end–user prior to instantiating the feature. This means that feature geometry is not known at the time of feature definition. Linear sweeps are already used in the sketching mode for features which do not suffer from this problem. By supporting complex sweeps and defining rules (if..then) in combination with (complex) parameter dependencies, the present feature definition capabilities can be extended in order to comply with the problem of complex feature geometry. The conceptual graphs and DOF analysis seem well applicable for these extensions. The mechanism of managing the feature internal and external constraints also has not been fully implemented yet due to the large effort involved. In order to reduce this, work is currently being performed in interactively defining geometric constraints similar to interactively defining features.

5. CONCLUSIONS AND RECOMMENDATIONS This paper has focussed on the interactive feature definition module which supports both feature based design of the FROOM system as well as feature recognition in the PART process planning system. The feature definition is based on a conceptual graph representation of features. The feature definition module allows for the definition of features based on sketching and graph editing. Also the identification of faces on a product model is an option, which is particularly suitable for CAPP systems (in order to be able to define features that have to be recognized). By these modes, constraints can be specified that both support the feature based design requirements (feature behaviour during instantiation and modification) and feature recognition requirements (relaxed feature definition to deal with feature intersections). Feature recognition algorithms can be generated au-

ă

pf2

Corner notch rectangular

⁄⁄ cf3 depr

D O

pf4 ⁄⁄ ă

ă

l

ă d w

pf1

L

ã pf4 :

cf3 :

subroutine_4 :

subroutine_3 :

Plane_surface (F4)

Cylindrical_surface (F3)

F4_nbf = Find_neighbour_faces ( F4 , all_faces , dist )

F3_nbf = Find_neighbour_faces ( F3 , all_faces , dist )

In_both_lists ( F4_nbf , F1 )

In_both_lists ( F3_nbf , F1 )

Find_perpendicular ( F4 , F1)

Find_perpendicular ( F3 , F1)

Find_perpendicular ( F4 , F2)

In_both_lists ( F3_nbf , F2 )

Find_parallel ( F4 , F3)

Find_parallel ( F3 , F2)

In_both_lists ( F4_nbf , F3 )

In_both_lists ( F3 , F2_nbf )

In_both_lists ( F4 , F1_nbf )

In_both_lists ( F3 , F1_nbf )

In_both_lists ( F4 , F3_nbf ) RETURN (F1+F2+F3+F4) RECOGNIZED

FOR_GOTO F4 = F3_nbf DO

pf2 :

subroutine_4

subroutine_2 :

END_FOR_GOTO

Plane_surface (F2)

F2_nbf = Find_neighbour_faces ( F2 , all_faces , dist ) In_both_lists ( F2_nbf , F1 ) Find_perpendicular ( F2 , F1) In_both_lists ( F2 , F1_nbf ) FOR_GOTO F3 = F2_nbf DO

pf1 : subroutine_1 : Plane_surface (F1)

subroutine_3 END_FOR_GOTO

subroutine_0 : PATTERN ’feature_name’ ( ’feature_number’ ) : FOR F1 = Faces_of ( model ) DO

F1_nbf = Find_neighbour_faces ( F1 , all_faces , dist)

VARIANT 1 :

FOR_GOTO F2 = F1_nbf DO

all_faces = Faces_of ( model )

subroutine_2 END_FOR_GOTO

subroutine_1 END_FOR END_PATTERN

FIGURE 16 : EXAMPLE OF TRANSFORMATION OF THE CONCEPTUAL GRAPH INTO FDL: PER CONCEPT A SUBROUTINE IS GENERATED REGARDING ITS ATTRIBUTES AND RELATIONS WITH OTHER CONCEPTS. THE FDL BLOCKS ARE MERGED FINALLY IN SUBROUTINE_0 WHICH REPRESENTS A VALID RECOGNITION ALGORITHM. tomatically based on the feature representation. The present implementation includes the graph editing mode of feature definition in combination with the sketching mode. In the future several extensions to the presented feature definition module might be required, such as the definition of geometrically more complex features. ACKNOWLEDGEMENTS This research is supported by the Technology Foundation (STW: a Dutch foundation sponsoring technical research).

REFERENCES Arbab, F., and Wang, B., 1989, ”A constraint–based design system based on operational transformation planning”, Proceedings, 4th. International Conference on Applications of Artificial Intelligence, J. Gero, ed., Springer Verlag, pp. 405–426. Bier, E., 1988, ”Snap dragging”, Technical report, no. csd–88–416, University of Berkeley, Available on: http://cs– tr.cs.berkeley.edu/TR/UCB:CSD–88–416.

FIGURE 17 : FEATURE DEFINITION EMPLOYING GRAPH EDITING. Billo, R.E., Henderson, M.R., and Rucker, R., 1989a, ”Applying conceptual graph inferencing to feature–based engineering analysis”, Computers in Industry, Vol. 13, pp. 195–214. Billo, R.E., 1989b, ”An object–oriented modeling methodology utilizing conceptual graphs for form feature definition”, Ph.D. Thesis, Arizona State University. Butterfield, W.R., Green, M.K., Scott, D.C., and Stoker, W.J., 1986, ”Part Features for Process Planning”, CAM–I Report R–86–PPP–01, CAM–I, Arlington, TX. Choi, B.K., Barash, M.M., and Andersson, D.C., 1984, ”Automatic recognition of machined surfaces from a 3–D solid model”, Computer–Aided Design, Vol.16, No. 2, pp. 81–86. Clément, A., and Rivière, A., 1993, ”Tolerancing versus nominal modelling in next generation CAD/CAM system”, Proceedings, CIRP Seminar on Computer Aided Tolerancing, ENS de Cachan, Paris, pp. 97 – 113. Duan, W., Zhou, J., and Lai, K., 1993, ”FSMT: a solid modelling tool for feature–based design and manufacture”, Computer–Aided Design, Vol. 25, No. 1, pp. 29 – 38. Emmerik, M.J.G.M. van, 1990, ”Interactive design of parameterized 3D models by direct manipulation”, Ph.D. Thesis, Delft University (NL). Erve, A.H. van ’t, 1988, ”Computer aided process planning for part manufacturing, an expert system approach”, Ph.D. Thesis, University of Twente, Enschede (NL). Finger, S. and Safier, A., 1990, ”Representing and recognizing features in mechanical designs”, Proceedings, Second international conference on design theory and methodology DTM ’90, Chicago, pp. 1–14. Fu, Z., De Pennington, A., and Saia, A., 1993, ”A graph grammar approach to feature representation and transformation”, Interna-

tional Journal of Computer Integrated Manufacturing, Vol.6, No.1, pp. 137–151. Heikens, E.J., 1994, ”FROOM 2D Sketcher”, BS report, Internal report PT 517. University of Twente, Mechanical Engineering Dept.. Henderson, M., Srinath, G., Stage, R., Walker, K., and Regli, W., 1994, ”Boundary representation–based feature identification”, Advances in Feature Based Manufacturing, J.J. Shah, M. Mäntylä, D.Nau, eds., Elsevier, pp. 15–39. Houten, F.J.A.M. van, Erve, A.H. van ’t, and Kals, H.J.J., 1989, ”PART, a feature based computer aided process planning system”, Proceedings, 21st. CIRP international seminar on manufacturing systems, Stockholm Houten, F.J.A.M. van, Erve, A.H. van ’t, Boogert, R.M., Nauta, J.,and Kals, H.J.J., 1990, ”PART, selection of methods and tools”, Proceedings, 22nd. CIRP international seminar on manufacturing systems, Enschede, NL. Houten, F.J.A.M van, 1991, ”PART, a computer aided process planning system”, Ph.D. Thesis, University of Twente, Enschede (NL). Hummel, K.E., and Brown, C.W., 1989, ”The role of feature in the implementation of concurrent product and process design”, Proceedings, ASME winter meeting, San Francisco, pp. 1–9. Joshi, S., and Chang, T.C., 1988, ”Graph–based heuristics for recognition of machined features from a 3–d solid model”, Computer–Aided Design, Vol.20, No. 2, pp. 58–64. Joshi, S., and Chang, T.C., 1990, ”Feature extraction and feature based design approaches in the development of design interface for process planning”, Journal of Intelligent Manufacturing, Vol.1, pp. 1–15.

Kim, Y., 1994, ”Volumetric feature recognition using convex decomposition”, Advances in Feature Based Manufacturing, J.J. Shah, M. Mäntylä, D.Nau, eds., Elsevier, pp. 39–65. Kramer, G., 1992, ”Solving Geometric Constraint Systems, a case study in kinematics”, The MIT Press, Cambridge, Massachussetts, London, England. Krause, F.–L., Kramer, S., and Rieger, E., 1991a, ”PDGL: A language for efficient feature–based product gestaltung”, Annals of the CIRP, Vol. 40, No. 1, pp. 135–138. Krause, F–L, Ulbrich, A., and Vosgerau, F., 1991b, ”Feature based approach for the integration of design and process planning systems”, Product Modelling for Computer–Aided Design and Manufacturing, J.Turner, J.Pegna, M.Wozny, eds., Elsevier Science Publishers B.V.(North Holland), pp. 285 – 297. Kyprianou, L., 1980, ”Shape classification in computer aided design”, Ph.D. Thesis, University of Cambridge. Laakko, T., and Mäntylä, M., 1992, ”Feature–based modelling of families of machined parts”, Human aspects in computer integrated manufacturing, G.J. Olling, F. Kimura, eds., PROLAMAT ’92, pp. 351 – 360. Liu, H–C., and Nnaji, B.O., 1991, ”Design with spatial relations”, Journal of Manufacturing Systems, Vol.10, No. 6, pp. 449–463. Marefat, M., Kashyap, R.L., 1990, ”Geometric reasoning for recognition of three–dimensional object features”, IEEE transactions on pattern analysis and machine inteligence, Vol. 12, No 10, pp. 949–965. Menon, S. and Kim, Y.S., 1994, ”Cylindrical Features in Form Feature Recognition Using Convex Decomposition”, Proceedings, IFIP WG 5.3 Conference on Feature Modeling and recognition in advanced CAD/CAM systems, Valenciennes (F), Vol.1, pp. 295–314. Pratt, M.J., 1988, Synthesis of an optimal approach to form feature modelling, Proceedings, Computers in Engineering Conference, pp. 263–273. Pratt, M.J., 1990, ”A hybrid feature based modelling system”, Advanced geometric modelling for engineering applications, F.L.Krause, H.Jansen, eds., Elsevier Science Publishers, pp. 189–210. Sakurai, H., and Chin, C.–W., 1994, ”Definition and recognition of volume features for process planning”, Advances in Feature Based Manufacturing, J.J. Shah, M. Mäntylä, D.Nau, eds., Elsevier, pp. 65–80. Salomons, O.W., Houten, F.J.A.M. van, and Kals, H.J.J., 1993a, ”Review of research in feature–based design”, Journal of Manufacturing Systems, Vol.12, No.2, pp. 113–132. Salomons, O.W., Slooten, F. van, and Houten, F.J.A.M. van, and Kals, H.J.J., 1993b, ”Observations from redesign and process planning practice, a study of human practice aimed at improving feature based CAD/CAPP”, Proceedings, MICAD, Vol. 1, Paris, pp. 115–129. Salomons, O.W., Jonker, H.G., Slooten, F. van, Houten, F.J.A.M. van, and Kals, H.J.J., 1994a, ”Interactive feature definition”, Proceedings, Conference on Feature modeling and recognition in advanced CAD/CAM systems, IFIP WG 5.3, Valenciennes (F), Vol. 1, pp. 181–204, available on http://utwpue.wb.utwente.nl/stw–doc/ papers/paper–ifd.ps. Salomons, O.W., Slooten, F. van, Koning, G.W.F. de, Houten,

F.J.A.M. van, and Kals, H.J.J., 1994b, ”Conceptual graphs in CAD”, CIRP Annals, Vol. 43, No.1, pp. 125–128. Salomons, O.W., 1995a, ”Computer support in the design of mechanical products, constraint specification and satisfaction in feature based design for manufacturing”, Ph.D. Thesis, University of Twente, Enschede (NL). Salomons, O.W., Jonge Poerink, H.J., Slooten, F. van, Houten, F.J.A.M. van, and Kals, H.J.J., 1995b, ”A computer aided tolerancing tool based on kinematic analogies”, Proceedings, CIRP seminar on computer aided tolerancing, Tokyo, pp. 53–72 (and to be published by Chapman & Hall) Salomons, O.W., Slooten, F. van, Houten, F.J.A.M. van, and Kals, H.J.J., 1995c, ”Conceptual graphs in constraint based re–design”, Proceedings, ACM solid modelling conf., Salt Lake City. Shah, J.J., and Rogers, M.T., 1988, ”Expert form feature modelling shell”, Computer–Aided Design, Vol. 20, No.9, p. 515–524. Shah, J.J., 1990, ”Philosophical development of form feature concept”, CAM–I report P–90–PM–02, pp. 55–70. Shah, J.J., Balakrishnan, G., Rogers, M.T., and Urban, S.D., 1994a, ”Comparative study of procedural and declarative feature based geometric modeling”, Proceedings, Conference on Feature modeling and recognition in advanced CAD/CAM systems, IFIP WG 5.3, Valenciennes (F), Vol. 2, pp. 647–671. Shah, J.J., Ali, A., and Rogers, M.T., 1994b, ”Investigation of declarative feature modelling”, Proceedings, ASME Computers in Engineering Conference (CIE’94), Vol.1, pp. 1–12. Shah, J.J., Shen, Y. and Shirur, A., 1994c, ”Determination of machining volumes from extensible sets of design features”, Advances in Feature Based Manufacturing, J.J. Shah, M. Mäntylä, D.Nau, eds., Elsevier, pp. 129–157. Sheu, L–C., and Lin, J.T., 1993, ”Representation scheme for defining and operating form features”, Computer–Aided Design, Vol. 25, No. 6, pp. 333–347. Sowa, J.F., 1984, ”Conceptual Structures, information processing in mind and machine”, Addison–Wesley Publishing Company. Sreevalsan, P.C., and Shah, J.J, 1991, ”Unification of form feature definition methods”, IFIP WG 5.2 workshop on Intelligent CAD, Columbus, Ohio. Tseng, Y–J. and Joshi, S.B., 1994, ”Recognizing multiple interpretations of interacting machining features”, Computer–Aided Design, Vol. 26, No. 9, pp. 667–688. Vandenbrande, J.H., Requicha, A.A.G., 1993, ”Spatial reasoning for the automatic recognition of machinable features in solid models”, IEEE transactions on pattern analysis and machine inteligence, Vol. 15, No 12, pp. 1269–1285. Vries, de J., Vin, de L.J., Streppel, A.H. and Kals, H.J.J., 1995, ”The use of incomplete geometry in sheet metal part manufacturing”, Proceedings, 27th CIRP international seminar on manufacturing systems, Ann Arbor, MI (and to be published in Manufacturing Systems 1996, J. Peklenik, ed.) Wang, N., and Ozsoy, T.M., 1991, ”A scheme to represent features, dimensions and tolerances in geometric modelling”, Journal of Manufacturing Systems, Vol. 10, No.3, pp. 233–240. Wilson, P.R. and Pratt, M.J., 1988, ”A taxonomy of form features for solid modeling”, Geometric modeling for CAD applications, M.J. Wozny, H.W. McLaughlin, eds., Elsevier Science Plublishers B.V. (North Holland), pp. 125–135.