Feature conversion for concurrent engineering

(1)

Feature Conversion

for

(2)

Advanced School for Computing and Imaging

This work was carried out in graduate school ASCI. ASCI dissertation series number 21.

(3)

Feature Conversion

for

Concurrent Engineering

PROEFSCHRIFT

ter verkrijging van de graad van doctor aan de Technische Universiteit Delft

op gezag van de Rector Magniﬁcus Prof.dr.ir. J. Blaauwendraad in het openbaar te verdedigen ten overstaan van een commissie,

door het College voor Promoties aangewezen, op dinsdag 20 januari 1998 om 16:00 uur

door

Jannis Klaas DE KRAKER informatica ingenieur geboren te Egmond-Binnen

(4)

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without permission from the author.

(5)

Dit proefschrift is goedgekeurd door de promotor: Prof.dr.ir. F.W. Jansen

Toegevoegd promotor: Dr. W.F. Bronsvoort

Samenstelling promotiecommissie: Rector Magniﬁcus, voorzitter

Prof.dr.ir. F.W. Jansen, Technische Universiteit Delft, promotor

Dr. W.F. Bronsvoort, Technische Universiteit Delft, toegevoegd promotor Prof.dr. W. Gerhardt, Technische Universiteit Delft

Prof.dr. I. Horváth, Technische Universiteit Delft Prof.dr. B. Brüderlin, Technische Universität Ilmenau Dr.ir. F.J.A.M. van Houten, Universiteit Twente

Dr. M.J. Pratt, Rensselaer Polytechnic Institute en National Institute of Standards and Technology

(6)

(7)

Preface

I carried out the research described in this thesis at the Laboratory of the Computer Graphics and CAD/CAM group of Delft University of Technology. It was supported by the Netherlands Computer Science Research Founda-tion (SION), with ﬁnancial support from the Netherlands OrganizaFounda-tion for Scientiﬁc Research (NWO).

My promotors, Erik Jansen and Wim Bronsvoort, initiated a series of PhD research projects in our group that exploit the emerging area of fea-ture modeling. Winfried van Holland was the first PhD student in this series; he focused on assembly features. I carried out my project in cooperation with Maurice Dohmen, who focused on constraint-based feature validation. Our projects were the first focusing on form feature modeling techniques for concurrent engineering. As such, we were the first PhD students who researched multiple-view feature modeling, for which we created a com-pletely new system. Recently, we handed over the torch to Rafael Bidarra and Alex Noort, who are continuing the series of feature modeling research.

My experiences of the work of a PhD student is best described by a propo-sition from K.E. Shahroudi: “To work with pleasure, an unprejudiced mind,

. . . , to experience the excitement of a discovery, happy are those who can live like this.”, see also [Herbergs 1995]. Working as a PhD student gave

me the opportunity to explore an interesting research area, and to develop myself both personally and intellectually. The work was challenging, and obtaining my results was rewarding.

(8)

Since the work was challenging, it was sometimes also hard. One thing in particular got my mind off work: sports. I love to play basketball, and also the lunch time ’soccer’ with my fellow PhD students worked off frus-trations and stress, providing a good balance.

Many people of the Computer Graphics & CAD/CAM group have con-tributed in a variety of ways to my research. I wish to thank them all for their contributions. In particular, I would like to mention a few of them with whom I closely cooperated.

With Maurice Dohmen, I have a special relation that combines personal and professional life. Professionally, he always was a sparring partner for me being of great help in generating and evaluating ideas. Our close coop-eration began with the ﬁrst ideas for the design of Spiff, and has now come to an end after we have proofread each other’s thesis.

I am thankful to my supervisor Wim Bronsvoort, with whom I have had many discussions. His ideas, comments, and guidance were a crucial factor in the success of the research.

I also want to thank the other members of the feature modeling research group for their input and cooperation: my fellow PhD students Alex Noort, Rafael Bidarra, and Winfried van Holland; technical staff members Aadjan van der Helm, Kees Seebregts, and Peter Kailuhu; and master’s students Arnout Kuiper, Bart Vergouwe, and Jan Wouter Versluis.

Also thanks to my other colleagues who provided a pleasant working environment: my fellow PhD students Andrea Hin, Ari Sadarjoen, Arjan Kok, Erik Reinhard, Freek Reinders, Theo van Walsum, and Wim de Leeuw; my room mates Bart Netten and Robert van Vark; and—last but not least— the secretaries Coby Bouwer and Toos Brussee.

Finally, I want to express my thankfulness to my friends and family for their support in various ways, particularly to Jacqueline.

Klaas Jan de Kraker Delft, November 1997

(9)

1

Introduction

Product modeling used to be performed with technical drawings made with pen and paper. Later, these 2D drawings were made on computers. Cur-rently, the use of 3D geometric modeling software is widely spread.

Also product development in general has evolved. Contemporary prod-uct development requires dealing with resources economically, while aim-ing at higher quality products. 3D geometric models are not sufﬁcient in today’s product development practice, because they lack functional product information.

This research investigates possibilities and develops techniques, using so-called features, to represent and use this functional information.

1.1 Product modeling and concurrent

engineer-ing

Product modeling is the process of creating a computer representation of an industrial product in a sequence of modeling steps. In this way, a product model is built and modiﬁed. Most often, only geometric product information is represented. However, for capturing the semantics of a product, also functional product information is required. This may either be the function for the user of some part of the product, or information about the way it is manufactured or assembled.

(12)

Features have been proposed to also represent this functional

prod-uct information. For that purpose, features incorporate geometry and con-straints which are validated throughout the modeling process. In current implementations, however, features are mostly macros for geometric mod-eling operations. They have not yet matured as a representation of func-tional information. In particular, if a product model is modiﬁed, feature intersections may change and consequently features are easily corrupted, e.g. a feature may be absorbed by a larger feature.

Another aspect of product development is concurrency. In concur-rent product development, diffeconcur-rent engineering disciplines simultaneously work on the development of a product. They perform all kinds of analysis and make product enhancements while functional aspects of other disci-plines must be preserved.

Combining feature-based product modeling and concurrent product de-velopment, functional product information can be represented and main-tained. In such an advanced concurrent engineering environment, each engineering discipline is represented by a view that contains the features relevant for that discipline. A modeling system that implements an ad-vanced concurrent engineering environment is an important step towards integrated product development.

1.2 Research objectives

The main research objective is to develop a new product model for multiple-view feature modeling. For maintaining this product model, a feature con-version method will be developed that enables communication between different views and maintains data consistency when the product is modi-ﬁed. It should be a generic method allowing extensions.

As part of the product model, new techniques for feature validity speci-ﬁcation and maintenance will be developed.

The last objective is to develop a prototype modeling system demon-strating the research results.

The research has been performed in close cooperation with Maurice Dohmen, who focuses on constraint-based feature validation [Dohmen 1997], which involves simultaneous maintenance of constraints from dif-ferent domains.

