WEB-ENABLED FEATURE-BASED MODELING IN A DISTRIBUTED DESIGN ENVIRONMENT. Jae Yeol Lee, Hyun Kim, and Sung-Bae Han

Transcription

1 Proceedings of DETC99: 1999 ASME Design Engineering Technical Conferences September 12-15, 1999, Las Vegas, Nevada DETC99/DFM-8941 WEB-ENABLED FEATURE-BASED MODELING IN A DISTRIBUTED DESIGN ENVIRONMENT Jae Yeol Lee, Hyun Kim, and Sung-Bae Han Concurrent Engineering Research Team Electronics and Telecommunications Research Institute (ETRI) 161 Kajong-Dong, Yusong-Gu, Taejon, , South Korea jaelee@etrirekr ABSTRACT Network and Internet technology open up another domain for building future CAD/CAM environments The environment will be global, network-centric, and spatially distributed In this paper, we present Web-enabled feature-based modeling in a distributed design environment The presented approach combines the current feature-based modeling technique with distributed computing and communication technology for supporting product modeling and collaborative design activities over the network The approach is implemented in a client/server architecture, in which Web-enabled feature modeling clients, neutral feature model server, and other applications communicate with one another via a standard communication protocol The paper discusses how the neutral feature model supports multiple views and maintains naming consistency between geometric entities of the server and clients as the user edits the part in a client Moreover, it explains how to minimize the network delay between the server and client according to dynamic feature modeling operations Keywords: Feature-based modeling, Web-enabled CAD, distributed computing, WWW, CORBA, and Internet INTRODUCTION Network and Internet technology open up another domain for building future CAD/CAD environments The environment will be global, network-centric, and spatially distributed, which enables product designers to more effectively communicate, obtain, and exchange a wide range of design resources during product development Moreover, with the growing popularity of WWW-based browsers, it is becoming evident that the networkoriented design environment will soon be a new paradigm for product development 2,15,20 In engineering design practice, more and more downstream activities associated with various manufacturing aspects are being considered during the design phase As design is an interactive process, developing techniques to manage computational costs better is critical in systems that enable designers to explore and experiment with alternative ideas during the early design phase Thus, achieving reasonable levels of interactivity between design and downstream activities requires a well integrated system that can support both design and analysis 4,5,10,12,16,17 Feature-based modeling has been considered a new paradigm for integrating design and engineering activities It enriches product data representation with semantic information that allows more efficient and direct communication between engineering processes Thus, the concept of features has been used in a wide range of applications such as part and assembly design, design for manufacturing, process planning, and many other applications Further, these applications are moving to distributed heterogeneous computing environments to support design and manufacturing processes that are temporally and spatially distributed 6,13,14,18 Note that it is undesirable and often infeasible to require that all of the participants in the design and manufacture of a product use the same hardware and software systems 7 In some cases, the wanted service may not even be available on a particular computational platform, and further, requires interfacing to a system developed in a totally different environment (eg, different programming languages and operating systems) Several research efforts have addressed ways in which a computer-network oriented design environment will be able to support product designers and suggest what a computer-based design tool or system should look like in such an environment 4,7,15,19,20 However, these works are conceptual in nature and do not provide well-structured representation and detailed algorithms For instance, they have not addressed how 1 Copyright 1999 by ASME

