COMPUTER-AIDED DESIGN & APPLICATIONS, 2017VOL. 14, NO. 4, 408–421http://dx.doi.org/10.1080/16864360.2016.1257184

Associative CAD references in the neutral parametric canonical form

Daniel R. Staves , John L. Salmon and Walter E. Red

Brigham Young University, USA

ABSTRACTDue to the multiplicity of computer-aided engineering applications used in industry, interoperabil-ity between programs has become increasingly important. A 1999 study by the National Institute forStandards and Technology (NIST) estimated that inadequate interoperability between the originalengineeringmanufacturers (OEM) and their suppliers cost theUS automotive industry over $1 billionper year,with themajority spent fixingdata after translations. TheNeutral Parametric Canonical Form(NPCF) prototype standarddevelopedby theBYUSite of theNSFCenter for e-Designoffers a solutionto this problem by enabling real-time collaboration between heterogeneous systems while preserv-ing design intent. The NPCF is implemented within a SQL database and defines the schema both forneutral features and for the parameters defining the inter-feature relationships and associations.

KEYWORDSInteroperability;heterogeneous CAD; designintent; collaboration

1. Introduction

Iterative engineering processes have long been integral toengineering design. Before computer technology assistedthe design process, designers and engineers gatheredaround the drafting table to coordinate their work onproducts. Detailed drafting standards (ISO 128, DIN 6,ASME Y14.5) were employed to ensure accurate inter-pretation of drawingswhen transferred to other designersand manufacturers. Even with these standards, however,close personal contact between the designer and man-ufacturer was usually necessary [11]. With advances inCAD and communications via the Internet, computersare now a recognized necessity in the design process.While email has allowed designers and manufacturersto be geographically separated, mutual and interactivecommunication of design information is no less vitalnow than in the past [24]. Part models and drawingsmust be frequently exchanged, translated, and checkedbetween designers andmanufacturers at each iteration ofthe design. These designers and manufacturing person-nel often use different applications that require transla-tion or rework to make the models consistent betweensystems.

While many methods of the design process haveremained the same during the transition from the draft-ing tables of the past to themodern computer aided engi-neering processes of today, the tools of engineering havechanged dramatically. A wide variety of computer-aidedtools are available that specialize in the many different

CONTACT Daniel R. Staves danstaves@byu.edu

aspects of design, like finite element analysis (FEA), com-putational fluid dynamics (CFD), and solid or surfacemodeling (CAD). Companies, engineers, and designerschoose these tools based on their strengths, ease of use,and familiarity.

Translation processes and standards have been devel-oped for designers and engineers to work with the mul-tiplicity of file types and mathematical definitions offeatures in order to carry out their work. The transla-tion process, however, often strips the original modelof its design intent, or intelligence embedded into themodel. In addition, the process can introduce tolerancevariations, which impedes proper manufacturing. Trans-lating also slows the design process and hindersmeaning-ful collaboration between designers working in separatesystems.

1.1. The cost of poor interoperability

Due to a shift in production practices in the 1980s, USautomakers increased their market share and becamemore competitive in the US automotive market [2]. Alarge part of this increase in production is due to amove toward concurrent engineering and design out-sourcing. This shift resulted in the sharing of designdata between a greater number of people and organiza-tions bothwithin the company and between the companyand its suppliers. While overall productivity increased,the move highlighted many difficulties related to the use

© 2016 CAD Solutions, LLC, http://www.cadanda.com

COMPUTER-AIDED DESIGN & APPLICATIONS 409

of heterogeneous CAD packages. Estimates found thatimperfect interoperability, or model transfer betweenCAD packages, during this time cost between $1.02 bil-lion and $1.05 billion within the US automotive supplychain alone [2]. The vast majority of this cost is due tothe time spent fixing data from poor CAD model trans-lations between both theOEMs and their suppliers. Inter-actions with Industry Advisory Board (IAB) membersof the National Science Foundation (NSF) Center for e-Design have revealed a similar trend in the US aerospaceindustry.

Difficulties in the translation process arise becauseof differences in the way each CAD system representsthe part model. Because there is no standard, modernCAD packages store feature and design data in propri-etary formats, even though each system represents thesame type of data: three-dimensional geometric mod-els. These systems often only support interoperability bytranslating geometric Boundary REPresentation (BREP)data through formats such as IGES and STEP.While thesetranslation methods have been extensively and success-fully used in industry, the variances in the translationprocess between applications can cause geometric errorsamong transferredmodels [5]. In addition, by only trans-lating BREP data, crucial design intent stored withinfeature data is lost, which greatly hinders meaningfulcollaboration. Any modifications or adjustments to themodelmust either bemade on the originating system andre-translated or completely redesigned in the new system.In addition to these limitations, this method inherentlyfollows a serial, single-user work-flow, only allowing oneuser at a time to design or update the model. Before adesign can be shared, it must be exported in a neutral for-mat and sent to the end-user. This significantly impedesthe advantages of concurrent engineering.

The interoperability challenge is illustrated by the sim-plified product development process depicted in Figure 1.Black arrows in the figure represent the flow of the designand related data as it is passed between designers andgroups. Before the design data is passed to another group,

it is often converted to a neutral format, such as IGESor STEP, as illustrated by the convert data stage. Afterimporting into the new system, the model must undergoa fidelity check to ensure an accurate import. If themodelis to be used for CAE analysis, it may need to be updatedto fix geometric continuity problems associated with theneutral format. The red arrows represent the feedbackloops through which the design must pass if any of thesetests are failed. As the number of designers using CADsystems increases, the time spent resolving these conflictsin the feedback loops increases, which can significantlydelay the product launch and increase costs.