(13)

1.3 Thesis outline

The remainder of this thesis is organized as follows. The ﬁrst two chapters provide background information about feature modeling and concurrent engineering. Chapter 2 elaborates the need for features and which infor-mation is represented in several types of features. Furthermore, it presents ways for obtaining features, and discusses feature validation issues. Chap-ter 3 presents how product development can beneﬁt from using features, reducing time-to-market and increasing product quality. For such product modeling, it presents functional requirements and requirements for a system architecture.

Chapter 4 presents a new approach to feature modeling for concur-rent engineering. It combines concepts from the previous two background chapters, resulting in the new multiple-view feature conversion approach. It provides an overview of the product model and its functionality, including multiple-way feature conversion, which is elaborated in later chapters using illustrative examples.

Chapter 5 presents one part of the product model, the representation of the product geometry. It presents the data structure for this newly de-veloped cellular geometry representation, and presents maintenance and query functions illustrating its use.

Chapters 6 and 7 elaborate the main functional parts of multiple-view feature conversion, presenting detailed descriptions of newly developed feature conversion techniques. They describe how different views are de-rived and how multiple views are maintained.

Chapter 8 presents an example modeling session with our multiple-view modeling system. Using extended examples, it demonstrates the concepts presented in earlier chapters.

Finally, Chapter 9 draws conclusions on the work presented, and indi-cates directions for future research.

(14)

(15)

2

Feature modeling

This chapter introduces the basic concepts of feature modeling. It ﬁrst mo-tivates the need for features, and discusses several feature types according to their abstraction level. Following, it discusses the relatively new but im-portant issue of feature validation. Lastly, it presents the three traditional techniques to obtain features in a model.

2.1 Motivation for features

Over the last decade, geometric modeling techniques have been greatly improved, so that it is currently possible to represent very complexobjects with geometric models. It is also possible to create, edit, and display such models. Thus with respect to geometric modeling capabilities, a great deal of functionality has been accomplished. So, why do we need features at all? Before answering this question, let us first give a definition of features to define what we are talking about. In the past, a lot of effort has been put into making a good feature definition, see for example [Bronsvoort and Jansen 1993]. For now, we comply to the application-independent and general definition of Wilson and Pratt [1988] by defining a feature as “a

region of interest in a part model ”.

Returning to the above question, from [Shah and M¨antyl¨a 1995] argu-ments can be extracted on why geometric models are not suitable for de-signing products, and why features are needed.

(16)

The ﬁrst is that geometric models do not store design intent. They do not represent why the geometry is as it is. Such information is required, for example, to make redesign effective. Redesign creates a new product based on an existing design. For example, Ilies and Shapiro [1997] have done a case study on the redesign of an automotive hood latch. It appeared that it was neither stored nor known by anyone why certain geometry was there. It even seemed to be nonfunctional, whereas it accounted for a large part of the production costs. In the same philosophy, Lahti et al. [1997] argue for capturing and deploying design decisions, for which they do a ﬁrst proposal.

Furthermore, construction of geometric models can be tedious. Model-ing primitives are often of a low level (points, lines, and planes) and do not match the designer’s way of thinking.

Another important argument is that partial specification of product ge-ometry is desirable. Different design phases, such as conceptual and func-tional design, each specify part of the product geometry. For example, conceptual design assigns a global structure to the product geometry, and functional design only needs to specify parts of the product geometry that satisfy certain functional demands. It is advised to leave geometry that does not need to be specified unspecified or vague. This is called design by least commitment [Mäntylä 1989]. Details can be added later, possibly even by the manufacturing or assembly process planning engineers. For example, a designer may globally specify a connection between two components, e.g. a rigid connection, and it may be left to the assembly engineer to choose the actual connection, e.g. glue or snap-fit. The problem of geometric models here is thus that they always have to be fully specified.

Geometric models only represent one ideal product instance, and do not easily incorporate tolerances, which are essential for manufacturing. Toler-ances are required to ensure that a part is functional, and manufacturable and assemblable at reasonable cost. Tolerancing consists of specification, allocation, and analysis. Instances of different tolerance classes can be spec-ified, e.g. tolerances on size or dimension, orientation, position, and form. Examples of tolerances on the form of faces are flatness and cylindricity. Once allowed tolerance values have been allocated, they can be analyzed on their consequences. Tolerance analysis is still an area of research, see for example [Turner 1990, Inui et al. 1995].

Features can overcome these problems. They are parameterized objects that represent design intent. Therefore, they can be changed easily and quickly while keeping the design intent. Furthermore, features may specify partial geometry, and may include tolerances.

(17)

2.2 Feature types

Features have been designated as elements that link and integrate dif-ferent applications such as design and manufacturing. However, this is not straightforward as is shown later in this chapter.

We summarize the answer, on why we need features, by saying that geo-metric models have shortcomings for designing and representing products, and that besides geometric information, it is needed to store functional product information. This functional information can be incorporated in features.

2.2 Feature types

A large variety of features exists, and therefore some classiﬁcation is desired. Features can be classiﬁed according to two orthogonal criteria, namely the application in which the features are used and the abstraction level of the features.

Applications, such as design, strength analysis, manufacturing, and as-sembly each have their own type of features. For example, design features represent intended product functionality, engineering analysis features rep-resent a product idealization, manufacturing features reprep-resent manufac-turing process information, and assembly features, see [van Holland 1997], represent handling and connection information.

The abstraction level of a feature is deﬁned as the extent to which the feature represents concrete geometry. For example, a conceptual design feature that represents concepts or functions, is of a higher abstraction level than, for example, a round feature on an edge that represents actual geom-etry.

Most of the examples of features given above are highly application spe-cific, and of a high abstraction level. A type of feature that is less application specific, and can be used in most applications, is the form feature. Many different definitions of form features have been proposed, of which repre-sentative ones have been summarized by Bronsvoort and Jansen [1993]. It is now more or less agreed upon that a form feature represents a physical part of an object that is mappable to a generic shape and has functional sig-nificance. Examples of form features are protrusions, holes, slots, pockets, and chamfers, see Figure 2.1 on the following page. Form features are of a moderate abstraction level, because they have functional significance, and have a predefined parameterized shape. Form features can be regarded as a layer over geometry, on top of which more application-specific features can be specified. In that case, form features are used as a basis to define more

(18)

slot

chamfer

pocket protrusion

thru hole

Figure 2.1: Examples of form features.

application-speciﬁc features [Bronsvoort et al. 1996]. This thesis focuses on form features.

Form feature modeling can be considered as a follow-up to parametric modeling. In parametric modeling, geometric objects are characterized by a number of parameters. For example, a block can be characterized by its length, width, and height, and a cylinder by its radius and height. Such objects are called parameterized objects. They have a generic description of which an instance can be created by specifying its parameters.

