ASPECTS OF DESIGN RETRIEVAL PERFORMANCE USING
AUTOMATIC GT CODING OF 2D ENGINEERING DRAWINGS
Doug Love
Aston University, Birmingham, U.K, 0121-359-3611, Email: [email protected] Jeff Barton
Aston University, Birmingham, U.K, 0121-359-3611, Email: [email protected]
Abstract:
Many companies have the aim of reducing part variety as it confers on it a range of significant benefits. Achieving this requires a retrieval system that is effective, that designers will use and that is cost effective to implement and maintain. Coding and classification/Group Technology(GT) codes are widely used in systems for retrieval of existing parts but involve expensive and time consuming manual coding. A system called Camac has been developed which uses a novel approach of automated coding of 2D engineering drawing to deliver a cost effective solution with the added benefit that searching is based on a CAD sketch of the part and not text descriptors. Testing has already shown that the performance of Camac to be excellent but that it may be affected by the detail and quality of the seed sketch. Testing is describe which investigates the impact of sketch detail and quality as well as database size. It is concluded that an acceptable performance with poor quality sketches should be attainable with databases in excess of 20000 items and that for good quality sketches databases of significantly greater size will not be a problem.
Key Words: design retrieval, coding & classification, Group Technology (GT)
1. Introduction
Variety reduction is popular aim in many manufacturing companies. The use of existing assemblies and components brings with it many advantages, not just in the cost of the product but also its reliability (the previous design has been tested) and time to market (it is quicker to complete the design). It is not uncommon however to find a set of components that are so similar, that a single or small subset of items would provide the same functionality. Where the designer is unaware of the existence of the similar items it might be excusable. However, in many cases the designer is aware that a similar item does exist but considers that is quicker and easier to draw a new part than to retrieve the exiting one.
While the use of use of standards and preferred item catalogues are a common method of variety control for standard parts, this is not a viable option for the many non-standard
components that are specific to a particular company. The control of these items requires a means of searching and retrieving that the designer considers to be significantly easier and quicker than creating a new drawing. Not only must the retrieval be easy and quick but the retrieval performance must be acceptable if the designer is to be convinced of its utility.
2. Coding and Classification Systems and the Control of Part Variety
Coding and classification systems have been used in manufacturing and design
applications for many years. The earliest UK system (Brisch) dates back to the middle of the last century [1] and a large number of other systems were developed during the explosion of interest in Group Technology (GT) that occurred in the 1960's and 1970's. Gallagher and Knight described over 20 codes in their book on GT first published in 1973 [2]. In all these systems the part's geometry, material and, occasionally, production process information is encoded into a string of digits or alphanumeric characters. It follows then that two parts having the same or similar codes will be likely to have similar properties. In GT applications codes were sorted to form 'families' of parts based on their geometric or material properties. The assumption here was that similar geometry implied similar manufacturing methods and thus a common basis for the design of a focused cell to manufacture the part family. Design retrieval applications are more straightforward since it is generally the geometry of the part itself, rather than properties inferred from it, that is of prime concern to the designer. Thus it is not surprising that GT codes have been widely used in design retrieval, as is illustrated in Tatikonda and Wemmerlov's [3]survey of US applications of GT coding and classification systems which listed many design-related benefits as a consequence of the use of the technique.
Design retrieval is fundamental to the control of variety since it is allows a designer to check if a part already exists that can be used before they create a brand new one. Control of part variety offers cost benefits that extend well beyond those that are generated in the design office itself. Indeed it is likely to be the downstream cost savings that flow from re-use of existing parts that are likely to be most significant. Many estimates are available for the cost incurred during the life of a part created unnecessarily, for example see Sharma [4], and Dowlatshahi and Nagaraj [5]. Savings in design and development are difficult to validate but Johnson and Broms [6] assert that their study of Scania showed that product development costs were directly proportional to the size of a company's parts range.
Whilst the significance of the potential savings are undeniable, even if their exact value can be debated, it is also true that the costs associated with the system used to control the growth in variety must also be contained. These costs include purchase, implementation, operation and maintenance. Product Data Management (PDM) systems have been seen as one way to achieve variety control but the complexity (and high cost) of these systems reflect the fact that their functionality greatly exceeds this one requirement. Coding and
classification systems naturally vary in both their purchase and running costs but it is
significant that resource costs have been found to be a key reason for companies abandoning their use [7]. The design of the system has an impact on the costs involved, especially those related to maintenance and system set-up. This is because the speed with which parts can be coded is directly related to the labour costs associated with creation and maintenance of the parts database.
All the early C&C systems were designed for manual use and thus employed simple structures and limited length to aid recollection and manual handling. These constraints limited their utility, capacity to store information and operational efficiency. Later
developments sort to employ computer technology to alleviate some of these problems, for example MICLASS [8] used a structured dialog with the user to generate its numeric code. An early predecessor of the system described in this paper [9]employed a binary code to increase capacity and improve the efficiency of the user interface in an attempt to improve coding rates. The study of GT applications mentioned above [7] found that manual systems
took between 2 and 5 minutes to code a part while computerised systems took between 5 and 15 minutes for each component. Hyer and Wemmerlov speculate that the surprising increase in times for supposedly more efficient computerised systems may reflect their use for more complex parts. It may also reflect the design of the user interface employed by the OIR system (a derivative of MICLASS mentioned above) that was used by many of the companies surveyed. These figures broadly agree with our experience with the Camac (v5) [10] and Opitz [11]systems although the former was a little quicker, averaging around 10 drawings per hour for complex parts. The significance of these rates can be judged from a simple
example. A company that has 100,000 drawing to code would need to employ an engineer dedicated to coding alone for 40 hours every week for a period of over five years. This implies either significant set-up costs or, if parts are only added when modified or created, a very long period before any pay-back is evident. Once the system was set up an engineer would be needed to maintain the database by adding new parts, re-coding any that are
modified and removing obsolete items. If new parts are added at a rate of 0.25% of the range per month and a similar number are modified then this would generate a workload of around a 50 man-hours/month. In these circumstance it can be appreciated that short term pressures would tempt companies to abandon the technique.
3. Automated Coding & Classification of Parts
Clearly a method of automating the coding process would offer great benefits in reducing the set-up and maintenance costs of these systems. It would also avoid errors that are
introduced by humans when interpreting the drawing geometry into code values. Only limited information has been published on coding errors but our experience is that serious error rates can reach 3% whilst Hyer and Wemmerlov [7] report higher average rates of between 3.4% and 5.86%. Automating the coding process is not a trivial task especially when considering 2D drawings, rather than a 3D model, as the source of the process. There is an interesting example of the use of a neural network to identify features from a bit-mapped 2D drawings so as to populated a small part of an Optiz code [12]. As might be expected, more examples exist of systems that produce codes from 3D data sources (for example see Nadir et al. [13]and Ames [14]). However the 2D case is likely to be much more important for design retrieval since companies have far more legacy drawings in this format than have yet been produced in, or converted to, 3D systems.
The prospects for automation of the coding process are affected by the nature of the retrieval problem. The examples quoted above make no distinction between the problem of retrieval for GT family formation and design retrieval. GT applications require a high level of discrimination in the retrieval mechanism since inappropriate parts cannot be tolerated in the family or cluster returned. The cell has to be designed to manufacture every member of the family so that parts that do not 'fit' have to be detected and removed manually. High levels of discrimination help that process but risk rejection of other parts that should be included, thus representing a serious challenge to any retrieval system based on data that can be
automatically extracted from the drawing. However design retrieval applications require much less precision in the retrieval process since the designer will simply ignore
inappropriate items and select the best fit part providing it is displayed in a convenient manner.
GT family formation also differs from design retrieval in that it requires the system to return a cluster of parts that are similar to a 'seed' component rather than one good matching item. Ideally the cluster should be as large as possible, consistent with limited range of manufacturing processes supported by the cell. The design case is exactly the opposite - the
designer wants to examine as small a set of parts as possible, consistent with finding an
optimal match. This distinction is of interest because some approaches to design retrieval [15, 16] focus on a technology that is cluster-based and thus inherently more suited to GT family formation. This approach was used in the traditional Brisch system [1] where progressive categorisation of the part leads to allocation to a sub-group or cluster. From a classification viewpoint this approach is efficient and leads to a very short code but it suffers from the fact that minor differences in interpretation made in the early stages of the process can lead to two similar parts being allocated to different clusters. In any search the system can only return one cluster per search so that a user will remain unaware that other matches may exist in the database. This issue is particularly serious when the search requirement is defined loosely -Brisch has problems returning parts based on an incomplete definition of the desired
characteristics because a match would occur for parts located in many clusters. In the design case this is likely to be a common requirement and one that is easily met by more
conventional coding structures used by most other systems where parts of the code are used to represent particular characteristics. For example a search for all long rotational parts that have a through bore can be carried out in the Opitz code by matching on values in the first and third digits. A further refinement was offered by a previous version of Camac (v5) [10] that could calculate the degree of 'similarity' that existed between the search criteria code and that of each part in its database and so provide a 'fuzzy' search capability. This meant that Camac could return the results of a search in order of 'similarity'. The designer could then scan the list accordingly.
Although Camac v5 computerised all storage, searching and analysis operations it still required an engineer to interpret the drawing and enter properties that are coded. This issue meant that whilst technically successful it suffered from the resource constraints discussed above. This problem lead to the development of a new version of the system (v6) that sought to automate the extraction and coding of properties from the part CAD drawing file. In other respects the system retained the key features of the previous system, notably the binary code structure and the 'fuzzy' search capability that provided the retrieval based on part similarity
4. Development of an Automated Coding System
Once an ability to automatically code parts is established it follows that the user can interact with the system in a graphical manner; knowledge of the underlying code structure is not required because any drawing, even a sketch, can be coded automatically and that code used to search the database. Display of parts in order of similarity to the target part or sketch can also utilise graphical images of the parts so users can readily judge the suitability of the parts that had been found. These considerations meant that the user-interface had to be completely re-written and the underlying database structure has also changed considerably.
The user is presented with a browser that allows the parts database (called a catalogue in Camac) to be manually scanned. A master record is created in the catalogue for each part that holds a range of descriptive data and, if required, a copy of the source CAD file in DXF format. Subsidiary, linked, records are used to hold a code and image of each 2D view of the part that has been extracted from the full drawing. If a 3D model exists of the item then another subsidiary record is also created to hold an image of the model, a pointer to the model file, and a 3D version of the Camac code. This structure means that the system will allow a 2D sketch to be used to search for a 3D model.
A particular problem exists when coding 2D engineering drawings that is rarely discussed in the literature that is concerned with 2D image retrieval. Much of this literature is
concerned with the general problem of retrieval of bit-map images and unsurprisingly most of the reported systems appear to assume that the image is 'clean' in that it contains no irrelevant graphical elements systems (see Eakins [17], for example). In an engineering context the desired 2D image is that of a simple view that defines the essential geometry of the part without any of the extraneous 'clutter' that is necessarily present on a normal engineering drawing. By 'clutter' we mean for example title blocks, dimensions, textual comments, sections and machining marks. Since the drawing will normally contain several views it follows that a truly automatic system must be able to locate each of these and extract them free of 'clutter'. Camac uses a filtering process for this purpose that allows the user to define the types of entity that should be removed. If the company follows sound drawing
conventions then the filtering definitions are straightforward and can be applied across a company's complete drawing database. However experience suggests that companies do not always apply such standards consistently so that, whilst all new drawings can dealt with readily by the imposition of sensible draughting standards, it does mean that creation of the database of past drawings may require more extensive analysis of past drawing practise. The extent of the pre-processing required affects the speed of the extraction and coding process, for example single views of simple parts can be coded at rates exceeding 1000/min whilst multi-view drawings of complex non-rotational parts or assemblies will drop this rate to 10/min. Even the slowest of these rates compares very well with manual methods and suggest that even very large databases could be created in a matter of days or weeks rather the years it would traditionally have taken. Coding of parts can be accomplished either singly or through a batch run.
Searches in Camac use a drawing of the desired item. The drawing is normally of one view of the part and can be either fully-detailed or a simple sketch. In this context it is important to note that the 'sketch' is not a bit-map image like that produced by an illustration programme but a vector graphic drawing (i.e. collection of geometric entities with
dimensional information) created quickly by a designer in a CAD system. The differences
Sketch in CAD Window or load a detailed
Drawing from file, then search the catalogue
Camac browser displays the retrieved parts in order of similarity
Double-click on the drawing to load the part into the viewer window
between a sketch and a detailed drawing are discussed briefly below in section 5 below. Camac codes the seed drawing (or sketch) and uses that code to search the catalogue of existing drawings, calculating a similarity index as it goes. Parts are then sorted in the browser display in descending order of similarity to the original seed. Double clicking on a part view or 3D model image will result in the system displaying the full 2D drawing in another window. Figure 1 illustrates this process.
The current version of the system is a prototype but further versions are planned that will offer tight integration with appropriate 2D and 3D CAD systems.
5. Effect on Retrieval Performance of Partitioning the Database
In principle the code structure can be adjusted to match a particular set of parts but prior to this paper all retrieval testing had used essentially the same code definitions even though the characteristics of the parts in the database varied considerably. The ability to tailor the code to a particular group of parts opens up the possibility that better retrieval performance could be obtained by splitting a company's database up into catalogues with each one containing parts of a particular type. Searching a series of catalogues, rather than just one, is a facility that could be easily added to the system so the approach would not affect retrieval
convenience. To test this hypothesis we set up the series of tests that are described below. The database of parts was created from drawings offered on the web by supplier of tooling parts and assemblies. The database was partitioned into the same 'categories' used by the original manufacturer. This produced 6 catalogues containing specialist parts.
The retrieval performance of the system varies with the quality and detail of the original drawing used as the seed part [18]. It is possible that the any improvement in performance offered by partitioning the parts database would differ for detailed and sketched originals.
For these experiments we have selected a representative part from each tooling part category and then created a 'good' and 'poor' sketch of each one. The distinction between these types of sketch is that the former is a simplified version of the original drawing, such as might be
Sketch Quality 0145 1002 2210 3130 4532 5005
Detail
Good
Poor
Part Numbers
produced by an experienced draughtsman whereas the 'poor' version also contains errors of location and form as well. These are the kind of errors that might be expected to be made by an inexperienced or casual user.
The full set of detailed originals and sketches are shown in Figure 2. The original 'complete' catalogue that contained all 3392 parts was split into the six categories shown in Table 1. The table also shows the number of parts in each of the classified catalogues. The original drawings were simple single views of each part. In each case an automated code fitting routine was run that revised the code definitions to match the range of property values that were present in the set of parts in each catalogue. Thus when a search was performed the seed drawing (detailed or sketch) was coded with the appropriate target catalogue's code definition before the similarity indices were calculated.
Retrieval performance can be measured in a number of ways but for design tasks there are two circumstances that need to be considered. If a designer has very particular requirements then the need is for the system to return all the matching parts that are in the database as
Handles and Knobs Jigs and Fixtures
Locating Pins Locators
Nuts, Bolts & Washers Supports Complete -Number of Parts Similar to Seed 440 513 404 24 22 11 Total Number of Parts 3392 6 14 13 708 962 365
Table 1. Statistics of the Parts Catalogues
Complete Catalogue Categorised Catalogue 0 10 20 30 40 50 60 70 80 90 100 0 50 100 150 200
Cumulative Items Retrieved
R ecall (% ) Poor Sketch 0 10 20 30 40 50 60 70 80 90 100 0 50 100 150 200
Cumulative Items Retrieved
R
ecall (
%
)
Detailed Sketch
Figure 3. Retrieval Performance Results - Recall
0 10 20 30 40 50 60 70 80 90 100 0 50 100 150 200
Cumulative Items Retrieved
R ecal l ( % ) Good Sketch
conveniently as possible. The designer must be sure that all possibilities have been covered. A conventional measure of retrieval performance, 'recall', can be used here. Recall measures the proportion of all the matching parts in the database that have been returned in the first 'n' parts. In this case we will set n equal to 200, since this represents a reasonable maximum value for manual scanning. In the second case the designer has a less precise set of requirements and thus the requirement is to return a good match as high in the list of parts as possible. This could be called the 'first hit' metric where the rank position of the first
acceptable match is taken as the key measure.
The graphs shown in Figure 3 give the recall performance for the three types of original seed and in each case compare the performance of the categorised and complete databases.
These recall figures given in the graphs are presented as a summary of the performance across all the parts being an average of the six individual part recall percentages by rank decade. In these tests the retrieval performance:
• is best for the detailed seed drawing for both the categorised and complete databases (achieving over 90% in the first 50 parts returned);
• is better for the categorised database across all type of original drawing;
• differs most between the categorised and complete databases for the sketches and the gap is greatest for the 'poor' sketch;
• is good for even the poorest sketch when used on a categorised database (achieving recall of around 70% in the first 50 parts returned for both types of sketch).
These results are related to the situation in which the designer needs to be confident that all the possible matches have been returned from the database. It can be seen that this is achieved for the large (complete) catalogue only for the detailed drawing although both sketches do well searching the categorised databases.
The results shown in Table 2 are most relevant to the second case mentioned earlier -when a designer has a more flexible requirement and is merely concerned with finding a good match as quickly as possible. The table shows the rank of the first matching part returned by the system and results are given for the detailed original and the two types of sketch. The detailed original is included for completeness although as would be expected the originals simply find themselves. The table indicates both the rank and the identity of the part that was returned in each case. In many instances the sketch returns the target component as the
Rank of First Hit & Part Numb er Found
Seed Used:
Catalogue Used: Complete Categorised Complete Categorised Complete Categorised 0145 (Handles & knobs) 1 (0145) 1 (0145) 3 (0145) 1 (0145) 256 (0187) 2 (0164) 1002 (Jigs & fixtures) 1 (1002) 1 (1002) 1 (1002) 1 (1002) 9 (1009) 3 (1002) 2210 (Locating pins) 1 (2210) 1 (2210) 1 (2210) 1 (2210) 2 (2210) 1 (2210) 3130 (Locators) 1 (3130) 1 (3130) 1 (3130) 1 (3130) 3 (3056) 1 (3238) 4532 (Nuts, bolts & washers) 1 (4532) 1 (4532) 1 (4655) 1 (4655) 1 (4655) 1 (4655) 5005 (Supports) 1 (5005) 1 (5005) 11 (5005) 1 (5005) 36 (5006) 3 (5006) Ta rg e t Pa rt
Detailed Drawing Good Sketch Poor Sketch
highest ranked part. In the other cases whilst the first item returned was a different part, it was an acceptable match. In all but two cases the first match is returned within 11 parts and only in one instance (the poor handle sketch using the complete database) does the system fail to return a match in a reasonable number of parts. As might be expected the good sketch produces a better performance than the poor one. It is also evident that the results for the categorised databases are consistently better than those for the complete one.
6. Discussion and Conclusion
The results above suggest that for the second case, a good quick match (fit hit metric), performance is in general not greatly affected by sketch quality or categorisation of databases. While there is noticeable reduction in performance as the sketch quality is reduced it is not practically significant except for the poor sketch of item 0145 with the complete database. While we are not able to offer an explanation at this time for these items having a relatively poor performance, from a practical point of view we are not overly concerned given that the majority of users would not be producing sketches of this poor quality.
For recall-related application, i.e. where a full set of matching parts is required, it would appear that to achieve an acceptable performance, when using a large non-categorised database, requires a detailed sketch. This could have implications for the maximum size of the database that could be tolerated whilst maintaining retrieval performance for sketch driven searches. However this conclusion ignores the possibility of the user employing a 'two pass' search strategy. In the first pass the sketch is used to search the database to return a set of possible matching parts. The results in table 2 show that the first hit performance in these circumstances will normally return a good match in the first tens of parts. This set is visually scanned for the best match and that item is selected as the basis of another, second, search. Since the second search uses a detailed original the recall performance will be lifted to the much higher value shown in Figure 3 thus ensuring a comprehensive set has been retrieved from even a poor starting sketch.
For the size of database used in the testing, the results show that partitioning is not required to achieve an acceptable performance when using sketches. It is however, not possible to say with certainty that for significantly larger databases the same results would hold. If performance with sketches were significantly affected by an increase in database size, then a short-term solution would be to partition the database. Based on the current testing the system would achieve an acceptable performance using poor sketches with over 20000 parts. This figure is based on 6 partitions of 3400 parts each, however, using more partitions would enable even larger numbers to be accommodated. For good quality sketches significantly larger databases could be used and still give an acceptable performance.
While we see no reason for the performance to deteriorate significantly with larger databases, further testing is to be carried out to investigate this aspect.
References
[1] William F. Hyde, “Improving Productivity by Classification, Coding and Data Base
Standardization”, Marcel Dekker, NY, 1989.
[2] C.C. Gallagher and W.A. Knight, “Group Technology”, Butterworth, 1973.
[3] Tatikonda, M.V. & Wemmerlov, U., “Design and implementation of group technology
classification and coding systems: insights from seven case studies”, International Journal of
[4] Sharma, S.C. “A critical study of the classification and coding systems in manufacturing
companies”, MSc Thesis, Lehigh University, U.S., 1978.
[5] Dowlatshahi, S. & Nagaraj, M., “Application of Group Technology for design data management”, Computers & Industrial Engineering, Vol. 34, No. 1, 1998, pp. 235 – 255.
[6] Johnson & Broms, “Profit Beyond Measure”, Nicholas Brealey, 2000.
[7] Hyer, N.L. & Wemmerlov, U., “Group Technology in the U.S. manufacturing industry: a survey of
current practices”, International Journal of Production Research, Vol. 27, No. 8, 1989, pp. 1287 –
1304.
[8] Houtzeel , Alexander, 1975, “MICLASS, A Classification System Based on Group Technology”, . Conference, SME Tech Paper, Los Angeles, CA, USA, , Mar 10-13 1975, MS75-721.
[9] D.M. Love and A.R. George, “Designing a Computerized Component Coding and
Classification System to Minimise Implementation Costs”, Proceedings CADCAM,
Cambridge, 1985, pp. 23-31.
[10] Holmes, N.E. and Love, D.M., “The Role of Coding and Classification in a User-Oriented View
of CIM”, Proceedings 8th Int. Conference on Computer-Aided Production Engineering,
Edinburgh, Ed. McGeogh, J.A., August 1992, pp. 137-141.
[11] Opitz, H., “A Classification to Describe Workpieces”, Pergamon Press, Oxford, 1970. [12] Kaperthi, S & Suresh, N.C. “A neural network system for shape-based classification and
Coding of rotational parts”, International Journal of Production Research, Vol.29, No.9, 1991,
pp.1771-84.
[13] Nadir, Y., Chaabane, M., Marty, C., “PROCODE - Automated coding system in group technology
for rotational parts”, Computers in Industry, Vol.23, 1993, pp.39-47.
[14] Ames, A.L, “Production ready feature recognition based automatic group technology part
coding”, Proceedings Symposium on Solid Modeling Foundations and CAD/CAM Applications.
ACM, New York, NY, USA, 1991, pp.161-169
[15] Thomas P. Caudell; Scott D.G. Smith; Richard Escobedo and Michael Anderson.,”NIRS: Large
Scale ART-1 Neural Architectures for Engineering Design Retrieval. Neural Networks”, Vol. 7,
No. 9, 1994, pp.1339-1350.
[16]Manuel J. Fonseca and Joaquim A. Jorge, “Towards content-based retrieval of technical drawings
through high-dimensional indexing”, Computers & Graphics, Vol. 27, No. 1, February 2003,
pp.61-69.
[17] Eakins, J.P., “Design criteria for a shape retrieval system”, Computers in Industry, Vol.21, 1993, pp.167-184.
[18] Barton, J.A. and Love, D.M., “Retrieving Designs from a Sketch using an Automated GT Coding
& Classification System”, Proceedings of the 6th International Conference on Industrial
