Ž .Computers in Industry 41 2000 261–277www.elsevier.nlrlocatercompind

Migrating from IGES to STEP: one to one translation of IGESdrawing to STEP drafting data

Mangesh P. Bhandarkar a, Blair Downie b, Martin Hardwick b, Rakesh Nagi a,)

a Department of Industrial Engineering, 342 Bell Hall, State UniÕersity of New York, Buffalo, NY 14260, USAb Department of Computer Science and Center for AdÕanced Technology in Automation, Robotics and Manufacturing, Rensselaer

Polytechnic Institute, Troy, NY 12180, USA

Received 12 January 1998; accepted 21 June 1999

Abstract

This paper focuses on a procedure for converting product design data from an Initial Graphic Exchange SpecificationŽ . Ž .IGES format into Standard for the Exchange of Product Model Data STEP format. IGES is used for representing designand topology information in a platform independent format. The failure of the IGES standard to provide information otherthan drawing and solid modeling has led to the emergence of a new international standard for product model data exchangeŽ .ISO 10303 called STEP. STEP is designed to support a product through its entire life cycle. The STEP standard consists ofa set of application protocols. An application protocol is specific to a particular engineering domain. In this case, STEPapplication protocol 202 is used because it defines the constructs necessary to represent the associative draughting

Ž .information described by IGES. The translator parses the IGES file and converts it into the corresponding STEP AP202format. To test the conformance of the generated STEP file we have written code to enable visualization of an Application

Ž .Protocol 202 AP202 STEP file. The visualization uses the Open Inventor Toolkit available for the Silicon GraphicsŽ .platform. The visualizer reads the STEP AP202 file and converts the geometry and related annotations into the

corresponding Inventor specific format. The file can then be viewed using the default Inventor viewer. q 2000 ElsevierScience B.V. All rights reserved.

Keywords: IGES; STEP; Translation

1. Introduction

The past few years have seen a change in manu-facturing strategies and technologies. The marketshave become more and more fragmented, and com-petitiveness has increased. For a manufacturing en-terprise to be competitive and thrive in such a dy-namic environment it must be capable of adjusting

) Corresponding author. Tel.: q1-7166452357; fax: q1-7166453302; e-mail: nagi@eng.buffalo.edu

rapidly to the market. This has led to the emergenceof a new manufacturing paradigm called Agile Man-ufacturing, where multiple companies cooperate un-der flexible virtual enterprise structures. The impetusis on producing products of better quality in the leastamount of time and at the best possible price.

Agile manufacturing makes use of modern infor-mation technology to form a virtual enterprise. Part-ners must maintain a high amount of communicationand data exchange between themselves for the suc-cess of the virtual enterprise. Data exchange does not

0166-3615r00r$ - see front matter q 2000 Elsevier Science B.V. All rights reserved.Ž .PII: S0166-3615 99 00052-4

( )M.P. Bhandarkar et al.rComputers in Industry 41 2000 261–277262

mean just verbal communication, but the companiesmust exchange complete information about theirproducts, all the way from design, manufacturing toinspection and shipping. This information should beavailable to each relevant partner over the entire lifecycle of the product.

Researchers have recognized the need for an in-ternational standard for product data exchange whichwould facilitate the seamless exchange of data. Com-panies in their own efforts have also recognized thesame need. Attempts were made in the past to de-velop an international standard for data exchange.The earlier efforts led to the Initial Graphic Ex-

Ž .change Specification IGES , which stores drawinginformation in an ASCII or binary neutral formatwhich can then be exchanged between various users.

Ž .Many Computer Aided Design CAD software ven-dors support IGES. Files in the IGES format can beloaded into these packages and in turn saved backinto the IGES format. As effective as it might seem,IGES is currently being used in the industry butlacks considerably in many respects such as the lackof a formal information model, problems during fileexchanges and manipulations, lack of life-cycle sup-port and hard to understand file formats.

This led to the development of the Standard forŽ .the Exchange of Product Model Data STEP . STEP

became an ISO standard in 1993. STEP is publishedin a series of parts which include the following:description methods, integrated resources, applica-tion protocols, abstract test suites, implementationmethods and conformance testing. The informationin STEP is represented using an information model-

w xing language called EXPRESS 13 . STEP uses ap-Ž .plication protocols APs to specify the representa-

tion of product information for one or more applica-tions. For example the application protocol that de-fines the constructs for representing product shapeand assembly information is called ‘Configuration

ŽControlled Design’, AP203. The draughting in ISOterminology drafting is spelled draughting, we will

.be using the ISO spelling throughout the paperinformation can be represented in AP202, ‘Associa-tive Draughting’ schema.

STEP has gained considerable importance due toactive support from the automobile, aerospace andthe defense sector. PDES Inc., an industryrgovern-ment consortium, has been formed for accelerating

the development and implementation of STEP in theUnited States. Similar organizations exist in Ger-many, United Kingdom and Japan. Many companiesare providing tools to access and manipulate STEPdata. Also, the development in Internet related soft-ware has led to a rapid increase in STEP-basedproduct data exchange over the world wide web.CAD software vendors and third parties for systemslike AutoCAD, PROrEngineer, CATIA, Unigraph-ics, Microstation, Trispectives and ACIS, have STEPinterfaces in their new releases. As the acceptanceand the use of STEP-based information exchangeincreases, a need for translation services to convertinformation represented in legacy file formats likeIGES into STEP will arise. In addition to this is alsothe fact that the current version of IGES may be thelast and a policy will be developed for companies tomigrate to STEP. We have realized this requirementand the current paper focuses on our efforts in thedevelopment of a translator from the IGES drawingspecification into the relevant STEP format.