Form features are parameterized objects that, besides geometric informa-tion, store functional information as well. Part of this functional information is represented by the feature geometry. For example, a screw hole part of a connection requires to have a cylindrical shape to be functional. Other func-tional information can be represented in constraints. A constraint speciﬁes a relation within or between entities that must be maintained. Constraints act on form feature topology elements, or feature elements, and/or form feature parameters. A feature element is a feature volume, face, edge, or vertex. Various types of constraints can be thought of for use in feature modeling. A simple type is a constraint that puts a limit to a parameter value, which is often restricted to be in some range to be meaningful. An-other type is a constraint that speciﬁes how a feature can be attached to a model, for example a drilled hole is often restricted to be orthogonally positioned with respect to its entrance face. Also more complexconstraint types can be thought of, for example constraints that specify accessibility conditions for manufacturing and assembly purposes. Summarizing, form

(19)

2.2 Feature types

additive protrusion connector

stand-alone volume void passage depression

subtractive edge transition flat

circular spherical form feature

flat

corner transition circular array one-dimensional two-dimensional three-dimensional other feature pattern transition feature volume feature

Figure 2.2: STEP form feature classiﬁcation. After [STEP 1992].

features represent functional product properties by embedding parameter-ized geometry and constraints. A feature model is a collection of feature instances, possibly containing additional constraints.

Several researchers have tried to classify form features from different per-spectives and according to different criteria, see for example [Cunningham and Dixon 1988, Shah et al. 1990, Ovtcharova et al. 1992, STEP 1992]. Most classiﬁcations have at least three basic types of form features in common, which are volumetric, transition, and pattern, see Figure 2.2.

Volumetric form features add or subtract a volume; examples are slots,

holes, and protrusions. They have a global effect, and give a body and structure to an object.

Transition form features specify a transition between topology elements,

for example a round on an edge joining two faces. Thus, transition form features are basically local operations.

Both volumetric and transition form features have been classified fur-ther. Particularly, volumetric form features have been classified according to different criteria. For example, they can be classified according to either their shape type, their nature, i.e. whether they add or subtract material, and their number of closure faces. Closure faces, or virtual faces, are fea-ture faces that do not occur on the product boundary, e.g. the top face of a hole. However, in the leaves of the classification trees, often the same feature classes occur. It thus appears that these classifications are more or less arbitrary. It is mostly a matter of how users of a modeling system like to see them grouped in the user interface.

Pattern form features consist of multiple disjoint, mostly volumetric,

(20)

exam-ples are a rectangular and a circular pattern. Where other form features are parameterized geometrically, patterns are parameterized topologically. Parameters specify the number of features in the pattern. Examples are an array of cooling ribs, and a circular pattern of ﬁxturing holes, see Figure2.3.

(a) (b)

Figure 2.3: Examples of pattern features.

Compound form features are another form feature class. They compose

a complexvolume from several elementary volumes. An example is a stepped hole composed of two cylinders.

Form features can also be classiﬁed by whether they are represented implicitly by their parameter values only or explicitly by their evaluated ge-ometry. It has been proposed to represent transition features and surface properties such as a thread implicitly. Reasons for this are that an applica-tion is not always interested in all details of such features, and evaluaapplica-tion of such features can be a complexprocess, and results in model images of high complexity. Volumetric features should always be represented explicitly.

In the remainder of this thesis, form features will simply be denoted as features, and focus will be on volumetric features.

2.3 Feature validation

Feature validation is concerned with the representation of features, and

includes specifying and maintaining the meaning of features.

In most of today’s feature modeling systems, both academic and com-mercial, features are mainly a macro for creating a geometric model. They can be used to construct complexmodels efﬁciently. However, it is often not checked in any way whether the constructed geometry is meaningful, i.e. represents design intent. Even if this is done at creation time, the geom-etry can be edited subsequently such that it is no longer meaningful.

(21)

2.3 Feature validation

Take, for example, Pro/ENGINEER [Parametric 1996], which is known as one of the best commercial modeling systems with feature modeling capabilities. However, similar results can be obtained from most other fea-ture modeling systems. A short in-house study has shown that the lack of feature validation at model creating and subsequent editing can give un-desired results. For example, a protrusion may become disconnected from the model if a slot undercuts it. Another example is about reference faces and different types of holes. A through until hole ends at a speciﬁed end face. However, if it is repositioned so that it does not intersect the end face anymore, the hole becomes a through all hole. Although the system is geometrically quite robust, these two examples illustrate often undesired re-sults because they do not capture and maintain intended product properties. Such cases should at least be detected and be reported to the user. A more advanced solution would be feature interaction management, which antici-pates on such cases automatically [Bidarra, Dohmen and Bronsvoort 1997]. Concluding, feature validation should maintain the meaning of features au-tomatically under model modiﬁcations.

Feature validation consists of feature speciﬁcation, feature geometry and constraint representation, and feature validity maintenance. They have been interweaved in most feature modeling research, but they actually are differ-ent aspects that need to be considered separately.

For specifying features, several researchers have used a special feature

language, i.e. a different language than the programming language in which

the modeling system is implemented. This is a clean way to specify fea-tures and their properties formally, and to create systems that are exten-sible to some extent. For example, the object oriented paradigm [Gorlen et al. 1990, Booch 1994, Lockheed Martin 1996] has been proven to be suitable for feature modeling [Shah et al. 1990]. Features can be spec-iﬁed as classes that have certain properties that are represented in so-called members. Members can represent the feature geometry, parame-ters, and constraints. Examples of other languages are Lisp feature spec-iﬁcations in EXTDesign [Laakko 1993], and the GeoNode Modeling Lan-guage [van Emmerik 1990]. In EXTDesign, Lisp frames are used to combine a feature geometry description with embedded constraint declarations. In GeoNode, a hierarchy of local coordinate systems (lcs) is created. They are used to attach constraints to, and to position and dimension features, see Figure 2.4 on the following page.

Constraints are important in feature speciﬁcation, because they specify various feature properties. The most common constraints are geometric and algebraic constraints. Geometric constraints specify geometric relations

(22)

n2 root n1 n2.x_equal->n1 n1.tx = 40.00 n1.ty = 40.00 n2 = lcs(root) n1.x_distance->root > 0.00 n1.y_distance->root > 0.00 n1.z_distance->root > 0.00 extern root,n1 n1.tz = 30.00 n1 = lcs(root) o1 = blk(root,n1) o2 = cyl(n2,n1) exp "[(o1+o2)]" L = n1.tx W = n1.ty * 2 H = n1.tz export L,W,H

Figure 2.4: Generic feature speciﬁcation in GeoNode of a partially rounded block.

such as parallelism and distance. For example in GeoNode, several types of such low-level constraints can be specified in a feature model. To ease model specification, GeoNode provides so-called high-level constraints that specify higher-level functional relations, e.g. an against relation [de Kraker et al. 1994]. Algebraic constraints specify relations between dimensions in the form of equations. Examples are a parameter value interval, and a linear equality declaring the sum of two parameters to be equal to a specified value.