Design intent captures the purpose of the modelingorder and geometry chosen by the designer. In modernparametric-based CAD, this is often stored within CADfeatures such as axis systems, planes, sketches, extrudes,revolves, and sweeps. It is also stored in the associa-tions relating the CAD features together. By selectingfeatures during the modeling process, an experienceddesigner implicitly defines the important parameters ofthe model, which is extremely important to manufactur-ing and future updates to the design. Because these par-allel design processes are often utilized to facilitate col-laboration between geographically dispersed designers,these implicit definitions set by the designer are especiallyimportant to preserve. When a CAD model is translatedinto neutral formats such as IGES and STEP, this designintent is lost as all features are replaced by geometricrepresentations. Engineers, designers, andmanufacturersare unable to identify the important parameters set by theoriginal designer without post-processing.

1.2. Background

Due to the multiplicity of commercial CAD applications,companies often interface with a wide variety of CADfile formats through interactions with their supply chain.To open and use these formats, CAD applications musttranslate part models and assembly files between hetero-geneous CAD systems. Translation inconsistencies arise

Figure 1. Simplified Serial Product Development Process.

410 D. R. STAVES ET AL.

because differentCADsystems generate different featuresor may represent similar features differently. With nostandard definition representing CAD features, each sys-temmaydefine a feature differently.Due to these differentdefinitions, translating between programs is nontrivial.

The InternationalGraphics Exchange Standard (IGES)format was first developed in 1980 to facilitate the trans-lation between heterogeneous CAD systems [1]. IGESwas the first attempt at resolving the data exchange chal-lenge between CAD systems. It works by translating theCAD model of each system to its basic geometric dataand is the most widely used neutral format today. WhileIGES has been very successful in allowing models devel-oped in different systems to be exchanged, it falls shortin that only BREP data is translated. All associative linksbetween features are broken, and design intent is lost.

Created in 1984, the Standard for the Exchange ofProductModel Data (STEP) is a redesign of IGES, aimingat a more advanced, database-oriented, and integratedsolution based on product lifestyle data [19]. It fixessome shortcomings of IGES, including standardizing theprocessors, and uses a formal language to define thedata structure to avoid ambiguities during interpretation,which could result in as much as 50% failure rates [6].Work has continued on the STEP standard, most recentlyby the SolidModel ConstructionHistory (SMCH) group,which is seeking to preserve design intent through thetranslation process by recording the history of the modelas it is created. SMCH adds an implicit, or history-based,representation of the model to the explicit BREP data.This effectively creates solids that maintain their originalrelationships with other solids after the translation pro-cess, preserving design intent and allowing them to beedited and manipulated accordingly [23]. A drawback ofSMCH is that the file size is large due to both the B-repand construction history data being stored,making it dif-ficult for collaborative, multi-user applications in whichdata is transmitted frequently between clients.

A number of successful solutions have investigatedpreserving design intent through model translation byutilizing the command history used to create the CADmodel. The Macro-Parametric approach proposed byChoi et al. [4] utilizes each CAD system’s built-in macrofunctionality, which automatically records each actionperformed by the user. The macro file is translatedinto a format readable by the new CAD system andexecuted, mirroring the original actions performed inthe new format. This approach was continued by Mun,et al. by determining a common set of modeling com-mands from six different CAD systems [21]. Continuedresearch into the Macro Parametric Approach [7,14,22]has further expanded the capabilities of the format andimproved the state of CAD interoperable methods. The

Neutral Modeling Commandmethod addresses the needfor a collaborative heterogeneous CAD solution throughthe use of each CAD system’s application programminginterface (API) [12–15]. Each client runs an add-on pro-gram that translates system modeling operations (SMO)into neutral modeling commands (NMC) in real timeand is synchronized between clients through a server.The modeling commands are then translated to theSMO of the designation CAD system and applied tothe model, effectively recreating the model’s operationhistory. The development of other collaborative CADsolutions [3,10,17–18,25] have also improved upon theprocesses of transferring geometricmodels betweenmul-tiple clients using heterogeneous CAD systems. Theseapproaches have made strides in the effort to preservedesign intent through the translation process. However,the design intent is transferred by mirroring the designhistory of the part between all clients. While this mir-rored history enables feature edits on remote clients, itis not stored in a way that preserves referential integrityto ensure validity of stored data.

1.3. The neutral parametric canonical form (NPCF)approach

The BYU Site of the NSF Center for e-Design has soughtto reduce the design cycle time by developing syn-chronous, multi-user collaborative design tools. Its mostrecent work to develop the NPCF seeks to solve the inter-operability problem by formulating neutral standards forrepresenting CAD features while maintaining associativ-ity between features. It utilizes a client-server architecturefor communication, and a SQL database for persistentstorage to enable multiple users to access the same CADmodel. This format enables simultaneous design amongheterogeneous CAD systems. Currently, this interoper-able design workflow supports real-time collaborationbetween Dassault Systemes CATIA, Siemens NX, andPTC Creo CAD systems.

Like previous approaches to solving the CAD interop-erability problem, the NPCF method seeks to preservedesign intent through the translation process. Designintent is preserved during the translation process bytranslating data required to re-create features to a neutralformat as opposed to translating the geometric results ofthe features themselves. This type of data enables design-ers to not only edit the geometry that is imported fromdifferent systems, but understand how the features relateto the rest of the model. This, for example, enables theentire part to update after a parameter change. Ratherthan using the modeling history to preserve this designintent, as in the case of the Macro-Parametric or NeutralModeling Command approach, the features themselves

COMPUTER-AIDED DESIGN & APPLICATIONS 411

are neutralized while retaining their original parameter-ization and associativity. The neutral features are storedin the database using design rules to ensure referentialintegrity of all associative links and data integrity of thefeature parameters. The neutral features are automati-cally forwarded to all clients subscribed to the part orassembly model to be incorporated into their local mod-els, enabling simultaneous collaboration between geo-graphically separated users running heterogeneous CADsystems.