The paper is organized as follows. We first pre-sent a brief overview of IGES and STEP followed bya literature review. We go on to describe the currentproblem on hand and present the work done in termsof the coding and testing of the translator. To vali-date the converted STEP file, work has also beendone to develop a visualizer. Finally we concludewith a discussion and proposed further work.

2. Background

This section briefly covers the history of elec-tronic data exchange for product design information.The IGES standard which can be regarded as the‘‘first modern electronic data exchange tool’’ is de-scribed. We have also provided reasons as to whyIGES did not gain much popularity, and also taken alook at the STEP standard and it benefits over IGES.

2.1. Product data exchange history

In the 1960s and most of the 1970s, each CADsystem had its own file format for the representationof product design information. Information transferwas done by producing hard copy drawing from thefirst systems and then manually reentering the draw-

( )M.P. Bhandarkar et al.rComputers in Industry 41 2000 261–277 263

ing information into the second CAD system. Thiswas a very tedious process, it was prone to errorsand caused the repetition of data in multiple fileformats.

As the number of CAD-based systems increased,the need for exchange of information between thevarious systems increased. At this early stage, elec-tronic data transfer between the various systems wasachieved by using custom translator software to con-vert data files from one system format to another.Although custom translators were fast, efficient andreasonably accurate if written properly, this approachsuffered from the following drawbacks. The numberof custom translators required to transfer files be-

Ž .tween all the CAD systems is equal to N= Ny1 ,where N is the number of CAD and engineeringsystems. Having custom translators between everyCAD system, even in a moderately sized organiza-tion, far outweighs the effectiveness of the transla-tors. Also, writing, testing and maintaining customtranslators is expensive and consumes considerableamount of resources.

With the increase in the number of CAD-basedengineering applications like designing, finite ele-ment analysis and process planning, along with theadvent of the computer integrated manufacturing phi-losophy, the need for a standard for representingCAD and other engineering information became in-creasingly apparent. This led to the development ofthe IGES standard, which specifies a neutral fileformat for exchanging data between CAD androrengineering systems. CAD systems, using IGES toexchange data, only require a pre-processor to importan IGES file into the CAD system and a post-processor to convert the data back to the IGESformat. This eliminates the need for custom transla-tors between each of the individual CAD systems.Section 2.2 describes the IGES specification andsome of the difficulties associated with IGES dataexchange which has led to the development of theSTEP standard.

( )2.2. Initial Graphic Exchange Specification IGES

IGES provides a standard format by which theuser can transfer product design data from one CADsystem to another. IGES specification is concernedwith the data required to describe and communicate

the essential engineering characteristics of physicalobjects. The application areas covered by IGES in-clude electrical, plant design, as well as mechanicalapplications.

IGES has information structures or entities to beused for digital representation and communication ofproduct definition data. In other words, the IGESformat treats the product definition as a file ofentities. Each entity, which is the fundamental unitof data in an IGES file, is represented in an applica-tion-independent format. The entity representationcontains enough information to support the needs ofmost of the currently available CADrCAM systems.The entities can be broadly classified into geometryentities and non-geometry entities which are elabo-rated in the following.

Geometry entities represent the definition of thephysical shape and include points, curves, surfaces,solids and relations which are collections of similarlystructured entities. Non-geometry entities provide aviewing perspective of which a planar drawing iscomposed, by providing annotation and dimension-ing appropriate to the drawing. Non-geometry enti-ties further serve to provide specific attributes orcharacteristics for individual entities. Non-geometryentities include view, drawing, dimensions, text, no-tation, witness lines and leaders. For details aboutthe IGES specification, the descriptions and arrange-ment of the data in an IGES file the readers are

w xdirected to 9 .Since IGES specifies a neutral file format for the

representation and exchange of product data, it has aclear advantage over custom translator developmentand maintenance. Although IGES seems to be quiteuseful and facilitates electronic data exchange, IGEShas some problems. IGES does not have a formaldata model which leads to ambiguities in certaincases. The IGES files because of their 80-column fileformat are very verbose. These files are also verydifficult to understand because of the complicatedway in which the data is arranged. If there is an errorin the IGES file, it is very difficult to find themistake and correct it. Errors may arise due tochanges made in the file. Further, due to lack of anyconformance requirements imposed by IGES, CADvendors have developed their own flavors for theIGES files which are not often consistent with othervendors. This leads to incomplete translation and

( )M.P. Bhandarkar et al.rComputers in Industry 41 2000 261–277264

loss of information, which is unacceptable for engi-neering applications.

IGES does not provide data that may be relevantto applications other than drawing or 3D modeling.For example the designer may be interested only inthe drawing or the geometry of the part to be manu-factured, but the process planner would be moreinterested in the manufacturing view of the partwhich may contain form features and the manufac-turability information of the part, and the inspectiondepartment may be interested in the tolerance infor-mation for the part. Each of the departments wouldshare the same IGES file and it is left to the interpre-tation of the individual to derive the relevant infor-mation. Thus IGES does not provide any life-cyclerelated information and is also not very extensibledue to the lack of any integrated resources.

Ž .To summarize: i IGES does not have a formalŽ .information model, ii there is a problem of incom-

plete exchange due to various ‘flavors’ added byŽ .CAD vendors, iii IGES does not support life-cycle

information which may be relevant for engineeringŽ .applications other than design, and iv the IGES

80-column format is not easily human understand-able and hence mistakes if any cannot be easilyfound and corrected. All these reasons led to thedevelopment of the STEP standard which aims ataddressing all the above issues.

2.3. Standard for the Exchange of Product Model( )Data STEP

The shortcomings of the IGES standard led to thedevelopment of the ISO STEP standard. STEP pro-vides representation of product information alongwith the necessary mechanisms and definitions toenable product data to be exchanged. The exchangeis among different computer systems and environ-ments associated with the complete product life cy-cle including design, manufacturing, utilization,maintenance and disposal. The information generatedabout a product during these processes is used formany purposes. Such use may involve many differ-ent computer systems within the same organizationor between different organizations.