An until now less common constraint type that specifies important fea-ture properties is the so-called semantic constraint . Semantic constraints specify the extent to which a feature face has to lie on the product bound-ary [Bidarra and Teixeira 1994]. They are expressed as logical predicates that can be verified. An example is a semantic constraint on the bottom of a blind hole declaring it to be completely on the product boundary. This constraint clearly specifies part of the hole’s functionality, because if it would be violated, e.g. by feature intersections, the hole would no longer be blind. Semantic constraints are now also being used by others, for ex-ample [Hoffmann and Joan-Arinyo 1996, Mandorli et al. 1997].

For representing feature model geometry, standard geometric modeling techniques have been used, such as B-rep and CSG. For detailed informa-tion about geometric modeling, see [Requicha 1980, Weiler 1986, M¨antyl¨a 1988, Hoffmann 1989].

In an early survey paper, Pratt [1988] discusses several issues about fea-ture geometry representation to achieve an optimal approach to feafea-ture modeling. His two main conclusions are summarized here. The ﬁrst is that

(23)

2.3 Feature validation

a volumetric feature representation is preferred over a surface representa-tion. A volumetric representation represents features as ‘volume’ entities, i.e. closed solids, whereas a surface representation uses ‘surface’ entities, i.e. collections of faces. The second is that a B-rep is preferred over a CSG representation, which is mainly because B-rep is an evaluated ge-ometry representation, whereas CSG is an unevaluated representation. A B-rep representation can explicitly represent feature intersections. These two conclusions have lead to a proposal for a feature model geometry rep-resentation consisting of an irregular cellular structure, in which some cells are occupied by material (part body and protrusion feature cells) whilst others are empty (depression and hole feature cells). Such a model does not have the properties of two-manifold B-rep models, but instead is a non-manifold model. Surprisingly, however, most current geometry repre-sentations of feature models are still based on a two-manifold B-rep, see for example [Falcidieno and Giannini 1989, Shah 1991, Sheu and Lin 1993], and no implementation of a cellular model has been reported yet. Only Brunetti et al. [1996] plan to use the Selective Geometric Complexes [Rossignac and O’Connor 1990], which is a dimension-independent model for pointsets with internal structures and incomplete boundaries. It is currently being extended [Rossignac 1997, Rappoport 1997], but so far, it is a theoretical paradigm of which only a partial implementation has been reported [Sriram et al. 1995].

Constraints are often represented in a constraint graph. This is a satisfac-tory representation, in which the nodes represent constraint variables and the arcs represent constraints.

Feature validity maintenance is concerned with determining all feature pa-rameters and satisfying all speciﬁed constraints. It is performed when a feature is added or deleted, and when a feature parameter is changed. There are two approaches to feature validity maintenance: procedural and declarative.

Early feature modeling systems, for example [Shah et al. 1990, van Em-merik and Jansen 1989], represent the procedural approach to validity maintenance. An important characteristic of this approach is that the fea-ture model construction history is used to validate a model, thus validity speciﬁcation and maintenance are interrelated. For example, in GeoNode [van Emmerik and Jansen 1989, van Emmerik 1990] a tree of local coordi-nate systems is constructed that is used to position and dimension features. For determining all feature parameter values, the tree is traversed, and local coordinate systems are transformed in the order in which they are posi-tioned in the tree. Similarly, in the ASU Features Testbed [Shah et al. 1990],

(24)

a unidirectional chain of feature parameters is constructed when features are instantiated, which is used to determine feature parameter values.

An advantage of the procedural approach is that it is simple, and that conﬂicts are avoided. However, it establishes a rigid scheme for determining feature parameter values, and provides few possibilities for changing feature parameters and for adding constraints. For example, constraints are always unidirectional, and therefore cannot mutually inﬂuence two entities: there is always only one entity that can be changed and that determines the other. Shah, Ali and Rogers [1994] have also investigated the declarative

ap-proach to validity maintenance. In this apap-proach, validity speciﬁcation and

maintenance are separated. All feature properties, including feature geom-etry, are expressed as constraints. These, and all parameter value specifica-tions, are handed to a constraint solver that determines all remaining feature parameter values and thus the geometry. The main advantage of declarative modeling is that there is much more freedom in the way in which feature parameters can be changed, and in the type of constraints that can be spec-ified. The main difficulty is that all constraints must be solved. Constraints may be from different domains, and under-specifications and even conflict-ing constraints can occur, which makes solvconflict-ing very complex. This is the subject of the work by Dohmen [1997].

2.4 Techniques for obtaining features

There are three techniques to get features into a product model: feature recognition, design by features and feature mapping.

The ﬁrst applications in which features were used, were based on feature recognition. Feature recognition can be deﬁned as deriving a feature model from a given geometric model. It has been used mostly for deriving manu-facturing process plans. There are two forms of feature recognition: it can take place interactively by an engineer, or completely automatically by a software system.

In interactive feature recognition, an engineer creates features by pick-ing topology elements in an image of a geometric model that make up a feature. A feature library could be used to assist the engineer. For example, if he is recognizing a blind hole, the modeling system can guide him to pick one planar and one cylindrical face. Further assistance could consist of do-ing some validity checks, for example checkdo-ing whether the two faces are adjacent and perpendicular. An advantage of interactive feature recognition is that it is quite ﬂexible, because any combination of entities can be

(25)

recog-2.4 Techniques for obtaining features

nized as a feature. However, two disadvantages making it very impractical to use are that it is a laborous task, and that the engineer is responsible for feature validation.

In automatic feature recognition, a software system generates a feature model automatically, given a geometric model and often a feature library. The last 20 years, a large amount of research on automatic feature recogni-tion has been done.

Despite all feature recognition research, developed techniques are still limited in their possibilities. For example, they often only work for a re-stricted set of geometric models, and intersecting features can mostly not be recognized. Also, it has been said that the combinatorial complexity of certain techniques is a problem. However, Sakurai [1996a] argues that this is not a problem of the algorithm, but of reality. A solution for long com-putation times might be a parallel implementation of a feature recognition technique [Regli et al. 1997].

Traditionally, automatic feature recognition techniques have been sub-divided in syntactic-pattern, rule-based, graph-based, and volume decom-position techniques. For reviews, refer to [Shah 1991, Bronsvoort and Jansen 1993, Case and Gao 1993, Salomons et al. 1993]. The ﬁrst three techniques perform matching of a pattern that represents a feature with the geometric model, and the latter technique subdivides the geometric model in parts that represent features. In Section 6.1, we discuss these techniques according to whether they use generic feature speciﬁcations explicitly, and we generalize the use of rules.

Until now, feature recognition techniques have been application spe-ciﬁc. Most techniques have aimed at recognizing manufacturing features. Furthermore, they mostly generate only one feature interpretation. A feature

