CAD/CAM Data Exchange

UNIT 7 CAD/CAM DATA EXCHANGE

Structure
1.7.1 Introduction Formatted: Indent: Left: 0.39", Hanging: 0.39", Outline
Objectives numbered + Level: 2 + Numbering Style: 1, 2, 3, … +
Start at: 1 + Alignment: Left + Aligned at: 0.39" + Tab
2.7.2 Types of Interfaces after: 0.64" + Indent at: 0.64", Tab stops: Not at 0.64"
3.7.3 Description of Various Standard Interfaces Formatted: Outline numbered + Level: 2 + Numbering
1.7.3.1 Initial Graphic Exchange Specifications (IGES) Style: 1, 2, 3, … + Start at: 1 + Alignment: Left + Aligned
at: 0.39" + Tab after: 0.64" + Indent at: 0.64", Tab
2.7.3.2 Product Definition Data Interface (PDDI)
stops: Not at 0.64"
3.7.3.3 Product Data Exchange Specifications (PDES)
4.7.3.4 Standard for Exchange and Transfer (SET) Formatted: Indent: Left: 0.79", Hanging: 0.39", Outline
5.7.3.5 Verband der Automobileindustries Flachenschnittsteele (VDAFS) numbered + Level: 3 + Numbering Style: 1, 2, 3, … +
Start at: 1 + Alignment: Left + Aligned at: 0.79" + Tab
6.7.3.6 Cad *I Interface
after: 1.29" + Indent at: 1.29", Tab stops: Not at 1.29"
7.7.3.7 Standard for External Representation of Product Data (STEP)
+ 1.5"
4.7.4 The UPR Architecture Formatted: Outline numbered + Level: 2 + Numbering
1.7.4.1 A Star Architecture Style: 1, 2, 3, … + Start at: 1 + Alignment: Left + Aligned
2.7.4.2 Universal Support of Data Types at: 0.39" + Tab after: 0.64" + Indent at: 0.64", Tab
3.7.4.3 Data Unification stops: Not at 0.64"
4.7.4.4 Rewriters and Import Flow Formatted: Indent: Left: 0.79", Hanging: 0.39", Outline
5.7.4.5 Dynamic Import Verification numbered + Level: 3 + Numbering Style: 1, 2, 3, … +
Start at: 1 + Alignment: Left + Aligned at: 0.79" + Tab
5.7.5 Summary after: 1.29" + Indent at: 1.29", Tab stops: Not at 1.29"
6.7.6 Answers to SAQs + 1.5"
Formatted: Outline numbered + Level: 2 + Numbering
7.1 INTRODUCTION Style: 1, 2, 3, … + Start at: 1 + Alignment: Left + Aligned
at: 0.39" + Tab after: 0.64" + Indent at: 0.64", Tab
Since the introduction of the computer as an automation tool for planning and control of stops: Not at 0.64"
manufacturing operations, the problem of interconnecting various software and hardware
systems has become a major issue. The first computer-based planning and control
systems were custom designed and configured for dedicated applications. It was
extremely difficult and often impossible to take existing software and hardware modules
developed for one platform and use them for the configuration of a planning and control
system for another.
Drawings created with Computer-Aided Design (CAD) tools, which were introduced in
the 1960s, represented tremendous productivity gains over paper drawings, such as ease
to revise and archive. CAD tools also opened new opportunities, such as enabling
manufacturing instructions to be derived automatically and executed directly from the
drawing. Nevertheless, as computer design and manufacturing tools proliferated to meet
increasingly complex and diverse engineering needs, so did the formats that each tool
used to capture and store product data. While paper drawings can be marked up by
anyone with a pencil, a product model that cannot be interpreted by the necessary CAD
tool is useless. For organizations to share designs across various CAD and
Computer-Aided Manufacturing (CAM) tools, their data files must be formatted in a
manner that the tool can recognize. This requirement has become increasingly important
in an age where large manufacturers often form joint ventures to address a business
opportunity, and where partners in a supply chain are being called upon to deliver an
increasingly complex array of services.
Most companies find it difficult to enforce the use of a common set of CAD/CAM tools
within their organization. Because of the lack of any common set of tools, a common
format for neutral file exchange is needed. Using a neutral standard for transferring
information across heterogeneous systems drastically reduces the requirements for
translators. The cost benefits are suggested by the reduction in necessary translators
shown in Figure 7.1. The direct translators required for 4-systems is equal to 12
(Figure 7.1(a)) whereas in the case of a neutral file exchange number of translators 123
Computer Aided Design required are 8. Thus it illustrates that by using a neutral file exchange, the number of
translators (for N systems) can be reduced from scaling as n (n – 1) to 2n.

 

 
(a) By Direct Translators

 

 
(b) By Neutral Format
Figure 7.1 : Efficiency of a Neutral Format of Data Exchange

It is further understood that if the number of systems are more, exchange through neutral
file would be much more effective.
See when N = 10. Number of direct translators required 10  9 = 90.
Number of translators through neutral file = 2  10 = 20.
If the transfer is among (almost) the same type of systems (it means typically that the
software packages should be of the same name and same version), then the most efficient
way of transfer is by direct exchange (Figure 7.2). No conversions or standards are
needed.


CAD System A
Data Specific to Both
System A and B 
CAD System B

Figur
e 7.2 : Data Exchange from System A to B; Direct Transfer
If the two involved systems are of different type (Figure 7.3) then the file exported by
system A cannot be expected to be understood by system B. Then some sort of
conversion needs to take place. The issues concerning conversion are discussed later.

124
conversio
n

 
 CAD/CAM Data Exchange

Figure 7.3 : Data Exchange from System A to B; a Conversion Takes Place

The problem of data exchange among various heterogeneous systems had been
recognized many years ago and initiated standardization activities in almost every
industry that uses CAD/CAM and CAE tools. Also an attempt was made to draft
standards on an international level to conceive standard interfaces for interconnecting
CAD and CAM systems in order to transfer design data to the planning activities of
manufacturing. Information which is communicated across the interfaces contains
graphical, drawing related, geometry and product model data as in Figure 7.4. This data
is used for process planning, scheduling, manufacturing and quality control.

Figure 7.4 : Product Information Communicated between CAD/CAM Activities Scanned Image ????
The three main reasons for transferring data among CAD systems (or CAE systems or
agents etc.) are :
1.(i) To communicate with remote computers and design workstations. Practical Formatted: Indent: Left: 0.39", Hanging: 0.39",
limitations, such as shortage of workstations, can already lead to Numbered + Level: 1 + Numbering Style: i, ii, iii, … +
storage/retrieval and interchange of CAD models. Start at: 1 + Alignment: Left + Aligned at: 0.39" + Tab
after: 0.89" + Indent at: 0.89", Tab stops: Not at 0.5" +
1.(ii) Long-duration storage and retrieval, and archival purposes.
0.89"
1.(iii) During the design process, a CAD system may turn out to be incapable of
performing the required modeling operations. Then it can be decided to send
the CAD model to a different CAD system which does have the required
functionality.
To improve the control over the various exchange processes and to reduce the number of
necessary converters, one may use a CAD transfer standard. Well-known standards
include IGES, DXF and STEP. If a particular standard is used, the sending system
should export the data in the format defined by the standard. The receiving system needs
to be able to read and interpret this data (Figure 7.5). Later we will see that the use of a
standard only superficially solves some of the interoperability problems.

IGES
Eexport IGES

 
ExportIm
port
Neutral Data Using IGES
Standard Conversion

Figure 7.5 : Data Exchange from System A to B; the Data Exchange Standard IGES is used;
Implicitly, a Conversion Takes Place

125
Computer Aided Design Coming back to CAD/CAM exchange, the heart of any CAD/CAM model is its
component databases. Which include information of points, lines, arcs, their relations and
their locations. This data is made available for use in all the succeeding applications like
FEM analysis, solid modeling, process planning, Material Requirement Planning (MRP),
CNC Programs generation and inspection programs etc. Thus we have to discuss a
universal data exchange system for all applications of CAD/CAM data exchange.
The concept of a universal data exchange system is depicted in Figure 7.6. In this figure,
it is shown how various CAD systems communicate with the production planning and
control system. The adaptation of protocols, data formats and data transmission rates is
done by the interface. The interface must provide a real time compatibility and it must
ensure that the semantics of the exchanged information is maintained. Data conversion
may be done directly in the interface with preprocessors or postprocessors. With the help
of such an interface it becomes possible to use existing software and hardware modules
for various applications in a factory. In addition, a company’s own manufacturing data
can be easily merged with those from vendors and suppliers. It is also possible to build
manufacturing planning and control systems from heterogeneous modules supplied by
different vendors.

CAD System 1 CAD System 2 CAD System n

Database INTERFACE Database

CAP CAM CAQ