Ž .STEP is based on a three layered architecture: ithe reference model which develops a number of

Ž .topical models specific to individual applications, ii

the logical layer which specifies the format defini-Ž .tion language called EXPRESS, and iii the physical

layer which defines the communication file structurecalled STEP file.

STEP uses a formal information modeling lan-w xguage, EXPRESS 13 , to specify the product infor-

mation to be represented. The use of a formal lan-guage enables precision and consistency of represen-tation and facilitates implementation. Application

Ž .protocols APs are used to specify the representa-tion of product information for one or more applica-tions. Application protocols are based on four main

Ž . Ž .ideas: i scope and context of application, ii anŽ .Application Reference Model ARM defining the

Ž .requirements, iii an Application-Interpreted ModelŽ .AIM which satisfies the requirements given in the

Ž .ARM using STEP constructs, and iv conformancerequirements and test procedures for compliance withthe application protocol. Several APs have alreadybeen developed to support different kinds of engi-neering applications. A graphical view of the STEP

w xarchitecture can be found at 17 .STEP enables all people contributing to the de-

sign, manufacturing, marketing and supply of a prod-uct and its components to contribute to, to access,and to share information. STEP aims at eliminatingthe concept of ‘‘islands of automation.’’ STEP alsoattempts to unite manufacturing efforts among cor-porate partners, distant subsidiaries and suppliersacross diverse computer environments. It is intendedto fit in with the new emerging paradigm of virtualenterprises and agile manufacturing. STEP addressesthe issues of diversified engineering applications andcovers security aspects, which become relevant nowthat several companies would be sharing the sameproduct information.

Due to its increasing awareness and the presenceof compatible tools STEP has started to gain consid-erable industry acceptance, notably in the aerospaceand defense industry, automotive industry and shipbuilding industry. Companies have now started look-ing at STEP as a means of defining and storingproduct data information. Already product geometryand 3D rendering information are being stored asdocuments defining the product in enterprise product

Ž .data management PDM systems. This allows view-ing and modification of geometry using any CADtool capable of interpreting STEP geometry and

( )M.P. Bhandarkar et al.rComputers in Industry 41 2000 261–277 265

breaks the dependency between CAD systems andproduct definition. However the problem still existsfor drafting data. Storing drafting information in alegacy format, such as IGES, leads to redundantrepresentation of product definition and geometryinformation in multiple formats. Such redundantstorage, in an environment where product data isbeing continuously changed and updated, leads toincoherent product data and incompatibility betweendifferent forms of representation of the same infor-mation.

Two dimensional representation of geometry inthe form of drawings can be perceived as one partic-

Žular view of product information as opposed to 3D.view . In fact many CAD systems treat drawing

information as 3D geometry projected onto a 2Dplane. The representation of drawing data in a STEPformat facilitates uniform representation of multipleviews of product data thus enabling better control.All the above factors warrant a translation betweenIGES and STEP to achieve representation of productdata in a single standard compliant and system inde-pendent format. Section 3 provides a literature re-view about existing work done in this area.

3. Literature review

The authors are not aware of any large scaleefforts to write a translator from IGES to STEP, inparticular for 2D draughting information of designs.

w xHowever STEP Tools Inc., 18 have a translatorwhich converts IGES geometry information into

Ž .NURBS Non-Uniform Rational B-Splines for visu-alization purposes. This translator however translatesonly the geometry and does address any draftingtype information. Another aspect of this translator isthat it converts all the geometry into STEP NURBSand thus does not make use of the vast number ofgeometry resources offered by STEP. Other STEPsoftware vendors, namely ProSTEP and EuroSTEPmay also may have such commercially availabletranslators however to the best of the authors knowl-edge none of them specifically translate more thangeometry and product structure information.

There may however be certain small scale transla-tors available which have been written for particular

w xapplications. Basu and Kumar 2 have written a

translator for finite element analysis. The translatorŽ .extracts mesh entities nodes and elements from an

IGES file and a simple Fortran 77 program convertsthese into relevant entities for Finite ElementrBoundary element analysis.

w xSsemakula and Satsangi 16 have done somework with IGES and PDES 1 for computer integratedprocess planning. However they have not written anydirect translation between IGES and PDES. Liu et al.w x14 have written a translator to convert IGES enti-ties into an object-oriented format. The objects arethen used for feature extraction. The translator doesnot deal with all the IGES entities and does notconvert the entities into the STEP format.

w xCAD software companies, like AutoCAD 1 ,w x w xPROrEngineer 10 and CATIA 4 , have developed

their own in-house translators to convert from IGESinto their software specific format. This is to facili-tate import and export of IGES files from their CADproduct to enhance acceptability or migration to theirsystem. However these translators cannot be usedindependently for information exchange without theirrespective proprietary post-processor which write outfiles from their CAD format into IGES or STEP.

w xSTEP Tools Inc., 18 , has a visualizer that can beused to view AP203 STEP files. However we are not

w xaware of any visualizer for AP202 11,12 STEPfiles. There has been some work done to convertIGES entities into Silicon Graphics Inventor format.This effort has been done by a third party vendor for

w xSilicon Graphics 15 but again nothing that handlesgeometry as well as drafting data.

4. Approach

STEP has gained considerable popularity in therecent past, mainly due to the active support forSTEP from the automobile and the aircraft indus-tries. The number of STEP-based applications hasbeen on the rise for the past few years. CAD vendorsare also developing STEP interfaces to their prod-ucts. Companies that have been using IGES-basedCAD systems have considerable data in this legacy

1 PDES was the precursor to STEP in the US.