This paper describes the process utilized to deter-mine a normalized, neutral format for CAD features andincorporate it into the NPCF SQL database.

2. NPCFmethods

The goal of the Neutral Parametric Canonical Form(NPCF) is to enable real-time, simultaneous translationof both model and design intent between heterogeneousCAD clients. This is made possible by a client-serverarchitecture in which CAD operations performed byclients running a CAD system are neutralized and sentto the server for distribution among other clients. Inaddition to this architecture, other methods facilitate thetransfer of design intent and feature associativity duringthe modeling process. They enable modern, commer-cially available CAD packages to work simultaneously ina heterogeneous environment.

The current state of the NPCF provides support fora limited subset of CAD features as the focus is cen-tered on transferring design intent while maintaining thedata integrity of the model. Continued development issupporting new features in the NPCF database.

2.1. Maintain referential data integrity

Traditional neutral formats like IGES and STEP store partinformation in a file, either as text-based or binary files.While convenient for sharing files via secure file trans-fer or email, they are unable to maintain the integrity ofthe data. Often, corrupt data is written by a CAD sys-tem rendering the neutral file unreadable. To prevent thistype of corruption within the NPCF, a SQL database isused in conjunctionwith unique identifiers to link featuredata together. Neutral features are represented by tablesarranged in a hierarchal format with common parame-ters shared by many features being placed in tables at thetop of the hierarchy, and parameters specific to featuresare placed in dedicated feature tables. This arrangementenables feature references and inter-feature references tobe stored. In this instance, referential integrity is main-tained because the references are only allowed betweencertain features. For example, an extrude feature can

reference a sketch as the profile to extrude where is itnot able to reference a coordinate system.When definingthe neutral extrude feature table on the NPCF database,associations are created linking the extrude table with thesketch table, enabling the correct feature associations.

In addition to the hierarchical arrangement of distinctfeatures represented on the database, sub-hierarchies rep-resenting feature variations are also incorporated into theNPCF. These feature variations include the multiple defi-nitions CAD systems use to define a feature. For example,a plane feature can be defined using a 3D point in spaceand a normal vector, or by an offset from another surface.Both of these parameter sets make up a different sub-feature table located on the database hierarchy directlybelow the plane feature table. General parameters used todescribe all planes are included in the generic plane tablewhile specific parameters used to define a plane variationare stored in the sub-feature tables.

An important step in preserving referential integrityis to utilize a sub-hierarchy within the NPCF databaseto handle feature variations rather than including all fea-ture parameters in a single table. Each parameter requiredto define a particular feature variation is marked in thedatabase as non-nullable, signifying that all fields mustbe filled with the proper data type if it is to be saved inthe database. By imposing this requirement, only datastructures that are completely filled out with all requiredinformation are stored in the database and transmitted toother clients.

Table 1 describes the process used to incorporate newfeatures into the neutral database. When a new feature isto be added, feature creation methods are identified andcompared between CAD systems to identify commonal-ities. For example, both a blind extrude in Creo and anextrude-by-values inNX expect a sketch feature onwhichthe operation is to be performed and numerical limits toidentify the start and end points of the extrude. Thoughthese feature variations are given different names andtreat the limits differently, both can be neutralized intothe same format without loss of data or semantic mean-ing. Contrasting this feature variation with an extrude-to-plane operation, both methods utilize the same sketchparameter, but accept different objects to define limits.

Table 1. Feature parameter distribution pro-cess utilized when adding new features todatabase.

NPCF Database Feature Addition Process

Identify feature variations on all systemsIdentify commonalities between systemsDetermine neutral format for all feature variationsSplit parameters between common tablesAdd associations representing inheritance relationshipsSave database changes

412 D. R. STAVES ET AL.

When splitting parameters between common tables, asdescribed in Table 1, a generic extrude table will be cre-ated that stores the referenced sketch parameter, and twofeature variation tables will be created to hold the param-eters required by the blind extrude and planar extrude,respectively.

2.2. Defining a neutral format

The principle of neutralization versus translation is animportant distinction between the way theNPCF enablesinteroperability between heterogeneous CAD systemsand methods employed by previous CAD interoperabil-ity formats. The neutralization method converts CADdata from an originating system to a neutral format aftera CAD process is performed. The neutral format com-pletely defines the feature by its parameters and is storedwithin a database. It is then converted to the CAD for-mat of the destination system and incorporated into thelocal part model for interaction by the other user. Thecollection of neutral features associated with a single partremain on the database as the master copy of the modelfromwhich all systems load data. This single neutral copyensures model consistency between clients and sessions.

A major advantage of this method is its support formulti-user processes. All data is stored in an open for-mat easily accessible and readable by any interested partywith the proper access credentials. When support fornew CAD systems is to be integrated into the neutral-ization method, software is required only to convert theCAD specific data to the neutral format (and from theneutral format to the CAD specific format) without anyneed for consideration of the other supported CAD sys-tems. Access to only one CAD system’s API is requiredto perform these conversions, eliminating the need for acompany to hold costly CAD licenses for every formattheir suppliers may use.

To understand the data requirements for representinga feature in a neutral format, creation and edit actionswere recorded using each CAD system’s built-in script-ing or journaling functionality. This is the process usedby Li et al. to determine the neutral modeling com-mands format [16]. Most major CAD systems supportthis functionality, but a good understanding of the CADsystem’s API can allow a developer to program withoutthe recorded script.

The inputs to the scripted feature are comparedbetween systems to identify commonalities and shed lighton the data required to define a neutral format for thefeature. The format was chosen by identifying the mini-mum ideal set of parameters that fully defines the feature.During the translation process, these parameters maybe converted to equivalent representations based on the