2 to distribute necessary processings among distributed components, and how to modulate the communication among the components to minimize the network delay If the amount of data exchange can not be triggered appropriately, this will be a critical deadlock for distributed computing Thus, it is crucial to develop a well-integrated, network-centric, and agential architecture for collaborative and distributed design and manufacturing In this paper, we present Web-enabled feature-based modeling in a distributed design environment The presented approach combines the current feature-based modeling technique with distributed computing and communication technology for supporting product modeling and collaborative design activities over the network The presented approach is implemented in a client/server architecture, in which Webenabled feature-based modeling clients, neutral feature model server, and other applications communicate with one other using a standard communication protocol for accessing remote objects This paper focuses on 1) the neutral feature representation for multiple views, 2) communication between the server and clients, and 3) client-side processing The neutral feature model server acts as a service provider to distributed applications It is shared among clients, and it offers functionalities needed for feature modeling and other applications In particular, it has a consistent naming scheme for handling feature interactions, maintaining relationship between geometric entities of the server and clients, and realizing real-time dynamic modeling A CORBA-based standard communication protocol is used to link the server and diverse clients in a transparent and modelerindependent fashion The protocol makes the feature model server appear to have the same functionality to various clients, thus creating plug compatible environment Attributed Abstracted B-rep is introduced to support various client-side processings It is an abstracted and simplified B-rep such that it realizes much data reduction for inexpensive and distributed processings This paper also discusses how the neutral feature model is maintained as the user edits the part in a client Moreover, it explains how to minimize the network delay between the server and client according to dynamic feature modeling operations The remainder of this paper is organized as follows Section 2 discusses distributed computing research efforts in various communities Section 3 overviews the proposed approach Section 4 presents distributed feature-based modeling Section 5 shows some implementation results In section 6, we conclude with some remarks RELATED WORK As network-enabled CAD technologies become more commonplace on the desktops of designers, new research & development, and standard issues are certain to arise However, developing networked engineering services entails creating and managing user interfaces, rendering graphics, accessing Internet services, and creating software utilities that interoperate on heterogeneous hardware and software platforms 15 Technologies such as Object Management Group s (OMG) Common Object Request Broker Architecture (CORBA) are providing central to the interoperation of functions and objects CORBA allows applications to communicate with one another no matter where they are located or who has designed them Thus, CORBA has been accepted in the engineering community as an object-oriented implementation framework for interoperable, distributed engineering applications Java will be a critical tool for distributed Internet programming It enables the creation of novel platformindependent software tools, systems, and agents It is envisioned that users will be able to load Java-based objects and link them together to create full applications Currently, however, there are no native Java libraries or APIs for supporting solid and geometric modeling and other infrastructures needed for CAD/CAM Work on standards for geometric/solid modeling has been under way for several decades The standard for the exchange of product model data (STEP) is an international standard which includes surface and solid modeling STEP/PDES provides a static interface between applications and modelers In contrast, AIS (Consortium for Advanced Manufacturing, International) is a dynamic interface, which provides access to modeler s procedures and allows the direct creation, modification and interrogation of solid models 1 Communication between applications and the modeler is channeled through the AIS implementation, which maps the AIS procedure calls into modeler-specific API calls 6 AIS implementations would make it possible to write applications in a modeler-independent fashion and, therefore, guarantee their portability However, AIS does not support attribute structures which are extremely useful in feature modeling Several research efforts have addressed ways in which a computer-network oriented design environment will be able to support product designers and suggest what a computer-based design system should look like in such an environment Phang et al proposed a framework for the modeling and evaluation of product design problems in a computer networkoriented design environment 14 A product design problem is modeled in terms of interacting objects, called modules, each representing a specific aspect of the problem Modules interact with one another through services that allow the exchange of information Gadh and Sonthi defined and identified different levels of geometric abstraction that are necessary for Internetbased VP 4 Shah et al developed an architecture for standardizing communications between geometric modeling core systems and applications 18 Han and Requicha proposed a similar approach that provides transparent access to diverse solid modelers 6 Wang and Wright described a distributed manufacturing service 20 They emphasized how current CAD tools will evolve to facilitate the distributed design and fabrication process Hardwick et al proposed an infrastructure 2 Copyright 1999 by ASME

3 that enhances collaboration between companies in the design and manufacture of new products 7 This architecture integrates the WWW for information sharing on the Internet with the STEP standard for product modeling Martino et al proposed an approach to linking the design process with downstream engineering processes based on an integrated feature-based modeling approach that supports both design-by-features and feature recognition 13 SYSTEM OVERVIEW The architecture of the proposed Web-enabled featurebased modeling system is shown in Figure 1 It consists of a Feature Modeling Server, Web-based Clients, and a CORBAbased standard communication protocol Feature Modeling Server Feature Agent Manager Neutral Feature Model Solid Modeling Kernel Communication Protocol Web-based Clients Client-Side Feature Model Attributed Abstracted B-rep Communication Protocol CORBA, Network (Internet, Intranet, WWW) Figure 1 System Architecture for Web-enabled featurebased modeling The Feature Modeling Server offers the functionality needed for feature modeling and other applications, and is shared among application tools It consists of Feature Agent Manager, Neutral Feature Model, and Solid Modeling Kernel The Feature Agent Manager is a meta object that manages all the agents that serve various clients connected to the server Each agent takes responsibility for answering requested services to each connected client The Neutral Feature Model corresponds to an integrated feature-based representation of the product It is built upon the Solid Modeling Kernel with a generic naming scheme The generic naming scheme generically names geometric entities that are invariant over geometric processings such as topological changes and Boolean operations 2,9 Thus, it is possible to support feature interaction management, transparent relationship between geometric entities of the server and clients, real-time feature modeling update, and attribute mechanism ACIS is used as the Solid Modeling Kernel Various applications such as feature-based design, feature recognition and process planning can run in Web-based clients Each client can view and extract the necessary data required in GUI its application context from the Neutral Feature Model Since the client must have decoupled and agential capabilities, it should provide 1) unambiguous and exact representation of parts in its domain, real-time displays of the represented parts, fast navigation, and a user-friendly interface For this reason, each client has two types of models: 1) Client-Side Feature Model and 2) Attributed Abstracted B-rep (AAB) Since this paper focuses on the integrated feature-based modeling system for design and manufacturing, form features or machining features can be the Client-Sided Feature Model 12,17 The Attributed Abstracted B-rep is a simplified B-rep of the Neutral Feature Model It consists of approximated faceted data with generic name identifiers Thus, it is used for 1) maintaining naming consistency between geometric entities of the server and clients and 2) minimizing interactions with the server for client side processings This makes it possible that a large set of processings can be done in the client side without interactions with the server so that the user can proceed modeling operations as if he/she is doing the work in a stand-alone machine CORBA-based standard communication protocol offers the standard view of the modeling server to the layers and applications built on top of it It forms an interface which is built along the lines of CAM-I AIS philosophy 1 It consists of CORBA IDL interfaces that offer a set of solid and feature modeling services The member methods of the interface call functions of the feature model server These methods provide services to instance primitives, perform Boolean operations, sweep and sweep planar profiles, delete solids, perform transformation operations and service topological and geometric queries DISTRIBUTED FEATURE-BASED MODELING Neutral Feature Representation Basic functions of the Neutral Feature Model include creation/deletion of geometric entities, topological queries, property queries, and modification functions such as Boolean operations and sweeping However, one of the main problems in representing and modeling features in a common and neutral structure concerns problems of feature interaction and of shape data sharing 13 Shape features of different views can interact and have overlapping parts That is, features are not always disjoint but may intersect and/or overlap, completely or partly Thus, one shape entity can belong to more than one feature at the same time However, this kind of feature interactions can cause a naming inconsistency problem among geometric entities so that a feature or a solid shared by multiple systems cannot be distinguished Another problem is how to store other information on features rather than geometric information such as surface finish, dimension & tolerance, and design intent The following subsections discuss an attribute attaching 3 Copyright 1999 by ASME