( )M.P. Bhandarkar et al.rComputers in Industry 41 2000 261–277266

format. To avoid the regeneration of this data in theSTEP format, our objective is to develop a translatorfrom the legacy format to the new file format. Forthis current project we have concentrated on thegeometry, topology and draughting information.

The STEP scheme which is most relevant for thew xtask on hand is the AP202 11,12 , Associative

Draughting Schema. AP202 has recently been re-Ž .leased as an International Standard IS . This section

describes AP202, the associative draughting schema.To approach the translation effort in a formal mannerwe have developed an information model of theIGES specification using EXPRESS. Then, the map-ping between IGES and AP202 has been describedin terms of their respective EXPRESS schema enti-ties. Along with the conceptual clarity, this approachhas other advantages including database population

Ž .of large files see Section 5 .

(4.1. Application protocol 202 associatiÕe draught-)ing

AP202 is the STEP schema intended for inter-organization exchange of computer-interpretabledrawing information and associated product defini-tion data. The EXPRESS definition of the AP202

w xschema can be obtained from Ref. 12 . The follow-ing fall under the scope of AP202:Ø Structures for representation drawings for the pur-

pose of exchange, suitable for mechanical andarchitectural engineering, and construction appli-cations.

Ø Drawing management information.Ø Information on product versions being docu-

mented by drawing.Ø Computer-interpretable product shape model de-

fined in two or three dimensional coordinatespace.

Ø Transformations and appearance characteristicsused for the generation of drawing views.

Ø Association between dimensions, draughting call-outs, or fill areas and product geometry.

Ø Mechanisms for the grouping of the elementsdepicted on a drawing.Drawings have been the traditional way of con-

veying product shape information, by means of stan-dard orthographic projections. For many years draw-ings were generated manually and today CAD sys-

tems are used to generate the same drawings. Themethod used by CAD systems differs: some use theprinciples of 2D representation as used in manualdrawings, while others provide the facility to create a3D geometric representation or draughting shapemodel of the product shape. The 2D lines and curvesare then generated from this draughting shape modelusing viewing information. Finally there are somesystems, for integrated modeling and draughting,which provide a three-dimensional draughting shapemodel. A window into the draughting shape model isutilized so that the model may be seen or viewed asa part of the drawing. AP202 supports draughting of

Ž .product in the following three ways: i 2D Annota-Ž .tion Geometry on the drawing sheet, ii 2D ViewŽ .Projections of the product shape, and iii 2D or 3D

Shape with information to derive view projections.Ž .Constructive Solid Geometry CSG solids cannot

Ž .be converted into STEP AP202 to be specificdirectly, as AP202 uses Boundary RepresentationŽ .B-Rep to represent solid models. CSG solids canbe converted by using a solid modeler like ACIS tointerpret the CSG tree and convert it to the corre-sponding B-Rep format. For this reason we haveeliminated CSG entities and concentrated our effortson converting the rest of the IGES entities. Finiteelement modeling entities are not supported inAP202, hence these have not been considered in ourcurrent work.

4.2. IGES as EXPRESS schema

EXPRESS is an information model specificationlanguage which was developed to enable writingformal information models for describing mechanicalproducts. As we noted earlier, STEP uses the EX-PRESS modeling language to represent the productinformation model. The advantages of using a formallanguage have been emphasized in Section 2.3. Toadd to the same, EXPRESS is also ‘‘object-orientedlike’’ allowing the use of object-oriented methodolo-gies like encapsulation, abstraction and inheritancew x13 . EXPRESS also has a formally defined graphicallanguage called EXPRESS-G, which is used forrepresenting subsets of the textural form. EXPRESS-G allows the easy understanding and manipulation ofthe information model.

( )M.P. Bhandarkar et al.rComputers in Industry 41 2000 261–277 267

Due to all these advantages of using EXPRESS, aschema for the IGES specification has been written.The complete listing of the EXPRESS model for

w xIGES can be found at 8 . The top level schema iscalled iges_types_schema; Fig. 1 shows theiges_entity_type_schema. This schema contains anentity called iges_ file which is the highest levelentity. The iges_ file entity contains a list of stringswhich define the start section of the IGES file, apointer to an entity which defines the global sectionof the IGES file, and a list of directory_entry. The

directory_entry is an abstract supertype of geomet-ric_entity, constructiÕe_solid_geometry_entity,boundary_representation_entity, annotation_entity,or structure_entity. These five types of entities arereferenced from five separate schemata:1. The iges_curÕe_and_surface_geometry_schema

covers all the geometry related entities.2. The iges_annotation_schema contains the defini-

tions of all the annotation entities.3. The iges_boundary_representation_schema cov-

ers all the B-Rep topology entities.

Fig. 1. IGES types SCHEMA.

( )M.P. Bhandarkar et al.rComputers in Industry 41 2000 261–277268

4. The iges_constructiÕe_solid_ geometry_schemacovers all CSG elements.

5. The iges_structure_schema contains all the struc-ture entities.Each schema covers a particular class of entities

which are written as EXPRESS classes and classifiedinto one of the five schemata. The parameters ofeach entity, as defined by IGES, form the data

elements of each class. Fig. 2 shows the EXPRESSdefinition of a geometric_entity and circular_arc_entity which is a subtype of the former.

4.3. IGES to AP202 mapping

The development of the translator involves deter-mining the mapping between the IGES entities to the

Fig. 2. EXPRESS definition for geometric_entity and circular_arc_entity.

( )M.P. Bhandarkar et al.rComputers in Industry 41 2000 261–277 269

Ž .corresponding STEP AP202 entities. The mappingis based on the perception and understanding of theIGES and AP202 definitions of entities. The com-plete mapping can be found in Table 1. Furtherexplanation and rationale for specific mapping can