1. Process Control of : 8. Testing
Formatted: Indent: Left: 0", Hanging: 0.2", Bulleted +
planning 5. machine tools 9. Evaluation
Level: 1 + Aligned at: 0.25" + Tab after: 0.5" + Indent
2. Assembly 6. robots test 10. Reporting
planning system
at: 0.5", Tab stops: 0.2", List tab + Not at 0.25" + 0.5"
3. Test planning 7. transport Formatted: Indent: Hanging: 0.5", Bulleted + Level: 1 +
4. Manufacturing systems Aligned at: 0.25" + Tab after: 0.5" + Indent at: 0.5",
equipment Tab stops: 0.25", List tab
programming
Formatted: Indent: Hanging: 0.5", Bulleted + Level: 1 +
Figure 7.6 : Universal Interface for Interconnecting the Computer Planning and Control
Aligned at: 0.25" + Tab after: 0.5" + Indent at: 0.5",
Activities of a Manufacturing System
Tab stops: 0.2", List tab + Not at 0.25" + 0.5"
Requirements for Standard Interface
1. Formatted:
The interface must be capable of handling all kinds of manufacturing Indent: Left: 0.39", Hanging: 0.39",
data.
Bulleted + Level: 1 + Aligned at: 0.25" + Tab after: 0.5"
2. There should be no information loss when data is transferred between
+ Indent at: 0.5", Tab stops: Not at 0.5"
heterogeneous systems. In other words, it must be possible to maintain the
semantics during conversion.
3. The system must be capable of handling the real time requirements of a
manufacturing system efficiently and effectively.
4. The system should be open-ended to permit extensions or contractions.
5. The system should be adaptable to other standards.
6. The system must be independent of the computer and communication
architecture used.
7. The systems should be capable of handling maximum number of data
entities. Ideally, there should not be any limitation.
8. It must be possible to form application – oriented subsets of the standard to
reduce cost and overheads.
9. The system should be capable of achieving production data.
10. The interface must be upward and downward-compatible in a hierarchical
control structure.
126
 CAD/CAM Data Exchange
11. Test procedure must be provided to verify the efficiency and accuracy of
data transmission.

7.2 TYPES OF INTERFACES

An interface can be regarded as an aggregate of conditions, rules and conventions which
describes the information exchange, between two communicating objects. An object in
our context can be human, software, modules, computer hardware or manufacturing
processes. In principle, three types of interfaces can be distinguished including language
interfaces, procedural interfaces and descriptive interfaces (Table 7.1). The CAD system
must be capable of exchanging data with the manufacturing system components are as
shown.
The language or user interface (Table 7.1 and Figure 7.7) is the window through which
the user can communicate with the CAD module. The user employs the icons, pictorials,
menus or textual languages to describe design and manufacturing problems. The textual
languages are still the most important means of user/system communication. However,
the interactive graphic languages are increasingly gaining importance, they are easier to
learn and offer a more natural method of user/agent communication.
The procedural interfaces refer to language interfaces which are necessary to do the
technical calculations, CAD modeling, process planning and machine programming.
These interfaces may use subprograms, parameter and machine programming. These
interfaces may use subprograms, parameter descriptions or host languages to perform the
individual CAD activities; thereby the host language concept is of particular importance.
A host language is an existing language such as Fortran, C, C++ or Vb, Vb+ etc. which
has been extended to be able to handle specific constructs like the description of a circle.
This is often done by calling subroutines. Procedural interfaces are also used to set up, in
a generic way, the CAD configuration to be used or to manipulate data of the CAD
database.
Table 7.1 : Types of Software Interfaces
Procedural Interface Descriptive Interface
Language Interface
(Program Interface) (Data Interface)
Types Language syntax Subprograms (of extended Data structures
Language grammar languages) Data formats
Language development Parameter description
Host languages
Representatives Fortran, COBOL, Pascal, VC, GKS graphic interface IGES
VC++ Data manipulation interface SET
Data manipulation languages Fortran variant programming VDAFS
Manufacturing machine Libraries
programming language
Archives
Form element and variant
description languages
Examples P1 = POINT/0,0,12 CALL POINT(X,Y,Z,P1) ‘P1’ 421,0,0,12
L3 = LINE/P1,ATANGL,45 CALL LINE (P1,0) ‘L3’ 520,0,0,12,45
C2 = CIRCLE/P1,P2,P3 CALL CIRCLE (P1,P2,P3,C2) ‘L2’ 200,0,0,12,
4,5,3,5,6,10

Figure 7.8 shows the concept of the Graphical Kernel System (GKS) which is a standard
interface that can be used to operate different CAD hardware/software systems through
an application program. GKS defines a language independent nucleus for operating a
graphic system.
Workplace Plotter Metafile

  127

Graphic interface
GKS
CAM
NC machine
Computer Aided Design

Figure 7.7 : CAD/CAM Interfaces

User Program
Application-oriented Layer
Language-dependent Layer
Graphical Kernal Kernel System
Operating System
Other Resources Graphical Resources

Figure 7.8 : The Layer Model of the Graphical Kernel System (GKS)
The user communicates with the graphic system via his program. The GKS system is
embedded in the user program by an application-oriented layer and a language
independent layer, whereby each layer calls upon the functions of the adjacent lower
layer. The following services are available to the user :
1. Formatted:
methods for the abstract definition of the peripherals which are Indent:
needed for a Left: 0.39", Hanging: 0.39",
CAD session; Bulleted + Level: 1 + Aligned at: 0.25" + Tab after: 0.5"
+ Indent at: 0.5", Tab stops: Not at 0.5"
2. definition of basic graphic elements, polynomials, text and so on;
3. performance of graphic operations such as transformation, rotations, picture
segmentation, editing and so on;
4. generation of a neutral picture file (meta-file) for the system independent
storage of data, the exchange of data between different CAD systems and
the organization of the output of graphic data;
5. definition of a segment file for storing picture segments during a CAD
session;
6. input and output of graphic information.
Descriptive interfaces are the window to other CAD systems, to the master databases or
to the manufacturing activities. The basic concept of a descriptive interface is shown in
Figure 7.9. With this concept it is possible to exchange models between two different
128
CAD systems. For example, model data of the CAD system A is converted via a CAD/CAM Data Exchange

pre-processor to a neutral presentation form and from there via post-processor to a

CAD System 1 Neutral Interface CAD System 2

CAD
CAD Exchange Msodel 1
Model 1 Model
Pre- PrePost-
processor
A
processor A
A 1 1
B
A–B B C
B C B–D
PrePost- C Pre-
processor A–C processor D D
D
2 C–D 2

Figure 7.9 : Exchange of CAD Models between Two Different CAD Systems

neutral presentation form and from there via post-processor to the representation scheme
needed by the CAD system B. The exchange model representation is a system-
independent method of describing the application. It can be accessed by any CAD system
which has the proper pre- and post-processors. Typical equipment independent interfaces
to manufacturing are CLDATA for NC machine programming and IRDATA for robot
programming.
Figure 7.10 depicts the development of various standard interfaces for CAD/CAM and
CAE application.
Interfaces Standardization organization
CAD/CAD CAD/CAM National and European International ISO
IGES
PDES  ANSI (USA) 
PDDI
SET  AFNOR (France)  Product Data
Structure
VDAFS  DIN (Germany) 
CAD*I  ESPRIT (European
STEP
Commission) 
CIM-OSA  ESPRIT (European
Commission) 

Figure 7.10 : Development of CAD/CAD and CAD/CAM Standards

7.3 DESCRIPTION OF VARIOUS STANDARD INTERFACES

7.3.1 Initial Graphics Exchange Specification (IGES)
The basic concept of IGES is concerned with the exchange of product description data
from one CAD system to another one. The CAD/CAM integration information network
(CIIN) of Boeing served as the preliminary basics of IGES. This exchange takes place via
a neutral data format, (see Figure 7.9). If information has to be transferred from one type
of CAD system to another it is converted via a pre-processor to the neutral data format
specified by IGES and then converted via a post-processor to the proper data format of
the other CAD system. With this concept, it is possible to transfer CAD data between any
set of CAD systems, as long they are equipped with the corresponding pre- and post-
processors.

129
Computer Aided Design
Terminate Section T1
(statistics)

Parameter data section P1

(Element data; pointed
coordinates, values, etc)
Directory entry section D1
(Element descriptor;
type, pointer, form, etc)
Global Section G1
(General information for
pre and post-processor)
Start Section S1
(Comment)

Flag Section C1
(Data type) or
B1

Figure 7.11 : Sections of the IGES Data File

IGES tries to represent technical drawings; three-dimensional wireframe, surface and
volume models; FEM models; and symbolic representations in a neutral data format.
The IGES concept developed to date has the following five versions :
Version Year
IGES – Version 1.0 1981
IGES – Version 2.0 1983
IGES – Version 3.0 1984
IGES – Version 4.0 1986
IGES – Version 5.0 1988

Version 1.0 was conceived for the early CAD systems and was tailored toward the
technology of the 1970s. Presently, most equipment manufacturers support Versions 2.0
and 3.0 (read the Box 1 and 2 for interesting history of IGES and its developers).
Box 1
THE BIRTH OF IGES
In 1979, events took place that catalyzed the CAD vendor and user community to create the first
national standard for CAD data exchange. Mechanical CAD systems were less than ten years old,
and there were only a handful of products with any significant market penetration. Even at this
early stage, users were overwhelmed by the inability to share data among these tools and with
their own internally-developed databases. Frustration was evident at a fateful two-day Society of
Manufacturing Engineers (SME) meeting in the Fall of 1979. On the first day, an attendee from
General Electric (GE) challenged a panel of CAD vendors, that included Computer Vision,
Applicon and Gerber, to work together to enable a common neutral exchange mechanism. While
this need was intuitive from a user perspective, this was a very threatening proposition to the CAD
vendors – who feared that publicly sharing the structures of their databases would be tantamount
to giving away their competitive advantage. It would have been easy to gloss over the challenge;
after all, the major vendors all had at least token representation on the ANSI committee
responsible for CAD standards. Instead, the Computer Vision representative responded with a
challenge of his own: If Boeing and General Electric (and perhaps others) would contribute the
CAD translators they had already developed, the vendors would share their database structures.
What led to this offer was a fortunate blend of business motivation and private agendas. It just so
happened that the evening before the CAD panel, a CAD vendor representative was busily
recruiting employees for his (unannounced) new robotics company. In forming this company, he
gained the user’s perspective: his product was going to need to have access to CAD data! If he
130
 could set the wheels in motion for the CAD vendors to make public their database structures, his CAD/CAM Data Exchange