4 mechanism and a generic naming scheme of the Neutral Feature Model Attribute mechanism The necessary information on features is stored in a boundary representation (B-rep) model as attributes An attribute is attached to each feature solid, face, edge, or vertex in a B-rep model as ATTRIB class instances as shown in Figure 2 ACIS provides a mechanism to attach user-defined attributes to any entity in the data structure Moreover, each geometric entity can have various application specific attributes (Figure 2(a)) For instance, each face can be assigned with attributes that reference the design features that are responsible for forming the face This attribute information is maintained during solid modeling operations By examining the attributes attached to the faces of a feature after a modeling operation, thus, we can identify real faces and virtual faces, as shown in Figure 2(b&c) This information on virtual faces can be used for various applications such as constructing the closure volume of a feature and finding the tool approach directions and cutting motions to proceed without collisions For a splitting instance, three faces, f 1, f 2, and f 3, of the feature F 1 are split after adding the depression feature F 2, as shown in Figure 3(b) On the other hand, if a face of a newly added feature overlaps with a face of other feature in the current design model, the two faces are merged to a face For the example shown in Figure 3(c), after adding a new depression feature F 2, the faces f 1 and f 3 of the feature F 1 are merged with the side faces of the feature F 2 to the faces f 1 and f 3, respectively Note that the task of feature-based applications may be extremely difficult without handling feature interactions 12 This is why it is hard for traditional feature recognition approaches to handle complex feature interactions appropriately Thus, the information on split, trimmed and merged faces must be well managed to effectively handle feature interactions f 1 Stock f2 f 4 f 5 f 1 f 3 f 2 f 6 ENTITY attrib_ptr ATTRIB ATTRIB (a) Feature F 1 0 NEXT PREV ENT NEXT PREV ENT 0 f f 1 2 f 2 f 2 f 1 f 1 (a) f 3 f 3 f 3 Feature F 1 (b) Feature F 2 Feature F 2 Delta volume Virtual faces Real faces f 1 f 1 (b) (c) Figure 2 Attaching attribute information on geometric entities: (a) attribute pointers, (b) adding a feature, (c) virtual and real faces f 3 f 3 Generic naming scheme During feature-based modeling operations, Boolean operations are constantly applied to features, and the boundary evaluation process iteratively merges the solid representation of the single design feature entities into the part s final solid model According to the boundary evaluation process, however, the geometric shape of a feature may change during the process of adding features to the current design model That is, either a certain face of the feature is removed or part of the face is trimmed For example, Figure 3(a) shows trimmed faces after adding a depression feature F 1 to the stock f 1 and f 2 are trimmed to f 1 and f 2, respectively, and f 3 ~ f 6 are newly created Feature F 1 (c) Figure 3 Trimming, splitting and merging of faces In this research, using a generic naming scheme, we manage all the topological changes of faces such as trimming, merging and splitting caused by feature interactions 9,12 The generic naming scheme plays the following several important roles in feature-based applications: 1) Provide naming consistency between geometric entities of the server and their clients 2) Provide a scheme for minimizing network delay caused by distributed feature modeling operations 4 Copyright 1999 by ASME