interpretation is an interpretation of a (geometric) model in terms of

fea-tures. In our terminology, a feature interpretation corresponds to a feature model instance. It is currently being realized that multiple feature

interpre-tations of one product should be recognized, even within one application,

see the following section. Therefore, the issue of multiple interpretations is gaining popularity, see for example [Han 1997].

In design by features, a feature model is constructed by using features from the beginning. This requires a feature library, from which classes can be instantiated by an engineer. Assignment of a functional meaning to parts of an object is here not done by feature recognition after creating a geometric model, but during the design phase: the engineer can put his intent for parts of the object into the product model using features. Also, a model can be constructed with high-level operands and operations, such as slots

(26)

and blendings, which is considerably easier and faster than working with low-level geometric elements as in a solid modeling system. Furthermore, design changes can be made easily by changing feature parameters.

The third method is feature mapping, also called feature transformation and feature conversion, which is the process of deriving a new feature model in some application (target) from an existing feature model in an-other application (source). The advantage of feature mapping over fea-ture recognition, is that the nongeometric information stored in the feafea-tures could be used to derive a new feature model. Such feature mapping uses a richer model, and could thus theoretically give better results.

Feature mapping, transformation, and conversion have been used as synonyms, however, we redeﬁne feature conversion. Below, we shortly discuss the approach in which features are actually mapped on the generic level, which is mainly a static approach. In Chapter 4, we present a new feature conversion approach that integrates feature recognition and con-straint maintenance techniques, which is particularly suitable for concurrent engineering, and which is a more dynamic approach.

For understanding the mapping problem, Shah [1988] has deﬁned feature spaces analogously to vector spaces in linear algebra, and concludes that if feature spaces overlap, at least a partial mapping is possible.

He specifies some mapping classes for these cases [Shah and Mäntylä 1995]. Two examples are the specialization mapping and the discrete de-composition mapping. The specialization mapping occurs when the levels of specialization of two applications are different. For example, a through hole design feature may be mapped to several alternative manufacturing features, depending on the diameter and the depth of the hole. Hence this is a 1 ! n mapping. The geometry and parameterization of all these hole

features may be the same; they only differ in the manufacturing knowl-edge associated. In the discrete decomposition mapping, one feature is decomposed into m features (m > 1). In the example of Figure 2.5 on the

next page, the counter-bored hole is to be manufactured by a sequence of operations for producing the through hole and for enlarging it at the top.

He also indicates several difﬁculties of feature mapping. Features may be of different abstraction levels, e.g. some features only represent their geometry partially. Different feature parameters that are used in some ap-plications, and attributes such as tolerances, may not be relevant in all applications.

The most important obstruction for realizing feature mapping, we think, is what is called the conjugate mapping. For this mapping, no generic scheme can be speciﬁed, even if feature spaces are fully conjoint, e.g. if

(27)

2.4 Techniques for obtaining features 00000000 00000000 11111111 11111111 000 000 000 000 000 000 000 111 111 111 111 111 111 111 0000 0000 1111 1111

counterbore through hole + enlargement

Figure 2.5: Discrete decomposition mapping.

only form features are considered. This mapping can be illustrated by two feature models that represent the same product. One application represents the product with additive features, whereas the other represents it with subtractive features, see Figure 2.6.

000

111

000

111

Figure 2.6: Conjugate mapping.

The only generic mapping scheme imaginable maps an array of ribs onto an array of slots. However, such mapping is easily disturbed by other fea-tures. For example, if another additive feature is put between the ribs, the mapping onto the slots fails. Also if a subtractive feature is put between the ribs, the mapping onto the slot may still be valid, but it may be preferable to map the new model onto a model with a T-slot. Such an alternative feature interpretation would have to be coded explicitly in the mapping, which is particularly intractable in 3D. We conclude that with feature mapping, only special cases can be dealt with and that no general generic mapping scheme can be developed.

Another problem of feature mapping in general is that information can be lost. For example, constraints from the source application that are not relevant in the target application are lost. In particular in a concurrent engineering environment, such constraints should always be kept, see also the following two chapters.

(28)

(29)

3

Feature modeling for

concurrent engineering

This chapter discusses a way to use feature modeling in concurrent engi-neering environments. It ﬁrst introduces principles of and trends in con-current engineering. It then discusses approaches to multiple-view feature modeling, developed to support concurrent engineering. Lastly, it presents requirements for a product modeling system using multiple views.

3.1 Concurrent engineering principles

Product development consists of different phases. The main phases are design and manufacturing. These can be subdivided into functional, con-ceptual, and detail design, and manufacturing process planning, production planning, production, and testing, respectively. Traditionally, after an idea for a product has been developed, these phases are passed through se-quentially. Such product development is called sequential engineering, see Figure 3.1(a) on the following page.

In practice, sequential engineering has several problems. For example, economic reasons force companies to develop a new product and put it on the market quickly, i.e. before their competitors. Thus, product develop-ment time should be reduced. Furthermore, sequential engineering is often referred to as “over the wall engineering” [Hartley 1992]. After the design department has created a design, it is ‘tossed over the wall’ to the manufac-turing department. The manufacmanufac-turing engineers can only determine how they are going to manufacture the product. They do not have the

(30)

oppor-time functional design testing production production planning process planning detail design conceptual design

(a) Sequential engineering

time functional design testing production production planning process planning detail design conceptual design (b) Concurrent engineering

Figure 3.1: Time aspect of product development.

tunity to give suggestions for design improvements, except if the design appears to be unmanufacturable. In that case, they have to pass it back to the design department, which wastes a lot of development time. However, several studies have shown that about 80% of the total life cycle cost of a product is determined during design, although the cost of the design activity itself contributes only some 10% of the total cost [Boothroyd 1988, Gatenby and Foo 1990, Whitney 1990]. Dixon and Duffey [1988] believe that 40% of all product quality problems can be traced to poor design. This shows that sequential engineering leads to suboptimal products, e.g. products that are designed to perform the required functionality, but that are difﬁcult to assemble or maintain. Therefore, we must look for improvements for the product development process.

(31)

3.1 Concurrent engineering principles

The mentioned problems can be solved by the novel philosophy of concurrent, or simultaneous engineering. In concurrent engineering, en-gineers from different disciplines, work on the development of a product concurrently. Whereas these disciplines used to be involved in the prod-uct development process sequentially, and thus separately, they now are involved concurrently, and thus more integrated.

Concurrent engineering inﬂuences two important product aspects: product development time and product quality. According to this, two concurrent engineering techniques have been identiﬁed.

The first technique aims at decreasing product development time. To achieve that engineers work concurrently, a new development phase can be started before its preceding phase is completely finished. This can be accomplished by introducing extra mile-stones in each phase, at which processes in the next phase are started. At the extra mile-stones, a phase has not been completed yet, but certain design variables have been fixed. With this data, the next phase can be entered. This establishes that a next phase can be started earlier, reducing product development time. This is shown in Figure 3.1(b) on the preceding page, in which several product development phases overlap.