new company would have a better chance at success; however, an exchange standard was also in
the CAD vendors’ best interest. The CAD vendors tried to differentiate themselves based on
loyalty to their customers, that also had the negative effect of dividing the end users into camps.
There were large Navy contracts looming on the horizon, and no vendor wanted to look
unresponsive to customer requirements.
In the evening after the panel, several interested parties gathered in a smoke-filled room and asked
themselves if a common translator was really possible. The room had the right combination of
people at the right time. This included an Air Force ICAM representative willing to fund such an
effort and a National Bureau of Standards (NBS) representative who, after a call to his boss at
home for a sleepy approval, was willing to champion it. This whole initiative was thus initiated
with a $50,000 contract that established the effort’s initial structure and requirements :
1. An NBS representative was placed in the lead 2; Formatted: Indent: Left: 0.39", Hanging: 0.39",
2. Two initial IGES committees were formed: the Steering Committee to manage the Bulleted + Level: 1 + Aligned at: 0.25" + Tab after: 0.5"
effort and a Working Committee to perform technical work; + Indent at: 0.5", Tab stops: Not at 0.5"
3. A draft was to be delivered within three months.
With the fundamentals decided, conversation turned to a name for this new translation project.
The group nixed the suggestion “Universal Translator” to avoid offending those within ANSI,
who might have interpreted the project as a way to displace the years of effort already put towards
a Y14.26 standard. A minimalist approach was suggested :
I Interim, to suggest that it would not replace ANSI’s work;
G Graphics, not geometry, to acknowledge that academics may come up with superior
mathematical descriptions;
E Exchange, to suggest that it would not dictate how vendors must implement their internal
database; and
S Specification, not to be as imposing as a standard.
The panel reported on the second day, and the wheels were set in motion to create an “IGES.”
Once the panel admitted that a common translation mechanism was possible, it was impossible to
stop the momentum of the customers’ enthusiasm and expectations. Applicon and Computer
Vision agreed to open up their internal databases, GE offered its neutral database, and Boeing
offered the structure of its Computer Integrated Information Network (CIIN) database. Both GE
and Boeing contributed their existing translators. A core team was formed that included
representatives from NBS, Boeing, and GE. Team members had worked closely with each of the
vendors on internal integration projects. This prior experience built the expertise and trust needed
to craft a solution in a very short time, and neither vendor felt it gave an unfair advantage to the
other.
Soon after, an open meeting was held at the National Academy of Sciences on October 10, 1979.
Approximately 200 people attended to herald the birth of IGES. There was an atmosphere of
extraordinary excitement, although not everyone was supportive. In addition, although it was hotly
debated, the name of this project was eventually accepted with the minor change from “Interim”
Graphics Exchange Specification to “Initial” Graphics Exchange Specification.
After two critical reviews, the IGES team released its first draft in January 1980, containing
geometry, graphical data, and annotations. IGES was submitted to the ANSI Y14.263 committee
for standardization, which forced the committee to try to reconcile the very different views
embodied by the IGES work and the work funded by CAM-I on boundary representation
description. When version one of IGES was standardized (Y14.26M-19814), the work funded by
CAM-I was attached but unintegrated with the remainder of the standard.

IGES contains records of 80 character length which are presented by the 80 columns card
format; where columns 1-72 hold information in ASCII code and columns 73-80 hold an
alphabetic character followed by a serial number to indicate sections.
An IGES file has six parts, including a flag section, start section, global section, directory
entry section, parameter data section, and terminal section, (see Figure 7.11).
Table 7.2 : Elements of IGES Version 4.0
Object-related Entities Structure Entities Predefined Associations
Geometric Entities Modeling Entities
Circular arc Finite element Associativity definition Group w/o backpointers
Composite curve Nodal Associativity instance External reference file index
Conic arc Displacement/rotation Drawing Views visible
131
Computer Aided Design Copious data Offset surface Line font definition Views visible color
Plane Curve on a parametric surface Macro definition Line weight
Line Trimmed (parametric) surface Macro instance Entity label display
Parametric spline curve Nodal results Property Single parent association
Parametric spline Element results Subfigure definition External reference file index
surface Network subfigure definition Dimensional geometry association
Point CSG model Singular subfigure instance Ordered group w/o backup
Ruled surface Rectangular array subfigure Planar association
Surface of revolution Block Instance Flow
Tabulated cylinder Right angle wedge Circular away subfigure instance
Transformation matrix Right circle cylinder Network subfigure definition Drafting Entities (Annotations)
Flash Right circle cone Text font definition
Rational B-spline curve Frustum View Angular dimension
Rational B-spline Sphere External reference Centerline
surface Torus Nodal load/constraint Diameter
Offset curve Solid of revolution Text display template Dimension
Concept point Solid of linear extrusion Absolute text display template Flag note
Ellipsoid Incremental text display General label
Boolean tree template General note
Solid instance Color definition Leader (arrow)
Solid assembly Attribute table definition Linear dimension
Attribute table instance Ordinate
Dimension
Point dimension
Radius dimension
General symbol
Sectionated area
Section
Witness line

1. Formatted:
The flag section indicates if the file is in binary or in a compressed ASCII Indent: Left: 0.39", Hanging: 0.39",
format. It may not be used when the contents are representedBulleted
by ASCII+ Level: 1 + Aligned at: 0.25" + Tab after: 0.5"
characters. If the binary presentation is selected, the file can +beIndent at: 0.5", Tab stops: Not at 0.5"
compacted
by 70%.
2. The start section contains comments; it provides human readable comments
keyed in by the user and contains information for the receiving station.
3. The global section holds information describing the pre-processor and data
needed by the post-processor to handle the file.
4. The directory entry section describes all IGES entities specified in the file
(Table 7.2). The entities are the various geometric elements including points,
curves, surfaces and relations which are collections of similar structured
entities; annotations like dimensions, viewing angles and notations, and
structure elements like line font definitions, macro definitions, drawing
specific data and so on.
5. In the parameter data section, the parameters of the specified entities are
stored in a free format.
6. The terminate section contains a statistic indicating the size of each section
which is represented by the last sequence number of a section.
Although IGES is a commonly used interface it has many problems. Version 1.0 was
criticized for its huge file size and redundancy. This problem was reduced in Version 2.0
by introducing the binary format for setting up files. A problem exists of repeated
definitions between the data entry section and the parameter data section, and also files
are not very readable.
The pre- and post-processors are frequently of insufficient quality because companies
who supply them try to maintain proprietary rights. Thus, a one-to-one functional match
132
between the transferred information of two CAD systems is often not obtained. Also the CAD/CAM Data Exchange

more recent versions of IGES have problems. For example, the IGES Version 3.0 was not
developed to present information on solids. Thus solids must be described in an awkward
method by boundary entities, and thus some information about solids cannot be
transferred. In addition, there are representation schemes which are not unique and have
unstructured file formats.
For the evaluation of IGES, consider a CAD model of a plate with a hole at the centre.
Figure 7.12(a) shows the 3D model of the plate and Figure 7.12(b) shows the wireframe
model. The IGES neutral file for the wireframe model is given in Table 3.0.

(a) 3D Model

Y CS0
PNT0 PNT1
X

PNT7
PNT8

PNT3
PNT2

PNT4 PNT5
(b) Wireframe Model
Figure 7.12 : Rectangular Plate having a Central Hole

Table 7.3 : IGES – Wireframe Edges