w xbe found at Ref. 3 . Some of the entity whichwarrant special mention are listed below.

Ž .1 IGES rational b_splines curves and surfacesare mapped to a composite entity formed by

Ž .‘‘AND’ing’’ the b_spline curve or surface withŽ .knots and a rational b_spline curve or surface . This

is necessary because IGES specifies knots andweights for rational b_splines whereas STEP doesput any such restriction. Hence to achieve completemapping a composite entity must be used.

Ž .2 IGES witness line entity used for dimensionprojection lines on the drawing sheet is mapped intoAP202 projection curÕe. The witness line entityalways has an odd number of points, where thelengths of the visible and invisible segments arespecified and the first segment being invisible. Thevisibility and invisibility is dealt with using theAP202 curÕe style font pattern. The visible–invisi-ble portions are important for proper display ofdimensions lines on the drawing sheet.

Ž .3 IGES dimension entities are composite entitieswhich are composed of a general note entity, one ormore witness line entities, and one or more leaderarrow entities. All these individual components aremapped into a set of draughting callout elementsand then tied back into the respective AP202 dimen-sion entity. The angular dimension entity is a specialcase in which the points of the leader arrows arejoined using circular arcs rather than lines; this hasbeen treated separately by passing an arc betweenthe points of the leader arrow entity. For completedefinition of the 2D geometry the dimension is tied-back to the corresponding geometry element whichis represented by the dimension.

Ž .4 IGES manifold solid brep entity is a solidmodel representation entity in the B-Rep formatwhich is mapped into an AP202 brep with Õoids ormanifold solid brep depending on the presence orabsence of void shells. A more detailed explanationon the mapping of IGES manifolds can be found in

w xRef. 3 .Ž .5 IGES Õiew entity is mapped into an AP202

Õiew Õolume. The view volume has the required

information to project the geometry from drawingspace coordinates to view space coordinates. This isused for orienting and placing the geometry in theright perspective on the drawing sheet. There is alsoinformation required to clip the geometry for partialviews of the parts.

Ž .6 IGES drawing size entity is converted intoAP202 planar box. This planar box is used tocalculate the extent of the drawing sheet.

Having described the mapping between IGES andAP202, we now go on to describe the developmentof the translator and visualizer.

5. Implementation

This section describes the implementation of theIGES to AP202 translator. A discussion on the work-ing of the visualizer is provided at the end of thissection along with examples to validate the transla-tion from IGES to AP202. The implementation isdone in Cqq using object oriented programmingtechniques. An object oriented database called Rens-

Ž . w xselaer Object Store for Engineering ROSE 6 de-veloped at Rensselaer Polytechnic Institute is usedfor storing and retrieving the objects. The ROSEdatabase works using the compiled EXPRESS defini-tion of the schema. ROSE contains capabilities ofstoring aggregate data types like lists, sets, bags andarrays supported by EXPRESS, and also has func-tionalities to manage the objects. A complete de-

w xscription of ROSE can be found in 6 . The EX-PRESS schemata for IGES and AP202 are compiledinto Cqq classes using the express2cqq utilityprovided in ST-Developer by STEP Tools Inc. Classextension functions are then written to read-in theIGES file and to convert from IGES to AP202. Dueto the complex nature of the IGES file, the IGESinputroutput mechanism is presented first and thenthe translator implementation is explained.

5.1. IGES inputroutput

Ž .The IGES inputroutput IrO is used to read inthe data from the IGES file and write output to a filein the IGES format. We are currently using the IGESIrO only for reading in the IGES file and henceevery reference to IGES IrO will be made as IGES

( )M.P. Bhandarkar et al.rComputers in Industry 41 2000 261–277270

Table 1IGES to AP202 mapping

No. IGES entity AP202 entity

1 Angular Dimension Entity Draughting Annotation Occurrence and Angular Dimension2 Basic Dimension Entity Annotation Curve Occurrence3 Boundary Entity Boundary Curve4 Bounded Surface Entity Curve Bounded Surface5 Centerline Entity Annotation Curve Occurrence and Draughting Annotation Occurrence6 Circular Arc Entity Trimmed Curve or Circle7 Color Definition Entity Colour RGB8 Composite Curve Entity Composite Curve9 Conic Arc Entity Trimmed Curve with basis_curÕe as Parabola, hyperbola, ellipse

10 Coordinate Pair Entity Polyline11 Coordinate Sextuples Entity Composite Curve12 Coordinate Triples Entity Polyline13 Curve Dimension Entity Curve Dimension and Draughting Annotation Occurrence14 Curve on a Parametric Surface Entity Boundary Curve15 Diameter Dimension Entity Diameter Dimension Entity and Draughting Annotation Occurrence16 Edge Entity Oriented Edge17 Edge List Entity Edge Curve18 External Reference Entity Externally defined item19 Face Entity Advanced Face20 Flash Entity Circle or Planar Box or Composite Curve21 General Label Entity Leader Directed Callout and Draughting Annotation Occurrence22 General Note Entity Annotation Text Occurrence and Draughting Annotation Occurrence23 General Symbol Entity Leader Directed Callout and Draughting Annotation Occurrence24 Leader Arrow Entity Dimension Curve Terminator and Draughting Annotation Occurrence and