The second technique aims at increasing product quality. Here, product quality must be interpreted in the broad sense of the word, because it is deﬁned with respect to all engineering disciplines involved. This approach is called design for X (DFX). DFX is an umbrella for Design for Assem-bly [Boothroyd and Dewhurst 1990], and other approaches that have been reported, such as Design for Manufacturability, Design for Inspectability, Design for Environmentality, Design for Recyclibility, Design for Reliability, etc. [Gatenby and Foo 1990]. The X’s are made up of two parts: the corre-sponding life cycle aspect, and a “bility” that represents some performance metric, e.g. time and cost. Notice that all product aspects relevant to its life cycle can be incorporated.

DFX was initially implemented by providing designers with handbooks with rules that specified what a good design is. This approach has three disadvantages. Firstly, the number of rules may be large, which makes it very difficult to oversee for a designer. Secondly, it is difficult to indicate a rule’s area of validity. If all rules are supposed to be observed, contra-dicting situations may occur in specific cases, and it will not be clear to a designer what to do. Thirdly, no quantification of product qualities is given, therefore consideration of different alternatives is not supported. In this implementation, designers work alone.

(32)

Currently, several companies apply a team-based approach to DFX. They compose a product development team from experts from different disci-plines to develop an optimal product. However, computer tools are desired to support DFX automatically. Jo et al. [1993] have developed a conceptual model, called the concurrent engineering wheel, which demonstrates such a DFX implementation, see Figure 3.2. In this model, advanced product modelers are used, and all kinds of life-cycle analysis tools can be invoked. The control logic in the core performs steering of the various tools.

bility Assembla- Manufactura-bility Reliability maintenance and cycle analyses Life -product _modelers Advanced Control logic Process analysis Engineering Ergonomics Testability estimation Cost planning

Figure 3.2: Concurrent engineering wheel. After [Jo et al. 1993].

Several DFX computer tools have been developed [Gu and Kusiak 1993, Kusiak 1993, Parsaei and Sullivan 1993]. Some aim at supporting communi-cation between different disciplines. For example, they incorporate E-mail or video conferencing tools so that engineers can talk to each other. A limitation of these tools is that they enable negotiation possibilities only. They do not provide possibilities for sharing product data between differ-ent applications, which is essdiffer-ential for concurrdiffer-ent engineering. Others aim at product optimization techniques with respect to specific X’s. These tech-niques are quite diverse, ranging from studying and enhancing models of design processes, to use of specific artificial intelligence techniques. They are often specific to a product domain, for example a restricted product family. Such specific tools thus have a limited application domain.

Huang [1996] distinguishes two types of current DFX tools that enhance product quality, and presents extended examples. Tools that focus on one life cycle phase and use more than one performance metric, are called

(33)

3.2 Multiple-view feature modeling

tools of the Design for Life Cycle. For example, Design for Reliability may be applied for products of which the functioning is very critical. Reliabil-ity metrics are simplicReliabil-ity, clarReliabil-ity, and unReliabil-ity [Stephenson and Wallace 1996]. On the other hand, tools that focus on one performance metric but cover a range of life cycle phases, are called tools of the Design for Competi-tiveness. For example, Design for Modularity may be applied to enhance product planning and performance [Erixon 1996]. We may expect that more general techniques will be developed that integrate Design for Life Cycle and Design for Competitiveness by covering more than one performance metric and more than one life cycle, so that this distinction will at least partially disappear.

3.2 Multiple-view feature modeling

From the previous section, it can be concluded that concurrent engineering is an important evolution in product development, because it can reduce development time and increase product quality. In both concurrent engi-neering techniques mentioned, a key issue is the data communication and consistency between different applications. This requires more than verbal communication only. Product data should be shared and/or coupled be-tween different applications. We think that feature modeling techniques, including constraints, can play a major role here. Initial work on constraints in this context has been done by Bowen and Bahler [1992]. They propose to use constraints for detecting and explaining inconsistencies between appli-cations. Our view complies with that of Shah and M¨antyl¨a [1995], who ex-press that key issues in collaborative design include constraints and change management and propagation. Therefore, this section presents how feature modeling techniques can be applied in concurrent engineering.

The ideal product development environment combines concurrent engi-neering and feature modeling. Engineers from different disciplines work on the design of a single product, simultaneously developing a product of high quality. They can extend a design, or make enhancements, after perform-ing some kind of analysis. For example, an assembly engineer may specify a connection between two components, and an analysis on environmental load may result in certain changes to the product. They use design by fea-tures, so that they can beneﬁt from its advantages presented in the previous chapter, such as representing design intent.

(34)

through holes slot

base block protrusions

(a) Design view

through holes

stock slot

steps

(b) Manufacturing view

Figure 3.3: Example feature views.

In this context, we deﬁne the term feature view, or view for short. A

view is the representation of an engineering application; it represents the

way the application looks at a product in terms of features relevant in that application [Bronsvoort and Jansen 1993]. For that purpose, each view has its own feature library, or database, containing generic features, and a fea-ture model that represents the product. A feafea-ture model is one feafea-ture interpretation of the product. Thus, each view corresponds to one feature interpretation, and multiple feature interpretations exist. Views are a con-venient way to interact with a modeling system, since a view represents the language and terminology of an engineering application. Figure 3.3 shows an example of a design and a manufacturing view with each a different feature interpretation.

One of the first implementations of feature modeling for concurrent part design was First-Cut [Cutkosky et al. 1988]. It integrates detailed compo-nent design and process planning, by design with manufacturing features. The obvious advantage is that no extraction of manufacturing features is required. However, design by manufacturing features has some inherent problems [Shah and Mäntylä 1995]. It forces a designer to think in terms of destructive operations only, which often is not natural for him. Moreover, creating a product model consisting of manufacturing features requires am-ple knowledge of the underlying manufacturing process, which cannot be expected from a designer.

(35)

3.2 Multiple-view feature modeling primary view process planning view assembly planning view finite-element view conversion module A conversion module C conversion module B

Figure 3.4: Architecture with primary view and secondary views. After

[Cunningham and Dixon 1988].

Cunningham and Dixon [1988] propose a multiple-view system architec-ture with one primary view and several secondary views, see Figure 3.4. A model can only be created in the primary design view, and conversion modules are available to derive the secondary views. If a modiﬁcation is required on the basis of the outcome of a secondary view, this modiﬁcation has to be entered in the design view, after which new secondary views can be derived. Also in the work by De Martino et al. (1994, 1997) on multiple views, it is possible only to edit a model from the design view. Similarly, in [Suh and Wozny 1997], the design view plays a central role. Other views, called applications, are derived from the design view. Such an architec-ture requires one-way feaarchitec-ture mapping from the primary design view to the secondary views only.