PTC IGES file: Wire frame_Edges.igs S 1
1H,,1H;,4HSTEP,6Hi1.igs, G 1
49HPro/ENGINEER by Parametric Technology
Corporation, 7H1999390,32,38,7 G 2
38,15,4HSTEP,1.,2,2HMM,32768,0.5,13H000104.164438,0.00187075,18.708, G 3
5Hstaff,7HUnknown,10,0,13H000104.164438; G 4
110 1 1 1 0 0 0 000000000D 1
110 0 0 1 0 LINE 1D 2
110 2 1 1 0 0 0 000000000D 3
110 0 0 1 LINE 2D 4
110 3 1 1 0 0 0 000000000D 5
110 0 0 1 0 LINE 3D 6
110 4 1 1 0 0 0 000000000D 7
110 0 0 1 0 LINE 4D 8
124 5 1 1 0 0 0 001000000D 9
124 0 0 1 0 XFORM 1D 10 133
Computer Aided Design 110 6 1 1 0 0 9 000000000D 11
110 0 0 1 0 ARC 1D 12
110 7 1 1 0 0 0 000000000D 13
110 0 0 1 0 LINE 5D 14
110 8 1 1 0 0 0 000000000D 15
110 0 0 1 0 LINE 6D 16
110 9 1 1 0 0 0 000000000D 17
110 0 0 1 0 LINE 7D 18
110 10 1 1 0 0 0 000000000D 19
110 0 0 1 0 LINE 8D 20
110 11 1 1 0 0 0 000000000D 21
110 0 0 1 0 LINE 9D 22
110 12 1 1 0 0 0 000000000D 23
110 0 0 1 0 LINE 10D 24
110 13 1 1 0 0 0 000000000D 25
110 0 0 1 0 LINE 11D 26
110 14 1 1 0 0 0 000000000D 27
110 0 0 1 0 LINE 12D 28
110 15 1 1 0 0 0 001000000D 29
110 0 0 1 0 XFORM 2D 30
110 16 1 1 0 0 29 000000000D 31
110 0 0 1 0 ARC 2D 32
110 17 1 1 0 0 0 000000000D 33
110 0 0 1 0 LINE 13D 34
110 18 1 1 0 0 0 000000000D 35
110 0 0 1 0 LINE 14D 36
110,0D0,0D0,0D0,0D0,-1D1,0D0; 1P 1
110,0D0,-1D1,0D0,1.5D1,-1D1,0D0; 3P 2
110,1.5D1,-1D1,0D0,1.5D1,0D0,0D0; 5P 3
110,1.5D1,0D0,0D0,0D0,0D0,0D0; 7P 4
124,-1D0,0D0,0D0,7.5D0,0D0,1D0,0D0,0D0,-5D0,0D0,0D0,-1D0,0D0; 9P 5
100,0D0,0D0,0D0,2.5D0,0D0,2.5D0,0D0; 11P 6
110,0D0,0D0,0D0,0D0,0D0,5D0; 13P 7
110,1.5D1,0D0,0D0,1.5D1,0D0,5D0; 15P 8
110,1.5D1,-1D1,0D0,1.5D1,-1D1,5D0; 17P 9
110,0D0,-1D1,0D0,0D0,-1D1,5D0; 19P 10
110,0D0,0D0,5D0,0D0,-1D1,5D0; 21P 11
110,1.5D1,0D0,5D0,0D0,0D0,5D0; 23P 12
110,1.5D1,-1D1,5D0,1.5D1,0D0,5D0; 25P 13
110,0D0-1D1,5D0,1.5D1,-1D1,5D0; 27P 14
124,-1D0,0D0,0D0,7.5D0,0D0,1D0,0D0,-5D0,0D0,0D0,-1D0,5D0; 29P 15
100,0D0,0D0,0D0,2.5D0,0D0,2.5D0,0D0; 31P 16
110,5D0,-5D0,5D0,5D0,5D0,-5D0,0D0; 33P 17
110,1D1,-5D0,5D0,1D1,-5D0,0D0; 35P 18
S 1G 4D 36P 18 T 1
IGES files can also be generated for :
1.(i) Surfaces Formatted: Indent: Left: 0.39", Hanging: 0.39",
1.(ii) Datum curves and points Numbered + Level: 1 + Numbering Style: i, ii, iii, … +
Start at: 1 + Alignment: Left + Aligned at: 0.39" + Tab
after:
Today, IGES is still used as a universal tool, providing a neutral format for many0.89" + Indent at: 0.89", Tab stops: Not at 0.5" +
companies to transfer engineering data between CAD/CAM systems. As of 0.89"
late 1999,
over 25 vendors offered commercial IGES supporting tools.
Box 2
About the Three Authors of IGES
In 1977, the three authors of The Initial Graphics Exchange Specification were recognized
collectively for their contributions to the development of IGES Version 1.0 by receiving the
AIMTECH Joseph Marie Jacquard Memorial Award. The first author, Roger Nagel, was a NBS
staff member at the time and is now the Harvey Wagner Professor of Manufacturing Systems
Engineering in the Electrical Engineering and Computer Science Department at Lehigh
University. He created Lehigh’s Robotics Research Institute, established and directed the
Manufacturing Systems Engineering Program, and served as Executive Director of Lehigh’s
134
Iacocca Institute for Competitiveness Research. While an employee of NIST, Nagel was a key CAD/CAM Data Exchange
member of the scientific team developing the Factory Hierarchical Control System in the Robotics
Group. This work on hierarchical control systems, performed with James Albus, Tony Barbera,
and Gordon Vanderbrug, has been the basis of hundreds of computer-based control systems for
automation over the last 20 years. Nagel continues to serve as a technical advisor and consultant to
NIST’s Manufacturing Engineering Laboratory.
The other two authors were from industry. Walt Braithwaite is currently Corporate Vice President
for Company Offices Administration at the Boeing Company. He has held numerous positions
within Boeing, including Director of Program Management for the 737 and 757 airplane programs
and Chief of Engineering Operations for the 747 and 767 programs. As the lead engineer
responsible for technical direction in developing an information network to integrate computer-
aided design and computer-aided manufacturing, he led development of Boeing’s common data
format and translators, which were used as a basis for developing the IGES protocol.
Philip Kennicott joined the General Electric Research Laboratory in 1961 where he made
contributions in the fields of x-ray crystallography and spark-source mass spectrography. As a
consultant to General Electric’s Computer Aided Design Center, he was instrumental in making
General Electric the largest user of CAD/CAM equipment in the world in the 1970s. This work led
to the concept of a neutral database, the basis for the General Electric contribution to IGES.
Within the IGES community, Kennicott served as a leader of many technical activities, including
Editor of the continually evolving IGES standard. He also led a technical team to develop the
Department of Energy Data Exchange Format, the first IGES application protocol. He continued
this work at Sandia National Laboratories in 1989 and retired from Sandia in 1997.

7.3.2 Product Definition Data Interface (PDDI)

IGES provided a very practical first solution for CAD data exchange, complete with an
exchange file format. It was remarkable in the speed with which it was developed, due in
part to the relatively limited scope, the small size of the committee working on it, and a
commitment to produce a draft within three months. Once it fell under the scrutiny of an
ever-broadening community, weaknesses were identified that eventually justified
embarking on a new standard that could break tradition with IGES. The Air Force ICAM
program again made a significant contribution to the evolution of product data exchange
standards, this time through its Product Definition Data Interface (PDDI) contract. The
purpose of PDDI was to develop a mechanism to allow the complete exchange or sharing
of product model data directly among computer applications – without human
intervention. PDDI with its geometry focus, developed a set of information models, a
modeling language that contributed to EXPRESS, an exchange file format that separates
the data being exchanged from its definition, and a mechanism for applications to share
data.
One of the tasks of this contract involved an evaluation of IGES in the context of its
current implementations. This resulted in a thorough report and numerous constructive
requests for changes to IGES. This evaluation activity helped the community clearly
define IGES’s shortcomings :
1. Flavorings. IGES contained several ways to capture the same information, Formatted: Indent: Left: 0.39", Hanging: 0.39",
which made proper interpretation largely dependent on the particular Bulleted + Level: 1 + Aligned at: 0.25" + Tab after: 0.5"
“flavor” of the pre- and post-processors. + Indent at: 0.5", Tab stops: Not at 0.5"

2. File size/processing time. IGES was heavily criticized for requiring large
files that took hours or even days to parse, given the average computing
power available at the time.
3. Loss of information during exchange. Information would inevitably be lost
when information is passed between two CAD systems with inherently
different capabilities.
4. Lack of discipline, architecture. There was a perception that IGES was
developed without rigorous technical discipline, and that the use of
information modeling would be useful.
5. Upward compatibility. The need for generations of processors to parse files
compliant with earlier versions of IGES thwarted the breadth and rate of
change in succeeding versions. 135
Computer Aided Design 6. Automated, rather than improved upon, paper system. IGES was seen as a
method to exchange engineering drawings, but not capable of capturing
complete product data (including administrative information) to enable more
sophisticated automation.
Although PDDI was a research exercise, it contributed understanding, mechanisms, and
models to future standards, most notably ISO 10303 – Standard for the Exchange of
Product Model Data (STEP).
Additional shortcomings were later identified such as :
1. Subsetting. Vendors selected and implemented only portionsFormatted:
of the wholeIndent:
of Left: 0.39", Hanging: 0.39",
IGES, thus making exchange between two systems impossible Bulleted + Level:
without prior1 + Aligned at: 0.25" + Tab after: 0.5"
agreement on what was to be exchanged. + Indent at: 0.5", Tab stops: Not at 0.5"

2. Conformance testing. There was no mechanism for testing processors or

resolving errors between two processors.
The PDDI interface was developed in connection with the ICAM project which was
funded by the Air Force in order to improve the manufacturing methods in the aircraft
industry. The essential goal of this product was the creation of an interface between CAD
and CAM. PDDI is design-oriented, it provides a formal specification of a product model
and its submodels. The latter represent :
1.(i) The 3-D geometry of the product which is defined by a set ofFormatted:
curves, Indent: Left: 0.39", Hanging: 0.39",
surfaces and volumes. Numbered + Level: 1 + Numbering Style: i, ii, iii, … +
Start at: 1 + Alignment: Left + Aligned at: 0.39" + Tab
1.(ii) The topology which describes the set of elements and relations for defining
after: 0.89" + Indent at: 0.89", Tab stops: Not at 0.5" +
the product boundary.
0.89"
1.(iii) The tolerance which is inherent in the accuracy of the manufacturing
processes.
1.(iv) The future elements needed for defining manufacturing operations.
1.(v) The non-geometric information for organizational purposes and description
of material and its properties.
Additional information includes the specification of the pre- and post-processors needed
for the data exchange between CAD and CAM. The PDDI efforts were conceptual
research activities and the results were used for the development of the PDES activities
and are a major input to STEP.
7.3.3 Product Data Exchange Specifications (PDES)
By 1984, many of these international efforts had produced enough results to be
compared, and an international community was preparing to form in hopes of creating a
common solution to CAD data exchange. The drivers for a common international
standard included :
1. Global commerce and data exchange; Formatted: Indent: Left: 0.39", Hanging: 0.39",
Bulleted + Level: 1 + Aligned at: 0.25" + Tab after: 0.5"
2. Increasingly complex products;
+ Indent at: 0.5", Tab stops: Not at 0.5"
3. Multi-use software, e.g., design or engineering systems that apply to
multiple industries and applications;
4. Reliance on suppliers at all phases of product development;
5. Need for life0 cycle support.
Many felt that IGES could not adequately respond to these pressures.
In May of 1984, a late night meeting of the IGES Organization Edit Committee was held.
The outcome: the Boeing representative was tasked to write a paper on what the next
generation of IGES might look like without the constraint of providing upward
compatibility for IGES processors. This informal request was in response to pressures
from the PDDI results and European efforts. The first Product Data Exchange
136
Specification (PDES) report was issued in July of 1984, and was followed by a second CAD/CAM Data Exchange