Leader Terminator25 Line Entity Trimmed Curve26 Linear Dimension Entity Linear Dimension and Draughting Annotation Occurrence27 Loop Entity Face Outer Bound or Face Bound28 Manifold Solid B-REP Object Entity Manifold Solid B-Rep or B-Rep with voids29 New General Note Entity Annotation Text Occurrence and Draughting Annotation Occurrence30 Offset Curve Entity Offset Curve 3D31 Offset Surface Entity Offset Surface Entity32 Ordinate Dimension Entity Ordinate Dimension Entity and Draughting Annotation Occurrence33 Parametric Spline Curve Entity B-Spline Curve with Knots34 Parametric Spline Surface Entity B-Spline Surface with Knots35 Piecewise Curve Entity Polyline36 Planar Piecewise Curve Entity Polyline37 Plane Surface Entity Plane38 Point Entity Annotation Subfigure Occurrence and Draughting Annotation Occurrence39 Radius Dimension Entity Radius Dimension and Draughting Annotation Occurrence40 Rational B-Spline Curve Entity Rational B-Spline Curve and B-Spline Curve with Knots41 Rational B-Spline Surface Entity Rational B-Spline Surface and B-Spline Surface with Knots42 Simple Closed Planar Curve Entity Polyline43 Section Entity Annotation Curve Occurrence and Draughting Annotation Occurrence44 Sectioned Area Entity Annotation Fill Area Occurrence and Draughting Annotation Occurrence45 Spherical Surface Entity Spherical Surface46 Text Font Definition Entity Draughting Pre-defined Text Font47 Toroidal Surface Entity Toroidal Surface48 Trimmed Parametric Surface Entity Curve Bounded Surface49 Units Data Entity Global Units Assigned Context50 Vertex List Entity Vertex Point51 View Entity Presentation View52 Witness Line Entity Annotation Curve Occurrence and Draughting Annotation Occurrence

( )M.P. Bhandarkar et al.rComputers in Industry 41 2000 261–277 271

reader hereafter. We would also like to point to thereader that, similar to the reading functions, thereexists writing functions for the IGES IrO mecha-nism. The input phase creates objects for each of theentities in the directory entry section of the file, andpopulates the objects with appropriate attribute data.The IGES IrO is written as a Cqq class calledIOIGES. The class has private members like a pointerto the IGES file, a file position pointer, the sequencenumber and the directory entry index of the currentrecord being read, and a character array to store thecurrent line being read. Also functions to read asingle record, functions to read the common datatypes like integer, string, double and float, form theprivate member functions. Other functions that areused to open, close and parse each of the sections ofthe IGES file are written as public members of theIOIGES class.

When an IGES file is read, an instance of theIOIGES class is created. The reader first opens thefile for input and function calls are made to readeach of the sections. Each record in the file is readinto a character string. The length of the record ischecked to ascertain that it contains exactly 80 char-acters. The IGES reader first parses through the startsection of the IGES file. Next the global section ofthe file is read, an object of the type global, whichdefines all the elements in this section, is created andpopulated using the data being parsed. The globalsection defines the parameter delimiters and therecord delimiters which are used throughout the file.The other data contained in the global section, asdescribed in Section 2.2, is subsequently read.

After the global section is populated, the IGESreader parses through the directory entry section ofthe file. The directory entry section is parsed in twopasses. In the first pass the record is read and theentity type number is read from that record. Theentity number is used to create an instance of anobject of that type. A Dictionary of created IGESobjects is maintained. The Directory Entry number inthe IGES file is converted into a string and this isused as the key to identify the objects. In the secondpass the elements of the directory entry are read in.The directory entry number of the particular entry isused to index into the Dictionary, retrieve the object,and to populate its other data elements. Next, theparameter data section is parsed. The sequence num-

ber of the record in the parameter data section isused to retrieve the instance of that particular object.This is the same as the second pass of the directoryentry section wherein a unique key is used to retrievethe instance, and the data in the record is used topopulate the object.

Finally, the terminate section of the IGES file isread and the file closed. The IGES data is nowavailable in the form of objects which are to beconverted into AP202 objects.

5.2. IGES to AP202

Fig. 3 contains a flowchart describing the workingof the translator, and elaborated in the followingsteps below.

Ž .1 First the IGES file is read in using the IGESreader. Each IGES entity is now available as apersistent object in the ROSE database. Persistentobjects do not cease to exist after the execution ofthe program is completed and hence can be writtenout to a physical file and transferred without loss ofinformation.

Ž .2 After the IGES file has been read into theROSE library, the translator goes through each of theentities in the directory entry section of the IGES fileand maps it into the corresponding AP202 entity.The IGES Schema has been written in such a waythat there is a common abstract class to each of theIGES entities. This allows the use of polymorphismŽ .as virtual functions in Cqq to be used during theconversion. One important aspect worth mentioninghere is that the IGES geometry entities have aninterpretation flag which specifies use of the particu-lar entity either as geometry or as annotation. If theflag is set to annotation, the mapped entity is con-verted into an annotation_curÕe_occurrence.

Ž .3 At the end of stage two, all the IGES entitieshave been converted into AP202. The mapped AP202shape elements are then parsed and grouped into ageometrically_bounded_surface_shape_representa-tion or an adÕanced_brep_shape_representation,depending on the existence or absence of any topol-ogy information in the file. The geometri-cally_bounded_surface_shape_representation or theadÕanced_brep_shape_representation are finallyconnected back to a draughting_model. The draugh-ting_model is the main collection point for the ge-ometry in the AP202 STEP file and can be conceptu-

( )M.P. Bhandarkar et al.rComputers in Industry 41 2000 261–277272

Fig. 3. Flow chart of IGES to AP202 translation.

ally thought-of as the abstract representation of thedrawing sheet.

Ž .4 AP202 uses the concept of Model-View-Drawcoordinates for the representation. The geometry isrepresented in the model space coordinates where

Ž .one point generally one end of the solid is used asthe origin for all the geometry. The annotations arerepresented in their own drawing space called theview space coordinates. And the drawing sheet level

Želements such as the border of the drawing sheet,.the identification box etc. are represented in the

