- Email: [email protected]
CAPP integration
Computers ind. Engng Vol. 18, No. 4, pp. 435-444, 1990
:
Printed in Great Britain. All rights reserved
APPLICATION
OF PDES TO CAD/CAPP
0360-8352/90 $3.00+ 0.00 Copyright © 1990 Pergamon Press pk
INTEGRATION
MUKASA E. SSEMAKULA a n d AJAY SATSANGI Department of Mechanical Engineering, University of Maryland, College Park, MD 20742, U.S.A.
(Received for publication 13 March 1990) Ablm'aet--process planning plays a key role in the integration of the design and manufacturing functions, because it is the function responsible for covening design specifications into manufacturing instructions. In this paper, we describe the development of a robust interface between a process planning system and a CAD system using the new and emerging Product Data Exchange Specification (PDES) standard for product data definition. The relevant feature data constituting the part definition are extracted from the design database and used as input to the process planning system. Based on this input, a detailed process plan is generated by the system and this can be used to physically manufacture the part. This demonstrates a good basis for true integration between CAD and CAM.
1. INTRODUCTION
With the rising importance of industrial competitiveness, the need for technological improvements in the manufacturing arena is becoming acute. It is clear that automation will be the source of many of these improvements. Automation in manufacturing can speed product turnaround, reduce the need for retooling, and lead to a more efficient allocation of resources. This automation can be achieved by implementing a Computer Integrated Manufacturing (CIM) system. There are a number of obstacles; however, to the implementation of a fully integrated, and automated manufacturing system. One of the major obstacles is the lack of smooth information flow between Computer Aided Design (CAD) systems, and Computer Aided Manufacturing (CAM) systems. Traditionally, these two functions have developed as independent activities, with no feedback from CAM to CAD to reflect manufacturability considerations. To realize CIM, integration between CAD and CAM is necessary. Many CAD/CAM vendors claim to have working versions of integrated CAD/CAM systems. Indeed these systems generally have the capability of generating NC part programs based on the geometry of a part designed in CAD. However, a close scrutiny of such systems often reveals the need for extensive human interaction. The user is still required to provide crucial manufacturing data to the system in order to generate workable NC programs. For example, the sequence of operations, cutting parameters, and cutting tools must be determined by the user. All these data originate from the process planning function, and this suggests that process planning is the essential link between design and manufacturing. Here, we present work based on the concept of design by features. A designer selects a feature from a library of predefined features to create the design. The computer database then stores the feature as an entity. With this approach, the problem of feature recognition and extraction is eliminated. This simplifies the problem of interfacing CAD with CAPP because feature recognition is the major hurdle in transferring information from CAD to CAPP. The first step is to identify a data structure which is suitable for representing manufacturing features. The feature data structure must be able to represent complex structural objects whose components may be either geometrical, topological or technological in nature. The information provided by implicit design features must be complete enough to enable explicit instantiation of those features, which may be required by process planning, inspection, and administrative areas, among others. 2. PROBLEM DEFINITION
2.1. CAD systems overview CAD systems have evolved from their earliest applications as simple drafting aids, to their current level of sophistication; which enables detailed analysis of the part design to be carried out. 435
436
MUKAS^ E. SSEMAKULAand AJAY S.~'rsxNGI
This requires that the CAD part representations contain extensive part description data. The three most important part modeling techniques are: (1) Wireframe models; (2) Boundary Representation (B-Rep) models; (3) Constructive Solid Geometry (CSG) models. The component description which is stored in the database forms the heart of the CAD system. A solid modeler allows the user to design and store a model of a 3-D solid object in a robust database containing both geometry and topology. The two major database formats for solid modelers are the CSG tree of primitive volumes and associated Boolean operations used to construct the part; and the boundary representation (B-Rep) containing faces, edges, and vertices of the resultant object. In an integrated design and manufacturing system, CAD serves as a repository of all the part definition data. All other applications in the system need to retrieve the relevant part definition data contained in the CAD database. Manufacturing applications generally operate on the basis of features and so the part definition data should be interpretable in the form of feature data. It is therefore necessary in an integrated system that downstream applications be able to retrieve and interpret data in the CAD database according to their particular needs. 2.2. CAD databases
After an object has been defined, the modeler converts the input to a storage data structure maintaining the geometry and topology of the part. Three major forms of storage exist: CSG, B-Rep and MESH [1]. CSG and B-Rep storage structures are analogous to the CSG and B-Rep model construction techniques. For example CSG stores the model as a tree where the leaves are primitives and the nodes are Boolean operators. With B-Rep storage, linked lists of all vertices, edges, and faces constituting the geometry and topology are maintained. In this case the computation required to evaluate the various entities is extensive. In return for the large number of calculations in the construction mode, B-Rep modelers givea resultant data structure which is more detailed and more convenient for use by the analysis and output processors than the CSG storage method. B-Rep stores the actual model description whereas CSG stores instructions for how to construct the model. MESH storage is not widely used and we concentrated on evaluating CSG and B-Rep. In selecting a solid modeler to use for CAD/CAPP integration, specification of a CAD part representation becomes a major consideration. Armstrong [2] started with a B-Rep database and transformed it into a cell enumeration format for determination of NC tool paths. Woo [3] used CSG to define part features, whereas Chang [4] used a B-Rep database to generate process plans as well as NC tool paths. It is not obvious which type of storage technique is superior for use in integration of CAD with other applications. The choice would be determined by the type of information needed, and the extent of calculation required to derive it. A summary of the two most widely used solid modeling techniques and their part representation schemes is shown in Table 1. The CSG tree stores a model in an implicit or unevaluated form; the edges and vertices of the final part must be calculated from the set operations on the primitives. The features of the object however may be present in the CSG tree in explicit form. It is possible though that some features may not be present in the tree and they may arise from evaluation of the CSG tree; for example a slot may be formed by uniting two small blocks to a larger block. The B-Rep graph on the other hand, contains an explicit or evaluated model, The faces, edges, and vertices are represented explicitly. In this case however, the features are implicit, requiring interpretation of the geometry and topology. This explicit/implicit difference has a great influence on the format of the CAD/CAM link. The above comparison would seem to suggest that manufacturing features may more easily be extracted from the C S G tree because it can describe them explicitly.For example, if the designer used only machining primitives, the object could be created by beginning with a block stock of material and simulating the manufacturing steps during the design process by subtracting primitive volumes defined as slots, holes or other routinely used features. The resulting C S G tree would
Application of PDES to CAD/CAPP integration
Table 1. Part representation in solid modelers Modeling technique CSG B-Rep
Model representation Implicit Explicit
437
,~I
Feature representation Explicit Implicit
Fig. I. Non-unique feature construction in CSG.
contain explicit solid descriptions of all features in an unevaluated form. Arbab [5] has developed a system using just such an approach with his Deforming Solid Geometry (DSG) concept. That approach has some obvious advantages over the use of B-Rep data structures but there are at least two major difficulties. The first difficulty is that it requires that the designer, in addition to optimizing the design, must also be involved with the manufacturing task by using only a limited selection of machining primitives. In general, the designer is interested in the functionality of the part and will generate many intermediate designs before arrifing at a satisfactory solution. It is clearly inconvenient for the designer to simultaneously determine a sequence of feature creation for all design iterations. Moreover, the use of machining primitives is too restrictive, and inappropriate for design analyses such as kinematic analysis or finite element analysis. The second difficulty with interpreting the CSG tree to determine process plans is the problem of non-unique trees. A feature can be constructed in multiple ways. A slot can result from subtraction of a block or it may result from adding two blocks to a larger block as in Fig. 1. To consider all possible primitive combinations for a certain feature type would be a daunting task. There is an additional problem arising from the complexity of the CSG tree. To verify the presence of a particular feature, one approach would be to look for obvious primitive volume operations which would suggest the feature. Consider again the case of subtracting a block to create a slot. To ensure that the slot indeed does exist, the complete tree must be examined to check if any subsequent primitive operations overlap this block, and if so, to determine if they affect the making of the slot. The process of proving the existence of a feature is essentially a partial evaluation of the tree, and if this evaluation must be done for every suspected feature, the computational cost could rapidly surpass that required to generate a B-Rep database. Because of the non-unique representation scheme of CSG, and the desire to allow designers to be free from process planning details, it was decided to use B-Rep based part models for this research. The B-Rep data contains the evaluated model independent of the original building primitives. This allows a fresh view of the model, to perform manufacturing planning and other downstream functions, unrelated to the particular sequence used during the design stage. 3. APPROACHES TO CAD/CAPP INTEGRATION
3.1. Automatic feature extraction It is clear that features data are required to drive process planning, and that process planning is the essential link between CAD and CAM. For a true integration between CAD and CAPP, an automatic interpretation of the CAD data is necessary. Feature extraction is the task of determining the features of a part from a given geometric description. Some researchers have developed
438
MUKASAE. SSEMAKULAand AJAY SATSANGI
algorithms for the automatic extraction of features from a CAD database. Stanley, Henderson and Anderson [6] developed an approach using syntactic pattern recognition to extract feature information from a CAD database. Syntactic pattern recognition is applied to the classification of holes from 2-D cross sectional descriptions extracted from a 3-D solid model geometric database. The system includes a program to extract an edge list of a hole from a CAD database, and codes the cross-section into a representative character string. A routine that analyses the syntax and recognizes features, then classifies the string according to user-defined generic hole families. A feature is defined by specific combinations of faces, edges, and vertices that may be identified using a pattern recognition process. Srinivassan and Liu [7, 8] used a similar approach in their work. The objective was to utilize CAD geometric data in manufacturing applications such as group technology and process planning. A workpiece is represented as a syntactic pattern made up of geometrical primitives. Formal language theory is then applied to the problem of part family formation and classification. Lee and Fu [9] reported work on feature extraction from CSG databases. The constitution of a feature is governed by the relationships among the edges and/or axes of the participating primitives during model construction. An arbitrarily constructed CSG tree as input is first traversed to generate all principle axes. Before these axes are used to locate a particular feature, they are first partitioned into several clusters based on their spatial relationships. Within each cluster, axes involved in a particular feature can be located according to the conditions defined by the feature. The feature representation is then unified by rebuilding the CSG tree. Other prominent work in feature extraction includes that by De Floriani [10], and Woo [11]. The above work on feature extraction, as well as that of other researchers in the field, need recognition. A significant drawback of such work however is that it amounts to making explicit what is implicit in the solid model. Therefore it cannot derive information that does not normally exist in the solid model such as tolerances and surface finish. This information however is crucial to the successful development of a manufacturing process plan. Another drawback is that there is also room for misinterpretation because of data redundancy. Consequently, the algorithms for recognizing even simple features are fairly complex and are generally modeler-specific. Feature recognition and extraction is in effect an effort which would be unnecessary if a method could be devised for retaining in the modeler all the information available to the designer.
3.2. Design by features To be able to fully utilize features throughout the product life cycle, features must be an integral part of the design process. This requires a Design by Features approach and a feature based product modeler. The design database would thus contain complete feature definition data. Downstream functions such as process planning, manufacturing, inspection, assembly, and maintenance can then all make use of the same feature data. Among the important benefits of the design by features approach is that as the product is being developed, the designer can invoke downstream applications to evaluate the design, for example in terms of manufacturability or ease of assembly, and obtain immediate feedback on the impact of the design on these downstream functions. This entails the philosophy of Design For Manufacturability (DFM) which demands that product and process designs be developed simultaneously [12]. This would be very difficult in the absence of features data. Features can also be used to drive process planning, robotic manipulators, and automated vision/inspection systems among others. Feature based modelers have been developed for castings [13], injection molded parts [14], as well as machined parts [15, 16]. Product modelers based on the design by features principle promise to play a critical role in CAD/CAM integration. For this to succeed, it is crucial that features be defined in a form that is suitable for use at various levels of the enterprise. Thus, features data needs to be stored in a form which allows different applications to view the same data in different ways and hence extract only information that is relevant to the specific application. As discussed earlier, features required for design analysis are not necessarily the same as those for manufacturing planning, and these in turn will differ from those required for inspection purposes. Thus the geometry data has to be amenable to varied interpretation while still maintaining consistency. Different applications could then use the same geometrical data to define different features that are suitable for the specific application. This approach is particularly suitable to use with B-Rep type solid models since these
Application of PDES to CAD/CAPP integration
439
contain detailed and explicit data describing both geometry and tbp01ogy as can be seen in Fig. 2.
3.3. Application of PDES There have already been several efforts do develop a platform that can serve as a basis for complete product definition. The most important early work was that carried out under the Product Definition Data Interface (PDDI) study. This work was done by the McDonnell Aircraft Company on behalf of the U.S. Airforce [17]. Parallel work in this area by CAM-I was carried out in support of that organization's process planning systems [18]. The culmination of these efforts has been the development of the Product Data Exchange Specification PDES standard under the guidance of the IGES organization, in close collaboration with the International Standards Organization (ISO) under its STEP program, aimed at developing an international standard format for product data definition. In some of our previous work, we have endeavored to develop an interface between CAD and CAPP using the widely accepted IGES standard for graphical data [19, 20]. This work was promising enough that we decided to investigate the suitability of using PDES for this same purpose. The primary advantage of PDES over IGES as a vehicle for interfacing various CAD/CAM modules is that PDES contains a lot more information about the product than IGES. Examples of such additional information include topology, feature description data, and attributes (e.g. surface finish, and tolerance). It is anticipated that PDES/STEP will indeed become an international standard accepted by industry, similar to IGES. 3.3.1. PDES overview. The Product Data Exchange Specification (PDES) is designed to completely define a product for all applications over its expected life cycle. Product data includes the geometry, topology, tolerances, relationships, attributes, and features necessary to completely define a component part or assembly of parts for the purpose of design, analysis, manufacture, test, inspection, and product support. PDES is designed to be informationally complete for all downstream applications and to be directly interpretable by these applications. The main types of data which are used in PDES to describe a product are: • • • •
Administrative and control data; Geometry such as points, curves, and surfaces; Topology such as vertices, loops, and faces; Tolerances; • Form features; • Attributes such as surface finish; • Material properties; • Part Assemblies.
Topology
QI
''.1 *
•
.l
1,
,l
l,
v-
Geometn/
I
I
'1
P-(x,y.Z)
Fig. 2. Geometry and topology relations in B-Rcp modeler. CAIE 18/~-B
I
440
MUKASA E. SSEMAKULAand AJAY SATSANGI
It is clear from the above list that PDES will provide the information required for process planning. It is emphasized however that PDES is still in the process of development and this work was done as part of that development effort. In fact at the time our work was done, the first version of PDES had not yet been released and consequently, some representational issues had not yet been resolved. The National Institute of Standards and Technology (NIST) is responsible for co-ordinating the American PDES development efforts and we worked in close collaboration with the Institute. 3.3.2. Creation ofPDES testfile. PDES is intended to be a standard comprising a computerized product model in a neutral form, without loss of completeness or integrity throughout the lifecycle of the product. Our work involved first of all undertaking a detailed study of the PDES format as proposed, to determine its suitability to represent process planning data, and then generate suitable PDES files that could be used to transmit the required data for process planning. As mentioned earlier, PDES is still at an evolutionary stage and therefore the format specifications are liable to change from time to time. Our aim was not simply to use PDES for CAD/CAPP integration, but rather to explore the detail data requirements for such a link and consequently determine if PDES meets those requirements and hence establish its suitability for this task. For this reason, it was necessary for us to stick to a specific format which had already been agreed by the PDES committee at the time we started our project. The format we used was the February 1988 version (Washington edn). The structure of the geometry and topology entities are not expected to change. An important issue arising from the fact that this is an evolving standard, is that there are as yet no commercial CAD packages that can produce PDES files. We overcame this by using an adaptation of the ROMULUS solid modelling system available at NIST. ROMULUS supports true boundary representation and the AMRF facility at NIST has a modified version which allows the editing of the CAD database to add features and tolerance information. This verion is therefore suitable for use as a testbed for the design.by features concept. ROMULUS does not generate PDES files but it generates a part description in the in-house AMRF format. The part shown in Fig. 3 was developed on this system and used as a test part. A part description file for the part in the AMRF format was generated. The actual data contents of the AMRF format and the PDES format are quite similar, so it is possible to translate between the two data formats. Accordingly, a processor was written to translate the part model from the AMRF format to the equivalent PDES B-Rep format. 3.3.3. Interpretation of the PDES file. The importance of PDES lies not only in its representational capabilities, but also in its function as the primary mechanism through which different
1.0
)._..o
i.o_:-
~5
,(I
)
/
,
I TM
3'
1.0
•
.I
6.0
( I ) HoLe ( D t a : 1.0 m, Depth : 0.5 x ) ( 2 ] P o c k e t ( 2 " x 2 " , Corner radius : 0 . 2 5 " , [ 3 ] BLock (6#x 3Xx 1#)
Depth : 0.5"
Fig. 3. Drawing o f PDES test part.
Application of PDES to C A D / C A P P integration
441
::::::i:i:i:i:-:i:i~:-:i:~.'~'~.'i:i;i:i.'.::iil
..::~:~:~:i:i~:::::::::~ ~::-.'i:i:i:.:.'."::.. :::::::::::::::::::::::::::::::::::::::::
Fig. 4. Structural representation of a pocket.
users communicate with the part database. The user must be able to retrieve specific data from the PDES file and manipulate that data on an as-needed basis. This requires that the PDES data must be accessed, extracted, and transformed into a form manipulable in the application environment. As was explained earlier, the B-Rep database contains an explicit or evaluated model. The faces, edges, and vertices are represented explicitly as they. appear in the model. The features, which are required for process planning and other manufactdring related activities, are implicit. The geometry and topology data in the database must be interpreted to retrieve the feature data. The interpretation of the PDES database into user manipulable feature data, constitutes the interface between the CAD data and manufacturing functions such as CAPP. We have developed a structural feature representation scheme for use within PDES, that facilitates feature interpretation. It takes advantage of the fact that geometrical and topological entities are defined explicitly within the PDES database. The relevant entity definitions are combined according to specific structural rules, to derive a feature definition. Consider a rectangular pocket as an example. The pocket can be defined by a total of nine surfaces, consisting of 4 fiat vertical faces, 4 curved corner surfaces, and 1 flat face forming the bottom of the pocket; Table 2. Structural data arrangement for a pocket Poc.ket: FLSh FLS2: FLS3:
FLSI, FLS2, FLS3, FLS4, FLS5, FLS6, FLS7, FLS8, FLS9 FACE (LLSI, SLSI) FACE (LLS2, SLS2) FACE (LLS3, SLS3)
FLSg: LLSI: LLS2: LLS3:
FACE EDGE EDGE EDGE
LLS9: ELSI: ELS2:
EDGE LOOP (ELS24. ELSI I, ELS8, ELS23) EDGE (VTX, VTX2, CLSI) EDGE (VTX2, VTX3, CLS2)
ELSI2: SLSI: SLS2:
EDGE (VTXI, VTX9, CLSII) PLANE (AXIS2 PLACEMENT, POINT, DIRECTION) CTCl, TSDI PLANE (AXIS2 PLACEMENT, POINT, DIRECTION) CTC2, TSD2
CLSI: CLS2:
CIRCLE (RADI, AXIS2 PLACEMENT (CENT PT, DIREUFION) 1'9 TSD3) CIRCLE (RADI, AXIS2 PLACEMENT (CENT PT, DIRECTION) Pl0 TSD3)
VTXI:
CTCI (Pl)
VTX2:
CTC2 (P2)
~l'X8: RADI: Pl: P2:
CTC8 (P8) 0.250 2.25, 0.50, -0.50 3.75, 0.50, -0.50
F'9: Pl0:
3.75. 0.75, 0.00 3.75, 0.75, --0.50
(LLSg, LOOP LOOP LOOP
SLSg) (ELSI, ELS2, ELS3, ELS4, ELSS, ELS6, ELS7, ELSS) (ELS9, ELSI0, ELSI, ELSll) (ELSI2, ELSI3, ELS2, ELSI0)
Where: F S L n - Face Logical Structure n; L L S a - Loop Logical Structure n; S L S a Surface Logical Structure n; ELSm - Edge Logical Structure n; CLSm - Curve Logical Structure n; VTXn ~ Vertex n; TSDn -Three Space Direction n; RAD~ - R a d i u s m; CTCn ,~ Cartesian Coordinate Three n; Pn =Point a; n = 1,2,3...
3,,42
MUKASA E. SSEMAKULA and ,~OAY SATSANGI
as shown in Fig. 4. With the structural feature representation approach, the feature definition is recursively built from the definition of lower level entities until raw geometrical data in terms of coordinate geometry is reached. A representative data structure for a pocket is shown in Table 2. From the feature representation such as that shown in Table 2, one has to traverse the definition-structure-tree and trace the defining data through the various levels from face, loop, edge, vertex, and finally three coordinates associated with the feature. This can be achieved by a parsing function. We developed a parser to read the PDES file and extract the process planning information. The parser is written in C and runs on a VAX/UNIX platform. The parser extracts the base coordinate geometry for the feature. Once the coordinate geometry is obtained, appropriate trigonometric and geometric relationship are applied to derive the parameters required for process planning. For example, the process planning data required for a pocket would be Drawing Code, Surface Area, Width, Depth, Perimeter, and Minimum Corner Radius. PART NAME PART NUMSER ORAWZNONO. M / T NUMBERS
)P
ORW.C
= = : =
POES PART TEST 5 AJ. S 11
OP, DEBCRP.
MAT. NAME : MILD STEEL MAT. SPECF : EN t A ASSEMBLY NO.= BAT. 5
NO.
TOOL OIAM,
M / T NO. FEED
SPEED
t.
NEW M / T
O.
0.00
11.
0.00
2.
LOAD M / T FACE '1
O.
O.OO
11.
O. O 0 0 .
BATCH S I Z E : 1 DATE = 8/26/88 PLANNER : AJAY
cUTTING CONOZI"ZON$ RPM DEPTH WIDTH P A U
0,00
O,
0.OO
0.OO
O0
O.
O. OO
O. O 0 0 .
$.T.
O,
M.T.
H.T.
15D0
0-00
0.00
0.00
0.00
5.00
3.
H1
CENTRE DRILL
7.
2.50
11.
O. 12
O. 21
t6OO.
7.46
O. OO
1.
0.00 '
0.04
0.75
4.
H1
P I L O T ORI"LL
B,
5.50
t 1.
O, t 6
0.43
1487.
I E . 70
0. OO
1,
0.00
0.06
O.?S
5.
H1
D R I L L TO F I N A L DIAM.
6,
19.50
11.
O. 35
O. 4 3
419.
12.70
0.00
I.
0.00
O,IS i
0,75
6.
H1
SORE
4.
22.45
11.
0.23
0,92
?80.
1.4T
0.00
I.
0.00
0.07
0.75
7.
H1
BORE
4.
25,40
11.
O. 2 3
0,92
690.
1,47
0,00
1.
0,00
0.0B
0,50
8.
PI
POCKET M I L L {ROUGH CUT)
3,
50.00
11.
76.89
0.47
179.
12.70
60.00
I.
0,00
2.48
0.75
9.
P1
POCKET M I L L F I N I S H SIDE
3.
12.00
11.
291.84
0.47
746.
6.35
12.00
2.
0.00
0.53
0.75
10.
UNLOAD M / T
O.
0.00
11.
0.00
O.OO
O.
0.00
0.OO
O.
0.00
0.00
5.00
t 1.
INSPECTION
O.
0.00
1 1.
0.00
0.00
O.
0.00
0.00
O,
0.00
0,00
2.00
TOTAL S E T - U P T I M E
=
1 5 . 0 0 MIN
TOTAL M A C H I N I N G T I M E PER COMPONENT :
3.39 MIN
TOTAL HANDLING T I M E PER COMPONENT : I"OTAL T I M E FOR BATCH = FFEOS
1 7 . 0 0 MZN
3 5 , 3 9 MZN
= M M / R P M FOR HOLE MAKING OPERATIONS
TOOL L I S T
TOOL NO.
TOOL NAME
TOOL TOOL T I M E ZN CODE DIAMETER U U ( M Z N )
T I M E ZN CUT(MEN)
1
CENTRE-DRILL
7,
2.50
0.79
0.04
2
T W I S T DR~LL
6.
5.50
0.81
0.06
3
T W I S T DRILL
6.
19.60
O, Se
0.13
4
BORING
4,
EB. 4 5
O. 8 2
O. 0 7
5
BORING
4.
eB.40
0.811
O.Oe
6
DORMER
S.
50.00
B.~3
2.4|
7
DORMER
3.
IB.OO
l.aB
0.53
Fig. 5. Process plan generated by ICAPP.
NOTES
NOTES
Application of PDES to CAD/CAPP integration
443
Once all the parameters o f each feature are extracted, they are placed in a user defined output file. The file contains additional information from the header section such as designer name, date etc. This file is then used as the input to the process planning system which can generate a process plan based on this data. The process planning system used for this purpose was I C A P P [21]. The I C A P P process planning system was able to generate the process plan shown in Fig. 5 for our test part based on such a file. F r o m the work done, it was evident that PDES goes a long way in satisfying its intended goal o f providing sufficient product definition data to satisfy the needs of various applications for the product life-cycle. In particular, the proposed use of explicit feature definitions in the product definition database will obviate the need for complex computer algorithms for automated feature recognition and extraction. Moreover, by using a standard format such as that provided by PDES, the approach described here will be independent of the modeler used to generate the underlying model description of the part. In this case, a simple parsing function was sufficient to retrace and extract the geometrical data required for process planning applications whereas attributes could be obtained directly from the product database. Due to the evolving character of PDES, the results reported here cannot be taken as final. In particular, at the time of this work, feature representation standards had not been finalized. The information required for these definitions however has .been well understood and a format is proposed here which makes it easy for various application functions to retrieve the data as needed. 4. CONCLUSION This work has demonstrated the viability of PDES as a product definition standard, with the capability of providing detail product definition data usable by various application functions other than design. The capability to represent features within the product definition simplifies the task of integrating different modules to the design database and eliminates the need for feature recognition and extraction. This is a significant saving on the computational effort required to integrate various modules such as C A D , C A P P and CAM. Acknowledgement--We are indebted to Mr Bradford Smith of NIST, and chairman of the IGES/PDES committee, for his
continual help and support during the course of this work, and for putting NIST facilities at our disposal.
REFERENCES 1. H. A. Voelker and A. A. G. Requicha. Addendum: geometric modeling systems. Seminar on Geometric Modeling,
SIGGRAFHgl, Dallas, Tex. (August 1981). 2. G. T. Armstrong, G. C. Carey and A. de Pennington. Numerical code generation from a geometric modeling system. In Solid Modeling by Computers: From Theory to Applications (Edited by M. S. Pickeue and J. W. Boyse).Plenum Press, New York 0984). 3. T. C. Woo. Computer understanding of designs. PhD Thesis, University of Illinois, Urbana-Champaign, Ill. 0975). 4. T. C. Chang. TIPPS--A totally integrated process planning system. PhD Thesis, Virginia Polytechnic Institute, Biacksburg, Va. 0982). 5. F. Arhab. Requirements and architecture of a CAM-oriented CAD system for design and manufacture of mechanical parts. PhD Thesis, UCLA (1982). 6. S. M. Stanley, M. R. Henderson and D. C. Anderson. Using syntactic pattern recognition to extract feature information from a solid geometric database. Computers mech. Engng 2(2), 61-66 (1983). 7. R. Srinivasan and C. R. Liu. On some important geometrical issues in generative process planning. Proc. Syrup. Integrated and Intelligent Mfg. ASME Winter Annual Meeting, Boston, Mass. pp. 229-244 (December 1987). 8. R. Srinivasan, C. R. Liu and K. S. Fu. Extraction of manufacturing details from geometric models. Computers ind. Engng 9(2), 125-133 (1985). 9. Y. C. Lee and K. S. Fu. Machine understanding of CSG: extraction and unification of manufacturing features. IEEE CG and A (1987). 10. L. De Floriani. Representation and extraction of shape features in a solid model. NATO ASI on Theoretical Foundations of Computer Graphics and CAD (July 1987). 11. T. C. Woo. Feature extraction by volume decomposition. Proc. Conf. on CAD~CAM Technology in Mechanical Engineering, MIT, Cambridge, Mass. (March 1982). 12. S. C.-Y. Lu and S. Subramanyam. A computer based environment for simultaneous product and process design. In Advances in Manufacturing Systems Engineering. ASME Special Publication PED-31, ASME Winter Annual Meeting, Chicago, I11.pp. 35-46. (November 1988). 13. S. C. Luby, J. R. Dixon and M. K. Simmons. Design with features: creating and using a feature database for evaluation of manufacturability of castings. Computers mech. Engng 5(3), 25-33 (1986).
444
MUKASAE. ~ M A K U L A
and A JAY SATSANGI
14. M. Vaghul, J. R. Dixon, G. E. Zinmeister and M. K. Simmons. Expert systems in a CAD environment: injection molding part design as an example. Proc. 1985 ASME Conf. on Computers in Engineering (1985). 15. K. E. Hummel and S. L. Brooks. Symbolic representation of manufacturing features for an automated manufacturing system. Technical Report BDX-613-3580, Allied Bendix, Kansas City Division (1986). 16. B. Kumar, D. K. Anand and J. A. Kirk. Integration and testing of an intelligent feature extractor within a flexible manufacturing protocol. Proc. 16th North American Mfg Res. Conf. (1988). 17. McDonnell Aircraft Company. Product definition data interface. System Specification Document SS 560130100. Airforce Wright Aeronautical Laboratories, Wright-Patterson AFB, Ohio (1984). 18. W. R. Butterfield, M. K. Green, D. C. Scott and W. J. Stoker. Part features for process planning. CAM-I Report R-86-PPP-01, CAM-I Inc., Arlington, Tex. (1986). 19. M. E. Ssemakula and J. S. Gill. CAD/CAPP integration using IGES. Adv. Mfg Engng 1(5), 264-270 (1989). 20. M. E. Ssemakula and P. O. Sivac. Automatic generation of NC part programs. Proc. AUTOFACT "87 Conf., Detroit, Mich. (November 1987). 21. M. E. Ssemakula and B. J. Davies. Integrated process planning and NC programming for prismatic parts. Proc. 1st Int. Machine Tool Conf. (MACH '84), Birmingham, U.K. pp. 143-154 (June 1984). 22. S.A. Vogel, J. A. Krakauer and N. P. Jeffries. CAD/CAM systems for small companies. Proc. Autofact West, Anaheim, Calif., Vol. 1, pp. 3-12 (November 1980).
:
Printed in Great Britain. All rights reserved
APPLICATION
OF PDES TO CAD/CAPP
0360-8352/90 $3.00+ 0.00 Copyright © 1990 Pergamon Press pk
INTEGRATION
MUKASA E. SSEMAKULA a n d AJAY SATSANGI Department of Mechanical Engineering, University of Maryland, College Park, MD 20742, U.S.A.
(Received for publication 13 March 1990) Ablm'aet--process planning plays a key role in the integration of the design and manufacturing functions, because it is the function responsible for covening design specifications into manufacturing instructions. In this paper, we describe the development of a robust interface between a process planning system and a CAD system using the new and emerging Product Data Exchange Specification (PDES) standard for product data definition. The relevant feature data constituting the part definition are extracted from the design database and used as input to the process planning system. Based on this input, a detailed process plan is generated by the system and this can be used to physically manufacture the part. This demonstrates a good basis for true integration between CAD and CAM.
1. INTRODUCTION
With the rising importance of industrial competitiveness, the need for technological improvements in the manufacturing arena is becoming acute. It is clear that automation will be the source of many of these improvements. Automation in manufacturing can speed product turnaround, reduce the need for retooling, and lead to a more efficient allocation of resources. This automation can be achieved by implementing a Computer Integrated Manufacturing (CIM) system. There are a number of obstacles; however, to the implementation of a fully integrated, and automated manufacturing system. One of the major obstacles is the lack of smooth information flow between Computer Aided Design (CAD) systems, and Computer Aided Manufacturing (CAM) systems. Traditionally, these two functions have developed as independent activities, with no feedback from CAM to CAD to reflect manufacturability considerations. To realize CIM, integration between CAD and CAM is necessary. Many CAD/CAM vendors claim to have working versions of integrated CAD/CAM systems. Indeed these systems generally have the capability of generating NC part programs based on the geometry of a part designed in CAD. However, a close scrutiny of such systems often reveals the need for extensive human interaction. The user is still required to provide crucial manufacturing data to the system in order to generate workable NC programs. For example, the sequence of operations, cutting parameters, and cutting tools must be determined by the user. All these data originate from the process planning function, and this suggests that process planning is the essential link between design and manufacturing. Here, we present work based on the concept of design by features. A designer selects a feature from a library of predefined features to create the design. The computer database then stores the feature as an entity. With this approach, the problem of feature recognition and extraction is eliminated. This simplifies the problem of interfacing CAD with CAPP because feature recognition is the major hurdle in transferring information from CAD to CAPP. The first step is to identify a data structure which is suitable for representing manufacturing features. The feature data structure must be able to represent complex structural objects whose components may be either geometrical, topological or technological in nature. The information provided by implicit design features must be complete enough to enable explicit instantiation of those features, which may be required by process planning, inspection, and administrative areas, among others. 2. PROBLEM DEFINITION
2.1. CAD systems overview CAD systems have evolved from their earliest applications as simple drafting aids, to their current level of sophistication; which enables detailed analysis of the part design to be carried out. 435
436
MUKAS^ E. SSEMAKULAand AJAY S.~'rsxNGI
This requires that the CAD part representations contain extensive part description data. The three most important part modeling techniques are: (1) Wireframe models; (2) Boundary Representation (B-Rep) models; (3) Constructive Solid Geometry (CSG) models. The component description which is stored in the database forms the heart of the CAD system. A solid modeler allows the user to design and store a model of a 3-D solid object in a robust database containing both geometry and topology. The two major database formats for solid modelers are the CSG tree of primitive volumes and associated Boolean operations used to construct the part; and the boundary representation (B-Rep) containing faces, edges, and vertices of the resultant object. In an integrated design and manufacturing system, CAD serves as a repository of all the part definition data. All other applications in the system need to retrieve the relevant part definition data contained in the CAD database. Manufacturing applications generally operate on the basis of features and so the part definition data should be interpretable in the form of feature data. It is therefore necessary in an integrated system that downstream applications be able to retrieve and interpret data in the CAD database according to their particular needs. 2.2. CAD databases
After an object has been defined, the modeler converts the input to a storage data structure maintaining the geometry and topology of the part. Three major forms of storage exist: CSG, B-Rep and MESH [1]. CSG and B-Rep storage structures are analogous to the CSG and B-Rep model construction techniques. For example CSG stores the model as a tree where the leaves are primitives and the nodes are Boolean operators. With B-Rep storage, linked lists of all vertices, edges, and faces constituting the geometry and topology are maintained. In this case the computation required to evaluate the various entities is extensive. In return for the large number of calculations in the construction mode, B-Rep modelers givea resultant data structure which is more detailed and more convenient for use by the analysis and output processors than the CSG storage method. B-Rep stores the actual model description whereas CSG stores instructions for how to construct the model. MESH storage is not widely used and we concentrated on evaluating CSG and B-Rep. In selecting a solid modeler to use for CAD/CAPP integration, specification of a CAD part representation becomes a major consideration. Armstrong [2] started with a B-Rep database and transformed it into a cell enumeration format for determination of NC tool paths. Woo [3] used CSG to define part features, whereas Chang [4] used a B-Rep database to generate process plans as well as NC tool paths. It is not obvious which type of storage technique is superior for use in integration of CAD with other applications. The choice would be determined by the type of information needed, and the extent of calculation required to derive it. A summary of the two most widely used solid modeling techniques and their part representation schemes is shown in Table 1. The CSG tree stores a model in an implicit or unevaluated form; the edges and vertices of the final part must be calculated from the set operations on the primitives. The features of the object however may be present in the CSG tree in explicit form. It is possible though that some features may not be present in the tree and they may arise from evaluation of the CSG tree; for example a slot may be formed by uniting two small blocks to a larger block. The B-Rep graph on the other hand, contains an explicit or evaluated model, The faces, edges, and vertices are represented explicitly. In this case however, the features are implicit, requiring interpretation of the geometry and topology. This explicit/implicit difference has a great influence on the format of the CAD/CAM link. The above comparison would seem to suggest that manufacturing features may more easily be extracted from the C S G tree because it can describe them explicitly.For example, if the designer used only machining primitives, the object could be created by beginning with a block stock of material and simulating the manufacturing steps during the design process by subtracting primitive volumes defined as slots, holes or other routinely used features. The resulting C S G tree would
Application of PDES to CAD/CAPP integration
Table 1. Part representation in solid modelers Modeling technique CSG B-Rep
Model representation Implicit Explicit
437
,~I
Feature representation Explicit Implicit
Fig. I. Non-unique feature construction in CSG.
contain explicit solid descriptions of all features in an unevaluated form. Arbab [5] has developed a system using just such an approach with his Deforming Solid Geometry (DSG) concept. That approach has some obvious advantages over the use of B-Rep data structures but there are at least two major difficulties. The first difficulty is that it requires that the designer, in addition to optimizing the design, must also be involved with the manufacturing task by using only a limited selection of machining primitives. In general, the designer is interested in the functionality of the part and will generate many intermediate designs before arrifing at a satisfactory solution. It is clearly inconvenient for the designer to simultaneously determine a sequence of feature creation for all design iterations. Moreover, the use of machining primitives is too restrictive, and inappropriate for design analyses such as kinematic analysis or finite element analysis. The second difficulty with interpreting the CSG tree to determine process plans is the problem of non-unique trees. A feature can be constructed in multiple ways. A slot can result from subtraction of a block or it may result from adding two blocks to a larger block as in Fig. 1. To consider all possible primitive combinations for a certain feature type would be a daunting task. There is an additional problem arising from the complexity of the CSG tree. To verify the presence of a particular feature, one approach would be to look for obvious primitive volume operations which would suggest the feature. Consider again the case of subtracting a block to create a slot. To ensure that the slot indeed does exist, the complete tree must be examined to check if any subsequent primitive operations overlap this block, and if so, to determine if they affect the making of the slot. The process of proving the existence of a feature is essentially a partial evaluation of the tree, and if this evaluation must be done for every suspected feature, the computational cost could rapidly surpass that required to generate a B-Rep database. Because of the non-unique representation scheme of CSG, and the desire to allow designers to be free from process planning details, it was decided to use B-Rep based part models for this research. The B-Rep data contains the evaluated model independent of the original building primitives. This allows a fresh view of the model, to perform manufacturing planning and other downstream functions, unrelated to the particular sequence used during the design stage. 3. APPROACHES TO CAD/CAPP INTEGRATION
3.1. Automatic feature extraction It is clear that features data are required to drive process planning, and that process planning is the essential link between CAD and CAM. For a true integration between CAD and CAPP, an automatic interpretation of the CAD data is necessary. Feature extraction is the task of determining the features of a part from a given geometric description. Some researchers have developed
438
MUKASAE. SSEMAKULAand AJAY SATSANGI
algorithms for the automatic extraction of features from a CAD database. Stanley, Henderson and Anderson [6] developed an approach using syntactic pattern recognition to extract feature information from a CAD database. Syntactic pattern recognition is applied to the classification of holes from 2-D cross sectional descriptions extracted from a 3-D solid model geometric database. The system includes a program to extract an edge list of a hole from a CAD database, and codes the cross-section into a representative character string. A routine that analyses the syntax and recognizes features, then classifies the string according to user-defined generic hole families. A feature is defined by specific combinations of faces, edges, and vertices that may be identified using a pattern recognition process. Srinivassan and Liu [7, 8] used a similar approach in their work. The objective was to utilize CAD geometric data in manufacturing applications such as group technology and process planning. A workpiece is represented as a syntactic pattern made up of geometrical primitives. Formal language theory is then applied to the problem of part family formation and classification. Lee and Fu [9] reported work on feature extraction from CSG databases. The constitution of a feature is governed by the relationships among the edges and/or axes of the participating primitives during model construction. An arbitrarily constructed CSG tree as input is first traversed to generate all principle axes. Before these axes are used to locate a particular feature, they are first partitioned into several clusters based on their spatial relationships. Within each cluster, axes involved in a particular feature can be located according to the conditions defined by the feature. The feature representation is then unified by rebuilding the CSG tree. Other prominent work in feature extraction includes that by De Floriani [10], and Woo [11]. The above work on feature extraction, as well as that of other researchers in the field, need recognition. A significant drawback of such work however is that it amounts to making explicit what is implicit in the solid model. Therefore it cannot derive information that does not normally exist in the solid model such as tolerances and surface finish. This information however is crucial to the successful development of a manufacturing process plan. Another drawback is that there is also room for misinterpretation because of data redundancy. Consequently, the algorithms for recognizing even simple features are fairly complex and are generally modeler-specific. Feature recognition and extraction is in effect an effort which would be unnecessary if a method could be devised for retaining in the modeler all the information available to the designer.
3.2. Design by features To be able to fully utilize features throughout the product life cycle, features must be an integral part of the design process. This requires a Design by Features approach and a feature based product modeler. The design database would thus contain complete feature definition data. Downstream functions such as process planning, manufacturing, inspection, assembly, and maintenance can then all make use of the same feature data. Among the important benefits of the design by features approach is that as the product is being developed, the designer can invoke downstream applications to evaluate the design, for example in terms of manufacturability or ease of assembly, and obtain immediate feedback on the impact of the design on these downstream functions. This entails the philosophy of Design For Manufacturability (DFM) which demands that product and process designs be developed simultaneously [12]. This would be very difficult in the absence of features data. Features can also be used to drive process planning, robotic manipulators, and automated vision/inspection systems among others. Feature based modelers have been developed for castings [13], injection molded parts [14], as well as machined parts [15, 16]. Product modelers based on the design by features principle promise to play a critical role in CAD/CAM integration. For this to succeed, it is crucial that features be defined in a form that is suitable for use at various levels of the enterprise. Thus, features data needs to be stored in a form which allows different applications to view the same data in different ways and hence extract only information that is relevant to the specific application. As discussed earlier, features required for design analysis are not necessarily the same as those for manufacturing planning, and these in turn will differ from those required for inspection purposes. Thus the geometry data has to be amenable to varied interpretation while still maintaining consistency. Different applications could then use the same geometrical data to define different features that are suitable for the specific application. This approach is particularly suitable to use with B-Rep type solid models since these
Application of PDES to CAD/CAPP integration
439
contain detailed and explicit data describing both geometry and tbp01ogy as can be seen in Fig. 2.
3.3. Application of PDES There have already been several efforts do develop a platform that can serve as a basis for complete product definition. The most important early work was that carried out under the Product Definition Data Interface (PDDI) study. This work was done by the McDonnell Aircraft Company on behalf of the U.S. Airforce [17]. Parallel work in this area by CAM-I was carried out in support of that organization's process planning systems [18]. The culmination of these efforts has been the development of the Product Data Exchange Specification PDES standard under the guidance of the IGES organization, in close collaboration with the International Standards Organization (ISO) under its STEP program, aimed at developing an international standard format for product data definition. In some of our previous work, we have endeavored to develop an interface between CAD and CAPP using the widely accepted IGES standard for graphical data [19, 20]. This work was promising enough that we decided to investigate the suitability of using PDES for this same purpose. The primary advantage of PDES over IGES as a vehicle for interfacing various CAD/CAM modules is that PDES contains a lot more information about the product than IGES. Examples of such additional information include topology, feature description data, and attributes (e.g. surface finish, and tolerance). It is anticipated that PDES/STEP will indeed become an international standard accepted by industry, similar to IGES. 3.3.1. PDES overview. The Product Data Exchange Specification (PDES) is designed to completely define a product for all applications over its expected life cycle. Product data includes the geometry, topology, tolerances, relationships, attributes, and features necessary to completely define a component part or assembly of parts for the purpose of design, analysis, manufacture, test, inspection, and product support. PDES is designed to be informationally complete for all downstream applications and to be directly interpretable by these applications. The main types of data which are used in PDES to describe a product are: • • • •
Administrative and control data; Geometry such as points, curves, and surfaces; Topology such as vertices, loops, and faces; Tolerances; • Form features; • Attributes such as surface finish; • Material properties; • Part Assemblies.
Topology
QI
''.1 *
•
.l
1,
,l
l,
v-
Geometn/
I
I
'1
P-(x,y.Z)
Fig. 2. Geometry and topology relations in B-Rcp modeler. CAIE 18/~-B
I
440
MUKASA E. SSEMAKULAand AJAY SATSANGI
It is clear from the above list that PDES will provide the information required for process planning. It is emphasized however that PDES is still in the process of development and this work was done as part of that development effort. In fact at the time our work was done, the first version of PDES had not yet been released and consequently, some representational issues had not yet been resolved. The National Institute of Standards and Technology (NIST) is responsible for co-ordinating the American PDES development efforts and we worked in close collaboration with the Institute. 3.3.2. Creation ofPDES testfile. PDES is intended to be a standard comprising a computerized product model in a neutral form, without loss of completeness or integrity throughout the lifecycle of the product. Our work involved first of all undertaking a detailed study of the PDES format as proposed, to determine its suitability to represent process planning data, and then generate suitable PDES files that could be used to transmit the required data for process planning. As mentioned earlier, PDES is still at an evolutionary stage and therefore the format specifications are liable to change from time to time. Our aim was not simply to use PDES for CAD/CAPP integration, but rather to explore the detail data requirements for such a link and consequently determine if PDES meets those requirements and hence establish its suitability for this task. For this reason, it was necessary for us to stick to a specific format which had already been agreed by the PDES committee at the time we started our project. The format we used was the February 1988 version (Washington edn). The structure of the geometry and topology entities are not expected to change. An important issue arising from the fact that this is an evolving standard, is that there are as yet no commercial CAD packages that can produce PDES files. We overcame this by using an adaptation of the ROMULUS solid modelling system available at NIST. ROMULUS supports true boundary representation and the AMRF facility at NIST has a modified version which allows the editing of the CAD database to add features and tolerance information. This verion is therefore suitable for use as a testbed for the design.by features concept. ROMULUS does not generate PDES files but it generates a part description in the in-house AMRF format. The part shown in Fig. 3 was developed on this system and used as a test part. A part description file for the part in the AMRF format was generated. The actual data contents of the AMRF format and the PDES format are quite similar, so it is possible to translate between the two data formats. Accordingly, a processor was written to translate the part model from the AMRF format to the equivalent PDES B-Rep format. 3.3.3. Interpretation of the PDES file. The importance of PDES lies not only in its representational capabilities, but also in its function as the primary mechanism through which different
1.0
)._..o
i.o_:-
~5
,(I
)
/
,
I TM
3'
1.0
•
.I
6.0
( I ) HoLe ( D t a : 1.0 m, Depth : 0.5 x ) ( 2 ] P o c k e t ( 2 " x 2 " , Corner radius : 0 . 2 5 " , [ 3 ] BLock (6#x 3Xx 1#)
Depth : 0.5"
Fig. 3. Drawing o f PDES test part.
Application of PDES to C A D / C A P P integration
441
::::::i:i:i:i:-:i:i~:-:i:~.'~'~.'i:i;i:i.'.::iil
..::~:~:~:i:i~:::::::::~ ~::-.'i:i:i:.:.'."::.. :::::::::::::::::::::::::::::::::::::::::
Fig. 4. Structural representation of a pocket.
users communicate with the part database. The user must be able to retrieve specific data from the PDES file and manipulate that data on an as-needed basis. This requires that the PDES data must be accessed, extracted, and transformed into a form manipulable in the application environment. As was explained earlier, the B-Rep database contains an explicit or evaluated model. The faces, edges, and vertices are represented explicitly as they. appear in the model. The features, which are required for process planning and other manufactdring related activities, are implicit. The geometry and topology data in the database must be interpreted to retrieve the feature data. The interpretation of the PDES database into user manipulable feature data, constitutes the interface between the CAD data and manufacturing functions such as CAPP. We have developed a structural feature representation scheme for use within PDES, that facilitates feature interpretation. It takes advantage of the fact that geometrical and topological entities are defined explicitly within the PDES database. The relevant entity definitions are combined according to specific structural rules, to derive a feature definition. Consider a rectangular pocket as an example. The pocket can be defined by a total of nine surfaces, consisting of 4 fiat vertical faces, 4 curved corner surfaces, and 1 flat face forming the bottom of the pocket; Table 2. Structural data arrangement for a pocket Poc.ket: FLSh FLS2: FLS3:
FLSI, FLS2, FLS3, FLS4, FLS5, FLS6, FLS7, FLS8, FLS9 FACE (LLSI, SLSI) FACE (LLS2, SLS2) FACE (LLS3, SLS3)
FLSg: LLSI: LLS2: LLS3:
FACE EDGE EDGE EDGE
LLS9: ELSI: ELS2:
EDGE LOOP (ELS24. ELSI I, ELS8, ELS23) EDGE (VTX, VTX2, CLSI) EDGE (VTX2, VTX3, CLS2)
ELSI2: SLSI: SLS2:
EDGE (VTXI, VTX9, CLSII) PLANE (AXIS2 PLACEMENT, POINT, DIRECTION) CTCl, TSDI PLANE (AXIS2 PLACEMENT, POINT, DIRECTION) CTC2, TSD2
CLSI: CLS2:
CIRCLE (RADI, AXIS2 PLACEMENT (CENT PT, DIREUFION) 1'9 TSD3) CIRCLE (RADI, AXIS2 PLACEMENT (CENT PT, DIRECTION) Pl0 TSD3)
VTXI:
CTCI (Pl)
VTX2:
CTC2 (P2)
~l'X8: RADI: Pl: P2:
CTC8 (P8) 0.250 2.25, 0.50, -0.50 3.75, 0.50, -0.50
F'9: Pl0:
3.75. 0.75, 0.00 3.75, 0.75, --0.50
(LLSg, LOOP LOOP LOOP
SLSg) (ELSI, ELS2, ELS3, ELS4, ELSS, ELS6, ELS7, ELSS) (ELS9, ELSI0, ELSI, ELSll) (ELSI2, ELSI3, ELS2, ELSI0)
Where: F S L n - Face Logical Structure n; L L S a - Loop Logical Structure n; S L S a Surface Logical Structure n; ELSm - Edge Logical Structure n; CLSm - Curve Logical Structure n; VTXn ~ Vertex n; TSDn -Three Space Direction n; RAD~ - R a d i u s m; CTCn ,~ Cartesian Coordinate Three n; Pn =Point a; n = 1,2,3...
3,,42
MUKASA E. SSEMAKULA and ,~OAY SATSANGI
as shown in Fig. 4. With the structural feature representation approach, the feature definition is recursively built from the definition of lower level entities until raw geometrical data in terms of coordinate geometry is reached. A representative data structure for a pocket is shown in Table 2. From the feature representation such as that shown in Table 2, one has to traverse the definition-structure-tree and trace the defining data through the various levels from face, loop, edge, vertex, and finally three coordinates associated with the feature. This can be achieved by a parsing function. We developed a parser to read the PDES file and extract the process planning information. The parser is written in C and runs on a VAX/UNIX platform. The parser extracts the base coordinate geometry for the feature. Once the coordinate geometry is obtained, appropriate trigonometric and geometric relationship are applied to derive the parameters required for process planning. For example, the process planning data required for a pocket would be Drawing Code, Surface Area, Width, Depth, Perimeter, and Minimum Corner Radius. PART NAME PART NUMSER ORAWZNONO. M / T NUMBERS
)P
ORW.C
= = : =
POES PART TEST 5 AJ. S 11
OP, DEBCRP.
MAT. NAME : MILD STEEL MAT. SPECF : EN t A ASSEMBLY NO.= BAT. 5
NO.
TOOL OIAM,
M / T NO. FEED
SPEED
t.
NEW M / T
O.
0.00
11.
0.00
2.
LOAD M / T FACE '1
O.
O.OO
11.
O. O 0 0 .
BATCH S I Z E : 1 DATE = 8/26/88 PLANNER : AJAY
cUTTING CONOZI"ZON$ RPM DEPTH WIDTH P A U
0,00
O,
0.OO
0.OO
O0
O.
O. OO
O. O 0 0 .
$.T.
O,
M.T.
H.T.
15D0
0-00
0.00
0.00
0.00
5.00
3.
H1
CENTRE DRILL
7.
2.50
11.
O. 12
O. 21
t6OO.
7.46
O. OO
1.
0.00 '
0.04
0.75
4.
H1
P I L O T ORI"LL
B,
5.50
t 1.
O, t 6
0.43
1487.
I E . 70
0. OO
1,
0.00
0.06
O.?S
5.
H1
D R I L L TO F I N A L DIAM.
6,
19.50
11.
O. 35
O. 4 3
419.
12.70
0.00
I.
0.00
O,IS i
0,75
6.
H1
SORE
4.
22.45
11.
0.23
0,92
?80.
1.4T
0.00
I.
0.00
0.07
0.75
7.
H1
BORE
4.
25,40
11.
O. 2 3
0,92
690.
1,47
0,00
1.
0,00
0.0B
0,50
8.
PI
POCKET M I L L {ROUGH CUT)
3,
50.00
11.
76.89
0.47
179.
12.70
60.00
I.
0,00
2.48
0.75
9.
P1
POCKET M I L L F I N I S H SIDE
3.
12.00
11.
291.84
0.47
746.
6.35
12.00
2.
0.00
0.53
0.75
10.
UNLOAD M / T
O.
0.00
11.
0.00
O.OO
O.
0.00
0.OO
O.
0.00
0.00
5.00
t 1.
INSPECTION
O.
0.00
1 1.
0.00
0.00
O.
0.00
0.00
O,
0.00
0,00
2.00
TOTAL S E T - U P T I M E
=
1 5 . 0 0 MIN
TOTAL M A C H I N I N G T I M E PER COMPONENT :
3.39 MIN
TOTAL HANDLING T I M E PER COMPONENT : I"OTAL T I M E FOR BATCH = FFEOS
1 7 . 0 0 MZN
3 5 , 3 9 MZN
= M M / R P M FOR HOLE MAKING OPERATIONS
TOOL L I S T
TOOL NO.
TOOL NAME
TOOL TOOL T I M E ZN CODE DIAMETER U U ( M Z N )
T I M E ZN CUT(MEN)
1
CENTRE-DRILL
7,
2.50
0.79
0.04
2
T W I S T DR~LL
6.
5.50
0.81
0.06
3
T W I S T DRILL
6.
19.60
O, Se
0.13
4
BORING
4,
EB. 4 5
O. 8 2
O. 0 7
5
BORING
4.
eB.40
0.811
O.Oe
6
DORMER
S.
50.00
B.~3
2.4|
7
DORMER
3.
IB.OO
l.aB
0.53
Fig. 5. Process plan generated by ICAPP.
NOTES
NOTES
Application of PDES to CAD/CAPP integration
443
Once all the parameters o f each feature are extracted, they are placed in a user defined output file. The file contains additional information from the header section such as designer name, date etc. This file is then used as the input to the process planning system which can generate a process plan based on this data. The process planning system used for this purpose was I C A P P [21]. The I C A P P process planning system was able to generate the process plan shown in Fig. 5 for our test part based on such a file. F r o m the work done, it was evident that PDES goes a long way in satisfying its intended goal o f providing sufficient product definition data to satisfy the needs of various applications for the product life-cycle. In particular, the proposed use of explicit feature definitions in the product definition database will obviate the need for complex computer algorithms for automated feature recognition and extraction. Moreover, by using a standard format such as that provided by PDES, the approach described here will be independent of the modeler used to generate the underlying model description of the part. In this case, a simple parsing function was sufficient to retrace and extract the geometrical data required for process planning applications whereas attributes could be obtained directly from the product database. Due to the evolving character of PDES, the results reported here cannot be taken as final. In particular, at the time of this work, feature representation standards had not been finalized. The information required for these definitions however has .been well understood and a format is proposed here which makes it easy for various application functions to retrieve the data as needed. 4. CONCLUSION This work has demonstrated the viability of PDES as a product definition standard, with the capability of providing detail product definition data usable by various application functions other than design. The capability to represent features within the product definition simplifies the task of integrating different modules to the design database and eliminates the need for feature recognition and extraction. This is a significant saving on the computational effort required to integrate various modules such as C A D , C A P P and CAM. Acknowledgement--We are indebted to Mr Bradford Smith of NIST, and chairman of the IGES/PDES committee, for his
continual help and support during the course of this work, and for putting NIST facilities at our disposal.
REFERENCES 1. H. A. Voelker and A. A. G. Requicha. Addendum: geometric modeling systems. Seminar on Geometric Modeling,
SIGGRAFHgl, Dallas, Tex. (August 1981). 2. G. T. Armstrong, G. C. Carey and A. de Pennington. Numerical code generation from a geometric modeling system. In Solid Modeling by Computers: From Theory to Applications (Edited by M. S. Pickeue and J. W. Boyse).Plenum Press, New York 0984). 3. T. C. Woo. Computer understanding of designs. PhD Thesis, University of Illinois, Urbana-Champaign, Ill. 0975). 4. T. C. Chang. TIPPS--A totally integrated process planning system. PhD Thesis, Virginia Polytechnic Institute, Biacksburg, Va. 0982). 5. F. Arhab. Requirements and architecture of a CAM-oriented CAD system for design and manufacture of mechanical parts. PhD Thesis, UCLA (1982). 6. S. M. Stanley, M. R. Henderson and D. C. Anderson. Using syntactic pattern recognition to extract feature information from a solid geometric database. Computers mech. Engng 2(2), 61-66 (1983). 7. R. Srinivasan and C. R. Liu. On some important geometrical issues in generative process planning. Proc. Syrup. Integrated and Intelligent Mfg. ASME Winter Annual Meeting, Boston, Mass. pp. 229-244 (December 1987). 8. R. Srinivasan, C. R. Liu and K. S. Fu. Extraction of manufacturing details from geometric models. Computers ind. Engng 9(2), 125-133 (1985). 9. Y. C. Lee and K. S. Fu. Machine understanding of CSG: extraction and unification of manufacturing features. IEEE CG and A (1987). 10. L. De Floriani. Representation and extraction of shape features in a solid model. NATO ASI on Theoretical Foundations of Computer Graphics and CAD (July 1987). 11. T. C. Woo. Feature extraction by volume decomposition. Proc. Conf. on CAD~CAM Technology in Mechanical Engineering, MIT, Cambridge, Mass. (March 1982). 12. S. C.-Y. Lu and S. Subramanyam. A computer based environment for simultaneous product and process design. In Advances in Manufacturing Systems Engineering. ASME Special Publication PED-31, ASME Winter Annual Meeting, Chicago, I11.pp. 35-46. (November 1988). 13. S. C. Luby, J. R. Dixon and M. K. Simmons. Design with features: creating and using a feature database for evaluation of manufacturability of castings. Computers mech. Engng 5(3), 25-33 (1986).
444
MUKASAE. ~ M A K U L A
and A JAY SATSANGI
14. M. Vaghul, J. R. Dixon, G. E. Zinmeister and M. K. Simmons. Expert systems in a CAD environment: injection molding part design as an example. Proc. 1985 ASME Conf. on Computers in Engineering (1985). 15. K. E. Hummel and S. L. Brooks. Symbolic representation of manufacturing features for an automated manufacturing system. Technical Report BDX-613-3580, Allied Bendix, Kansas City Division (1986). 16. B. Kumar, D. K. Anand and J. A. Kirk. Integration and testing of an intelligent feature extractor within a flexible manufacturing protocol. Proc. 16th North American Mfg Res. Conf. (1988). 17. McDonnell Aircraft Company. Product definition data interface. System Specification Document SS 560130100. Airforce Wright Aeronautical Laboratories, Wright-Patterson AFB, Ohio (1984). 18. W. R. Butterfield, M. K. Green, D. C. Scott and W. J. Stoker. Part features for process planning. CAM-I Report R-86-PPP-01, CAM-I Inc., Arlington, Tex. (1986). 19. M. E. Ssemakula and J. S. Gill. CAD/CAPP integration using IGES. Adv. Mfg Engng 1(5), 264-270 (1989). 20. M. E. Ssemakula and P. O. Sivac. Automatic generation of NC part programs. Proc. AUTOFACT "87 Conf., Detroit, Mich. (November 1987). 21. M. E. Ssemakula and B. J. Davies. Integrated process planning and NC programming for prismatic parts. Proc. 1st Int. Machine Tool Conf. (MACH '84), Birmingham, U.K. pp. 143-154 (June 1984). 22. S.A. Vogel, J. A. Krakauer and N. P. Jeffries. CAD/CAM systems for small companies. Proc. Autofact West, Anaheim, Calif., Vol. 1, pp. 3-12 (November 1980).