report in November of 1984. These reports laid the groundwork for the PDES Initiation
Effort, which, similar to PDDI, was considered a theoretical exercise at building a
standard based on a broader automation goal and the discipline of information modeling.
The PDES Initiation Effort used a simple machined part as a product emulator, and
focused on both the logical information being captured and the “physical” mechanisms of
data exchange. Those involved originally assumed that this next generation standard
would be IGES Version 3. Instead, the work spawned a separate U.S. national effort
known as PDES. PDES was eventually folded into the international effort led by ISO
TC184/SC4 responsible for developing and standardizing STEP.
The PDES Initiation Task and Report also included an Electrical Schematic Reference
Model. The Initiation Task validated, through modeling, the concept that electrical
connectivity and mechanical joining both shared a common underlying topology. This
topological foundation found later application in electrical product modeling for both
IGES and STEP.
The aim of PDES is to provide an interface which permits the exchange of data of the
entire product development cycle and production cycle, see also PDES (1985). It can be
viewed as an expansion of IGES whereby organizational and technological data have
been added. Functionally PDES will contain IGES Version 4.0. The physical and logical
structure of both interfaces will be different. For this reason there will be a conversion
program to transfer IGES into the PDES format.
A special feature of the PDES development is the use of the formal language EXPRESS
for modeling the product information. There will be capabilities for defining
manufacturing features, FEM and special applications for civil engineering, electronics,
ship building and so on. The results of the PDES project will be the major input to STEP.
7.3.4 Standard for Exchange and Transfer (SET)
The interface SET is a standard for the exchange of all data which is generated for
CAD/CAM. It is a French development and was first published in 1984 (SET 85).
Several additions have been published since (SET F88, SET S 88 and SET V88).
The information transferred via the SET interface are wireframe, surface,
B-representation and FEM models, as well as technical drawings and scientific data.
Organizational, material property and tolerance information cannot be defined by
individual models but they must be contained in the drawing for transfer.
SET allows the exchange of data between different CAD/CAM systems and also between
CAD/CAM systems and central data banks. It features a much more general data
structure than IGES; data is stored in a very compressed form. Thus the neutral file size is
much smaller and the processing time is much shorter than for IGES.
The structure of a typical SET file is shown in Figure 7.13. The delimiters of the file are
begin and end blocks. The BEGIN section contains administrative data and other
information of a general type.
BEGIN SET
BEGIN ensemble 1
Entity block 1

Entity block n
END ensemble 1

BEGIN ensemble 2
Entity block 1

Entity block m
END
BEGIN SET

Figure 7.13 : Structures of a SET Data File

137
Computer Aided Design The END section describes the total number of blocks stored in the SET file. The file is
structured from assemblies which contain a series of blocks; the blocks may be nested
and hold the CAD information which has to be transferred. There are different types of
information units defined. They are :
Class 0
The geometric primitives needed for describing 2- and 3-dimensional objects such
as points, lines, circles, parabolas, planes and surfaces.
Class 1
Complex geometric entities for defining complex curves, complex solids, shells,
faces and so on.
Class 2
Graphical aids to map product information onto technical presentations. These aids
include view block definitions, block definitions, line fonts, cross hatching,
characters for defining symbols and so on.
Class 3
Grouping mechanisms to assist the mathematical operations needed for the
manipulation of the design objects. Typical representations are coordinate
transformations, scalar series, general matrices, tabulated functions, physical
quantities, material properties and so on.
Class 4
Descriptive aids to represent diameters, angles, labels, text, cross-hatching, surface
finishes and so on.
Class 5
Elements defining the structural relations such as calling block, group, attribute
and homogeneous entities.
Class 6
Connecting elements to describe logic between the elements of any class.
Class 7
FEM elements to build the FEM model. Typical elements are finite elements,
model for an element, computations, definition of a computation, loads, damping,
Eigenvalue, knot renumbering and so on.
Class 80
Gives the user the possibility of defining his own elements.
Class 99
Management aids to structure SET files. They include SET header, ensemble
header, ensemble header as well as ‘End’ specifier for an ensemble and a ‘SET’.
7.3.5 Verband der Automobileindustries Flachenschnittstelle (VDAFS)
This interface was developed by the Association of the German Automobile Industry for
the transfer of 3-D curves and surfaces for which IGES only offers an unsatisfactory
solution. Two versions of this interface have been developed and are discussed in
Frankfurt Verband der Automobilindustrie (1983) and Mund et. al. (1987).
Similar to IGES, the VDAFS interface contains a fixed record length of 80 characters. A
file consists of a header and a data section. The header describes the data source, the
project name, the origination date, the validity date, the source CAD system and the user.
In the data section the geometric objects are described with the help of entities.
Characteristic for the data presentation is an APT-oriented data format.
Elements of the VDAFS version 2.0 are shown in Table 3. Curves and surfaces are
described with the help of points, set of points and set of vectors (Table 7.4).
Table 7.4 : Elements of VDAFS Version 2.0
138
 CAD/CAM Data Exchange
Geometric elements Non-geometric elements
Points Begin specifier
Point sequence Comment
Point vector sequences Structuring (SET groups)
Circle (curve) Transformation matrix
Polynomial curve Transformation table
Surface End specifier
Curve of surface
Trimmed surface
Surfaces of patches

POINT
Individual points

PSET
Point sequence

MDI
Point Vector Sequence

CURVE
Polynomial curve

SURF
Surface represented by polynomials

Figure 7.14 : VDAFS Geometry Elements

With the VDAFS interface it is possible to transfer any described workpiece surface,
including the orientation of the cutting tool. Problems include the transfer of text,
dimensions, cross-hatching and so on. IN In addition, single elements are received by the
user in a basic atomic format and are difficult to use for further processing. Another
problem is that the interface has insufficient means of structuring data.
7.3.6 CAD*I Interface
The CAD*I interface was developed within the framework of the ESPRIT Project 322 of
the European Commission. The project was started in 1985 and had a duration of five
years. The results are recorded in the literature of Schlechtendahl (1988 and 1989). The
emphasis of this project was placed on the data exchange between various CAD systems,
the exchange of CAD and FEM models and the conception of a neutral databank for
CAD data.
For the realization of the data exchange reference architecture models for 3-D wire frame,
surface, CSG and b-rep representations were established, and an interface for FEM
applications was specified. For the description of CAD data structures, the specification
language HDSL (High-level Data Specification Language) was designed. This language
allows the expression of all essential elements of a CAD data structure with the help of
special language constructs.
Within the framework of this interface, an attempt was to be made to improve the
deficiencies of IGES, SET and VDAFS which have the following problems.
1. Many of the specifications are imprecise Formatted: Indent: Left: 0.39", Hanging: 0.39",
Bulleted + Level: 1 + Aligned at: 0" + Tab after: 0.1" +
2. The file formats are not suited for an efficient processor implementation 139
Indent at: 0.1", Tab stops: Not at 0.1" + 0.5"
Computer Aided Design 3. The structuring capabilities of the file format for CAD data are not adequate
4. The scope of the interfaces is very restricted
Work related to the following areas have been addressed in this interface.
1. Investigation of CAD data structures and the presentation ofFormatted:
2-D and 3-DIndent: Left: 0.39", Hanging: 0.39",
models by using new modeling techniques; Bulleted + Level: 1 + Aligned at: 0" + Tab after: 0.1" +
Indent at: 0.1", Tab stops: Not at 0.1" + 0.5"
2. Specifying neutral file formats and providing access mechanisms;
3. Development of pre- and post-processors for interfacing various CAD
systems,
4. Development of interface test methods, and aids for performing and
documenting tests.
One special goal of the CAD*I project was the interaction with the STEP activities to
develop solutions which could be directly implemented in STEP.
The publications of the CAD*I project are very complete and are well suited to give the
reader not familiar with CAD/CAM interfaces a good insight into the general problems of
software standards.
Box 3
The State of CAD Data Exchange October 2004
“Are we nearly there yet?”
“Are we nearly there yet?” the dreaded question we hear wailing from the back of the car. “Yes,
nearly there” is our cheery response. We didn’t mean it. We might be miles away, hours more of
tedious journey. The PLM industry forges forward, the CAD users seeking interoperability cry out
“Are we nearly there yet?” and the vendor side of the industry in a single chorus replies “Yes,
nearly there”.
The vast majority of day-to-day CAD translation is now satisfied by good explicit translation
between CAD systems. That is to say, solids are translated to solids, surfaces to surfaces and wire
frame, points, layers, colours and so on, to their equivalents. The translation products have
matured and the user can expect good results. For example one Theorem customer, a UK
automotive OEM, recently batch translated more than 30,000 models in less than 12 hours with
only 16 failures, A success rate of 99.95%. With this kind of success rate, why are we not able to
say, “Yes, we’re nearly there?”
The answer is that things are changing. Opportunities for improvement arise even with the CAD
systems themselves. For example, a CATIA V5 assembly can comprise CATIA V5 parts and
referenced geometry from a number of other CAD systems including native CATIA V4 parts. The
opportunity exists therefore for a single translator to translate the hybrid assembly, and this
capability has already been incorporated into Theorem’s recent Version 8 release.
The need for fast, accurate explicit translation still exists and just as new requirements have
appeared new solutions are required. 3D models have always had the ability to hold more than just
geometry and the ASME 14.41 standard now defines how 3D annotation, including dimensions
and tolerancing data should be held. This means that the user requirement for manufacturing detail
to be passed with a translated model now has a technical solution and the translation vendors have
a set of common standards against which they can provide workable solutions rather than just
technical solutions. These pictures show a real production example of CATIA V5 model data,
with 3D annotations and the resultant translation into VisMockup for enterprise wide use of the
information.
There have also been changes in the use of some pre-existing data formats. Open associations
have been formed to encourage some formats to become standards. The JT format was originally
introduced as a “light weight” format for visualisation of CAD models in other business related
applications. JT enables drawings, 3D models and assemblies to be viewed and used throughout
an enterprise. It has been shown to be quite adequate for some types of CAD data exchange and
since the formation of the JT Open association it is likely that it will continue to develop in
importance and functionality. One major automotive OEM has terabytes of data in JT format and
it may well decide that this will be the standard for exchange of information between itself and its
world-wide supply chain. An action like this does not diminish the number of translations
required, it will simply replace or even add to CAD to CAD translation with CAD to JT
translation. Perhaps JT to CAD translation will be the next natural development. JT may therefore
have the effect of increasing the number of translations that take place.
While one “open standard” develops, another is announced, and 3D XML is championed by some
as the next “open standard”. There is no doubt that the 3D XML protagonists have a huge
140
 following and we can expect 3D XML to become widely used, but is it going to replace all the CAD/CAM Data Exchange