requirements of the individual CAD system’s API. Forexample, a 2D point used in sketching in CATIA andCreo is defined by a sketching plane and an X and Y coor-dinate. On NX, however, the point used in sketching isdefined using X, Y, and Z parameters to specify location.Though both formats are mathematically equivalent, forease in conversion, the neutral format was defined usingthe X and Y coordinates and a sketching plane. This sameprocess was used to determine the neutral parameters forall supported CAD features within the NPCF.

2.3. Object relational manager

To facilitate reading from and writing to the database,an Object Relational Manager (ORM) is used to convertdata between programming objects and the database. It ismost often used as a familiar method in which softwaredevelopers can interact with a SQL database. The ORMgenerates programming class code based on the databaseschema. Because the database contains the parametersused to define a neutralized CAD feature, the ORM effec-tively defines the neutral data structure in which CADfeature parameters are stored and passed between clients.When the proper methods are called, the ORM saves theparameters stored in the neutral data structure to theircorresponding tables and columns in the database. Thesedata structures defined by the ORMmake up the founda-tion of the messages sent between the clients and server.

Because the ORM data structure is based on thedatabase schema, it automatically captures all param-eters and associations defined in the database tables.Since many of the associations in the database are usedto define the hierarchical nature of CAD features andobjects, these associations are modified within the ORMto represent inheritance relationships for the neutral datastructure. Inheritance is a principle often employed inobject-oriented programing to define instances whereone object derives methods and properties from anotherobject. In the API of a typical CAD system, CAD fea-ture objects derive certain methods and properties froma base feature class. In our dispersed representation ofCAD features in the database, where feature parame-ters for a single feature may be distributed throughoutmultiple tables, a feature variation inherits from a baseclass of that feature. By modifying the associations ofthe database tables imported by the ORM to representinheritance, single programming objects are created thatcontain all the parameters of the features from which it isderived.

The ORM, as shown in Figure 2, converts the fea-tures and feature variations distributed through the var-ious database tables into single CAD objects that con-tain all the parameters required to define each feature

COMPUTER-AIDED DESIGN & APPLICATIONS 413

Figure 2. The ORM converts database tables and schema into programming data structures.

or feature variation in a neutral format. The databasetables for sketch feature and plane feature variations arecombined into their own data structures. These struc-tures retain their relationships with the correspondingdatabase parameters fromwhich they are derived and areused for accessing and writing data within the database.The hierarchy established within the database betweentables is also retained in the data structures created by theORM as object inheritance.

Apart from combining feature parameters into a sin-gle feature object, inheritance is used to define data types.Since each feature variation is represented in the databaseas a separate table and modified by the ORM to be repre-sented as separate objects inheriting properties from thebase feature class, each feature variation object is of thesame type as the base feature object. This is an importantprinciple that enables feature references. A 2D sketch fea-ture in CAD, for example, references a plane feature todefine location. A plane feature has multiple feature vari-ations from which it can be defined. Using the methoddescribe above, the ORMwill generate feature objects for

each feature variation. However, since each plane featurevariation inherits the base plane feature, the parameterused to reference a plane feature in the sketch featureobject needs to be only of type plane object, and anyvariation of the plane object can be stored. This methodboth simplifies development and helps to preserve dataintegrity because only one reference parameter is neededto reference multiple feature definitions.

2.4. Interface inheritance

While the ORM alone enables multiple feature defini-tions to be referenced, many CAD features can referencecompletely different types of objects in a single param-eter. This is best illustrated by the example in Figure 3.A revolve feature revolves a 2D sketch around an axis togenerate 3D geometry. The axis of the revolve could bean axis feature defined by a 3D point and vector, or itcould be a line object in a 2D sketch. These two objectsin no way share an inheritance structure but must beable to be referenced in a single parameter to maintain

414 D. R. STAVES ET AL.

Figure 3. A revolve feature can revolve a 2D sketch around (a) an axis of a coordinate system or (b) a line of a sketch.

data integrity. Further modifications to the ORM arenecessary to support this functionality.

To maintain data integrity, the code generated by theORM is modified to implement an interface system.Interfaces are a commonly used paradigm in object-oriented programming to declare functional similaritiesbetween different object types. In essence, it allows unre-lated objects in code to interact with other objects inthe same way. In the case of the revolve feature example,both the axis feature and the 2D line object implementan interface which denote that both objects can be usedas a reference for an axis. In this case, the revolve featureaxis parameter does not require a specific feature type,but instead requires an object that implements an axisinterface. This is done by modifying the part of the ORMthat automatically generates the neutral data structure toinclude the interface code.

Database tables and data structures that reference aninterface rather than a feature need to bemodified aswell.Because each association in the database requires a singletable to represent the association, any feature table using aparameter to reference an interface must create the asso-ciation with the most basic database table from which allfeature tables associate. The parameter used for the ref-erence is given a reserved name that represents the typeof interface used. For the case of an axis reference, thereserved name is ReferencedAxis while other reservednames can be seen in Table 2. The ORM is modified toidentify these reserved names and replace all associatedreferences to the basic CADobject data structurewith theinterface type corresponding to the reserved name.

While creating a database association with the mostbasic database table lowers the data integrity of thedatabase by allowing any feature (including invalid fea-tures) to be referenced; invalid data is prevented frombeing added to the database by the modified ORM datastructures themselves. The data structures allow only

Table 2. Reserved names for database columns used to defineparameters that reference interfaces.

Reserved Name Function

ReferencedAxis Declare an object can be used as an AxisReferencedPlane Declare an object can be used as a PlaneReferencedDirection Declare an object can be used as a DirectionReferencedPoint Declare an object can be used as a PointReferencedProfile Declare an object can be used as a Profile