However, the solution with a primary design view and a number of secondary application views is far from ideal. If an engineer running an ap-plication program discovers that, for example, a dimension of the designed object has to be adjusted, he has to switch from his application view to the design view to make the adjustment. In this view, however, the feature model is different from the one in his own view, and it may be difﬁcult to ﬁnd the right adjustments of the feature parameters in that view. Fur-thermore, it requires different special purpose conversion modules, and is thus not generic. We have therefore developed an approach that gener-ically supports all different feature views simultaneously, and maintains all views by performing multiple-way feature conversion between these views [de Kraker et al. 1995]. The following section discusses requirements for such a multiple-view feature modeling system.

(36)

3.3 Requirements

From the preceding two sections, it can be concluded that an ideal feature modeling system for concurrent engineering supports different views of one product simultaneously. Two main functional requirements can be stated for a multiple-view feature modeling system. Firstly, it should be possible to invoke a view at any moment in the product development, which is particularly important for DFX. Secondly, feature model changes made in any view should be propagated to all other views.

For invoking a new view, a feature model for that view must be derived in a similar way as in the architecture with one primary and several sec-ondary views. For this, feature mapping and/or recognition techniques may be used.

Feature model changes consist of adding or deleting a feature or con-straint, and of changing a feature or constraint parameter. This requires that the modeling system stores and maintains the feature models, their geometry, and all the constraints from the different views. In particular, maintaining all the constraints from the different views is an important new requirement, which has not been dealt with by the approaches mentioned above.

For the types of views to be supported, two requirements are given. Firstly, we require that any type of view that contains form features is supported. Such view types are speciﬁed generically. View instances contain geometry and constraints, specifying a product including its functionality.

Secondly, we have argued in [de Kraker et al. 1995] that it should be pos-sible to edit the product model from any view. In some views, however, it may be undesirable to make substantial modifications to the product. For example, in a manufacturing view, it is undesirable to make modifications to the product that destroy certain product properties intentionally created in a design view. On the other hand, it is desired to allow certain modifica-tions to the product that accomplish that the product can be manufactured cheaper. For that purpose, each view is assigned a priority that is used to decide whether a change in some view is allowed and executed [de Kraker et al. 1997a], see also Chapter 4.

Also requirements for the system architecture can be formulated. In fea-ture mapping, there is an indirect, static relation between different views. However, for maintaining different views simultaneously, and particularly for propagating feature parameter changes, we need a direct, dynamic cou-pling between the views. We couple the different views via the product

(37)

3.3 Requirements

geometry, for which there are three reasons. Firstly, we are dealing with form features, and thus with the detailed design phases only. These fea-tures have a well-deﬁned, parameterized geometry, and result in a fully speciﬁed geometric model. Secondly, a common vocabulary for the views is required through which the views are coupled and can communicate. Thirdly, it must be possible to compare the views, for example to check whether they represent the same product. Hence geometry is suitable for coupling the views. It provides a neutral representation and communication medium, and allows to compare different views. The approach of using a geometry-based representation for multiple-views also has been followed by De Martino [1997]. She is currently working on specifying such a repre-sentation.

Because the different views represent the same product, it can con-veniently be represented in a central, shared geometric model. Using a central model has the advantage that we obtain a star architecture instead of a network architecture: for each view, only mappings to and from the central model need to be speciﬁed. Such mapping is preferably speciﬁed generically for all views. In this way, different views are supported.

In each view, constraint instances may be created. When one view is edited, the constraints from all views should be satisﬁed simultaneously to maintain validity of all views. For maintaining all constraints, they are conveniently represented in a central data structure.

For propagating a feature parameter change from one view to the oth-ers, the coupling between the views must be made explicit in geometric constraints. These constraints can be derived from the feature models auto-matically, and must be incorporated in the maintenance of all constraints.

Therefore, we propose a central product representation that contains the product geometry and all constraints. This representation is neutral with respect to all views. It provides a way via which the different views can communicate. New views can be derived from this representation, and parameter changes can be propagated using the constraints. Figure 3.5 on the next page depicts the resulting system architecture. It enables multiple-way feature conversion, which is elaborated in the following chapter.

(38)

feature view n view 1 model geometry model constraints, product model view 2 feature feature model

(39)

4

Multiple-way feature conversion

This chapter presents the new multiple-way feature conversion approach. It ﬁrst introduces a scheme for maintaining a set of views in a multiple-view feature modeling system. Following, it elaborates on a product model that contains the feature models of different views. Finally, it describes the ar-chitecture of a prototype software implementation.

4.1 Maintaining multiple views

In the multiple-view feature modeling concept, multiple views of a product under development are maintained simultaneously. Views are the high-est level entities, which are represented generically as classes with certain properties. For example, each view class is assigned a feature library and a constraint library that correspond to the view’s application. An instance of such a view class can then be created, and contains a feature model. The

multiple-way feature conversion approach enables that each view can be

invoked at any time, and that changes made in one view are reﬂected in all other views. For that purpose, a set of view instances is maintained.

After a product has been designed partially in one view, application engi-neers can perform three operations on their views: open, edit, and close, see Figure 4.1 on the following page.

An engineer can open a view to obtain a feature model for his applica-tion, e.g. when a new life cycle phase is to be invoked.

(40)

set of open views

open

edit

close

view 1 view 2 view n

view j view i

Figure 4.1: Maintaining a set of open views.

He can edit a view to make modifications to the product, which are propagated to the other views. This is done through the edit operations: adding and deleting a feature or a constraint, and changing a parameter. Not all edit operations are allowed in all views, e.g. in a manufacturing view it is undesirable to make modifications to the product that destroy certain functional product properties intentionally created in a design view. However, it is desirable to allow certain modifications to the product that accomplish that the product can be manufactured cheaper. For that pur-pose, it can be specified for each feature and constraint class which edit operations on it are allowed. An allowed edit operation in one view may, however, be in conflict with another view, e.g. with its constraints. As a first step to resolve such conflicts, each view is assigned a priority, which is used to decide whether the edit operation is executed or not [de Kraker et al. 1997a]. These priorities may be refined in future work. If the edit operation is executed, it is propagated to the other views. If not, the edit operation is canceled, which is reported in the corresponding view, see also Chapter 7.

To complete the list of view operations, an engineer can also close a

view to discard it until it is opened again.

The modeling system must anticipate on these user actions. It therefore maintains a set of open views which are kept consistent. Views are consistent if they represent the same product, i.e. have equivalent geometry. This deﬁnition is elaborated in terms of 3D geometric cells in Chapter 5.

(41)

4.2 Product model representation

Aview is opened by deriving a feature model that is consistent with the already open views and that corresponds to the way the application looks at the product. Ageneric method for opening a view, which uses speciﬁed view properties, is elaborated in Chapter 6.