collective CAD data held in different formats? Probably not. The most likely outcome is that both
“standards” will be widely used and that they will need to co-exist. Does this mean in the future a
translator to move data between JT and 3D XML? Any consideration of standards in the CAD
data translation environment must also include some thoughts about STEP. Once considered by
some to be nothing more than a “super IGES” STEP has slowly but surely become a real workable
standard in some major OEM’s and their supply chains. Perhaps one of the best-kept data
exchange secrets is that STEP specifications have now extended to include Feature and History
structure. There are formal specifications for a modular extension to AP203 and it will be finalised
as AP203 Edition II. It has been tested in productive use by a group of major industrial
organisations, and at least one vendor of translators already has a STEP product with Feature and
History capability.
So, even in this fairly simple overview of the developing requirements of the end user, and the
evolution of the new standards from the industry we see a continued state of flux and a continued
need for translators and their further development.
A clear indication that CAD data translation is now an accepted part of the complex mechanical
design world is the emerging trend towards building translators into other environments and other
applications. The stability and dependability of explicit translators now means that there is
considerable benefit to be gained by initiating not just batch translations from other applications,
but also from managing the pre- and post-processed data in product life-cycle management (PLM)
systems. The result is a requirement for an automated job manager to schedule the translations,
initiate the translations, perhaps share resources across a network and deliver a variety of different
file types to a PLM system.
Another major change is the way in which translators are now being developed. Whereas once it
was necessary to reverse engineer a translator, that is to actually de-code the source and target
CAD file formats, this is no longer necessary. The PLM vendors now provide API’s (application
programming interfaces) that enable authors of translators to create new translators very quickly
and to have a high degree of success even with early releases. This move away from dependence
on reverse engineered code also reduces the risk of translators becoming redundant through a
change in the data format of a CAD system.
So, the question “are we nearly there yet?” doesn’t help. It is more useful to ask the question
“Where are we going?” or perhaps “What do I want to do with the translated geometry?” A user
who asks these questions and carefully considers the answers, has the highest likelihood of getting
the right solution for his own data translation requirements.

7.3.6 Standard for External Representation of Product Data (STEP)

The furthest developed standard is by ISO 10303, or STEP, Standard for the Exchange of
Product model data. One of the benefits of STEP is the semi-automatic generation of
export/import software from the definition of the standard (which is itself
computer-readable) (Figure 7.15).

Analysis of
information needs

CAD system A CAD system B

Data model

Data schema in STEP file

EXPRESS

Import/export
software for STEP
files

Figure 7.15 : Data Exchange from System A to B, using the Data Exchange Standard STEP Solid Line

Origin of STEP

141
Computer Aided Design Considerable progress has been made in vector data exchange over the recent past.
Initially, some CAD/CAM vendors offered direct translator software. There are
several disadvantages to this approach, which include :
1. Formatted: Indent: Left: 0.39", Hanging: 0.39",
A unique pair of translators is needed for every version of every
combination of CAD/CAM systems available in the marketplace. Bulleted + Level: 1 + Aligned at: 0" + Tab after: 0.1" +
Indent at: 0.1", Tab stops: Not at 0.1" + 0.5"
2. The user is dependent on software vendors to maintain this almost infinite
combination of version applications.
3. The maintenance of all these combinations of transfer capabilities is costly,
and that cost is ultimately passed on to the user.
4. As a general rule, these translators passed low-quality solid geometry that
was not adequate for driving NC operations without the CAD/CAM user
having to aid the transfer process by doing a lot of geometry clean-up. Also,
no attempt was made to transfer parametric model dependencies/constraints.
As a result of these problems, most major weapons system developers and
many large-scale commercial vendors such as Boeing, Ford, and GM as well
as many CAD/CAM vendors have abandoned or are phasing out direct
translators. Rather, big business is helping to grow and is using an emerging
neutral file – an international standard approach known as ISO 10303 (also
known as STEP).
The STEP community is in the process of defining and standardizing a number of
domain-specific (mechanical or electrical) Application Protocols (AP) that will
define neutral files readable by any CAD/CAM system. These neutral files will
carry all the information needed for the development and life-cycle maintenance of
a new product. The neutral file structure will provide the much-needed
standardization of DoD’s technical data, thus enabling rapid and efficient
modification, storage, and retrieval of the technical data.
Today, all of the major CAD vendors are quick to offer the capability to import
and export STEP data files as the underlying STEP APs attain the ISO standard
acceptance level.5 Additionally, many large manufacturers who have their own
CAD modeling systems to conduct special product studies and design efforts use
STEP. The Army, for instance, has its Ballistics Research Laboratory (BRL) CAD
system, which is used for conducting ballistics studies. At present, no one
CAD/CAM vendor has the wherewithal to support all the CAD analytical
requirements of an organization as complex as DoD. There is a need to integrate
the “best” analytic point solutions together to develop the “best” affordable
weapon systems. STEP can help DoD fulfill this need.
Industry-Developed STEP Capabilities
AP-203, Configuration Control for 3D Design of Mechanical Parts and
Assemblies, provides a very robust mechanical parts product model geometry
transfer capability. This capability has been slow in coming. The solid model
capabilities and high numerical geometric precision possible in AP 203 (and all
STEP models) required many of the CAD/CAM vendors to push the technology
edge of their system’s capabilities. CAD vendor’s AP-203 geometry transfer
capability quality level is now high enough that translated solid models are readily
being used to construct NC operations driver files. AP-203, along with AP-224,
Mechanical Parts Definition for Process Planning Using Machining Features, has
had a significant cost savings impact on mechanical parts manufacturing. AP-224
defines a set of basic solids used for pick-and-place composite solid model
structuring, which greatly facilitated parts design and generative process planning
(GPP). GPP uses the underlying basic solid shapes of the composite solid to
conduct extensive cost-reduction trade-off analysis over the many processing
options typically available within a given machine shop.
Cost-reductions of 30 percent are fairly commonplace for GPP process planning
142 relative to the traditional variant process planning. Variant process planning
basically consists of using a process plan for a similar old part. Most old parts in CAD/CAM Data Exchange