5 3) Identify topological entities of solid models in such a way that the same entities can still be identified after the models have been re-evaluated from parametric design operations 9,11 4) Check the validity of machining features caused by feature interactions 12 In this paper, we focus on the first and second roles of the scheme The scheme keeps information about how faces of a model were created, split, merged, and deleted as shown in Figure 4 It is based on a directed acyclic graph called FaceIdGraph consisting of FaceIdNodes The incoming edges to a FaceIdNode represent information about the ancestors of this face, and the outgoing edges represent what happened to the face Figure 4 shows an evolving FaceIdGraph according to feature modeling operations f11 f12 f13 f11 f12 f13 f23 f31 f23 (a) (b) (c) f31 f32 f33 (d) f44 f51 f52 f53 f54 f44 f32 f31 f54 f52 f33 f53 f51 (Step 1) Create a block: Figure (a) (Step 2) Create a slot: Figure (a) (Step 3) Add the slot to the block: Figure (b) (Step 4) Create another slot: Figure (b) (Step 5) Add another slot to the part: Figure (c) FaceIdGraph generated by feature modeling Note: In this example we use notation fm,n denoting a face created during StepId m and with index n at the step m Figure 4 FaceIdGraph generated by feature-based modeling Note that a FaceIdNode is an attribute that can be attached to a face Further, the FaceIdNode contains the following data: 1) An identifier called FaceId 2) A real or virtual tag: the feature face is real when it corresponds to a face in the boundary representation of the final object, and is virtual when it does not correspond to a face in the final object 3) A link to a corresponding face in the boundary representation of the final object, if exists 4) A list to features to which the face belongs, together with the specification of the context where the feature is meaningful FaceIds are the principal types of identifiers Regularized solid models are 3D volumes bounded by a set of faces Edges and vertices are considered to be intersections of bounding faces, and thus, EdgeIds and VertexIds are defined in terms of their adjacent FaceIds Each face in the boundary of a solid model is assigned a unique FaceId The FaceId of a face f is defined by three components 9 : FaceId(f) = [stepid, faceindex, surfacetype] where stepid is the ID of a modeling step during which f was created, faceindex is the face index of the face f within the step stepid, and surfacetype is the type of the underlying surface of the face Edges are considered to be intersections of two or more faces; EdgeId of edge e is therefore defined in terms of FaceIds of faces surrounding the edge: EdgeId(e) = [adjfaceids, endfaceids 0,1 ] where adjfaceids is the ordered cyclic list of FaceIds of faces sharing edge e, endfaceids 0 is the unordered set of FaceIds of faces at one end of edge e, endfaceids 1 is an unordered set of FaceIds of faces at the other end of edge e In a similar manner, VertexIds are defined in terms of surrounding FaceIds Standard communication protocol The combination of generic geometric services and a neutral protocol essentially amounts to the creation of a geometric service husk for supporting commonly needed functions for a variety of applications CORBA IDL interfaces We view any user requested computational process as a service, and a service can only be invoked by calling a method of a CORBA object Any CORBA object to be accessed by other computational units has a corresponding CORBA definition This is realized by using the CORBA s Interface Definition Language (IDL) and the Application Programming Interfaces (API) that enable client/server object interaction within a specific implementation of an Object Request Broker (ORB) The ORB provides interoperability between applications on different machines in heterogeneous distributed environments and seamlessly interconnects multiple object systems Based on this concept, a CORBA IDL called DFMInterface is defined for a distributed feature modeling protocol as shown in Figure 5 In the protocol, a class named AgentManager manages all the agents connected to the server It provides several functions such as checking in/out, creating/deleting agents, transactions, etc Moreover, an agent named FAgent is defined to serve an application-orient client The FAgent provides all the necessary functionalities of the neutral feature model such as creating/deleting entities, geometric/topological queries, properties, visualization data access, and attribute attaching mechanism 5 Copyright 1999 by ASME