features that implement the correct interface to be ref-erenced. All read/write operations to the database areabstracted as far away from the user as possible to reducethe risk of data corruption. The ORM is as close as pos-sible to the database that it ensures future developers arenot able to make any errors and corrupt the data.

2.5. Client plug-in software

To simultaneously support multiple CAD packageswithin the heterogeneous environment, a client programis integrated as a plug-in application into each supportedsystem. This plug-in software is responsible for identi-fying when new operations are performed, convertinginformation about the operation into the correspond-ing neutral format. The plug-in software then pack-ages the neutral operation data into the ORM-generateddata structures, which ultimately fill the correct databasetables. The client then sends the data to the server to bedistributed to the other clients and to the database.

To facilitate the wide variety of APIs associated withthe CAD programs, the client-side architecture of theplug-in software is divided into two parts, as seen inFigure 4. The multi-user object (MUObject) classes areresponsible for handling communications with the serverand for neutralizing CAD data. These MUObject classesare all written in the C# programming language and con-tain the code that is generated by the ORM to read from

COMPUTER-AIDED DESIGN & APPLICATIONS 415

Figure 4. Client plug-in between a CAD application and the MUObject class.

and write to the database. When a CAD operation isperformed, the MUObject classes convert the operationdata to a neutral format and fill the ORM-generated datastructures. Amessage is then sent to the server containingthe neutral data along with information pertaining to theoriginating user, the part model that the message is asso-ciated with, and a time stamp to be used with orderingoperations. The MUObject classes also receive and de-serialize messages from the server. Since all clients per-form these same basic functions, the MUObject classescan be identical for all CAD packages.

The second part of the client interacts directly withthe CAD system’s API and is written in the languagebest supported by the system. For NX and CATIA, theclient plug-in is written in the C# programming lan-guage for simplicity of interacting with the MUObjectclasses. This is possible for these systems because theirrespective CAD APIs fully support the .NET framework.The client plug-in for Creo, however, is written in theC++ programming language because its .NET API lacksimportant functionality required to support interoper-able CAD. The C++ API, however, is complete, fullyfunctional, and able to support the CAD functionalityrequired for interoperability.

The plug-in section of the client utilizes event meth-ods within each CAD system to determine when featuredata needs to be synchronized between clients, such asin a feature creation, edit, or delete event. The plug-inthen collects information about the updated feature andformats the parameters in a way readable by the MUOb-ject class. When data is received from the server, whetherfrom remote clients or the database, the plug-in calls thepropermethodswithin theAPI of theCAD system to cre-ate, edit, or delete a feature, or perform a part model orassembly-level command.

By separating the client software package into twoparts, developers working on integrating newCADpack-ages into the interoperable software are, in essence, fur-ther abstracted away from the communication aspects ofthemulti-user program. Instead, developers are only con-cerned about translating between the CAD specific dataand the neutral format defined in the MUObject class.This work flow has significantly accelerated developmenttime as new features are supported in an incrementalprocess between CAD systems.

3. Implementation and verification

The Neutral Parametric Canonical Form (NPCF) is aset of prototype standards for representing CAD fea-tures and other CAD data in a neutral format that sup-portsmulti-user, simultaneousCAD.TheNPCFhas beenimplemented and tested using CAD Interop, a client-server application utilizing plug-in software to interfacewith commercial CAD systems. CAD Interop was devel-oped by the BYU Site of the NSF Center for e-Design tounderstand the requirements necessary to supportmulti-userCADprocesses between several heterogeneousCADsystems. The objective of this research is to extend theNPCF format and the CAD Interop prototype to sup-port associativity and enforce referential integrity dur-ing the modeling process in an effort to preserve designintent.

To support this research, 22 database tables were cre-ated, with associations between tables representing objectinheritance. These tables supported the initial 13 featureswhich were chosen by surveying a list of most used CADoperations utilized by a BYU senior design project. Thesefeatures include coordinate system, datum plane, datumaxis, 3Dpoint, 3D spline, 2D sketch, extrude, and revolve.

416 D. R. STAVES ET AL.

Supported 2D sketch features include 2D point, 2D line,2D arc, 2D circle, and 2D spline. Additional tables usedto enable assembly operations were also created.

3.1. Unique identifiers

The NPCF defines a set of parameters and relationshipsthat express CAD features in a neutral format. To testtheir viability, the NPCF was implemented in MicrosoftSQL Server with a database table for each feature vari-ation, and a database column within the tables for eachfeature parameter. In this implementation, each tablecontains a Globally Unique Identifier (GUID) parameterused to uniquely identify neutral CAD features stored inthe database. It is generated using theMicrosoftWindowsAPI to guarantee uniqueness between all clients with ahigh degree of certainty. Figure 5 describes the process ofcreating and propagating GUIDs through the NPCF pro-cess. After a new feature is created in the CAD system,a GUID is generated by the plug-in software and storedwith both the neutral data in the MUObject class andwith the CAD feature in the CAD system. The GUID isused to identify features on all clients, update feature datain the database when edits are performed in the CAD sys-tem, and link feature data dispersed between tables in theSQL database.

Because the GUID is unique between all clients, itcan be used to allow a single feature to be partially rep-resented by multiple database tables in a hierarchicalformat, similar to the way CAD features would be rep-resented in a CAD system’s API. For example, data fora coordinate system plane feature is stored in four sepa-rate tables as seen in Figure 6. Figure 6(a) shows both thedatabase schema that describes how the database tablesrelate to each other as well as a representation of thedata stored within each table. As seen in Figure 6(b), aGUID and time-stamp for the feature are stored in theInteropObject table. The same GUID, feature name, treeorder, and feature type are stored in a feature table. TheGUID and plane type are stored in the DatumPlane tableand the GUID, associated coordinate system, and plane