DoD’s inventory have not been run through a GPP trade-off analysis or anything
close to its cost optimization process.
AP-203 and AP-224 provide the necessary capability for low-cost generation of
mechanical parts CAD/CAM models and rapid transfer of the vector data among
disparate CAD/CAM systems. STEP’s transfer capabilities will result in creating
more private sector competition for manufacturing weapons systems components,
i.e., many 2nd and 3rd tier parts manufacturers will not bid on a job if the vector
data are not compatible with their CAD/CAM system. DoD needs to develop a
strategic plan for capturing this manufacturing benefit, especially for its legacy
systems where the technical data reside in a wide variety of formats if, in fact, they
exist.
A common complaint voiced in the end item management and DoD parts
manufacturing communities is that no technical data for many repair parts exist,
especially for some of those weapons systems procured via the performance
specifications method of acquisition. Engineering data tend to become a lost child
in the merger, acquisition, and business failure environment of the private sector
economy. It is costly to reengineer a part, but that is the only solution remaining
once the technical data are lost. However, the combination of AP-203 and AP-224
provides a low-cost redemption option for mechanical parts.
The STEP (Standard for External Representation of Product Data) project is
supported by the ISO workgroup TC 184/SC4. it is also sometimes called Standard
for Exchange of Product Definition Data. It is an effort by this group to develop an
international standard for representing product model and a data exchange is a
series of standards intended to provide a common mechanism for representing
product model data throughout the life-cycle of a product independent of any
application software that may be used to process it. The basic principles of STEP
are shown in Figure 7.16. The figure shows a computer-integrated manufacturing
system where CAD data is tightly coupled via the STEP interface to the main
production activities such as CAP, PP and C, CAM and CAQ. STEP will be
replacing the most of the standards developed so far above. The series of standards
in STEP provide a neutral representation of product model data in the form of a set
of integrated resources that support a complete and unambiguous definition of a
product. The resource constructs are documented in a single product data language
definition as discussed in Mason (1991).
There are five components in the STEP standard.
(i) The first component discusses the purpose of the standard. It contains :
1.(a) an overview describing the fundamentals of the entire standard, Formatted: Indent: Left: 0.79", Hanging: 0.39",
Numbered + Level: 1 + Numbering Style: a, b, c, … +
1.(b) EXPRESS which is a formal language for specifying the information
Start at: 1 + Alignment: Left + Aligned at: 0.79" + Tab
structures which are needed for defining the product model of STEP. after: 1.04" + Indent at: 1.04", Tab stops: Not at 0.5" +
1.(c) Framework for product modeling in which the basic methods of 1.04"
modeling are described.
(ii) The second component defined standards for the implementation of STEP. It
contains :
(a) Physical file implementations which define the rules according to
which the data structures defined in EXPRESS are mapped on a
segmental data file.
1.(iii) The third component specifies the framework for conformance testing. This Formatted: Indent: Left: 0.39", Hanging: 0.39",
segment defines the rules according to which an implementation is tested for Numbered + Level: 1 + Numbering Style: i, ii, iii, … +
standard conformity. Start at: 1 + Alignment: Left + Aligned at: 0.39" + Tab
after: 0.89" + Indent at: 0.89", Tab stops: Not at 0.5" +
1.(iv) This component includes standards for product modeling (Figure 7.16). The 0.89"
models include : 143
Computer Aided Design 1.(a) A presentation model which defines the type of presentation of Indent: Hanging: 0.36", Numbered + Level:
Formatted:
2 + Numbering
information. For instance how the product can be visualized on a CRT Style: a, b, c, … + Start at: 1 +
Alignment:
or paper. Features like colour, illumination, text font, view anglesLeft
and+ Aligned at: 0.89" + Tab after: 1.14" +
so on are determined here, see Figure 7.16(a). Indent at: 1.14", Tab stops: Not at 1"

1.(b) Materials model: is where the characteristics of material can be

described. For instance an elasticity matrix, material-specific
coefficients such as a coefficient of expansion, thermal conductivity,
heat transfer are specified, see Figure 7.16(b).
1.(c) Tolerance model describes dimensional tolerances, geometric
tolerances, from tolerances and so on, as shown in Figure 7.16(c).
1.(d) Surface model describes the specification for surface finish required,
as in Figure 7.16(d).
1.(e) Form-feature model describes the object from the point of view of
manufacturability whereby the form pattern is described or a method
to produce the form element. The manufacturing relevant features can
include holes, threads, keywords and so on, as shown in
Figure 7.16(e).
1.(f) Shape representation model is based on the elements of geometry and
topology model. There are three methods of object representation
specified; the wireframe, surface, and volume models. In the volume
we can have constructive solid geometry, and boundary representation.
The concept in these models is the formation of a neutral shell over the
basics elements of the topology model. The intention of this concept is
the separation of the operation models from the topology models as in
Figure 7.16(f).

Figure 7.16 : Models of STEP Scanned Image ????

(g) Topology model defines the entities for description of neighbourhood
144 relations. Surfaces, edges and vertices are defined. These topological
 features are described by association with corresponding geometric CAD/CAM Data Exchange

elements as seen in Figure 7.16(g).

(h) Geometry model contains all geometric information about the
definition of lines, and surfaces. By specific entity structures, points,
vectors, coordinate systems, transformations, curves and surfaces can
be described. Free-form surfaces can be approximated to computable
forms. All known mathematical forms are considered as shown in
Figure 7.16(h).
(v) Standard for the specific standard technical areas. These norms are based on
previously described models. Typical categories of these norms are:
1.(a) drafting, which describes the data type and structures for the layout Formatted: Indent: Left: 0.79", Hanging: 0.39",
the drawing and the presentation of technical objects. Various views, Numbered + Level: 1 + Numbering Style: a, b, c, … +
cross-sections, as well as dimensioning are captured. Start at: 1 + Alignment: Left + Aligned at: 0.79" + Tab
1.(b) product structure configuration management defines data structure, after: 1.04" + Indent at: 1.04", Tab stops: Not at 0.5" +
1.04"
makes possible the administration and the comparison of specified
various product versions. From this data structure of the partial model,
the bill of material and the product structure can be derived.
1.(c) finite element analysis which is represented by the partial model
analysis application.
1.(d) Kinematics where information for gears and robots is kept.
For ship building and building construction, the partial model architecture,
engineering, engineering construction are described.
(vi) Application protocols, which are used to give the user a certain amount of
freedom, are still left open in the above standards. The application protocols
are the final references to abide by :
1. Version 1 of STEP; Exchange of CAD drawings. Formatted: Indent: Left: 0.79", Hanging: 0.39",
Bulleted + Level: 1 + Aligned at: 0" + Tab after: 0.1" +
2. Version 2 of STEP; Exchange of drawing from 3-D product model.
Indent at: 0.1", Tab stops: Not at 0.1" + 0.5"
3. Version 3 of STEP; Exchange configuration controlled 3-D product
definition.
4. Version 4 of STEP; Exchange of b-Rep models.
In principle, the STEP development is done in three phases. In the first phase, an
application-oriented information structure is provided. This structure is also called
the application model; and is referred to as the application layer.
In the second phase, an information structure is provided by which all application
models can be described with the help of the language EXPRESS. This phase is
called the logical layer, and its output includes the information, objects, entities,
attributes, associations and conditions.
In the third phase, the physical layer, the data formats and data files are defined in
the Bachus-Naur-Form of the Wirth-Syntax Notation (WSN). The latter is a
common language known in computer science for describing compilers.
Box 4
STEP in the 21st Century
Evolutionary CAD applications supporting design can be categorized into three types – traditional,
knowledge based, and immersive. The present day traditional CAD system grew out of a need to
automate drafting. These systems provide comprehensive tools for generating geometric forms,
which encourages designers to come up with a form first and think about function later (i.e.,
form-to-function transformation). Knowledge-based tools that help a designer think in terms of
function are now starting to evolve. In this paradigm, form results from function (i.e.,
function-to-form transformation). In immersive CAD applications, the human being becomes part
of the design by using various immersive interfaces, including visual, speech, and haptic (special
mechanical gloves, boots, etc.) devices. This evolutionary CAD development path will make great
strides toward design optimization. 145
Computer Aided Design Interoperability among these evolving CAD systems, however, will continue to be an issue in our
competitive free market environment that rapidly generates proprietary solutions. But, the most
significant contribution STEP will provide is a bridge between the old and the new. Knowledge-
based design tools concentrate on the generation of a symbolic structure, using various types of
objects and relationships. Mapping from this symbolic structure to traditional CAD requires
appropriate interface specifications. Immersive CAD systems generate certain process constraints
such as trajectory and assembly mating constraints. The interface between immersive CAD and
traditional CAD systems requires extensions to AP 203 and other STEP standards.

7.4 THE UPR ARCHITECTURE

In this section, we provide a very general description of a novel architecture for complete
CAD data exchange, called the Universal Product Representation (UPR).
7.4.1 A Star Architecture
To ensure economic feasibility, we, like previous DE architectures, use a star
architecture. Each CAD system interfaces with a central data repository through export
and import modules (Figure 7.17). Unlike previous approaches, this does not mean that
we enforce an identical data model on all participating systems.
7.4.2 Universal Support of Data Types
To address inherent functional incompatibilities, we take the exact opposite route to the
‘least common denominator’ approach of previous solutions : the UPR data structures are
flexibly designed to support all possible data types; they can represent the union of the
data types supported by CAD systems, not only their intersection.
7.4.3 Data Unification
To optimize the UPR data structures, during design we study the semantics of each data
type of the supported CAD systems and identify data types that are of similar semantics.
Initial semantics assumptions are made according to the CAD system’s user guide, and
are modified after extensive empirical usage of the CAD system by experienced users.
Data types that are finally considered similar share data structures.
Data unification is only an optimization. When data types are incompatible, they are not
unified and are handled through rewrites (see below). This stands in sharp contrast to
previous methods, in which each and every data type is ‘unified’ by adopting a ‘standard’
definition.

Data Item Data Item

Verification Verification
datadata
Unified dataA
Rewrite Other
rewrites
UPR Import Flow

Export Import
UPR Architecture
CAD system CAD system

Figure 7.17 : For Each Data Item, the UPR Architecture Stores Import Flow
Rewrites and Verification Data May need to redraw this???
As a simple example, take the very common case of CAD systems using different terms
to denote semantically identical operations (e.g., 2-D Sketch and 2-D Section, Round and
146
Fillet). In this case unification simply amounts to selecting one of these terms and storing CAD/CAM Data Exchange