drawing space coordinates. To complete the transla-tion and create a valid AP202 STEP file, the annota-tions are arranged into their respective views and thegeometry is clipped onto the particular views, con-verting it from Model space to View space using acamera_image_3D_with_scale. The drawing sheetlayout is created in the drawing space coordinatesystem and all the views are transformed into thiscoordinate system. This final step is very importantbecause the proper clipping of the geometry into thedrawing space coordinates and associating the anno-tations with the specific view is essential for com-plete definition and eventual correct viewing of thedrawing sheet.

Ž .5 The STEP data is then, saved in the ROSEdatabase format and can be converted into a STEPPart 21 file format using a format utility providedwith the ST-Developer software by STEP Tools Inc.w x18 .

The translator has been tested and checked usingsample IGES files. Files tested include those ob-tained from National Institute of Science and Tech-

Ž . w x w xnology NIST 7 , WIZ WORKX 20 and Paramet-w xric Technology Corp. 10 .

5.3. Visualizer

After the IGES to AP202 translator had beencompleted it was necessary to write our own visual-izer due to the absence of a commercially availableAP202 viewer. The visualizer serves the dual pur-

Ž .pose of: i validating the generated STEP file, andŽ .ii displaying the drawing. The discussion on theVisualizer is included for the sake of completeness.

We decided to use Open Inventor 3D Graphicw xlanguage 19 toolkit on an SGI platform to write our

visualization software. In Inventor, scene graphs usedto render images on the screen are arranged in theform of a tree. Each branch of the tree containsinformation to describe a particular entity on the

( )M.P. Bhandarkar et al.rComputers in Industry 41 2000 261–277 273

Fig. 4. View of IGES file from the IGES manual.

scene graph. All these branches are attached to aparent node which is the starting point for the traver-

sal of the graph for rendering. Inventor can be usedfor 3-dimensional visualization of curves, surfaces,

Fig. 5. View of converted AP202 file.

( )M.P. Bhandarkar et al.rComputers in Industry 41 2000 261–277274

textures, text and camera views, thus it suits ourrequirements quite well. The way the visualizer worksis listed below.

Ž .1 The STEP file is read into the ROSE libraryso that it can be easily manipulated.

Ž .2 After the file is read into memory, all thegeometry and the topology information is convertedinto the Inventor format. All the geometry is con-verted into Non-Uniform Rational B-SplinesŽ .NURBS curves and surfaces. This is because In-ventor uses NURBS to render curves and surfaces.We have used the DT-NURBS Fortran library devel-oped by Boeing Information and Support Services

w xfor the US Navy 5 . This library is used to convertlines, arc, circles, conics and surfaces into NURBS.The geometry is then converted into an Inventornode.

Ž .3 At the next step we convert all the views andtheir view dependent annotations into correspondingInventor nodes. The geometry node is then trans-formed and added below the annotation nodes. Thisessentially performs the task of converting the geom-etry from drawing space coordinates into view spacecoordinates.

Ž .4 The Inventor file is written out as a ‘‘.iv’’ filewhich can then be visualized using a the iÕÕiew orsceneÕiewer programs provided with the Inventortoolkit.

Most of the files which have been converted intoAP202 have been converted into the Inventor formatand visualized. Fig. 4 shows a view of a sampleIGES file which can be found at the end of the IGES

w xmanual 7 , and the view of the corresponding STEPfile is as shown in Fig. 5.

Fig. 6. View of a nozzle in the IGES format.

( )M.P. Bhandarkar et al.rComputers in Industry 41 2000 261–277 275

Fig. 7. Converted nozzle file in the AP202 format.

It can be seen that the clipped view of the geome-try appears complete in the STEP view. This isbecause clipping is done in Inventor using a camera,however only a single camera can be applied to anInventor window. This would not allow us to see therest of the sheet. We are currently trying to work ourway around this problem to allow viewing of clippedviews in our visualizer. Fig. 6 shows the view of anozzle from an IGES file obtained from Parametric

Ž . w xTechnology Corp. PTC 10 and Fig. 7 shows thecorresponding STEP file. The AP202 file has beensent to PTC for testing of AP202 support for thelatest release of PROrEngineer. It can be seen thatthe symbol ‘‘f’’, which is used as a diameter sym-bol in draughting terminologies and the ‘‘8’’ symbolappearing after the angular dimensions are not visi-ble in Fig. 7. This is because the symbols are special

Žcharacters supported by IGES not supported in STEP

.directly and which are to be interpreted by theprocessor during display of the drawing. This can bedone with the help of STEP pre_defined_symbolentity and by converting the IGES symbols into oneof these types. These STEP symbols have to be theninterpreted by the visualizer at run time and theappropriate symbol should be displayed. The sym-bols would depend on the type of fonts supported bythe users machines. However, since the display ofsymbols is system dependent it has not been incorpo-rated into the visualizer. It must be noted that theselimitations are only for the viewer, while the STEPtranslation is complete.

6. Conclusion and further work

In the agile and virtual manufacturing environ-ment, the STEP international standard for product

( )M.P. Bhandarkar et al.rComputers in Industry 41 2000 261–277276

data exchange is becoming increasingly popular overthe legacy format such as IGES. IGES has beenfound to be restrictive because it does not capturedata about the product through its life-cycle. It isexpected that in the long run STEP would com-pletely replace IGES. The issue of migration fromIGES to STEP is being addressed through a migra-tion strategy being developed by IGESrPDES Orga-nization. We hope that the current work contributesconsiderably to these efforts. It is expected that thiswork will gain more importance once CAD vendorsdevelop AP202 support to their software productswhich is imminent now that AP202 has become aninternational standard.

In this effort we have focussed on the translationof IGES drawing information into the STEP AP202

Ž .drafting standard. The approach consists of: i ob-ject-oriented modeling of IGES specification using