An open view is edited through allowed edit operations. These can have quite different impacts on the other views, partly depending on the type of edit operation. One example is a parameter change, which should be propagated to the other views. This is implemented using constraints specially created for that purpose. If no conflicts occur during solving of the constraints, the parameter change has successfully been propagated. On the other hand, if conflicts do occur, the parameter change may either be propagated or canceled, depending on the types of the conflicting con-straints and the priorities of their views. Another example is propagating a feature addition or deletion, which is propagated to the other views by reopening them incrementally [de Kraker et al. 1997a]. Maintaining the set of views under these edit operations is elaborated in Chapter 7.

Aview is closed by deleting the view instance and its feature model.

4.2 Product model representation

Given a product and a set of open views, we can deﬁne a product model representation which main goal it is to enable multiple-view feature vali-dation. Multiple-view feature validation aims at validating multiple views simultaneously while keeping them consistent. Therefore, focus is on spec-ifying and maintaining feature model validity, and on coupling the different open views.

Several considerations have been made on how to enable feature validity speciﬁcation which integrates feature geometry and constraints. Symbolic handles must be available for geometry access and constraint speciﬁcation. These handles are provided by feature topology elements. For example, the closure top and bottom faces of a through hole can be used to attach the hole to a model, using constraints. Geometry handles must not only be available in a newly to be added feature, but in the feature model as well.

In the history-based approach, a new feature is attached to topo-logic entities in the B-rep which results from previous modeling opera-tions. This approach is applied in many feature modeling systems, e.g. [Parametric 1996, Chen and Hoffmann 1995b], but raises topologic naming problems. Ageneral property of the B-rep is that entities may be destroyed, split, or merged as a result of a modeling operation. Persistent topologic

(42)

naming is deﬁned as identifying and tracking topologic entities when a

geometric model is modiﬁed [Kripac 1995]. Chen and Hoffmann [1995a] show some typical problems that occur when features are attached to a B-rep. Their examples demonstrate naming problems and the associated ill-deﬁned semantics of a feature model when it is edited.

To resolve naming problems and the ill-defined feature model semantics, we propose attachments of canonical feature topology elements. Canonical feature topology elements are elements of generically defined shapes, i.e. elements of topological or geometrical parameterized shapes such as the faces of a CSG primitive or of a sweep. They are persistent, and thus can be used as constraint variables. Following this scheme, a new feature is attached with its topologic elements to topologic elements of other features. This is illustrated using an example from [Chen and Hoffmann 1995a], consisting of a block with a slot and a round on an edge, see Figure 4.2(a). In the history-based approach, the edge that was rounded was a B-rep edge. If the slot is deleted, the history-based approach may apply the round to the entire block edge, see Figure 4.2(b). If it would be readded, both block edge parts would become rounded, see Figure 4.2(c). The latter result is different from the initial model, which may not be expected. It is caused by the round being applied automatically to the entire block edge when the slot is deleted. We conclude that feature attachments to B-rep entities do not specify a feature model properly when it is edited, and thus that these relations should be specified better.

(a) Edge rounded (b) Slot deleted (c) Slot readded

Figure 4.2: Ill-deﬁned feature model semantics.

In our approach, the edge that is rounded is a part of the block edge. The round is attached to the block edge, and declared to start at the right slot face and to end at the right block face. If the slot is deleted, we would

(43)

4.2 Product model representation

immediately detect that the round becomes partly unattached. In this case, the user can be presented several options:

1. Recursively delete the features that are attached to the feature deleted as well.

2. Reattach features that are attached to the feature deleted. 3. Cancel the deletion operation.

Whichever option is chosen, a well-deﬁned and expected feature model results.

When changing feature parameters, canonical feature elements and shapes have another attractive property. Whereas in history-based model-ing, a feature parameter change requires a (partial) reevaluation of the fea-ture model geometry, our canonical feafea-ture shapes allow to directly change parameters of one feature.

Currently, only coplanar attachments have been implemented. Other, oblique and nonplanar, attachments must be investigated further.

Summarizing, by using attachments of canonical feature elements, we can specify a feature model using constraints on these topologic elements. Furthermore, we avoid naming problems, and the feature model semantics are well-deﬁned when the model is edited.

Because we take the declarative approach to feature modeling, the prod-uct model representation consists of two different levels: specification and maintenance, see Figure 4.3 on the next page. At the specification level, feature validity is specified, which is maintained at the maintenance level. At the specification level , each view is assigned a feature class library and a constraint class library. The view’s feature model is specified by instances of these classes. Both classes and instances are specified in Looks [Peeters 1993, Peeters 1995], a strongly typed object-oriented impera-tive programming language that resembles the Java language [Niemeyer and Peck 1996]. These specifications are processed by an interpreter for Looks, which has been implemented in C++.

For specifying feature classes, three types of feature constituents are available: shape, constraints and the nature of a feature.

Since only volumetric features are considered in this thesis, a shape is represented by a parameterized solid. To specify a compound feature, multiple shapes are combined.

(44)

maintenance specification constraint constraint constraint feature model 2 feature model 1 feature cellular model view 1 _{view 2} constraints product geometry link constraints view n graph n graph 1 graph 2 model n

canonical shape model,

Figure 4.3: Product model representation.

To specify feature validity, different constraint types that operate on feature topology elements and feature parameters are available. These con-straints are embedded as attributes of a feature class. Attach concon-straints specify the attachment of a feature to a feature model. They specify a hier-archical relation between two feature faces, and they make one feature face coplanar to another. Semantic constraints specify topologic properties of feature elements. For a vertex, edge or face, a semantic constraint speciﬁes the extent to which the element must lie on the product boundary. For a volume, a semantic constraint speciﬁes the extent to which the volume is allowed to be intersected by features instantiated later. Dimension

con-straints specify an interval for the value of a feature parameter. Algebraic constraints specify relations between parameters. For a complete

descrip-tion of the constraints that are used, see [Dohmen et al. 1996, Dohmen 1997]. The feature’s nature is either additive or subtractive, specifying whether the feature adds or removes material to or from the product.

Feature classes can be constructed using the feature constituents. Afeature class can embed them as attributes, or can inherit them from a base class, see for an example Figure 4.4 on the facing page. The class SteppedHole inherits the subtractive nature constituent. Furthermore, it inherits from class Compound, which contains a list of shapes. The class SteppedHole has two

Feature conversion for concurrent engineering

Feature Conversion

for

Feature Conversion

for

Concurrent Engineering

Preface

Contents

1

Introduction

1.1

Product modeling and concurrent

engineer-ing

1.2

Research objectives

1.3

Thesis outline

2

Feature modeling

2.1

Motivation for features

2.2

Feature types

2.3

Feature validation

2.4

Techniques for obtaining features

3

Feature modeling for

concurrent engineering

3.1

Concurrent engineering principles

3.2

Multiple-view feature modeling

3.3

Requirements

4

Multiple-way feature conversion

4.1

Maintaining multiple views

4.2

Product model representation