6 module DFMInterface { /* declarations */ interface AgentManager { FAgent CreateAgent(in string name); long CheckIn(in string userid, in string passwd); long CheckOut(in FAgent agent); void DeleteAgentByObject(in FAgent agent); FAgent Load(in string name, in long type); void Save(in string name, in FAgent agent); void SaveAs(in string name, in FAgent agent); }; interface FAgent { - Creation/deletion - Geometric/topological queries - Properties - Modifications - Analysis - Attribute-based mechanism - Visualization data access (Attributed Abstracted B-rep information) - Transferring To/From Disk }; }; Figure 5 CORBA IDL protocol Naming consistency between the server and client Application-oriented clients and server need a generic name or identifier for each modeling entity in order to communicate with one another because each client and the server maintain their own data models Each geometric entity is generically named by a structure of identifiers For example, B-rep entities such as faces are designated by a structure of integer and constant identifiers as shown in Figure 6(a) (see also Figure 4) The first and second fields of a faceid structure designate the particular stepid and faceindex, respectively The last field represents a surface type Similarly, an edgeid consists of adjacent faceids and an edge type Note that the task of the communication layer is to hide all these differences and provide uniform and transparent geometric services to applications 18 The communication layer must correlate generic names with the internal geometric entities used in the modeling server as shown in Figure 6(b) The layer encapsulates the modeling entities and passes the generic names of the encapsulated entities to the applications The applications communicate with the protocol through these generic names Thus, applications can be designed independently of how the entities are internally organized or represented in the server For instance, when a client asks the modeling server to create a feature, the communication layer: (1) creates a solid of the feature inside the modeling server built upon the ACIS solid modeling kernel; (2) obtains an ACIS pointer; (3) creates its FaceIdGraph; (4) tags generic name identifiers to geometric entities of the FaceIdGraph within the layer; (5) returns the generic name identifiers to the application Fid1 = [3, 1, PlaneType] Fid4 = [5, 4, PlaneType] Fid3 = [5,1, PlaneType] Fid denotes a face id and Eid an edge id where Fid = [stepid, faceindex, surfacetype] and Eid = [[adjfaceids], edgetype] f11 Fid2 = [5, 2, PlaneType] Eid1 = [Fid2, Fid5, StraightType] (a) Client-side Layer Topological entity ID (Generic name) - SolidId, FaceId, EdgeId, or VertexId (eg, Fid = [5,1, PlaneType]) Feature Model Layer - Solid Modeler - FaceIdGraph - f31 f32 (b) f51 f52 Eid1 = [Fid3, Fid5, StraightType] Fid5 = [5, 3, PlaneType] Communication Layer ID Mapping between server & clients - Generic name Id vs Ref of the Neutral Feature Model Figure 6 ID mapping between server and client Client-side processing Client-side processing is an important issue on the Web or network-centric environment This means that the server gives the client some of the responsibility for processing data 20 That is, the client must provide necessary functionalities for domaindependent client-side processings However, all these functionalities cannot be provided by the client itself Thus, it is important to balance necessary processings between the server and client and to minimize their interactions 6 Copyright 1999 by ASME

7 Attributed Abstracted B-rep (AAB) Attributed Abstracted B-rep (AAB) is introduced for the client-side model The AAB is an abstracted and simplified B- rep such that it can realize much data reduction for inexpensive and distributed systems Moreover, it can help a large set of client-side processings to be done with minimal communications with the server The AAB has two types of representations: 1) Face-based AAB and 2) Edge-based AAB The face-based AAB consists of FacetedFaces and the Edge-based AAB consists of FacetedEdges as shown in Figure 7 The face-based AAB is a B-rep consisting of triangulated polyhedrons that approximate the part, while the edge-based AAB is a B-rep of faceted edges that approximate the wireframe representation of the part Each FacetedFace consists of a FaceId for the generic name, a face equation FaceEq, and a TriangleList for display and other analysis purpose as shown in Figure 7 and 8 Each FaceId represents a generic name of a face and it is used as a communication identifier between the server and client The TriangleList of each face consists of Triangles with vertices and their corresponding normals Thus, it is possible to provide real-time displays, navigation, and various geometric interrogations such as mass property, area, and ray test However, the AAB does not support all the necessary functionalities that can be provided by the original geometric modeling kernel since it does not have topological information and geometric query functions In those cases, those functionalities can be accessed via the standard communication protocol Thus, the user can perform various modeling operations as if he/she is in a stand-alone machine <Attributed Abstracted B-rep (AAB)> ::= <Face-based AAB> <Edge-based AAB> <Face-based AAB> ::= ( <FacetedFace> {, <FacetedFace>} ) <FacetedFace> ::= (<FaceId>, <FaceEq>, <TriangleList>) <FaceId> ::= (stepid, faceindex, <surfacetype>) <surfacetype> ::= PlaneType CylinderType SphereType TorusType SplineType <FaceEq> ::= <PlaneEq> <CylinderEq> <SphereEq> <TorusEq> <SplineEq> <TriangleList> ::= (<Triangle> {, <Triangle>}) <Triangle> ::= (<Npoint>, <Npoint>, <Npoint>) <Npoint> ::= (<Point>, <Normal>) <Point>, <Normal> ::= (float, float, float) <Edge-based AAB> ::= (<FacetedEdge> {, <FacetedEdge>}) <FacetedEdge> ::= (<EdgeId>, <EdgeEq>, <PointList>) <EdgeId> ::= (<adjfaceidlist>, <edgetype>) <adjfaceidlist> ::= (<FaceId> {, <FaceId>}) <edgetype> ::= LineType EllipseType SplineType <EdgeEq> ::= <LineEq> <EllipseEq> <SplineEq> <PointList> ::= (<Point> {, <Point>}) <Point> ::= (float, float, float) Figure 7 Attributed Abstracted B-rep [3, 1, *] [5,1, *] Fid1 = [5, 4, *] T12 T11 T13 [5, 2, *] T16 T14 T15 FacetedFace1 = [Fid1, <FaceEq>, [T11, T12,,T16]] Fid2 = [5, 3, *] FacetedFace2 = [Fid2, <FaceEq>, [T21, T22,,T26]] Face-based AAB = [FacetedFace1, FacetedFace2, ] Figure 8 Face-based AAB Local update of AAB The AAB and the generic naming scheme make it possible to minimize the network delay according to incremental feature modeling operations It is quite inefficient if a client has to receive all the AAB from the server whenever the user edits a part Such inefficiency is the main reason of network delay, which makes it impossible to perform distributed feature modeling operations Thus, it is important to minimize the network delay by receiving the only portions of the AAB that must be modified, but the received data must be complete and compact As explained before, the generic naming scheme manages all the trimmed, merged, and split geometric entities Thus, it is possible to trace all topological changes of the AAB Figure 9 shows how the generic naming scheme supports local update of the client-side AAB according to incremental feature modeling operations When D 1 is designed as an initial feature, all the faceted faces f11 ~ f18 are transmitted to the client At this stage, the initial FaceIdGraph consists of eight FaceIdNodes as shown in Figure 9(a) However, when a through hole D 2 is added to D 1, f13 and f17 are trimmed and changed to f31 and f32, respectively (Figure 9(b)) In addition, f21 is added to the FaceIdGraph as a new face Thus, the following faces are created, deleted, and updated for the local update of the AAB: NewFaceIds = {f21} DeletedFaceIds = {f13, f17} UpdatedFaceIds = {f31, f32} In the client, existing f13 and f17 are deleted, f21 is received as a new face, and f31 and f32 are updated The other faces remain unchanged Similarly, when D 3 is added to the existing part, f51 is split to f52 and f53, and f14 and f16 are trimmed to f51 and f54, respectively Thus, the following local update occurs again: NewFaceIds = {f41, f42, f43} DeletedFaceIds = {f14, f15, f16} 7 Copyright 1999 by ASME