Ž .the EXPRESS language, and ii one-to-one entitymapping from IGES entities to the correspondingSTEP entities. The implementation is done usingCqq, object-oriented techniques and use of anobject-oriented database called ROSE for the storingand retrieval of objects. The implementation alsoinvolves development of a visualizer to check andvalidate the generated STEP drafting information.The visualizer is implemented on a Silicon Graphicplatform using the Open Inventor 3D graphic lan-guage.

In addition to the geometry, STEP also includessolid and feature information. We are currentlyworking on a STEP-based feature extraction system.The idea is to analyze the STEP B-Rep data andextract out manufacturing features from the same.The form feature would be stored in the STEPformat using AP224 ‘‘Mechanical product definitionfor process planning using form features’’. The fea-ture information can be used to develop processplans which can be directly interfaced with numeri-cally controlled machines.

Acknowledgements

Work on the project was done partially at STEPTools, Rensselaer Technology Park, Troy, NY andpartially at the State University of New York atBuffalo. We would like to thank all personnel at

STEP Tools for all their help to complete this pro-ject. Rakesh Nagi acknowledges the support of theNational Science Foundation career grant DMI-9624309.

References

w x1 Autodesk - AutoCAD, IGES Translator Release 13, UniformŽ .resource locator URL , http:rrwww.autodesk.comrprod-

uctsrmechrigestranrigestran.htm.w x2 D. Basu, S. Kumar, Importing MESH Entities through

Ž .IGESrPDES, Advances in Engineering Software 23 3Ž .1995 151–161.

w x3 M. Bhandarkar, Satisfying Data Needs In Agile Manufactur-ing Through Translation And Feature Extraction Into STEPProduct Data Models, Department of Industrial Engineering,State University of New York at Buffalo, 1997.

w x4 CATIArCADAM Solutions, URL, http:rrwww.catia.ibm.comrhtmlrcatmain.html.

w x5 DT_NURBS Generalized Spline Geometry Library, URL,http:rrdtnet33-199.dt.navy.milr.

w x6 M. Hardwick, RPI DICE team, ROSE 3.0 User Manual,Rensselaer Design Research Center, Rensselaer PolytechnicInstitute, Troy, NY, 1991.

w x7 IGES 5.2 Examples and figures, URL, http:rrmegavolt.eeel.nist.govrigesrspecfiguresrindex.html.

w x8 IGES EXPRESS model, URL, http:rrprema.eng.buffalo.edur ;mpb3rIGES.exp.

w x Ž .9 Initial Graphics Exchange Specification IGES Version 5.3,US Product Data Association, 1994.

w x10 Parametric Technology Corp., URL, http:rrwww.ptc.comand http:rrwww.ptc.comrproductsrexchangerindex.htm.

w x11 Part 202, Associative Draughting, US Product Data Associa-tion, 1996.

w x12 EXPRESS model for AP202, URL, http:rrwww.nist.govrsc4rsteprpartsrpart202risr.

w x13 D.A. Schenck, P. Wilson, Information Modeling the EX-PRESS Way, Oxford University Press, USA, 1994.

w x14 S.C. Liu, M. Gonzales, J.G. Chen, Development of automaticpart feature extraction and classification system taking CAD

Ž .data as input, Computers in Industry 29 1996 137–150.w x15 Silicon Graphics, Application Directory: IGES to Inventor,

URL, http:rrwww.sgi.comrProductsrappsdirectory.dirrApplicationsrData_AnalysisrApplicationNumber5794.html.

w x16 M.E. Ssemakula, A. Satsangi, Application of PDES toCADrCAPP integration, Computer in Industrial Engineering

Ž . Ž .18 4 1990 435–444.w x17 STEP on a page, URL, http:rrwww.nist.govrstepr

soaprsoapgraf.htm.w x18 STEP Tools Inc., URL, http:rrwww.steptools.com.w x19 J. Wernecke, The Inventor Mentor: programming Object-ori-

ented 3D graphics with Open Inventor, release 2, USA, 1994.w x20 The WiZ WORX homepage, URL, http:rrwww.wiz-worx.

comrwizworx.htm.

( )M.P. Bhandarkar et al.rComputers in Industry 41 2000 261–277 277

Mangesh P. Bhandarkar is a softwareengineer with Inso, PDM Division. Herepresents Inso at the Object Manage-ment Group and is a co-author of thePDM-Enabler specification. He is cur-rently a member of the finalization taskforce for the specification. He has anMS in Industrial Engineering from

Ž .SUNY Buffalo 1997 and BS in Pro-duction Engineering from University of

Ž .Bombay, India 1995 .

Rakesh Nagi is an Associate Professorof Industrial Engineering at the StateUniversity of New York, Buffalo. Hisrecent research interests are in AgileEnterprises, Information-Based Manu-facturing, and Logistics and SupplyChain Management. He was awardedthe National Science Foundation’s fac-ulty early career award in 1996, SME’sMilton C. Shaw Outstanding YoungManufacturing Engineer Award of 1999and IIE’s Outstanding Young IndustrialEngineer in Education Award of 1999.

Blair R. Downie is a research scientistin the Center for Advanced Technologyin Automation, Robotics, and Manufac-turing located on the campus of Rensse-

Ž .laer Polytechnic Institute RPI in Troy,New York. He also serves as a consul-tant for STEP Tools, an industry leaderin the development of software tools forthe emerging ISO STEP standard. Hereceived his master’s degree in Com-puter Science from RPI in 1987.

Martin Hardwick is a professor ofcomputer science at RPI and the directorof laboratory for Industrial InformationInfrastructure. He is also the presidentof STEP Tools. Due to his intimateunderstanding of the ISO STEP standardhe is a member of the board of PDESand the US Product Data Association.He has a PhD in mathematics and com-puter science from Bristol University,UK.