type are stored in the DBCsysPlane table. Each table islinked together using a primary-key/foreign-key refer-ence that automatically matches the correct data whenquerying the database for a feature.

Figure 6. (a) Neutral data for a single feature is partially repre-sented by multiple tables. (b) GUIDs are used to link the partialdata in each table together to completely define a neutral feature.

Figure 5. The order of operations after a new feature is created in the CAD Interop Multi-user prototype.

COMPUTER-AIDED DESIGN & APPLICATIONS 417

3.2. Software implementation

To support interoperable CAD on the local client, a soft-ware plug-in package was written for each supportedCAD system. As the primary purposes of the plug-inclient software are to detect CAD operations performedby the user and to perform remote CAD operationslocally, each software is written to utilize the native APIof the CAD system – NXOpen for NX, Pro\Toolkit forCreo, and Automation for CATIA.

The API’s of both NX and Creo expose events per-formed by the user. Callback functions can be registeredso that when a feature is created, for example, parametersrelating to the new feature can be stored and convertedto the neutral format. CATIA’s automationAPI, however,exposes no events. To identify when new features are cre-ated, the plug-in iterates through each feature within thepart’s feature tree. In all cases, when a new feature is iden-tified, either via an event or through iteration, a GUID iscreated using the Windows API and stored as a param-eter in the feature. The plug-in software then convertsthe CAD-specific feature parameters to the CAD-neutralparameters defined by the NPCF.

The 2nd part of the plug-in software is the same foreach client, and handles the transmission of neutral datato and from the server. To accomplish this, Microsoft’sentity framework is utilized as an ORM to read and writethe neutral data to the database. When an operation isperformed remotely, the neutral data is sent from theserver in the ORM object and converted by the CAD-specific part of the plug-in to a CAD feature. The CADfeature is then incorporated into the CAD model usingmethods outlines in each system’s API.

3.3. Feature capabilities and limitations

Each feature supported by the NPCF can be created,edited, and deleted in NX, CATIA, and Creo duringthe modeling process. During the implementation pro-cess, each feature is tested individually and all featuresare tested collectively during regular team-modelingsessions. During these sessions, errors that arise arerecorded and investigated to determine the cause. Mostare due to bugs and architecture limitations and can becategorized into three underlying causes:

(1) Some bugs are caused by programmer error. Whenimplementing a new feature into three differentCAD systems, crucial information is sometimesomitted causing a feature to be created incorrectly ornot at all. The majority of these bugs are located inthe plug-in portion of the client code when extract-ing or setting CAD feature information. These types

of bugs are given the highest priority during themodeling sessions and are fixed immediately.

(2) Some bugs arise because of limitations or errorswithin the CAD system’s API. An example of thisbug type occurred when implementing the revolvefeature into PTC Creo. In the plug-in implemen-tation for Creo, the integrity of local feature oper-ations is preserved by ensuring remote operationsdo not conflict. This is done by subscribing to but-ton events. During a team-modeling session, unex-pected behavior was observed around the revolvefeature and was traced to an API bug dealing withthe revolve button event. The issue was reported toPTC June 17, 2015 and is currently under investiga-tion. Workarounds are developed for these bugs toaddress the lost functionality. In the example above,a new button was placed in Creo’s user interfacethat must be pressed by the user after performing arevolve operation, simulating the functionality thatwas lost from the API bug.

(3) Sometimes a single feature can pass all tests, butwhen used during a team-modeling session, it cancause the program to crash. Often this is becauseof the lack of an overall consistency manager toensure multiple operations are not performed onthe same feature. To limit the effect of this architec-ture limitation, methods were implemented in eachclient plug-in to queue remote operations when alocal operation is performed. This fix has greatlyreduced the amount of reported bugs during team-modeling sessions. This solution, however, does notprevent potential conflicts that may arise when mul-tiple users are editing the same feature or feature tree.In its current implementation, CAD Interop avoidsthese conflicts because the only features supporteddo not remove geometry. An edge blend feature, forexample, removes an edge during its operation. Ifanother user were to, at the same time, create a fea-ture that uses that edge, a conflict would arise. Aserver-level consistency manager should be imple-mented to make the software more robust and han-dle this type of conflict, though the existing solutionis effective. In addition, a feature-locking conflictavoidance system as implemented in homogeneousmulti-user CAD applications [8,9,20] would solvemany of these problems.

This process for identifying, prioritizing, and fixingerrors that arise has been effective in rapidly improv-ing the state of the software. As development continueson the NPCF, this categorization process will continueto classify these types of errors to maintain this level ofprogress.

418 D. R. STAVES ET AL.

3.4. NPCF verification

As a result of this research, associations between fea-tures and methods for preserving design intent havebeen incorporated into the multi-user interoperabilityprogram utilizing the NPCF prototype standard. Neu-tral definitions for coordinate systems and datum planes,as well as extended definitions for extrude and revolvefeatures, have been defined and included in the hetero-geneous system. Additionally, support for PTC Creo hasbeen added to enable multi-user synchronous model-ing between NX, CATIA, and Creo CAD systems. Thecapabilities of the software andNPCF prototype standardare demonstrated by modeling two separate assemblies.The assembly models were selected to utilize the featuresand test the methods developed and implemented as aresult of this research. Both assemblies were modeled bymultiple users simultaneously. All users were co-locatedand allowed to collaborate prior to beginning modeling.While users in these sessions were co-located, the sameprocess could occur between geographically separatedusers by using a video-conferencing service.

The multi-user assembly modeled during this veri-fication process was designed to showcase the associa-tivity methods developed within the Neutral ParametricCanonical Form. Three clients using NX, CATIA, and