8 UpdatedFaceIds = {f51, f52, f53, f54} Note that the other unchanged faces do not have to be received from the server again For instance, f21 is a cylindrical face and thus has many triangles in the faceted triangle list, but it remains unchanged so that it does not have to be received again This shows how the proposed approach minimizes the network delay by effectively and locally updating the AAB This is a crucial issue but many research works have not dealt with seriously for distributed computing and modeling Incremental Feature Modeling D 1 : user-defined feature (linear sweeping of a section) FaceIdGraph Update Dynamic Update of AAB (a) f16 f15 f14 f13 f18 f11 FaceIdGraph consists of eight FaceIdNodes (f11 ~ f18) f18 NewFaceIds = {f11, f12,, f18} DeletedFaceIds = {} UpdatedFaceIds = {} f11 f17 f12 (b) D 2 : add a hole f21 f13 f21 f31 NewFaceIds = {f21} DeletedFaceIds = {f13, f17} UpdatedFaceIds = {f31, f32} f17 f32 f31 f32 f42 f41 f52 D 3 : add a slot f41 f42 (c) f53 f43 f51 f15 f43 f52 f53 NewFaceIds = {f41, f42, f43} DeletedFaceIds = {f14, f15, f16} UpdatedFaceIds = {f51, f52, f53, f54} f54 f14 f51 f16 f54 SYSTEM IMPLEMENTATION The proposed approach has been implemented as a Web- Enabled Feature-based modeling module (WEF) of the Web- Enabled Solid and Assembly modeling system (WESA) The WEF has the architecture of multiple clients and a central server as shown in Figure 10 The server has been implemented in C++ and the client has been implemented in Java In particular, Java3D is used for graphical rendering and navigation purpose The communication between the server and clients is done via the CORBA-based communication interface System modules Main system modules of the WEF include WEF server, WEF client, database server, and CORBA-based distributed Figure 9 Local update of AAB computing protocol as shown in Figure 10 A typical feature modeling procedure takes the following steps First, the user uses a World-Wide Web browser to enter the WEF site and downloads a Java applet (1) The client in the applet connects to an agent in the WEF server (2) Then, the agent connects to a database server for transaction management (3) Finally, the user is ready to load or save data from/to the database server For example, for loading data from the database server, the user is asked if he/she wants to check this data out of the database server When the checkout is validated, the data are transmitted to both the modeling server and the client (the neutral feature data are transmitted to the modeling server, and the clientoriented data are transmitted to the client) In addition, the designer can create a part through selection and instantiation of pre-defined design features or user-defined features from the feature library The client-side feature library consists of an object-oriented description of generic design 8 Copyright 1999 by ASME

