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, 305-350, South Korea
[email protected] 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 development2,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 analysis4,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 distributed6,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 systems7. 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 (e.g., 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 environment4,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
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 platforms15. 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 models1. Communication between applications and the modeler is channeled through the AIS implementation, which maps the AIS procedure calls into modeler-specific API calls6. 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 environment14. 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 VP4. Shah et al. developed an architecture for standardizing communications between geometric modeling core systems and applications18. Han and Requicha proposed a similar approach that provides transparent access to diverse solid modelers6. Wang and Wright described a distributed manufacturing service20. 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
that enhances collaboration between companies in the design and manufacture of new products7. 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 recognition13. 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
Web-based Clients Client-Side Feature Model
Solid Modeling Kernel
Attributed Abstracted B-rep
GUI
Neutral Feature Model
Communication Protocol 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 operations2,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
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 Model12,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 philosophy1. 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 sharing13. 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
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, f1, f2, and f3, of the feature F1 are split after adding the depression feature F2, 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 F2, the faces f1 and f3 of the feature F1 are merged with the side faces of the feature F2 to the faces f1′ and f3′, respectively. Note that the task of feature-based applications may be extremely difficult without handling feature interactions12. 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. f1′
f1 f2
f3
f4
f2′
f5
Stock
f6 Feature F1
ENTITY
attrib_ptr
0
ATTRIB
ATTRIB
NEXT
NEXT
PREV
PREV
ENT
ENT
(a) 0
f1
f2
(a)
f1′
f2
f1
f 2′
f3 ′
f3
f3
Feature F1
Feature F2 (b)
Delta volume
(b)
Virtual faces
Feature F2
f1
Real faces
f1′
(c)
Figure 2. Attaching attribute information on geometric entities: (a) attribute pointers, (b) adding a feature, (c) virtual and real faces
f3 f3 ′
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 F1 to the stock. f1 and f2 are trimmed to f1′ and f2′, respectively, and f3 ~ f6 are newly created.
Feature F1 (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 interactions9,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
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 operations9,11. 4) Check the validity of machining features caused by feature interactions12. 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.
f4.4 f3.1
f3.1 f5.1
f1.1
f3.2 f5.2 f2.3
f1.3
f1.2
f5.4 f3.3
(a)
(b)
f5.3
(c)
f3.1 f1.1
f5.1 f3.2 f5.2
(Step 1) Create a block: Figure (a) (Step 2) Create a slot: Figure (a)
f1.3
f5.3
f2.3 f5.4 f4.4
FaceIdGraph generated by feature modeling (d) Note:
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.
(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)
f3.3
f1.2
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 components9: 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, endFaceIds0,1] where adjFaceIds is the ordered cyclic list of FaceIds of faces sharing edge e, endFaceIds0 is the unordered set of FaceIds of faces at one end of edge e, endFaceIds1 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.
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.
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
module DFMInterface { /* declarations */ . .
(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. Fid2 = [5, 2, PlaneType]
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); . . . };
Fid1 = [3, 1, PlaneType]
Fid3 = [5,1, PlaneType]
Eid1 = [Fid3, Fid5, StraightType] Fid4 = [5, 4, PlaneType] Fid5 = [5, 3, PlaneType]
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 . }; . . };
Eid1 = [Fid2, Fid5, StraightType] Fid denotes a face id and Eid an edge id where Fid = [stepId, faceIndex, surfaceType] and Eid = [[adjFaceIds], edgeType]
(a) Client-side Layer Topological entity ID (Generic name) - SolidId, FaceId, EdgeId, or VertexId (e.g., Fid = [5,1, PlaneType])
Figure 5. CORBA IDL protocol
Communication Layer ID Mapping between server & clients - Generic name Id vs. Ref. of the Neutral Feature Model
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 applications18. 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:
Feature Model Layer -
Solid Modeler FaceIdGraph …
f3.1 f5.1
f1.1 f3.2
f5.2
(b)
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 data20. 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
Attributed Abstracted B-rep (AAB)
Attributed Abstracted B-rep (AAB) is introduced for the client-side model. The AAB is an abstracted and simplified Brep 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.
::= | ::= ( {, } ) ::= (, , ) ::= (stepId, faceIndex, ) ::= PlaneType | CylinderType | SphereType | TorusType | SplineType ::= | | | | ::= ( {, }) ::= (, , ) ::= (, ) , ::= (float, float, float) ::= ( {, }) ::= (, , ) ::= (, ) ::= ( {, }) ::= LineType | EllipseType | SplineType ::= | | ::= ( {, }) ::= (float, float, float)
Figure 7. Attributed Abstracted B-rep
[5, 2, *] [3, 1, *]
[5,1, *]
Fid1 = [5, 4, *] Fid2 = [5, 3, *] T11 T16 T15
T12 T13 T14
FacetedFace2 = [Fid2, , [T21, T22,…,T26]]
FacetedFace1 = [Fid1, , [T11, T12,…,T16]]
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 D1 is designed as an initial feature, all the faceted faces f1.1 ~ f1.8 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 D2 is added to D1, f1.3 and f1.7 are trimmed and changed to f3.1 and f3.2, respectively (Figure 9(b)). In addition, f2.1 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 = {f2.1} DeletedFaceIds = {f1.3, f1.7} UpdatedFaceIds = {f3.1, f3.2} In the client, existing f1.3 and f1.7 are deleted, f2.1 is received as a new face, and f3.1 and f3.2 are updated. The other faces remain unchanged. Similarly, when D3 is added to the existing part, f5.1 is split to f5.2 and f5.3, and f1.4 and f1.6 are trimmed to f5.1 and f5.4, respectively. Thus, the following local update occurs again: NewFaceIds = {f4.1, f4.2, f4.3} DeletedFaceIds = {f1.4, f1.5, f1.6}
7
Copyright © 1999 by ASME
UpdatedFaceIds = {f5.1, f5.2, f5.3, f5.4} Note that the other unchanged faces do not have to be received from the server again. For instance, f2.1 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 Incremental Feature Modeling
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.
FaceIdGraph Update
Dynamic Update of AAB
D1: user-defined feature (linear sweeping of a section) f1.1
f1.5 f1.4
f1.1
NewFaceIds = {f1.1, f1.2, …, f1.8}
FaceIdNodes (f1.1 ~ f1.8)
DeletedFaceIds = {} UpdatedFaceIds = {}
f1.3
f1.8
f1.6
(a)
FaceIdGraph consists of eight
f1.7
f1.8
f1.2
D2: add a hole
f2.1
NewFaceIds = {f2.1} f1.3
f3.1
f1.7
f3.2
DeletedFaceIds = {f1.3, f1.7} UpdatedFaceIds = {f3.1, f3.2}
f2.1
(b)
f3.2
f3.1
f4.1
f4.2
D3: add a slot
f5.2
f4.1 f4.2
f4.3
f4.3
f5.1
f5.3
f5.2 f1.5
(c)
f5.3 f5.4
f1.4
f5.1
f1.6
f5.4
NewFaceIds = {f4.1, f4.2, f4.3} DeletedFaceIds = {f1.4, f1.5, f1.6} UpdatedFaceIds = {f5.1, f5.2, f5.3, f5.4}
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 SYSTEM IMPLEMENTATION uses a World-Wide Web browser to enter the WEF site and downloads a Java applet (1). The client in the applet connects to The proposed approach has been implemented as a Weban agent in the WEF server (2). Then, the agent connects to a Enabled Feature-based modeling module (WEF) of the Webdatabase server for transaction management (3). Finally, the user Enabled Solid and Assembly modeling system (WESA). The is ready to load or save data from/to the database server. For WEF has the architecture of multiple clients and a central server example, for loading data from the database server, the user is as shown in Figure 10. The server has been implemented in C++ asked if he/she wants to check this data out of the database and the client has been implemented in Java. In particular, server. When the checkout is validated, the data are transmitted Java3D is used for graphical rendering and navigation purpose. to both the modeling server and the client (the neutral feature The communication between the server and clients is done via data are transmitted to the modeling server, and the clientthe CORBA-based communication interface. oriented 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 System modules features from the feature library. The client-side feature library Main system modules of the WEF include WEF server, consists of an object-oriented description of generic design WEF client, database server, and CORBA-based distributed
8
Copyright © 1999 by ASME
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 (e.g., 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
WEF data
Part Representation
Interface
AAB
http
Client-side Processings
Web Server STEP data
(1) Feature Representation
Scene Graph for Java3D
DB Server
Stub
CORBA over Internet (3) (2)
WEF Server 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
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 face5: (f2.*
Hole1
Figure 11. Snapshot of the WEF client
→f3.*)
Slot2
Slot1
Stock
Rib
simulation. In contrast, the exact collision detection is performed on the server side (e.g., 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.
face1: (f2.*
face2: (f1.*
Hole2 Rib
→f3.* →f9.* →f11.* )
Hole2
Slot1 Slot2
→f5.* →f7.*)
face4: (f1.*)
Hole1
Feature adding sequence: Stock → Rib → Slot1 → Slot2 → Hole1 → Hole2 Stock (1) fm.n: 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.*)
(b)
(a)
Figure 12. An example part in Figure 10 and related information: (a) design feature tree, (b) features and AAB
10
Copyright © 1999 by ASME
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 email, 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
REFERENCES 1. CAM-I, Application Interface Specification AIS 2.0. Technical Report R-90-PM-03, Consortium for Advanced Manufacturing, 1990 2. Capoyleas, V., Chen, X., and Hoffmann, C. M., Generic naming in generative, constraint-based design. ComputerAided Design, 28(1), 17-26, 1996. 3. Cutkosky, M. R., Tenenbaum, J. M., and Glicksman, J., Madefact: collaborative engineering over the Internet. Communications of the ACM, 39(9), 78-87, 1996. 4. Gadh, R. and Sonthi, R., Geometric shape abstractions for internet-based virtual prototyping, Computer-Aided Design, 30(6), 473-386, 1998. 5. Gupta, S. K., Automated manufacturability analysis of machined parts’ Ph.D. Thesis, University of Maryland, 1994. 6. Han, J. H. and Requicha, A. A. G., Modeler-independent feature recognition in a distributed environment. ComputerAided Design, 30(6), 453-463, 1998. 7. 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, 1996. 8. Kim, S., Yang, U., and Kim, J., COVRA-CAD: A CORBAbased distributed VR CAD Systems. Int. Conference on Virtual Systems and Multimedia, 1998. 9. Kripac, J., A mechanism for persistently naming topological entities in history-based parametric solid models. ComputerAided Design, 29(2), 113-122, 1997. 10. Lee, J. Y., A knowledge-based approach to feature-based parametric modeling, Ph.D. Thesis, POSTECH, Korea, 1998. 11. Lee, J. Y. and Kim, K., A 2D geometric constraint solver using DOF-based graph reduction. Computer-Aided Design, 30(11), 883-996, 1998. 12. Lee, J. Y. and Kim, K., A feature-based approach to extracting machining features. Computer-Aided Design, 30(13), 1019-1035, 1998. 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), 437452, 1998. 14. Phang, F., Senin, N., and Wallace, D., Distribution modeling and evaluation of product design problems. ComputerAided Design, 30(6), 411-423, 1998. 15. Regli, W. C., Internet-enabled computer-aided design. IEEE Internet Computing, 39-50, 1997. 16. Regli, W. C., Gupta, S. K., and Nau, D. S., Towards multiprocessor feature recognition. Computer-Aided Design, 29(1), 37-51, 1997. 17. Shah, J. J. and Mäntylä, M., Parametric and feature-based CAD/CAM: concepts, techniques, and applications, John Wiley & Sons Inc. New York, 1995.
18. 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), 811-824, 1997. 19. Trika, S. N., Banerjee, P., and Kashyap, R. L., Virtual reality interfaces for feature-based computer-aided design systems. Computer-Aided Design, 29(8), 565-574, 1997. 20. 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, 1998.
12
Copyright © 1999 by ASME