the data under its title. Another simple example is given by a ‘triangle’ object represented
by three vertices: one system may use a clockwise orientation while another may use a
counter-clockwise one. The UPR would arbitrarily select one of these options; import
procedures would employ the appropriate orientation. In practice, data unification
requires unifying data structures that are not formally mathematically equivalent. For
example, as mentioned above, almost all of the design features provided by CAD systems
are not formally specified. While their ‘ordinary’ semantics may possibly be understood
and expressed formally, their behaviour under various configurations is in many cases
hard to define. Nonetheless, we may allow their unification provided that their
‘inordinary’ behaviour occurs in a small number of cases, and relying on the rewrite
mechanism (see below) to handle these cases. Data unification serves to reduce the
number of disparate data types in the UPR. The exact magnitude of this reduction
depends on the functional similarities between the CAD systems and on the degree of
practical compromising exhibited by the UPR designer. Since almost all modern CAD
systems are based on the same fundamental paradigm and generally provide similar
functionality to their users, data unification can be expected to produce effective results.
7.4.4 Rewrites and Import Flow
As emphasized above, a major guideline of the UPR is addressing functional and
implementational incompatibilities. We answer this design goal by the concept of a
rewrite of a data item as another data item. A data item rewrite is used during import, in
two cases : (1) when the target CAD system does not have a compatible data type, and
(2) when import has failed for some reason. The implied import low is: if you do not
succeed (for any reason) in importing the unified data item into a CAD system, rewrite it
and try again.
A set of data type rewrites is attached to any unified type (Figure 7.17). Rewrites usually
modify the data itself, but they may also be purely functional, representing a different
algorithm for importing the same data. When a rewrite modifies the data, the data type
conversion is quite possibly, but not always, semantically lossy.
There are many situations where data type rewrites are highly applicable in the CAD
domain. The main example involves loss of associativity in some form. As an example
take the common ‘Extrusion’ parametric feature. The Extrusion operation takes a 2-D set
and extrudes it in 3-D space according to a given axis and a given size. The Extrusion
feature usually offers many different parameters. Two useful parameters are related to the
extrusion size: the size can be given explicitly as a distance (this is sometimes called a
‘blind’ extrusion), or it can be given by specifying the extrusion to end when the extruded
2-D set meets a certain geometric entity already present in the model (say, a Brep face of
the solid model). This latter usage is termed ‘associative’ because the extrusion size is
automatically modified when the geometric location of the target entity is modified.
Suppose now that the unified data type representing the Extrusion operation contains a
‘target entity’ parameter. Suppose further that this capability is lacking in some CAD
system. A data rewrite of the unified Extrusion can be defined by replacing the ‘target
entity’ parameter by an ‘absolute size’ parameter. In effect, an ‘Associative Extrusion’
data type is converted into a ‘Blind Extrusion’ data type. Such a conversion makes sense
from a data exchange perspective when the two operations are expected to possess
similar geometric semantics (that is, when the geometric changes performed on the model
is identical).
In many cases, there exists a natural hierarchy of data rewrites. In the Extrusion example
above, the rewrite into a blind extrusion is not the last one that can be attempted. If a
blind extrusion does not succeed, it can be rewritten into a ‘glue faces’ operation. This
operation can be implemented by computing the set of faces generated by the original
feature (in this case, if the associative extrusion and the blind extrusion generate an
equivalent set of faces) and gluing them into the model. This rewrite is possible when the
target CAD system supports a ‘glue faces’ operation.
Note that in the two given examples, an actual execution of the rewrite requires data that
is not necessarily exported into the unified data type. In the first example, we would need 147
Computer Aided Design the length of the extrusion, and in the second example the set of faces generated by the
extrusion. There are three main alternatives for dealing with such data: it can be
computed during export, requested during run-time from the CAD system from which the
data had been exported, or computed during import. The last alternative is usually not
feasible, because the data usually depends on internal implementation in the source CAD
system. The first alternative is the most general but also the most demanding in terms of
export efficiency and storage size. The second alternative is the most flexible but it
requires access to the source CAD system during import into the target CAD system,
which complicates the operating environment of the architecture as well as possibly
increasing its cost due to the additional CAD licenses required.
The rewrite hierarchy is not fixed. It may be the case that a user would prefer a particular
rewrite for one project and a different one for another project. In this case the sequence of
rewrites that are attempted at runtime can be determined by configuration data that can be
specified by users prior to the execution of the data exchange operation. Note that
rewrites enable a direct interface between pairs of CAD systems when this is of
advantage, even though the architecture itself is a star one. In order to provide such a
direct interface, all we need is to add a ‘source target CAD pair’ field to the rewrite.
When the import flow mechanism is faced with the need to select a rewrite, it can try to
first identify the presence of a relevant field of this sort, and invoke the corresponding
rewrite before the invocation of other rewrites. Such a capability might be useful for
optimization purposes or for unique requirements of a particular project.
7.4.5 Dynamic Import Verification
In order to be able to implement the outlined import flow, which involves iterative
attempts of data rewrites and renewed imports, it is essential to be able to recognize
import failures. Each data type stored in the UPR, including the unified data types and all
of their rewrites, need to have success verification mechanisms associated with them. In
some cases, success verification is only a matter of obtaining a binary answer from the
CAD system (yes or no). In most cases, however, success verification requires additional
data to be stored within the data type. For example, the success of an extrusion feature
can really only be verified by comparing the geometry generated by it in the source CAD
system with that generated by the target CAD system.
Data import verification in general, and feature verification in particular, are topics that
merit a detailed discussion which is certainly beyond the scope of this paper. For the
purposes of this paper it is sufficient to recognize that provisions for storing verification
data must be made within the UPR data structures, and that import verification is a basic
ingredient of the import flow execution. In practice, it is sometimes possible to relax
those strict verification requirements. For example, suppose that we have no rewrites for
design features and we must invoke a final geometry’ global solid rewrite whenever there
exists a single feature that does not produce accurate geometry. In this case we do not
need verification data for every feature, and it is sufficient to store verification data only
for the final, global geometry.
Note that the actual cause of failures is of implementational importance, because dealing
with CAD system bugs requires implementation mechanisms that are different from those
required by functional incompatibilities.
There are several other interfaces. Table 7.5 provides international interfaces.
Table 7. 5 : International Interface Activities
Type
Interface Application Area Country Standard Activity
Procedural Descriptive
CAD*I CAD-CAM; CAD-Divers Europe * ISO/TC184/SC4
CAD-NT CAD-CAD Germany * DIN V 4001
ESP CAD-CAD; CAD-Divers USA *
IGES CAD-CAD; CAD-Divers USA * * ANSI Y 14.26 M
148
 CAD/CAM Data Exchange
PDDI CAD-CAD USA *
PDES CAD-CAD; CAD-Divers USA * ISO/TC 184/SC4
STEP CAD-CAD; CAD-Divers France * AFNOR-Vorschi Z68-300
SET CAD-CAD; CAD-Divers International * * ISO/TC184/SC4/WG1
VDA-FS CAD-CAD; CAD-Divers Germany * DIN 66301
VDA-PS CAD-CAD Germany * * DIN 66304 (Entwurf)

SAQ 1
1.(a) Why CAD/CAM data exchange standards are required? Explain. Formatted: Numbered + Level: 1 + Numbering Style: a,
1.(b) Explain the developments in CAD/CAM that demand exchange standards. b, c, … + Start at: 1 + Alignment: Left + Aligned at:
0.39" + Tab after: 0.79" + Indent at: 0.79", Tab stops:
1.(c) What are the advantages of neutral file formats? Not at 0.5"
1.(d) Write history of CAD/CAM data exchange.
1.(e) Explain salient features of the following standards :
1.(i) IGES Formatted: Indent: Left: 0.79", Hanging: 0.39",
1.(ii) PDDI Numbered + Level: 2 + Numbering Style: i, ii, iii, … +
Start at: 1 + Alignment: Left + Aligned at: 0.89" + Tab
1.(iii) PDES after: 1.39" + Indent at: 1.39", Tab stops: Not at 1" +
1.(iv) STEP 1.39"

1.(f) Compare the above standards from the viewpoint of engineering Formatted: Numbered + Level: 1 + Numbering Style: a,
applications. b, c, … + Start at: 1 + Alignment: Left + Aligned at:
0.39" + Tab after: 0.79" + Indent at: 0.79", Tab stops:
1.(g) Discuss the salient features of STEP that applicable for transfer of
Not at 0.5"
manufacturing data bases.
1.(h) Give a brief history of STEP standard.
1.(i) Give a brief history of IGES.
1.(j) Explain the salient features of SET and CAD*I interfaces.
Activities Recommended
1.(a) The readers are requested to draw simple figures like circle, square, Formatted: Indent: Left: 0.39", Hanging: 0.39",
rectangle etc. in AutoCAD and study their IGES output files and write a note Numbered + Level: 1 + Numbering Style: a, b, c, … +
on them. Start at: 1 + Alignment: Left + Aligned at: 0.39" + Tab
after: 0.64" + Indent at: 0.64", Tab stops: Not at 0.5" +
1.(b) The students are required to draw simple 2D figures in AutoCAD and relate
0.64"
the dxF and IGES file contents and draw some
1.(c) Write a IGES file for a circle and square and read it in AutoCAD or any
CAD/CAM packages.
1.(d) Write single programs in EXPRESS language and interface them with STEP
tools.

149
Computer Aided Design

FURTHER READING
B. O. Nnaji, I (1989), “Computer Applications in Mechanical and Manufacturing
Engineering”, Kourse III, CAD : Its Role in Manufacturing.
B. Schlli, H. Grabowski, H. R. Anderi, R. and M. Schmitt (1089), “STEP – Development
of an Interface for the Exchange of Manufacturing Data”. VDI-Zeitschrift, 131(9).
IGES (1988), “Initial Graphics Exchange Specifications Version 4, Technical Report”,
National Institute of Standards and Commerce.
PDES (1985), “The Content, Plan and Schedule for the First Version of the Product Data
Exchange Specification (PDES)”, Technical Report, National Institute of Standards and
Technology.
N. N. Autumatisation Intustrielle Representation extreme des Donnees de Definition de
Products Specification du Standard.

150