9 features such as slot, step, hole, pocket, and rounding Each description contains the parameter list, dimension and location parameters, geometric constraints, and various other attributes The values of characteristic parameters are set directly on the user interface level of the WEF client Then, a list of parameters is sent to the WEF server via the communication protocol After consistency validation checking of the parameter list, the WEF server creates the neutral model (eg, canonical solid volume) of the design feature and performs several geometric processings according to the user s intent If all the necessary processings are successfully done, the WEF server transmits the AAB of the neutral model to the WEF client Finally, the AAB is displayed on the WEF client in a Web browser The same process continues until a desired model is created Note that the database server manages two types of data: 1) WEF data and 2) STEP data The WEF data have our generic data formats for feature-based modeling that consist of the client-oriented feature model and neutral feature model The correspondence between the client-oriented feature model and neutral model is maintained by the generic naming scheme and name identifiers as explained before On the other hand, the STEP data are AP203 physical files that can be imported from any commercial CAD systems Thus, the user can load the WEF data for feature modeling or import the STEP data for viewing and analyzing STEP files For effective visualization of the AAB, the scene graph is used to provide an interface to the Java3D graphics library The scene graph constructs a part description specific of the AAB to the Java3D library WEF Clients Sets of Java Applet Classes User Interface AAB Part Representation Feature Representation Stub Client-side Processings Scene Graph for Java3D http (1) Web Server WEF data DB Server STEP data (2) CORBA over Internet WEF Server (3) Skeleton Neutral Feature Model Solid Modeling Kernel Generic Naming Scheme Attribute Mechanism Figure 10 System modules Examples Figure 11 shows a snapshot of an object that is designed in a WEF client The object consists of a basic stock feature, a lateral rib design feature, two rectangular slot design features, and two hole features The rib is designed on the top face of the stock (See also Figure 12) Then, Slot1 is attached to the top face of the rib, and Slot2 is attached to the bottom face of Slot1 Finally, two holes are added on the top face of the stock For the sequence of the attached design features, the system also generates the parent-child relationship among features as shown in Figure 12(a) Moreover, Figure 12(b) shows the final AAB according to the incremental boundary evaluation of the design feature tree As the figure shows, real boundary entities can change status or can be split, merged or trimmed throughout the modeling operations For example, the top face of the stock has been changed as follows: 1) Initially, f1* is the top face of the design feature stock; 2) After the rib attachment: f1* is trimmed to f3*; 3) After Slot1 and Slot2 attachments: however, f3* remains unchanged; 4) After the first hole attachment: f3* is trimmed to f 9*; 5) After the second hole attachment: f9* is trimmed to f 11*; Similarly, the side face of the rib face1 has been changed as follows according to the Slot1 and Slot2 attachments: ( 9 Copyright 1999 by ASME

10 f2* f5* f7* ) On the other hand, face3 and face4 remain unchanged This example shows how features are attached in a WEF client, how the generic names of geometric entities are identified and maintained, and how the client and server communicate with each other to minimize the amount of data exchange by locally updating the AAB Figure 13 shows the visualization of STEP AP203 data containing a drill assembly The drill has been assembled in a commercial CAD software, SolidWorks Then, the assembly has been saved in a STEP file format Finally, the STEP file has been imported into the WESA system In the WESA system, each part is converted to a neutral feature model by attaching generic identifiers Then, the AAB of the neutral model is transmitted to the WEF client Moreover, the assembly hierarchy is also extracted from the STEP data and transmitted to the WEF client as shown in Figure 13 Figure 14 shows a good example of client-side processing: collision detection in an assembly model We can detect the interference or collision of parts by creating cross section views of the model and by identifying the model parts that are within a specified clearance distance of other parts This processing is done in a client without interaction with the server as the figure shows However, since the client-side model is based on the approximated model, the collision detection may be incorrect even the tolerance of the AAB can be controlled Thus, WESA provides two types of collision detection modes: 1) fast collision detection and 2) exact collision detection The fast collision detection is performed in a client without interacting with the server It is useful in dynamic and rough collision detection for virtual assemblability analysis and assembly Stock face5: (f2* f3*) Slot1 simulation In contrast, the exact collision detection is performed on the server side (eg, Boolean intersections) where the precise geometry information is available, and then the result is returned to the client It is slow but gives an exact solution It can be used in static collision detection such as interference checking of the final assembly model Figure 11 Snapshot of the WEF client Slot2 face1: (f2* f5* f7*) Slot1 Rib Hole1 Hole2 Rib face2: (f1* f3* f9* f11* ) Hole2 face4: (f1*) Slot2 Hole1 Feature adding sequence: Stock Rib Slot1 Slot2 Hole1 Hole2 Stock (1) fmn: m and n are the stepid and faceindex, respectively However, the faceindex is designated by * for simplicity (2) indicates the change of a face face3: (f8*) (a) Figure 12 An example part in Figure 10 and related information: (a) design feature tree, (b) features and AAB (b) 10 Copyright 1999 by ASME