Creo were given instructions prior to modeling, whichincluded the basic dimensions of each component ofthe assembly and the order of operations employed by asingle user to model the part. During modeling, clientssimultaneously modeled within the same parts, collec-tively working to complete the design before moving tothe next component. The absence of any conflict res-olution implementations in this architecture, however,necessitated that clients communicate to avoid interfer-ing with other’s operations. This method was illustratedearly in the modeling session as displayed in Figure 7.After the initial cylinder was extruded to define locationand size, each client simultaneously modeled geometrybased off the initial feature, although in relative isolation.

Figure 8 shows the finished pump bearing hous-ing part model on all three CAD clients. Collaborationbetween clients enabled each user to work on portionsof the model to collectively complete the model. A pro-cess similar to the one employed in this session not onlyenables users to work with the CAD system inwhich theyare most comfortable, but also enable users with differ-ent specialties to access and contribute to the part modelduring the design stage.

To test the software’s ability to exactly replicate mod-els between CAD systems, the finished part model from

Figure 7. Early in the modeling session, the NX client (top left), Creo client (top right), and CATIA client (bottom middle) created newfeatures referencing other’s modeling operations.

COMPUTER-AIDED DESIGN & APPLICATIONS 419

Figure 8. Completed assembly modeled simultaneously by an NX client (top left), a Creo client (top right), and a CATIA client (bottommiddle).

Table 3. Model parameter comparison of exported stere-olithography files.

Parameter NX CATIA Creo

X-Dimension 100.000 mm 100.000 mm 99.990 mmY-Dimension 82.500 mm 82.478 mm 82.495 mmZ-Dimension 60.000 mm 60.000 mm 60.000 mmVolume 114612.7 mm3 114721.5 mm3 114666.0 mm3

Surface Area 35687.9 mm2 35663.1 mm2 23665.4 mm2

each system was converted to a stereolithography (.stl)file used for rapid prototyping. When exporting to thisfile type, each CAD system represents the partmodel by atriangular tessellation covering all surfaces of the model.The STLfiles fromeach respectiveCADsystemwere thenimported into a third-party analysis tool to extract theimportant model parameters found in Table 3. Thoughthere are slight variations between the parameters, theseare extremelyminimal, with the largest percent differencecoming from the volume calculation, which is less than.095%. Even so, the differences in these parameters aremost likely due to variations in how each CAD systemcreates the tessellations.

In addition to testing the accuracy of recreatingmodels in multiple CAD systems, load tests were per-formed to determine the scalability of the NPCF archi-tecture. A guided model-rocket assembly, consisting of

Table 4. Guided Model Rocket ComponentsList.

Component Quantity

Motor Subframe 1Servo Motor 4Guidance System 1Nose Cone 1Lower Fin 3Upper Fin 4Motor 1Batter 1Nozzle 1Skin 1IMU 1

the 11 unique components in Table 4, was designedand modeled by six clients simultaneously within theheterogeneous environment. Modeling responsibilitieswere divided and strategy discussed between participantsprior to beginning modeling. Though some componentswere multiple instances of the same part (i.e., ServoMotors andFins), theywere all explicitlymodeled in theirproper position and orientation due to the lack of supportfor assembly constraints.

While each client modeled their respective compo-nents, geometry created by remote users were automati-cally integrated into the local assembly. As users alternatebetween creating sketches and constructing geometry,

420 D. R. STAVES ET AL.

Figure 9. Screenshot of rocket assembly as modeled by six clients simultaneously.

remote users’ work can be referenced and checked. Thiskind of awareness, similar to the collaboration aroundthe drafting table, fosters interaction between design-ers to help and check each other where needed. Agraphic of the six clients collaborating is included asFigure 9.

4. Conclusion

Inadequate CAD interoperability solutions continue toaffect the design process employed by engineers anddesigners. As concurrent engineering and design shar-ing practices continue to be implemented into the typicaldesign process, the shortcomings of the current heteroge-neous CAD environment will become increasingly evi-dent. With billions of dollars spent on fixing data aftera CAD part or assembly model is transferred, there isa great need to update the translation process to pre-serve the design intent stored within the original model.Design intent enables CAD parameters and geometry toupdate according to the constraints set by the originaldesign team. It is especially important in a multi-user

setting where designers could be dispersed geographi-cally thereby limiting face-to-face communication. TheNeutral Parametric Canonical Form seeks to addressthese concerns by creating a heterogeneous CAD envi-ronment supporting simultaneousmodeling. By utilizinga SQL database to store the neutral representations offeatures, part and assembly models can be created andsimultaneously edited bymultiple clients at once. In addi-tion, rules implemented on the database enforce referen-tial data integrity by declaring the parameters requiredto represent a feature and by enabling only valid inter-feature references. These architectural decisions improvethe translation of design intent between CAD systemsand preclude invalid data from corrupting neutral mod-els stored within the database.

While only a limited number of features are currentlysupported, they are sufficient to create interesting andcomplex part and assembly models. An initial limitedfeature set was specifically chosen to focus on the robust-ness of the solution. Current work is focused on increas-ing the number of supported features while maintainingstability.

COMPUTER-AIDED DESIGN & APPLICATIONS 421

ORCID

Daniel R. Staves http://orcid.org/0000-0003-3365-1160John L. Salmon http://orcid.org/0000-0002-8073-3655Walter E. Red http://orcid.org/0000-0002-9321-6913

References

[1] Basu, D.; Kumar, S. S.: Importing mesh entities throughIGES/PDES, Advances in Engineering Software, 23(3),1995, 151–161. http://dx.doi.org/10.1016/0965-9978(95)00075-5.

[2] Brunnermeier, S. B.; Martin, S. A.: Interoperability costsin the US automotive supply chain, Supply Chain Man-agement: An International Journal, 7(2), 2002, 71–82.http://dx.doi.org/10.1108/13598540210425821