11 CONCLUSION Figure 13 Visualization and analysis of a STEP AP203 file This paper presented a novel approach for modeling features in a distributed design environment The proposed approach has been implemented in a client/server architecture, in which Web-enabled feature modeling clients, neutral feature model server, and other applications communicate with one another using a standard communication interface This paper focused on 1) the neutral feature model representation and 2) client-side processing It also described how the system architecture should be for cost-effective, flexible, and portable distributed modeling Some advantages of this research are summarized as below: 1) The neutral feature model server acts as a service provider to distributed applications Moreover, it provides a generic naming scheme for naming consistency so that it can handle feature interactions and maintain the relationship between the geometric entities of the server and clients 2) The Attributed Abstracted B-rep (AAB) is introduced for client-side processing and for client-side data model The AAB is an abstracted and simplified B-rep such that it is appropriate for inexpensive and distributed processings Moreover, it helps the client have minimal interactions with the server during feature modeling operations Thus, it supports real-time feature modeling operations 3) The WEF client is programmed in Java so that it is platform-independent The user only needs a common Web browser for feature modeling No software installation is needed Further, no software upgrade and maintenance are needed, either However, there are also some issues to be investigated further in the future research as below: 1) It requires much work for collaborative modeling environment It will require the integration of additional support tools with the system such as , video conferencing, XML or SGML document, etc 2) We are also implementing a multi-server/multi-client system for more effective modeling When the number of WEF clients increases, the performance of the server decreases Thus, the distribution of clients inside multi-servers is being studied, and strategies on how to distribute these clients among the servers are being developed ACKNOWLEDGMENTS Figure 14 A client-side processing: cross sectioning This research has been supported by Korean Ministry of Information and Communication (Grant No 9MC4900) 11 Copyright 1999 by ASME

12 REFERENCES 1 CAM-I, Application Interface Specification AIS 20 Technical Report R-90-PM-03, Consortium for Advanced Manufacturing, Capoyleas, V, Chen, X, and Hoffmann, C M, Generic naming in generative, constraint-based design Computer- Aided Design, 28(1), 17-26, Cutkosky, M R, Tenenbaum, J M, and Glicksman, J, Madefact: collaborative engineering over the Internet Communications of the ACM, 39(9), 78-87, Gadh, R and Sonthi, R, Geometric shape abstractions for internet-based virtual prototyping, Computer-Aided Design, 30(6), , Gupta, S K, Automated manufacturability analysis of machined parts PhD Thesis, University of Maryland, Han, J H and Requicha, A A G, Modeler-independent feature recognition in a distributed environment Computer- Aided Design, 30(6), , Hardwick, M, Spooner, D L, Rando, T, and Morris, K C, Sharing manufacturing information in virtual enterprises Communications of the ACM, 39(2), 46-54, Kim, S, Yang, U, and Kim, J, COVRA-CAD: A CORBAbased distributed VR CAD Systems Int Conference on Virtual Systems and Multimedia, Kripac, J, A mechanism for persistently naming topological entities in history-based parametric solid models Computer- Aided Design, 29(2), , Lee, J Y, A knowledge-based approach to feature-based parametric modeling, PhD Thesis, POSTECH, Korea, Lee, J Y and Kim, K, A 2D geometric constraint solver using DOF-based graph reduction Computer-Aided Design, 30(11), , Lee, J Y and Kim, K, A feature-based approach to extracting machining features Computer-Aided Design, 30(13), , Martino, T D, Falcidieno, B, and Hasinger, S, Design and engineering process integration through a multiple view intermediate modeller in a distributed object-oriented system environment Computer-Aided Design, 30(6), , Phang, F, Senin, N, and Wallace, D, Distribution modeling and evaluation of product design problems Computer- Aided Design, 30(6), , Regli, W C, Internet-enabled computer-aided design IEEE Internet Computing, 39-50, Regli, W C, Gupta, S K, and Nau, D S, Towards multiprocessor feature recognition Computer-Aided Design, 29(1), 37-51, Shah, J J and Mäntylä, M, Parametric and feature-based CAD/CAM: concepts, techniques, and applications, John Wiley & Sons Inc New York, Shah, J J, Dedhia, H, Pherwani, V, and Solkhan, S, Dynamic interfacing of applications to geometric modeling services via modeler neutral protocol Computer-Aided Design, 29(12), , Trika, S N, Banerjee, P, and Kashyap, R L, Virtual reality interfaces for feature-based computer-aided design systems Computer-Aided Design, 29(8), , Wang, F-C and Wright, P K, Web-based CAD tools for a networked manufacturing service, Proceedings of DETC 98 ASME Design Engineering Technical Conference, Atlanta, Georgia, CIE-5517, Copyright 1999 by ASME