[3] Cheng, Y.; He F.; Wu, Y.; Zhang, D.: Meta-operation Con-flict Resolution forHuman-Human Interaction inCollab-orative Feature-Based CAD Systems. Cluster Computing.19(1), 2016, 237–253

[4] Choi, G.-H.; Mun, D.; Han, S.: Exchange of CAD PartModels base on the Macro-Parametric Approach, Inter-national Journal of CAD/CAM, 2(1), 2002, 13–21

[5] Gu, H.; Chase, T. R.; Cheney, D. C.; Johnson, D.: Iden-tifying, correcting, and avoiding errors in computer-aided design models which affect interoperability, Jour-nal of Computing and Information Science in Engi-neering, 1(2), 2001, 156–166. http://dx.doi.org/10.1115/1.1384887.

[6] Haenish, J.: CAD-Exchange Towards a First Step Imple-mentation, Industrial Electronics Society, 16th AnnualConference of IEEE, 1990, 734–739. http://dx.doi.org/10.1109/IECON.1990.149231.

[7] Han, S.: Macro-parametric: an approach for the history-based parametrics, in Soonhung Han (guest editor), Spe-cial issue: The future of CAD interoperability: History-based parametrics, Int. J. Product Lifecycle Management(IJPLM), 4(4): 321–325 Dec. 2010.

[8] Hepworth, A. I.; Tew, K.; Nysetvold, T.; Bennett, M.;Jensen, G.: Automated Conflict Avoidance in Multi-userCAD, Computer-Aided Design and Applications, 11(2),2014, 141–152. http://dx.doi.org/10.1080/16864360.2014.846070.

[9] Hepworth, A.; Tew, K.; Trent, M.; Ricks, D.; Jensen,C.; Red, W. E.: Model consistency and conflict resolu-tion with data preservation in multi-user computer aideddesign, Journal of Computing and Information Sciencein Engineering, 14(2), 2014. http://dx.doi.org/10.1115/1.4026553.

[10] Jing S, He F, Han S, et al. A method for topological entitycorrespondence in a replicated collaborative CAD system.Computers in Industry, 60(7), 2009, 467–475.

[11] Leach, L. M.: Language interface for data exchangebetween heterogeneous CAD/CAM databases, Disserta-tionAbstracts International Part B: Science and Engineer-ing, 44(5), 1983

[12] Li, M.; Yang Y.; Li, J.; Gao, S.: A preliminary study on syn-chronized collaborative design based on heterogeneous

CAD systems, PhD thesis, Zhejiang University, 2003.http://dx.doi.org/10.1109/CACWD.2004.1349025.

[13] Li, M.; Gau, S.; Li, J.; Yang, Y.: An approach tosupporting Synchronized Collaborative Design withinHeterogeneous CAD Systems, ASME 2004 Interna-tional Design Engineering Technical Conferences, 2004,511–519. http://dx.doi.org/10.1115/DETC2004-57703.

[14] Li, J.; Han, S.; Shin, S.; Lee, S.; Kang, Y.; Cho, H.;Kim, H.; Song, I.; Kim, I.; Rathore, P. S.: CAD DataExchange Using the Macro-Parametrics Approach: AnError Report, International Journal of CAD/CAM, 10(2),2010.

[15] Li, M.; Gao, S.; Wang, C. C. L.: Real-Time Collabora-tive Design With Heterogeneous CAD Systems Based onNeutralModeling Commands, Journal of Computing andInformation Science in Engineering, 7(2), 2007, 12–15.http://dx.doi.org/10.1115/1.2720880.

[16] Li, W.; Ong, S.; Fuh, J.; Wong, Y.; Lu, Y.; Nee, A.: Feature-based Design in a distributed and colaborative environ-ment, Computer-Aided Design, 36(9), 2004, 775–797.http://dx.doi.org/10.1016/j.cad.2003.09.005.

[17] Li, X.; He, F.; Cai, X.; et al: A method for topologicalentity matching in the integration of heterogeneous CADsystems. Integrated Computer-Aided Engineering, 20(1),2013, 15–30.

[18] Li, X.; He, F.; Cai, X.; et al: CAD data exchange basedon the recovery of feature modelling procedure. Inter-national Journal of Computer Integrated Manufacturing,25(10), 2012, 874–887.

[19] Marjudi, S.; Amran M.; Abdullah, K. A.; Widyarto, S.;Majid, N.; Sulaiman, R.: A Review and Comparisonof IGES and STEP, Proceedings of World Academy ofScience, Engineering And Technology. 62, 2010, 1013–1017.

[20] Moncur, R.; Jensen, C.; Teng, C.; Red, E.: Data consistencyand conflict avoidance in a multi-user CAx environment,Computer-Aided Design and Applications, 10(5), 2013,727–744. http://dx.doi.org/10.3722/cadaps.2013.727-744.

[21] Mun, D.; Han, S.; Kim, J.; Oh, Y.: A set of stan-dard modeling commands for the history-based para-metric approach, Computer-Aided Design, 35(13), 2003,1171–1179. http://dx.doi.org/10.1016/S0010-4485(03)00022-8.

[22] Mun, D.; Han, S.: Identification of Topological Enti-ties and Naming Mapping for Parametric CAD ModelExchanges, International Journal of CAD/CAM, 5(1),69–82, Dec. 2005.

[23] Pratt, M.J.: Extension of the Standard ISO10303 (STEP)for the exchange of parametric and variational CADMod-els, Proceedings of the Tenth International IFIPWG, 5(3),1998

[24] Wisnosky, D. E.: ICAM Program Prospectus, DTIC Doc-ument, 1977

[25] Zhang, D. J.; He, F. Z.; Han, S. H.; et al: Quantita-tive optimization of interoperability during feature-baseddata exchange. Integrated Computer-Aided Engineering,23(1), 2016, 31–50.