A11100 RTMflOl

v

NBS

PUBLICATIONS

NBSIR 81-2297

A Technical Briefing on the Initial

Graphics Exchange Specification

(IGES)

Automated Product Technology Division

Center for Manufacturing Engineering

National Engineering Laboratory

U.S. Department of Commerce

National Bureau of Standards

Washington, DC 20234

July 1981

-QC—

100

. U56

81-2297

1981

c, 2

S. DEPARTMENT OF COMMERCE

MIONAL BUREAU OF STANDARDS

INITIAL

GRAPHICS

EXCHANGE

SPECIFICATION

NBSIR 81-2297

A TECHNICAL BRIEFING ON THE INITIAL

GRAPHICS EXCHANGE SPECIFICATION

(IGES)

national bureau

of standards

library

AUG 7 1981

not OXC - tux

Qcfoo

. US(?

no • y/'Odin

tm

t.>

J. C. Kelly, Ph.D., Sandia Labs, Co-Chairman

Robert Wolf, Xerox Corp., Co-Chairman

Philip Kennicott, Ph.d., General Electric

Roger N. Nagel, Ph.D., International Harvester

Joan Wellington, Editor, National Bureau of Standards

Automated Product Technology Division

Center for Manufacturing Engineering

National Engineering Laboratory

U S. Department of Commerce

National Bureau of Standards

Washington, DC 20234

July 1981

U.S. DEPARTMENT OF COMMERCE, Malcolm Baldrige, Secretary

NATIONAL BUREAU OF STANDARDS, Ernest Ambler, Director

A

TECHNICAL BRIEFING

on

THE INITIAL GRAPHICS EXCHANGE SPECIFICATION (IGES)

Introduction

This technical briefing is composed of two parts. Part 1

consists of a set of slides* and some associated text. The

slides and the text are organized in tandem. The intent of the

text is to furnish associated information (for each slide) as opposed to furnishing specific text that is to be read verbatim.

The information in this section is ‘'soft*'* that is* not overly

technnical. In this Part the suggested slides for each section

follow the first page of the text of the section.

Part 2 consists of the more technical material. Here the

intent is to furnish text that can be read verbatim for each

slide. In this Part the suggested text follows each slide.

There is minimal overlap between the two sections.

A

TECHNICAL BRIEFING

on

THE INITIAL GRAPHICS EXCHANGE SPECIFICATION (IGES)

J. C. Kelly# Ph. D. . Sandia Labs# Co-chairman

Robert Wolf# Xerox Corp. » Co-chairman

Philip Kennicott# Ph. D. # General Electric

Roger N. Nagel# Ph. I). # International Harvester

Joan Wellington# National Bureau of Standards# Editor

77s, HIE OF CONTENTS

Page

Part 1

I. Introduction to IGES 1

1. 1 Overview 1

1.2 A typical scenario of development of user need

for IGES 14

1. 3 Cross-translation# the focal point of IGES 20

1.4 Preset goals for the* IGES Specification 25

1.5 Brief history# present committee structure of IGES 27

II. IGES Related to the Technology of Product Definition 35

2. 1 The technology of product definition 35

2. 2 IGES related to the present technology

of product definition 40

2. 3 IGES related to the hierarchy of the geometry

of product definition

2. 4 IGES related to the standards technology

Por product definition 51

Appendix A 57

Appendix B 58

Part 2 59

.

.

,

.

.

.

.

I. Introduction To IGES

1. 1 Overview

The In itial Graphic

communic at i on file str

Computer-ai ded Design an

systems in widespread u as a rec ep t acle for the

avai lab 1 e interactive

intended th at this struc

automatc interchange

transfer of data to and

for the arc hiving of the

s Exchange Specificati

ucture for data produc

d Computer-aided Manufa

se today. It haa been

data generated by toda

graphics deaign-draf t in

ture provide a common

of data between these

from external applicati

data.

on (IGES) ia a

ed on and used by

cturing (CAD/CAM)

designed to serve

y ' s commercially

g systems. It ia

basis for the

systems* for the

on programs* and

IGES represents an initial* organized attempt to address

and resolve the interface problems that arise as a result of the

introduction of the computer into the design and manufacturing

environment. The interface problems may have their origins in

either hardware or software* and* roughly speaking* can be

character i zed by the fact that the data as produced by one

system (or subsystem) is not able to be used by another system

(or subsystem). It is the common experience of many users that

the resolution of the interface problems associated with the

creating* transmi tt ing* storing* and retrieving of

computer-generated data is necessary in order that the full

potential of the computer for increased productivity be

rea 1 i z ed.

Several large companies have expended significant resources

in individual attempts to resolve their own internal interface

problems. Thus* translators have been written so that data can

be communicated from system to system. Subsequently* some

companies felt the need to devise standard data structures and

formats in order to curtail the resulting proliferation of

translators. It is also the common experience of these

companies that the translators were expensive to develop*

expensive to maintain* and achieved only limited efficiency.

These individual attempts at resolving interface problems

have emphasized the lack of any appropriate standardized

specification for a communication format for data exchange* and

they have also emphasized the need for some such specification.

Furthermore* with the increasing variety of vendors* and the

present acquisition rate of CAD/CAM systems by both government

and private organizations, the need will continue

IGES is an attempt to address this need,

an organized effort on a national level to

specifications where none presently exists

Thus IGES

introduce

to exist,

r epr esents

a set of

1
Initial

Graphics

Exchange

Specification - 1GES -

' IGES

A Project

of the

Air Force

ICAiVi Program
Funding Provided By Air Force, Army,

Navy, and NASA. Coordinated Through

ICAM Office

Contract To National Bureau of

Standards For Direction and Coordination
4 .

Interface Areas:

1. Between Different Interactive Graphics

Design-Drafting Systems — Different Suppliers — Same Supplier, Different Versions

2. Between Interactive Graphics DesignDrafting Systems + Externa! Applications Programs

3. Between Interactive Graphics DesignDrafting Systems and Archival Storage

The EGES Goal:

Resolve The Interface Problems

To Provide

1. Increased Productivity

2. Increased Flexibility
Heretofore —

Isolated, Individual Company

Attempts To

Resolve Interface Problems

1. Write processors (translators)

2. Develop local standards

Shortfalls Of Isolated Attempts — Company Viewpoint

1. Expensive to Develop

2. Expensive to Maintain

3. Limited Efficiency

7 .
Shortfalls Of Isolated Attempts

1. Duplication Of Effort

2. isolation Still Exists —

Now On Company Level

3. Lack Of Forum For

Convergence Of Ideas

SGES Provides

1. An Initial Framework

Where None Presently Exists

2. An Organized Attempt

On A IMaiional Level

3. A Forum For Convergence

Of Ideas

8 .
IGES Accomplishments

1. Produced A Set of Specifications

2. Embarked On A Schedule For

Testing, Benchmarking, Implementation

3. Initiated Efforts Toward Becoming

An American National Standard

4. Filled Over 1000 Requests For The

Set Of Specifications

IGES

Is Rapidly Becoming

Accepted As A

DeFacto Standard
Basis Of User Interest In IGES

1. Resolve interface problems

associated with creating, transmitting, using, and storing of

computer-generated product definition data

2. Provide insulation from supplier

revisions

Indications Of User Commitment

To IGES

1. Number and variety of organizations on

IGES committees

2. Many written declarations of support for

development and success of IGES

3. Users are beginning to specify IGES compliance in procurement specifications

xo.
Companies Having a Representative

on At Least One IGES Committee

Advanced Technology, Inc.

Applicon

Auto-trol

Aydin Controls

Bechtel

Bendix

Boeing

CALMA

CAM-1

Combustion Engineering, Inc.

Computervision

Control Data

DMT Corporation

DuPont

Evans and Sutherland

Ford

General Dynamics

General Electric

General Motors

Gerber

Harry Diamond Labs

Holquin and Assoc.

Hughes

IBM

International Harvester

John Deere

Manufacturing Data Systems, Inc.

Martin Marietta

McDonnell Douglas Automation Co.

NASA

National Bureau of Standards

National Computer Systems

Ocean Data Systems

Racal Redac

Rockwell International

Sandia Labs

Society of Manufacturing Engineers

Structural Dynamics Research Corp.

Time Engineering

Union Carbide

U.S. Air Force

U.S. Army

U.S. Navy

Vought

Westinghouse

Xerox

11 .
Basis of Supplier Interest

In IGES

1. IGES provides a recognized,

common receptacle for getting

data out of their own system

2. It is good business— customers

w&nt the IGES type capability

Indications Of Supplier

Commitment To IGES

1. Written and oral declarations of

commitment at the managerial

level from several suppliers

2. Detailed technical design

meetings scheduled between

IGES and participating suppliers

12 .
An IGES Self-Assessment

. . IGES is not perfect, it will not

solve all the information needs of

CAD/CAM systems, and it will need

further extension beyond its current

definition. However, IGES goes a long

way toward alleviating the current data

exchange problems, and is a significant response to today's needs."

13 .
The IGES effort has thus far produced a published set of

specifications tuithin the time frame which was originally laid

down# and it has embarked on an implementation# testing# and

benchmarking schedule. [See Reference 81 It has attracted

national attention. CSee Reference 101 The IGES mailing list

now contains over one thousand names. There is currently

underway an effort having to do with IGES becoming an American

National Standard. In actual fact# it is rapidly becoming a de

facto national standard

It is important that both users and suppliers of CAD/CAM

systems have a legitimate basis of interest in the development

and ultimate success of IGES. It is also important that both

users and suppliers make commitments to the development of IGES.

At the present time# there is ‘ evidence that such commitments

have been made.

It is also important to note that IGES is not being billed

by itself or by anyone else as the answer to all database

exchange problems that currently exist. Hopefully# IGES will

succeed on the basis of its demonstrated merits# or fail for

lack of same. The following self-assessment statement concludes

the Introduction of the IGES report: "In summary# IGES is not

perfect# it will not solve all the information needs of CAD/CAM

systems# and it will need further extension beyond its current

definition. However# IGES goes a long way toward alleviating

the current data exchange problems# and is a significant

response to today's needs."

1. 2 A typical scenario of development of user need for IGES

Historically, the interface problems have become apparent - and

acute - in parallel with the introduction of commercially

available interactive graphics design-drafting systems.

Interface problems associated with these systems have continued

unabated to the present day# and these systems constitute the

focal point of the IGES effort.

For example# the first acquisition for many companies was

the procurement of an interactive graphics drafting system.

This self-contained system brought about significant improvement

over manual drafting. The next acquisition was usually the

addition of a high speed plotter# possibly from a different

supplier. This acquisition brought about further improvements

in productivity# but it also brought about a new concern - the

interface compatibility of the two systems. Further procurement

of new generation drafting systems# again possibly from

different suppliers# gave extended capability but also

additional compatibility problems.

Increased sophistication of the commercially available

14 .
A Typical Scenario

. Of Development

Of User Need • For

IGES

15 .
I

1

j Applications

j

i Software i

i

16
j >

I IGDS ) \ /L \ /

^

/\

VA\\V\

N

\ /v

17 .
18 .
For Bidirectional Communication

Between N Centrally

Connected Systems

1- 2N Interfaces Will Suffice"

2.

An Additional System

Necessitates Only 2 New Interfaces

A Summary Of Typical Interface

Problems involving Interactive

Graphics Design-Drafting Systems

1. Hardcopy-postprocessing— COM, plotters, etc.

2. Mainframe-based applications— Mass Properties,

other Involved Analyses

3. Other Design-Drafting Systems— CrossTranslation

4. Mainframe Storage

5. Manufacturing data— NC data, routing data

19 .
sy stems

process#

interf ac

systems#

systems.

brought about an evolution of their role in the design

and with that came more interface ' problems:

ing internal applicationa-specif ic software to these

now aptly described as general purpose design-drafting

Orowth in the size of the company user base for these

systems resulted in further interface problems# as other

divisions made their procurements. Increased user

sophistication resulted in the formation of large central

databases# and this led to still another interface area - the

interface between a commercial system and the database.

Reflected here was a basic change in the user view of these

systems. Instead of being viewed strictly as a self-contained

unit# they could be given the added role of an interactive

communication tool between a user and a database.

Progr

developmen

formats f

efforts m

provided n external

single# re

CAD/CAM sy

essions of events such

t of sy stem-t ©-system

or internal comrounicat

ight possibly have be

o help in dealing with

interfaces. What was

cognized structure for c stems.

as these led

translators and

ion. However#

en locally ben

either actual

needed# and i oimuni cation of

to the local

standard data

while these

eficial# they

or potential

s needed# is a

data between

1. 3 Cross- translation# the focal point of XGES

The competitiveness and the

world in which we live accounts

effort. This is cross-transla

between interactive graphics

different brand name. From the c user# progress in this interfac

to be made. From the competitive

progress in this area would open

This interface area is the

certainly# this is the one

barometer for the success

expectation - is that IGES b

of the structure of the databa

being able to accommodate only

pen position information. In

type of information was decl

be inadequate because it did n

The motivitation behind str

structure as possible is that#

should be usable on a par with

diversity that exist in the

for the focal point of the IGES

tion* or# database exchange

design-draf ting systems of

ompetitive point of view of the

e area would allow the best buy

point of view of the supplier#

potential new markets.

most demanding one. Almost

which will serve as the primary

of IGES. The need - and the

e able to accommodate th» exchange

ses in question# as opposed to

the exchange of the equivalent of

fact# the exchange of this latter

ared at the very outset of IGES to

ot constitute database exchange,

iving for the exchange of as much

following an exchange# the data

what it was when it was created.

IGES pre- and post-processors comprise the ingredients for

20
IGES Contents

Entities— The Basic IGES

Units of Information

1. Geometry Entities

2. Annotation Entities

3. Structure Entities

21 .
Cross-Translation

Between Interactive Graphics Design-Drafting Systems

(Entities)

Pre

Entities

Post

>-{ Entities)

SGES Design Goafs for the

Cross-Translation Application

1. Basic database information,

including complex structures and

relationships, be exchanged.

2. Following exchange, the data

should be usable on a par with

what it was when it was created

22 .
Basis of User Interest In

Cross-Translation

1. User presently owns more than

one type of system

2. User wishes more supplier independence in the future

3. User wishes to accommodate

his customers by providing data

in the form they wish to see it.

Basis of Supplier Attitudes

Toward Cross-Translation

1. Pro— Opens Up Potential New

Markets

2. Con—Tends to Decrease

Individuality

23 .
The IGES Role in Cross-Translation

1. Consider, react, advise, concerning entity

associations specified by suppliers

2. Provide forum between users and

suppliers

3. Facilitate future demonstration of capability in this area

24 .
the cross-tranalat ion application. In the IGES scheme# each

partic ipating supplier of an interactive graphics

desi gn-draf t ing system will implement processors between his own

system and the communication file. Thus supplier commitment and

involvement are crucial to the IGES effort.

A pre-processor is a software module designe

information structured according to a specific

translate it into the communication file

post-proc essor accepts information structured acc

communication file format# and translates it into

system format. For example# in transferring inf

system A to system B# the pre-processor lies betwe

and the communication file# and the post-processor

the communication file and system B.

d to accept

format# and

format. A

ording to the

a specific

ormation from

en system A

lies between

The first generation of IGES processors will rely on fixed#

predetermined entity associations in both the pre- and the

post-processors.

The general role that IGES will play in thi

that of coordinator between users and suppliers,

to involve itself in discussions in an effor

react# and advise concerning the entity associ

by suppliers. IGES will try to promote understa

seek to develop concensus# but will not be

legalisms# or in certification situations su

whether or not a given supplier "meets" IGES.

s area will be

IGES will seek

t to consider#

at ions specified

nd ing# and will

come involved in

ch as dec i d ing

1.4 Preset goals for the IGES Specif ications*

Work toward producing the present set of IGES

specif ications began on October 11# 1979. On that day# the IGES

Technical Committee was formed# and commissioned to produce a

set of specifications. This Committee was chaired by Dr. Roger

Nagel of the National Bureau of Standards# and contained as

members Walt Braithwaite of Boeing# and Dr. Phillip Kennicott

of General Electric. Because of the immediacy of the need# the

driving force of this Committee was to publish a set of

specifications by early 1980. Three months of intensive effort

resulted in the presently available set of specifications being

put in the mail in late January.

Other goals influenced the IGES development. These were

1. Completeness - The format had to allow communication of

* As evidence of the fact that acronyms do indeed assume a

life of their own after a while# the phrase "IGES

Specifications" will continue to be used in spite of the

redundancy involved.

25
Preset Goals for the

IGES Specifications

The Overriding goal — Published

Early 1S80

Others

1. Completeness

2. Extensibility

3. Processor

Compatability

4. Responsive to

Community Input

IGES Technical Committee

1. Roger Nagel, Ph.D.,

National Bureau of Standards

2. Walt Braithwaite, M.S.,

Boeing Commercial Airplane Co.

3. Philip Kennicott, Ph.D.,

General Electric Co.

26 .
basic geometrical* annotation* and structural entities

(an entity is the basic unit of information in IGES. )

2. Extensibility - The format had to allow the

communication of material defined after IGES was

published.

3. Processor compatibility - The format was not to demand

a quantum jump in the state of the pre- and

post-processor art.

4. The format was to be based on as much input as possible

from the interested community.

1. 5 Brief history* present committee structure of IGES

The idea to create a graphics exchange specification as an

immediate step in the solution of the data exchange problem

first surfaced at the DOD/MTAG* meeting in Detroit in September*

1979. The CAD/CAM workshop at that meeting recommended that a

meeting be held within thirty days to formulate a set of

exchange spec if ications for publication early in 1980. As a

result of that recommendation* a meeting was convened by the Air

Force* Army* Navy* NASA* and NBS at the National Academy of

Sciences on October 11* 1979.

The October 11 meeting was used as a forum for a discussion

of the IGES concept. Presentations were made by suppliers*

corporate system designers* and standards groups concerning

their respective efforts to address data exchange problems.

Various offers were advanced as to which existing specifications

could be made available in order to assist in the development of

the IGES set of exchange specifications.

It was decided to use the Boeing CAD/CAM Integrated

Information Network (CIIN) standard format as the basis on which

to define the exchange specifications. This was done because

that system had been in use for several years and was known to

work. (As a result* the IGES structure is similar to that of

CIIN. However* IGES is not purely a CIIN derivative. Many of

the features presently in IGES were not in CIIN. ) Information

stemming from General Electric's work on a Neutral Data Base was

used as a source of advanced concepts* as were numerous other

formats provided to the Technical Committee. [References 3 and

4 pertain to CIIN* Reference 7 pertains to the General Electric

Neutral Data Base. 3 The upcoming effort was officially dubbed as IGES* and the

* Department of Defense Manufac tur ing Technology Advisory

Group
!GES ri/siSsstones

September, — DOD/MTAG Workshop Session

1979 On CAD/CAM Interaction

October — Boeing CHINS System Offered As

Basis for !GES

• _ — Technical Committee Established — Work Began for Jan. 1, 1930

Publication of Specifications

28 .
November — First Input Meeting;

Suppliers, Corporate

Systems Personnel

December — Second Input Meeting;

Interested Public

January, 1280 — Publication of

Specifications

February — IGES Committee Structure

Set Up

March — Early Thoughts on Testing,

Benchmarking, Demonstration

May — IGES Adopted by ANSI Subcommittee Y14.23 to be Part of Proposed

American National Standard

June — Detailed Technical Design

Meetings Between IGES and Participating Suppliers

29 .
IGES Committee Structure

Bradford Smith

National Bureau of Standards

IGES Chairman

30.
o3

CO C/>

LU 0 O G> , c{n( EEoO

</)

GQ o

CC

KJJ

LU

h-

(/)

31 .
The Near-Term IGES Schedule

1. June — Detailed technical

meetings with participating suppliers concerning entity mappings.

2. September —Tapes containing

IGES descriptions of individual

entities

The Longer-Term IGES

Schedule

1. Summer, Fall, 1980—Suppliers

continue processor implementation work

2. Public demonstration of

cross-translation capability

32 .
Technical Committee was formed to produce the speci

IGE8 is officially a project of the Air Force

Computer-Aided Manufacturing (ICAM) Program. It ia au

funda from the Air Force* Army* Navy* and NASA*

coordinated through the Air Force ICAM office. (It

emphasized that this funding has gone only to th

Bureau of Standards for directing and coordinating

work. The considerable part ic ipation by Boeing and

Electric* by means of the Technical Committee* was

and the cost was b.orne by these two organi zat ions. )

f ications.

Integrated

pported by

which are

should be

e National

the IGES

by General

voluntary*

Two public meetings were held while the specifications were

being drawn up. The first* on November 20 in Schenectady* NY*

was for suppliers and corporate systems personnel. The second*

on December 14 in Washington* was for the interested public. In

each case* opportunity was provided for reaction to what existed

at that time* and for suggestion and criticism.

The IGES specifications were published in January* 1980.

In May* these specifications were recommended by American

National Standards Institute (ANSI) Subcommittee Y14. 26 to be

part of a proposed American National Standard. (See Section

2. 4 ) Publication of the IGES Specifications marked the end of

one period in the IGES effort* and the beginning of another.

With publication* the Technical Committee ceased to exist. New

committees were then formed whose concerns reflect the fact that

IGES is moving toward being used.

The two standing IGES committees are the Steering Committee

and the Working Committee. The Steering Committee is a management advisory group. Its function is to see that IGES is

promoted* accepted* and used. The Working Committee is the

umbrella technical committee* and serves as the focal point for

technical information exchange. It has several subcommittees*

each of which performs a specific technical task. It will also

be concerned with carrying out the directives of the Steering

Committee.

At its first meeting*

Committee requested that other

Management Briefing Committee

material for a scripted slide

be of interest to management.

in January* 1980* the Steering

committees be formed. One is the

This Committee will prepare

presentation on IGES* tailored to

The Steering Committee also requested

Test* Evaluate* and Support Committee,

committee is to provide cohesion to

determining and supplying what is needed

by way of technical support. One present

formulation of test* benchmark* and impl

For example* in initial meetings of this

the formation of a The function of this

IGES activities by

in the IGES community

concern is with the

ementation procedures,

committee* discussion

33 .
involved the idea of a phased implementation for IGES. This led

to a grouping of the IGES entities into two exhaustive subsets.

One subset is intended to form a useful set of entities for

mechanical app 1 ications* the other for electrical applications.

(There are no present plans for identifying rigid* well-defined

subsets of IGES* with the thought in mind that a supplier would

implement all of a certain portion* and would then be justified

he "meets" that portion. There is instead

the marketplace will dictate what phased

take place. Thus the two subsets mentioned

more in the spirit of attempting to establish

in proclaiming that

the attitude that

implementation will

above are offered

concensus than to establish any type of official designation. > There has been discussion in the Test* Evaluate* and

Support Committee to the effect that the role of IGES in the

benchmarking procedure will be to make various "standard" IGES

tapes available. These could be applications oriented* and

possibly graded in sophistication in some manner. Users could

then make use of these tapes as they chose* to assist them in

their decision making in their dealings with suppliers. Several

companies have volunteered to make sample parts available for

use in these tapes. Also* definitive current plans call for the

production of tapes containing IGES descriptions of individual

instances of some of the basic geometry and annotation entities.

The Test* Evaluate*

in IGES providing a suppliers* and between

this committee will

suppliers in order to discuss entity mapping sc IGES. The Committee will then consider pairs o and anticipate potential cross-translat ion prob

schemes put forth* and will provide feedback to

and Support Committee

forum for coordination

suppliers themselves,

meet individually wi

has a direct role

between users and

In particular*

th participating

hemes to and from

f schemes* to try

lems based on the

the suppliers.

For an initial public demonstration of the IGES concept and

capab i 1 i t ies* a sample mechanical part has been agreed upon in

order that suppliers may work toward being able to accept and

produce an IGES description of it. (See Appendix B) No date has

been fixed for a d emonstration.

An Extensions and Repairs Committee has been set up within

the Working Committee. This committee is concerned with finding

and repairing errors and ambiguities in the specifications document* and with clarifying ports of the manual that prove difficult to understand. For extensions* the concern is not with the

addition of new entities of IGES. Rather* the concern is with

such things as the definition of new standard properties and assoc iat ivi ties* and with possible macros. In fact* concern thus

far has been with these things for the area of electrical design.

standard assoc iot ivi ties is further explained in the

the assoc iati vi ty instance entity. ) (The idea of

material for

34 .
An ANSI Coordination Committee has been formed. Future

concerns of this committee are: getting the IGES specification

into the required ANSI format# and coordinating comments

received during the ANSI review processes.

A Newsletter Committee and a Coordination Committee have

also been established. Vol. 1# No. 1# of the IGES Newsletter

was dated May# 1980. It will be published on an as-needed

basis. The Coordination Committee is a liason committee to

other interested groups and to professional societies.

A Software Library will be established for coordinating the

sharing of public domain software generated in the area

surrounding IGES.

II. IGES Related To The Technology Of Product Definition

Fundamental changes in the technology of product definition

have brought about the need for IGES. These changes may be put

in perspective by concentrating on the nature of the models used

to define the product and to communicate design intent.

2. 1 The technology of product definition

Present product definition methods reflect the

this technology is in a transition period. The

both the conventional human-oriented technology and

computer-oriented technology can currently be found.

The traditional model for product definition

human-oriented engineering drawings and associate

Over the years# the art of creating this model has r attention. The discipline of drafting methodology

to insure that design intent can be communicated in

manner according to established standards.

fact that

influence of

of the newer

consists of

d documents,

eceived much

has evolved

an orderly

At the opposite extreme lies a currently intensive research

area concerned with automated production via "integrated

systems". In particular# much attention is being focused on the

modeling of the geometry of individual components. Here the

intention is that the solid shape of a part be completely

described# by means of a software system called a geometric

modeler# in a manner capable of supporting later (automated)

processing. It is envisioned that# eventually# larger software

systems containing geometric modelers within them will have the

capability to give precise# complete representations

complicated assemblies# including all information relevant

the design and manufacture of the product# and also

of

to

all

35 .
IGES

Related To

The Technology Of

Product Definition

The Present Technology

Of

Product Definition,

36 .
Product Definition —

Involves Creation Of A Model To

1. Define the Product Itself (Geometry)

2. Communicate Design Intent

Traditional Product Definition

1. Human Oriented

2. Engineering Drawings and

Associated Documents — Configuration Data — Mathematical Tables — Fabrication Information

37 .
Future Product Definition Technology

1. Complete Computer Description Of — Product Geometry Sufficiently

Sophisticated to Support Automated

Processing — Information Necessary to Manufacture,

Inspect, Modify, etc. Product — Information Necessary to Manage These

Processes

2. Computer Description Will Accumulate From

Design Onward

Present Product Definition Technology

1. Transition State Between — Human Oriented Traditional Model — Computer Oriented Future Model

2. Today's Design-Drafting Systems Reflect Both Models — Computer Generation of Human Oriented

Traditional Model — Rudimentary Geometry Capability for Computer

Oriented Future Model

3d Wire Frame

Limited Planar, Curved Surface Capability

38 .
information necessary to effectively manage these processes.

Thus for a given product* a description will accumulate from

initial design onward* and will provide a consistent source of

information for everyone working on the product.

No such "integrated" system is in production use today.

However* integrated systems designed to address various portions

of the entire production process are being vigorously pursued in

both the United States and abroad. *

The present technology for product definition lies between

the two extremes of the established human-oriented drafting

methodology and the research in automated production. On the

one hand* the capabilities of the interactive graphics

design-drafting systems being marketed today reflect the fact

that these systems have been based on the drafting application.

This is appropriate* since drawings are still used as the

primary means of data definition* data communication* and data

storage. Thus the predominant current effect of the computer

having been introduced into the process of product definition is

that conventional human-or iented methods have been automated to

some degree.

On the other hand* with the systems being marketed today*

three dimensional "wire frame" models can be constructed* and

both planar and curved bounding surfaces are available to be

used in the product definition. (In fact* the systems being

marketed today are character i zed by some as "edge-surface"

systems. ) It is true that at present the emphasis is still on

the preparation of an engineering drawing from the three

dimensional model. But the stage is now set for the shift in

attitudes - and practices — that will result from the

computer-oriented model eventually being considered as the

* For example* the "I" in both the IPAD and ICAM acronyms

represents "Integrated". (IPAD is Integrated Programs for

Aerospace Vehicle Design* and ICAM is Integrated Computer

Aided Manufacturing. ) CAM-I is the acronym for Computer

Aided Manuf ac turing-International* Inc. Uithin CAM-I*

standing "projects" exist* each having specific concerns

within the production process. There is* among others* the

Geometric Modeling Project* and the Advanced Numerical

Control Project. A new project* the CAM-I Framework

Project* has recently been formed* and will act as

"Integrator" for the various projects. Reference 1 provides

information relative to the structure and concerns of CAM-I.

References 5 and 6 give overviews of ICAM and IPAD.

39 .
primary definition of a part* and the production of

human-oriented drainings as an application feeding off the model

definition.

2. 2 IGES related to the present technology of product definition

IGES has been tailored to accommodate the technology of

product definition as it exists in today's interactive graphics

design-draf t ing systems.

First* this technology is accommodated in the type of

entities provided in IGES. IGES entities allout support of the

traditional drafting application - the production of two

dimensional drawing models. In addition to this* IGES is

equipped to accommodate the eventual shift which will have the

computer-or iented model definition as primary and the

human-oriented drawing as a derivative of it. Thus* there are

IGES geometry entities which support the definition of three

dimensional wire frame models* and the use of planar and curved

bounding surfaces. IGES can further support the distinction

between three dimensional computer models and conventional two

dimensional drawing models by means of the view entity and the

drawing entity. The view entity allows communication of a

particular "picture” of a given three dimensional geometry

configuration. For example* parameters pertaining to the view

point and to clipping may be communicated. The drawing entity

allows communication of a two dimensional surface onto which

views have been projected and arranged in a selected manner.

Drafting annotation entities may also be included.

IGES also contains entities to allow communication of data

base structure. The property entity enables integer* real* or

textual data to be related to a specific entity. Any entity in

IGES may point to one or more property entities.

The assoc iativi ty definition entity

definition of a logical relationship which

entities* without the specification of which

used in any given "instance" of this

associativity instance entity specifies this

allows for the

is to exist between

entities are to be

relationship. The

information.

The IGES macro definition capability provides for the

definition of "new" IGES entities in terms of other IGES

entities and supplied parameters. For example* a variable sized

rectangle could be defined in terms of the variable parameters

of length and width.

The associativity definition and the macro definition

entities allow extension of IGES as necessary in order to meet

short term needs.

40 .
IGES

Related To The Present

Product Definition

Technology

IGES

Accommodates The Technology

Of

Product Definition

As It Exists In Today's

Interactive Graphics

Design-Drafting Systems
IGES Does This 1 hrough:

1. The types of entities it has

2. The particular application-independent format

it uses

The SGES Entitles

1. Can Accommodate Computer-Aided Generation of Traditional Engineering Drawings

2. Can Accommodate Current Capabilities for

Geometry of Computer-Oriented Model — 3D Wireframe — Planar, Curved Surfaces

3. Allow Maintenance of Distinction Between

Human Oriented Model and Computer

Oriented Model — View Entity — Annotation Entity

42 .
The IGES Entities, cont'd.

4. Allow Maintenance of Database Structure — Property Entity — Associativity Entity

5. Allow Extension as Necessary to Meet

Short-Term Needs — Macro Definition — Associativity Definition — Text Font Definition — Line Font Definition

The IGES Entity Format Has

Been Designed To Resemble

Those Found !n Today's

Commercially Available

Interactive Graphics DesignDrafting Systems

43 .
Entity Format

1. In Today's Systems — Attribute parameters which are same for

every entity — Definition parameters varying from entity

to entity

2. InIGES • — A fixed length directory entry which is

same for aSi ehtities — A variable length parameter data entry

varying from entity to entity

44 .
A second way in which IGES accommodates the technology of

product definition in today's systems is by means of the

application-independent format used to define each entity in a

product definition file. Entities in today's systems are

determined by definition parameters varying from entity to

entity* and by attribute parameters which are the same for every

entity. Typical examples* respectively* are geometry related

parameters* and the construction layer on which a given entity

is defined.

IGES supports this format in

each IGES entity has two parts:

is the same for all entities* and

can vary between entities.

a one-for-one manner in

a directory entry format

a parameter data entry

that

which

which

2.3 IGES related to the hierarchy of the

definition

geometry of product

It ha s desig n-draf

ing

frame 11 geome try

ob jec ts. In

repre sentat

ons

persp e^bi ve is

anoth er.

At the pre

model s commonli

may b e arran g ed

Thi» fir st

model (:onsi sts

been observed

it and IGES

already day

too* are

in their three dimensional

this section* various

for solid objects are touched, upon* and some

sought regarding their relationship one to

that present

at the level of "wire

description of solid

kinds of computer

used

> there are three types

to represent solid objects.

of computer

These types

type is the edge representation model. Here* the

of stored computer definitions of the edges of

the object. Depending on the sophistication of a particular

implementation* such information as which

face* or which edges meet at a given vertex may

contained within the data structure of the model.

The advantages of this type of model

basically a simple model* and* provided th<

complicated* it can be used profitably in

views of the object. The fatal disadvant<

model is that it is " inf ormationally incomple

that more than one solid object can correspond to the same edge

model. (This remains true even when only polyhedral objects are

being considered!)

ges bound a given

or may

1 . not be

are that it is

object is not too

enerat ing usable

e of this type of

" in the sense

The second type of solid representat

representation model. Here* the inten

specify precise mathematical definition

bounding surfaces - the faces - of the

that the totality of these surfaces

ion is the

tion is to

s for the

object* in

comprises a

boundary

be able to

var ious

such a way

complete

45 .
IGES

Related to the Hierarchy

Of the Geometry

Of

Product Definition •

Three Current Types Of

Computer Representations

For Solid Objects

1. Edge Representation Model

2. Boundary Representation Model

3. Volume Representation Model

46 .
Edge Representation Model

1. Conceptually Simple

2. Natural Extension of Drafting

Technology

3. Does Not Necessarily Delineate a

Single, Unique Object

Boundary Representation Model

1. Involves mathematically specifying all

exterior "faces" of the object

2. The totality of faces defines a unique

physical object

3. Implicitly contains the Edge

Representation Model

4. Difficult to verify integrity of model

. 47 .
Volume Representation Model

1. Involves specifying all points in 3D

space Occupied by the object

! 2. Defines a Unique Physical Object

3. Implicitly contains the Boundary

Representation Model

1. SGES is oriented to the edge

representation model, but

also accommodates limited

surface capability.

2. IGES in its present form

does not accommodate

either boundary representations or volume representations of solid objects.

48 .
Various Geometric

Modeling Systems For

Solid Objects

Are In Development

49 .
bounding envelope for the

representation# there is no poss

one object with any given boun

problem that was mentioned a

disadvantage of the edge model h

ob jec t. Mi th this type of

ibil i ty of assocat ing more than

dar y model. Thus the uniqueness

b ove as being the primary

as b een overcome.

It is easg to see that there is inherently more information

in this type of representation than there is in the edge

representation. In fact# for a given object# the required

geometrical information needed to construct an edge

representation is implicit in the boundary representation.

However# it is not a trivial task to verify that the totality of

the faces does indeed form exactly a complete bounding envelope

~ that is# with no part of the object left unenclosed# and with

no superfluous "dangling" faces.

The third type of computer model is the volume

representation model. Here the intention is to specify all

points in three dimensional space that are occupied by the

object. There is sufficient information in the volume

representation model to be able to derive a boundary

representat ion model from it. However# while this is very easy

to accept on an intuitive basis# neither is this trivial to

actually carry out in an automated manner.

Current design-draf t ing systems deal predominantly with

edge repr esentat i ons# although as mentioned earlier# certain

bounding surfaces are available to be used to augment the edge

representation. Geometric modelers are presently under

development at various places around the world# based on both

the boundary r epr esenta t i on technique and the volume

representation technique. [Reference 2 describes a recent CAM-I

sponsored seminar on geometric modeling. In addition to general

discussion on geometric modeling# this seminar featured reports

on the status and capabilities ol5 several existing geometric

modelers. 1 The prototype modeler PADL-1 out of the Production

Automation Project at the University of Rochester# and its

successor PADL-2# now under development there# both use the

volume representation to au tomat i chi ly generate the boundary

representat i on and the edge representation. [See References 11

and 123 Reference 9 provides a technical comparison between edge

representation models and volume representation models of a

certain type.

IGES in its present form does not accommodate either

boundary representations or volume Representations of solid

objects. This is considered appropriate# in view of the fact

that these representations are not in common use today# and in*

view of the fact that the underlying motivation for IGES was to

address immediate needs. It remains to be seen how extensible

IGES proves to be relative to this current research area — or#

even if it is desired for it to be extensible in this manner.

However# it is certainly reasonable to expect that CAD/CAM

50
systems offered by suppliers will eventually utilize these types

of representations of solid objects.

As explained below# there is a current standards effort

concerned with devising a system capable of accommodating both

boundary and volume representations of solid objects.

2. 4 1GES related to the standards technology for product

definition

Various standards currently exist which pertain to the

communication of product definition data by means of

conventional engineering drawings. However# in spite of the

fact that IGES is rapidly becoming a de facto national standard#

there are no existing national standards pertaining exclusively

to the communication of a complete computer-oriented product

definition.

The ANSI Subcommittee Y14. 26 has as its title "Computer

aided preparation of product definition data". This

Subcommittee has been in existence since 1970. Task Group 1 of

this Subcommittee <Y14.26. 1) has been concerned with computer

representation of physical object shape - that is# with the

geometry portion of product definition data. A system for

describing geometry has been devised by Y14. 26. 1. The intended

use of this system is to facilitate communication of object

shape descriptions between CA1>/CAM programs# and between data

bases of intercommunicat ing companies — for example# between

contractors and subcontractors. The system has been designed to

accommodate edge# boundary# and volume representations of solid

objects. The feasibility of the writing of pre- and

post-processors for the system proposed by Y14. 26. 1 has yet to

be pursued by Subcommittee Y14. 26.

Task Group 11 (Y14.26.ll) was formed in 1978# and is

concerned with all product definition data other than geometry - what is termed "non-geometry" data.

A brief history of the recent work of Subcommittee Y14. 26

is appropriate. At the August# 1978 meeting of this

Subcommittee# it was decided to begin the work of public

coordination# and thus to issue the work of Y14. 26. 1 as a

Proposed American National Standard# entitled "Digital

Representation of Physical Object Shapes". The subsequent

voting at the Y14 level produced comments on the Proposed

Standard# as did the six week public review period which ended

in June# 1979.

The main order of business at the August# 1979 meeting of

Y14. 26 was the resolution of these comments (or# at least to

resolve how to resolve the comments). Resolution of all

51 .
!GE:

Related To

The Standards Technology

For

Product Definition

1. There are no existing national

standards pertaining expressly to

a complete computer-oriented

product definition.

2. 5GES does pertain expressly to

computer-oriented product

definition data. It deals with

both CAD and CAM. It is rapidly

becoming a de facto standard.
American National Standards Institute (ANSI)

Y14 Committee— Engineering Drawings

And Related Documentation

Y14, Subcommittee 26 (Y14.261— Computer aided

Preparation of Product Definition

Task Group Y14.26.1- Digital Representation of

Physical Object Shape

Task Group Y14.2G.11 -Non-Geometry Data

May, 1980 Meeting of Y14.26

Voted to Issue IGES

As the First Three Parts

Of a Five Part

Proposed American

National Standard
comment*

that Y14.

meeting

re issued

American

intention

is dictated by ANSI procedure.

26 uould work during the months

and that the revised Propose

during the summer of 1980* th

National Standard/ for a per

being additional* and wider# exp

The plan- adopted was

following the August

d Standard would be

is time as a Draft

iod of one year — the

osuri.

A meeting was convened for Subcommittee Y14. 26 on May 1#2#

1980. The main order of business was consideration by the

Subcommittee regarding 1GES being adopted as an American

National Standard. A motion was approved concerning a Proposed

Standard Y14. 26. X# entitled Digital Representation for

Communication of Product Definition Data. (A motion was also

approved to the effect that X not be equal to 1. The exact

number of this Proposed Standard will be coordinated with ASME#

the Y14 Secretariat. >

Y14. 26. X is to be composed as follows:

Foreword

Part 1 Data Form (a

Part 2 Geometry (as

Part 3 Non-Geometry

Part 4 Geometry (as

Part 5 Non—Geometry

Further palints expressed

, presented in IGES)

presented in IGES)

(as presented in IGES)

presented in Y14. 26. 1)

(as presented in yl4. 26. 1)

n the motion were:

1. IGES (Version 1) be forwarded by Y14 Subcommittee 26 as

Parts 1# 2# and 3 of the proposed standard to the Y14

Standards Committee to begin the review and approval

process as an American National Standard.

2. IGES group as th® proponent be responsible for

considering comments arising from submittal of the

Foreward# Farts 1# 2# and 3 of the proposal for

approval as an American National Standard.

IGES and Y14. 26. 1 Task cooperate

Y14. 26. X Part 4 geometry format.

in formulating the

4. Y14. 26. 1 and Y14.26.ll Tasks be responsible for

considering comments arising from submittal of Parts 4

and 5# respectively# of the supplementary proposals for

approval as an American National Standard.

Item 3 refers to the fact that the IGES assoc iativity

54
entity is to be used to express* in the ICES format* the

geometry as presented by Y14. 26. 1. It was recommended at the

meeting* and agreed to by the participants* that* in the

interest of achieving a single American National Standard format

for communication of geometry data* the Y14. 26. 1 geometry could

and should use the ICES format structure.

55 .
REFERENCES

1.

2.

3.

4.

5.

6 .

7 .

8 .

9.

10.

11 .

12.

CAM-I Management Prospectus# Computer Aided

Manufacturing-International# Inc. # 611 Ryan Plaza

Drive# Suite 1107# Arlington# TX# 76011.

Computer Aided Design# Vol. 12# No. 2# march# 1980#

pp. 93—93.

Elson# Benjamin M. # Computer design seen cutting costs#

Aviation Week and Space Technology# November 12# 1979.

Harris# David H. W. # Application and implementation of

computer graphics to support the design of the Boeing

767 airplane# CAD/CAM# Jan. -Feb. # 1980.

XCAM Program Prospectus# Update 1# September# 1979.

IPAD Executive Summary# Report No. D6-IPAD-70020-M#

April 12, 1978.

Kennicott# P. R. # Evans# G. G. # and Jones# L. J. # A

database implementation of IGES# Proceedings of the

First Annual NCGA Conference# 1980.

« o Nagel# R. N. # Bra i thua

t e# W. W. # and Kennicott# P.

R. # Initial Graphics Exchange Specification (IGES)

Version 1.0# National Bureau of Standards Publication

NBSIR 80-1978CR ).

Peterson, D. P. # Defining solid objects: Comparing

wire frame with constructive solid geometry

repr esen tat i ons# Report SAND79-0877# Sandia National

Laboratories# Albuquerque.

The Anderson Report# Volume 2# No. 6# February# 1980.

Voeleker# H. B. # and Brown# C. M. # The PADL-2

Project# Proceedings of the seventh NSF grantees'

conference on production research and technology#

September# 1979# Ithaca# NY.

Voeleker# H. B. # and Requieha# A. A. G. # Geometric

modeling at the University of Rochester# Proceedings of

the first annual conference on computer graphics in

CAD/CAM systems# MIT# May# 1979.

. 56
Appendix A

IGES SH-ERINQ COMMITTEE

Chairman: Bradford Smith* National Bureau of Standards*

Mashing ton* DC

Vice Chairman: Roger N. Nagel* International Harvester*

Hinsdale* Illinois

Secretary: Joan Wellington* National Bureau of Standards

Wc:shington* DC

Committee Members:

John E. Anderson* Naval Weapons Center* China Lake* CA

T. N. Bernstein* USAF/AFMI. /L *1 (:* WPAFB. Ohio

Robert Blauth* Computervi si on Corp. * Bedford* MA

Gino Carli* Sandia Labs* Albuquerque* NM

Richard Costabile* Xerox Corp. * Webster* NY

Olan Bray* Control Data Corp. * Arden Hills* MN

Richard Jennings* DMT* Nashua* NH

James Jones* The Boeing Company* Seattle* HA

Glen Petersen* CALMA* San Diego* CA

C. R. Lewis* General Motors* Warren* MI

Fred Michel* DARCOM* Alexandria* VA

Stuart Miller* General Electric Company* Schenectady* NY

Raye J. Montague* Naval SEA Systems Command* Washington* DC

Jack Horgan* Applicon Inc.* Burlington* MA

George Salley* NASA* Hampton* VA

B. Neil Snodgrass* CAM-I* Arlington* Texas

Harry M. Taxin* Gerber Systems Technology* Inc.*

South Windsor* CT

Donald A. Vincent* SME* Dearborn* MI

57
Appendix B

r

SAMPLE 2Vz D PART

l

I

58 .
V

J

X li Part 2

.

'

-

59
I*.

A Specification

' For The

Exchange

Of . Product Definition

Data

60 .
The Initial Graphics Exchange Specification (IGES) has been

designed to accommodate the exchange of product definition

information between Computer-aided Design and Computer-aided

Manufacturing (CAD/CAM) systems.

61 .'
62 .
Product definition# as it is generated in today's

commercially available interactive graphics design-drafting

systems# can be subdivided into three categories: geometry#

annotation# and structure.

The category of

product definition

points# lines# arcs#

geometry consists of that

which describes the product i

ruled or parametric surfaces#

part of the

self# such as

etc.

part of the

and topol ogy

The category of annotation consists of that

definition used to clarify and enhance the geometry

of the product. For example# when product information is

communicated in the form of an engineering drawing# annotation

includes dimensioning and tolerancing information such as

dimension lines# text# true positioning symbols# etc.

The structure category consists of the various logical

relationships that exist within the product definition file.

Logical relationships may exist between the elements of the

product definition itself# as when specific manufacturing

instructions are associated with a specific element of the

geometry. Or# logical relat ionsh ips may pertain to the system

involved in the generation of the product definition# as when

several elements in the definition are grouped together to form

an entity that can be evaluated and/or manipulated as a single

item.

63
IGES Files

Basic Idea

Product Definition Information

Is Communicated As

A File Of Entities

64 .
An entity is the information unit in an I6ES file.

The basic idea in an IGES file is that product definition

information is communicated by means of a list* or file* or IGES

entities. The format of the IGES entities is application

independent. The essence of the IGES effort* as far as the

publishing of the specifications uias concerned* consisted of

determining what entities were to be included* and the format

for each.

65
8GES Entity Categorie

1. Geometry Entities

2. Annotation Entities

3. Structure Entities •
There are three broad categories of entities in IGES:

geometry entities* annotation entities# and structure entities.

' .1.

.

'

'
IGES Entity Structure

Each IGES Entity

Has Two Parts

1. A directory entry

2. A parameter data entry

68 .
Each entity in IGES has two parts. The first part consists

of a directory entry* the second part a parameter data entry.

The form of the directory entry is fixed. It is

for all entries. The parameter data entry varies from

entity.

Within an IGES file* al

into one section* and all

into one section. Within

contiguous records.

1 directory entries are

parameter data entries are

a section* each entry

the same

entity to

gathered

gathered

occupies

69 .
IGES File Format

80 Character

Records

Using ASCII Characters

70 .
An IGES file is written on 80 column records. using the

ASCII character set. The HO character records were chosen as being as universal medium as possible for transfer of information

between different computing systems. Numbers are recorded in

character form, to simplify the problems of differences in word

length when going from machine to machine.

Each record in the file has a unique letter in column 73.

which identifies the section to which it belongs. For example,

the directory entry section has a D in this column. A rightjustified sequence number is used in columns 74 through 80 to indicate the position of a record within a section.

71 .
IGES Data Types

1. Integer (Fixed-Point) Constants

2. Floating-Point Constants

3. String Constants

4. Pointer Constants

5. Language Statement Constantsi
There are five data type* in IGES: integer (fixed point)

constants* floating point constants* string* pointer constants

and language statement constants.

Integer constants may be positive or negative or zero. The

number of bits used by a particular machine for integer

representation can be specified within an IGES file.

Floating-point constants are distinguished by the presence

of a decimal point. IGES permits both single and double precision floating point constants. A single precision floating point

constant may be expressed with or without an exponent. Double

precision constants must be in exponential form.

String constants in IGES use the Hollerith form as found in

the ANSI specification of FORTRAN. A string constant is

preceded by an unsigned integer (the character count of the

string) and the letter "H". Any character from the ASCII

character set may be used. There is no limit on the size of a

string constant. In particular* string constants may cross card

boundaries.

A pointer at a particular location in an IGES file is a

device used to indicate that additional information exists

elsewhere in the file. For example* within the directory entry

for each IGES entry* there is a pointer into the parameter- data

section specifying the location of the parameter data for that

entity.

All other uses of pointers deal with the situation in which

one IGES entity is referenced by another. In these cases* there

is a pointer from the referencing entity to the directory entry

of the referenced entity. The pointer may be located in either

the directory entry section or the parameter data section of the

referencing entity.

For example* suppose that in given product definition

information* the four sides of a rectangle have been related* in

an unordered manner* and labeled by a name. Then* in the

corresponding IGES file# this association - called a group - is

recorded by means of an IGES entity called an associativity

instance. Within the parameter data for this associativity

instance entity# there will be pointers to the directory entries

of each of the four straight line entities of the rectangle. In

addition# within the parameter data for each of the straight

line entities* there will be a back pointer to the associativity

instance entity* to indicate that the particular straight line

is a member of the group. The name of the group can be

accommodated by the associativity instance entity.

Pointers are implemented using the sequence numbers.

A fifth data type*

for macro definitions,

ters and is not preceed'

constant. Its length

data record count in th

the language statement constant is used

It consists simply of a string of characd by the "nH" construction of the string

must be determined through the parameter

directory entry for the entity.

73 .
Free Format

74 .
The data in several sections of an I6ES file may be entered

in free format. The free format feature allows the

specification of parameters in a prescribed order* but does not

specify a location on the record. When free format is permitted

the following rules apply:

1. Blanks are ignored.

2. Commas are used to separate parameters.

3. A semicolon is

parameters.

used to terminate the list of

4. When two commas appear adjacent to each other (or

separated only by blanks) the pertinent parameter is

not specified in the file and should be given a default

value.

5. If a semicolon appears before the list of parameters is

complete* all remaining parameters should be given

default values.

6. Blanks are not ignored in string constants. In

addition* the comma and the semicolon are treated as

characters in a string constant* and do not have the

meaning specified in <2) through (5) above.

75 .
IGES Fife Structure

1. Start Section

2. Global Section

3. Directory Entry Section

4. Parameter Data Section

5. Terminate Section

76 .
Each IGES file contains five subsections: the Start

Section* the Global Section* the Directory Entry Section* the

Parameter Data Section* and the Terminate Section. The

subsections must appear in this order.

77
IGES

FILE

STRUCTURE

78 .

TERMINATE

SECTION
The arrows between the Directory Entry and the Parameter

Data Sections illustrate the action of the pointers.

$
A Closer Look

At The

1GES File Subsections

80 .
START SECTION

THIS SECTION IS A MAN READABLE S0000001

PROLOG TO AN IGES FILE. IT CAN CONTAIN S0D00002

AN ARBITRARY NUMBER OF RECORDS S000G003

USING ASCII CHARACTERS IN COLUMNS 1-72 S0000020

81 .
The Start Section of a IGES file provides a man-readable

prologue to the file.

Each Start Section record has an "S" in column 73» and a sequence number in columns 74 through 80. The information in

columns 1 through 72 does not have to be formatted in any special

uay, except that the ASCII character set must be used.

There must be at least one Start record.

82 .
GLOBAL

SECTION

r? \

ii

iOL

£

o

co

LU

a

3

<

-J U.

=>S

sf

Sl^

x O

LU

h*O

<X

<

X

o

cc

LU

I-

<

cc<

X

o

DC

LUh

LU

2

o

<

hi

H

<

CC

x^

Q LU

Q°

-j a

LU 2

LU LU

9 co

LU >

CO

cd2

Q

h-2

LU

a

QS

o o

CC DC

CL LU

CO

t

CQ _ cc < 55 lu

2 LU Q O ^ 2 O

O

CO

cc

LU

>

LU

CC

<

2

o

co

cc

LU

>

CC

o

h*

3

CO

cc

LU

CD

LU

I-2

X

o

LU

2 2

g g

co g o o

LU LU X XX

LU t LU

<29 LU

IUJCO — >• X CO

LU

>

rx

O

CO • •

< DC X LU

h- X

COS

us D CD^

cd2

CO

<

22

2 x

O

X

LU

DQ

D

2

LU

COX

XX

X

X

X O 22

2*

x<X

I-S

in

ota. co 0 X 20

i=cc

<

O

<

CO

g

h

2

<

“-D

2

2

g

g

o

x

X

X

_J

DQ3

O

a

<

h-2

O

x

CO

t

DQ

20 £

fi x 2

<S°

o £ Qx 3 x

x

X

>

IX

h hX X

x x

H hh H h* H

X XX X

X X X X

1- 1— h- h

X X X X

X X X

CD CD O CD X X X X

h- 1- 1- H 2 2 2 2

X

x

K-

<

X

<

X

r- CM CO co r>. 00 O) O r83 .

IMTEGER

NUMBER

OF

BITS

IN

A

DOUBLE

PRECISION

MANTISSA

The Global Section contains information describing the

pre-processor* and information needed by the post-processor in

order to handle an 1GES file.

Global Section records have a "G" in column 73. The parameters for the Global Section are input in free format.

85 .
DIRECTORY

ENTRY

(DE)

SECTION

SEQ

#

D

10

SEQ# D

20

STATUS #'S 9 ENTITY SUBSCRIPT # 19

LABEL DISPLAY 8 ENTITY LABEL 18

DEFINING MATRIX 7 RESERVED

^

. 17

VIEW 6 RESERVED 16

LEVEL #. 5 FORM

NUMBER # 15

LINE

FONT

PATTERN #, 4 PARAMETER RECORD COUNT # 14

VERSION #. 3 PEN NUMBER # 13

PARA- METER DATA 2 LINE WEIGHT # 12

ENTITY

TYPE

NO. # 1 ENTITY

TYPE

NO. # 11

H.OH003H Izauooau

NUMBER POINTER NUMBER

OR

POINTER

(POINTER

HAS

NEG

SIGN)
The Directory Entry Section of an IGES file has one entry*

consisting of two records# for each entity in the IGES file. The

two records contain twenty fields of eight columns each. The

meaning attached to each field does not vary between entities.

The contents of the directory tend to be that data common

to all entities in the file. The first field specifies the IGES

entity number. The second field is a pointer to the location

within the Parameter Data Section of the parameter data for the

entity. Information in the remaining fields is referred to as

attribute data. This information may be specified by a number

value* or by a pointer to the directory entry of another IGES

entity. In some cases* there is a choice.

A typical example of an attribute specified by a value is

in field twelve* where the pen number value specifies which pen

a plotter would use to draw an image of the entity. A pointer

would be used in field five* whenever the entity is to be

defined on more than one working level. (Some systems allow

entities to be defined on as many levels as is convenient. ) In

fields involving a choice# a pointer is specified by the

presence of a negative sign.

87
n

incn zopo

UJ<H<Q

tr

UJh

UJs<

t£<

a.

SEQUENCE NUMBER P# SEQUENCE NUMBER P# SEQUENCE NUMBER P#

fi£

a

X

1®®

H

H & CL

UJ UJ UJ Q Q o

CO CO CO

<£ < < 2 I 2 2 s 2 o © Q o a O > > > a m Q Q • • • • a

UJ UJ UI h h h- < < < X X < < < & X x . UJ UJ UI o m CO CO 2 co CO CO

yj

X

X

X

SL UJ UJ UJ > h H ITM p “ UJ , UJ > § 2 2 H < < < s- X 2 5 < X< U & &

*GV

X

X

H2

ui <P2

ui3d

UJ

CO

COa 2 § X < 8“ ft, o£

££

|3

Ss“

yj 3E > H 0 H

&sS 2 Q 5

uj

m

X 10 H X a 845 2 m H 3 - 2 2 Q

®S LU

ogee

£L CJ ui 1 2 m

“S 2

UJ

d 5 ui Z O (0

88 .
The Parameter Data Section of an IGES file contains, the

parameter data entries of the entities in the IGES file.

Parameter data varies from entity to entity.

Parameter data is entered in free format# with the first

field always containing the entity type number. Thus# the

entity type number and a comma always precede the first

parameter for each entity. The free field part of each

parameter record ends in column 64. Columns 65 through 72 on

each parameter record contain pointer to the sequence number of

the first record in the directory entry for the entity to which

the parameter data belongs. Column 73 contains a "P". As usual#

sequence numbers are located in columns 74 through 80.

With the exception of text strings# parameter data values

are restricted from crossing record boundaries. For each entry#

comments can be added following the parameter data# giving the

possibility of furnishing human readable information when necessary.

89 .
< 90
Each IGES file has one record in the Terminate Section,

vided into ten fields of eight columns each. This records

be the last record in the file. It has a "T" in column 73,

GOOOOOl in columns 74 through 80.

The first four fields on the terminate record give

number of records in each of the four previous sections.

d i - must

and

the

91 .
A Closer Look

ES Err

A
IGES GEOMETRY ENTITIES

ENTITY TYPE ENTITY TYPE NUMBER

CIRCULAR ARC ENTITY 100

COMPOSITE CURVE ENTITY 102

CONIC ARC ENTITY 104

COPIOUS DATA ENTITY ioa

PLANE ENTITY 108

LINE ENTITY 110

PARAMETRIC SPLINE 112

PARAMETRIC SPLINE SURFACE ENTITY 114

POINT ENTITY 116

RULED SURFACE ENTITY 118

SURFACE OF REVOLUTION ENTITY 120

TABULATED CYLINDER ENTITY 122

TRANSFORMATION MATRIX ENTITY 124

93 .
The IGES Geometry entities. Most of the geometry entities

are defined directly in three dimensional X# Y# 2 model space.

(That is# the coordinate system in which the model is defined.

The circular arc entity and the conic arc entity are exceptions.

I

94 .
Example:

The

Circular Arc

95 .
c

96 .
Circular arcs can be defined with the I6ES circular arc entity. Coordinate information for arc endpoints A and B is part

of the parameter data. By considering an arc to be drawn counterclockwise from the point listed first to the point listed

second/ a given arc can be distinguished from its complementary

arc (which has the same endpoints).

97 .
CIRCULAR ARC ENTITY

DIRECTORY ENTRY FIELDS

ENTITY NUMBER 100 STATUS #

PARAMETER DATA LINE WEIGHT #

VERSION #, PEN NUMBER #

LINE FONT #. PARAMETER CARD CT. #

LEVEL #. FORM NUMBER #

VIEW ENTITY LABEL

MATRIX ENTITY LABEL SUB #

LABEL SEQUENCE

PARAMETER DATA

&RAMETER VALUE FORMAT

1 Z FLOATING POINT

2 X FLOATING POINT

3 Y FLOATING POINT

4 X FLOATING POINT

5

- Y FLOATING POINT

6 X FLOATING POINT

7 Y FLOATING POINT

8 N INTEGER

9 DE POINTER

8 + N DE POINTER

9 + N M INTEGER

10 + N DE POINTER

• • •

• • • • • • 9 + N + M DE POINTER

COMMENT

CENTER DISPLACEMENT

FROM XT-YT PLANE

CIRCLE CENTER ABSCISSA

CIRCLE CENTER ORDINATE

END POINT ONE ABSCISSA

END POINT ONE ORDINATE

END POINT TWO ABSCISSA

END POINT TWO ORDINATE

NUMBER OF BACK POINTERS

(TO ASSOCIATIVITY ENTITIES)

/TEXT POINTERS (TO GENERAL

NOTE ENTITIES)

POINTERS TO ASSOCIATIVITIES

OR GENERAL NOTES .

r NUMBER OF

PROPERTIES

POINTERS TO PROPERTIES
In IGES* an arc of a circle is specified by giving planar

coordinates for the tuio endpoints of the arc* and the

coordinates of the center of the parent circle for the arc. (See

parameters 2 through 7 in the parameter data.

)

The definition plane for the arc is termed the XT*YT plane*

and is different from model space. The arc can be considered to

be rigidly displaced in a direction perpendicular to the XT*YT

plane (that is* in the ZT direction)* as parameter 1 in the

parameter data indicates.

The remaining parameters in this entity have to do with

possible related entities. For example* if an arc is one of the

entities in a group* then the associativity instance entity

specifying the various group elements could be pointed to by the

circular arc entity as being an associated entity.

The arc in the XT*YT plane is situated into model space by

use of the IGES transformation matrix entity. This entity

consists of a rotation matrix and a translation vector. Field 7

in the directory entry for the circle contains a pointer to the

matrix entity.

o

99 .
IGES ANNOTATION ENTITIES

ENTITY TYPE ENTITY TYPE NUMBER

ANGULAR DIMENSION 202

CENTERLINE 106

DIAMETER DIMENSION 206

FLAG NOTE 208

GENERAL LABEL 210

GENERAL NOTE 212

LEADER (ARROW) 214

LINEAR DIMENSION 216

ORDINATE DIMENSION 218

POINT DIMENSION 220

RADIUS DIMENSION 222

SECTION 106

WITNESS LINE 106

100 .
The IGES Annotation entities. Annotation entities are

part of the physical part description itself. Rather#

serve primarily to enhance the physical description of the

such as in the case of a linear or an angular dimension.

not

these

part#

101 .
102 .
i—1.5772

T

1.1160

>

-J 1.5772 L1

EXAMPLE 1 EXAMPLE 2

•

EXAMPLE 3

EXAMPLES OF LINEAR DIMENSIGNS

103 .
A linear dimension entity consists of a general note* tuio

leaders* and zero to two witness lines. The IGES general note

entity is used for all text in an IGES file. Here* this

consists of the numerical values shown. The leaders are the

portions of the entity containing the arrowheads. The witness

lines are used as needed.

0

104
LINEAR DIMENSION

DIRECTORY ENTRY FIELDS

ENTITY NUMBER 216 STATUS #

PARAMETER DATA

VERSION

LINE FONT

LEVEL

VIEW

MATRIX

LABEL

LINE WEIGHT #

#, PEN NUMBER # #, PARAMETER CARD CT. # #, FORM NUMBER #

ENTITY LABEL ; ENTITY LABEL SUB #

SEQUENCE 1

PARAMETER DATA

PARAMETER VALUE FORMAT COMMENT

1 DENOTE INTEGER POINTER TO.GENERAL NOTE DE

2 DEARRW1 INTEGER POINTER TO FIRST LEADER DE

3 DEARRW2 INTEGER POINTER TO SECOND LEADER DE

4 DEWIT1 POINTER POINTER TO WITNESS LINE DE,

5 DEWIT2 POINTER 0 IF NOT DEFINED

6 N INTEGER NUMBERS OF BACK POINTERS

(TO ASSOCIATIVITY ENTITIES)/TEXT

POINTERS (TO GENERAL NOTE

ENTITIES)

7 DE POINTER POINTERS TO ASSOCIATIVITIES

• • • OR GENERAL ... NOTES - - !

! •

6|+

DE

•

m POINTER

i

!

j 7|+N M INTEGER NUMBER OF PROPERTIES

8 + N DE POINTER) POINTERS TO PROPERTIES

t

•

7r»- N + M

»

•DE POINTER

105 .
A portion of the parameter data for the linear dimension

entity indicates that this entity really consists of a set of

pointers to other annotation entities. Thus* the witness line

in this entity is an example of a subordinate entity. An IGES

entity is considered to be a subordinate entity as it was

created purely as a subpart of another entity - that is* would

not be used independently. A flag in the directory entry is

used to indicate if a given entity is a subordinate entity.

(Entities formed into a group by means of an assoc iativi ty

instance entity are not subordinate entities. ) For a linear dimension entity* an associated entity could

conceivably be the geometry entity to which the dimension value

refers.

106
The IGES

View and Drawing

Structure Entities

107 .
Two other IGES structure entities are the view entity and

the drawing entity. These two entities reflect an attempt to

maintain within IGES the

dimensional description of

representation of the model*

engineering drawing. The

model and two dimensional

distinction between the three

a model* and a two dimensional

as* for example* in the form of an

intent is to allow the two ideas of

representation to be dealt with

separately* while maintaining a single model description within

the database. This contrasts with the situation where either

the model description itself must be changed in order to get a

two dimensional representati on such as a draftsman would

produce* or else a copy of the model description is changed*

thus admitting to potential compatibility problems when updates

are made.

108
109 .
110.

'
The concept of what type of information the view' entity and

the drawing entity can accommodate is illustrated in these two

pictures. A portion of the model is selected using a view

cube. (In two dimensions# the term "view window" might possibly

be used instead. View cube is a generalization of this idea to

three dimensions. ) The view cube is used to identify the portion

of the model that is of interest. (For example# a portion might

be selected and scaled in order to "blow up" a certain detail. ) Portions of the model outside the view cube are "clipped"# or

removed. Information within the view entity is then used to

rotate as necessary the portion of the model within the view

cube# in order to present the selected geometry on the two

dimensional drawing in the desired orientation,

projection onto the two-dimensional drawing is made#

control is allowed over entity attributes within each

example# it can be arranged that a line be dashed

and be solid in another.

As the

additional

view. For

in one view

The drawing entity gives the capability of collecting the

results of view operations and arranging them in two dimensional

space in a manner similar to conventional drafting practices.

While it is not essential to do so in the use of IGES# the

drawing entity also provides a convenient place to collect the

drafting annotation entities which aid in the description of the

model. The drafting annotation entities are essentially two

dimensional objects. By confining these entities to the two

dimensional representation via the drawing entity# rather than

attaching them to the model itself#

form# while the drawing entity

additional descriptive information.

the model is

is used to

kept in

collect

pure

this

111 .
f

IGES Structure Entities

1. Associativity Definition

2. Associativity Instance

3. Annotation

4. Line Font Definition

"T ‘ —

5. MACRO Definition

6. MACRO instance.;

7. Property

8. Subfigure Definition

9. Subfigure Instance

#/ 10. Text Font Definition,

11. View

112 .
The purpose of the IGES structure entities is to

communicate logical relationships between IGES entities. The

intent is to be able to faithfully accommodate the structure

within an originating product definition file.

The assoc iativity definition and the subfigure definition

entities have been mentioned elsewhere.

The macro capability provides for the definition of a "new"

entity in terms of other IGES entities. The "new" entity schema

is provided for by a macro definition# written using the macro

entity. The statements permissable are the assignment

statement (LET)# the entity definition statement (SET)# the REPEAT

statement# causing a group of statements to be repeated a

specified number of times# the CONTINUE statement# which

terminates the REPEAT group# and the HREF statement# used to

refer to other macros from inside a macro definition.

The text font definition entity is used to define

characters and character fonts not provided in the font

definitions of IGES. (In the IGES General Note entity# font

character ist ics are identified by an integer between 0 and 6.

These integers are determined on a system dependent basis. > The

text font entity pairs an ASCII value with a subfigure. The

subfigure contains the geometric components necessary to draw

the character.

The line font definition entity is used to generate line

fonts with repeating patterns. Repeating, patterns are specified

by on or off line segments. Up to 16 segments can be used in

the basic repeating pattern. A repeating subfigure pattern can

also be accommodated by this entity.

113 .
The

Subfiqure Instance Entil ses

114 .
A subfigure is exactly like a complete part description*

except that it is intended to be used uiithin the description of

some other part. Thus an "instance" of a subfigure may occur

only once in a part design* or it may occur many times.

Subfigures may be nested* thus providing a hierarchical

capability.

There is an IGES entity dealing with the definition of a

subfigure* and also an IGES entity used with each occurrence of

the subfigure. The subfigure definition entity specifies

pointers to specific entities or to other subfigures. The

subfigure instance entity refers back to the definition* and

also contains information pertinent to the location and the

scale factor for a particular occurrence.

As an example

occurrences of a in a part design.

the screw* and

the design.

of the use of a subfigure* consider the

ex-head screw in a number of different places

A subfigure entity could be used to represent

subfigure instance for each occurrence within

115 .
SUBFIGURE

DEFINITION &

INSTANCE > mOs<H

(0ZdE

eaD

GO0 LL

LUDdE

CQD

10

116
The

IGES

Property Entity

¥

117 .
The property entity is meant to contain any type of data

(integer* real* or text) which is necessary to enhance the

description of a particular entity. For example* on a printed

wiring board* the width of a line which is part of a conductive

path could be specified as a property value.

Any entity in IGE5 may point to one or more property

entities. Properties are referred to by the "associated

properties" pointers in the parameter data of the IGES entities.

In particular* a property entity may point to other

property entities* thus allowing the construction of networks.

Networks are useful for maintaining information such as signal

strings* dimension dependencies* etc.

118
PROPERTY GRAPH

NETWORK
The IGES

Associativity Definition

And

Associativity instance Entities

120 .
The IGES assoc iat ivi ty entity is like the subfigure entity

in that there is an associativity definition entity and an

associativity instance entity. The assoc iativi ty instance

entity is used each time the defined associativity relation

occurs.

However# the associativity definition entity is quite

general. It specifies the structure of a logical relationship

rather than specific entities which are to take part in the

relationship. The logical relationship may entail one or more

independently defined "classes"# each of which may have one or

more entries. A class may be ordered or unordered. The

assoc iativity instance defines# for each occurrence of the

assoc iativi ty relation# the number of entries in each class# and

the necessary data for each entry.

A group is perhaps the simplest example of an

associativity. For this# there would be one class# which would

be unordered (by definition). In a given instance# each entity

to appear in the group could be specified by a pointer.

121 •
ASSOCIATIVITY

/

0

122 .
ASSOCIATIVITY DEFINITION

12 :1 .
ASSOCIATIVITY

INSTANCE

124

ASSOCIATIVITY

INSTANCE

AND

RELATED

ENTITIES
An example of an associativity instance for a group.

This associativity instance entity specifies* by means of

the parameter Nl# that three entries are to be involved in this

particular instance. The pointer for each entry identifies the

participating entity.

The form number parameter is

assoc iativity instance entity

associativity definition entity,

can be accommodated.

the mechanism by which the

identifies the corresponding

Form numbers from 1 to 9999

If the form number is

associativity definition will

If the form number is between

definition is considered to be

included within the 16ES file.

5001 and 9999# then the

included within the IGES file,

and 5000# the assoc iativi ty

a "standard" one# and need not be

between

be

1

Form number 1 is the form number for a group. Thus# the

definition is known to specify one class* unordered# one data

item for each entry in the class* which will be a pointer. The

definition also specifies that each entity participating in a group instance will contain a back pointer to the parent

associativity instance entity.

125
126 .
IGES

ENTITY

STRUCTURE

! 27 .
Q.

£•

The IGES entity structure. A line between two boxes means

that the information in both boxes is within the same set of

records. A line with an arrow means that information is located

elsewhere# and that a pointer is used to locate it. Thus#

ttributes are part of the directory entry (DE). The entity

efinition box is used in those cases where it is necessary to

either change an existing entity definition or add a new entity

definition.

128 .
NBS-114A (REV. 2-80

U.S. DEPT. OF COMM.

BIBLIOGRAPHIC DATA

SHEET (See instructions)

1. PUBLICATION OR

REPORT NO.

NBSIR SI-2297

2. Performing Organ. Report No, 3. Publication Date

June, 19 SI

4. TITLE AND SUBTITLE

A Technical Bnleflng on the Initial Gnaphlcs Exchange Specification ( 1GES

5. author(S) j. c. Kelly, Robert Wolf, Philip Kennicott, Rogen Nagel.

Joan Wellington, Editor

6. PERFORMING ORGANIZATION (If joint or other than NBS, see instructions)

national bureau of standards

DEPARTMENT OF COMMERCE

WASHINGTON, D.C. 20234

7. Contract/Grant No. EV1457-S0-00012

8 . Type of Report & Period Covered

Jan. 19 SO to Jane, 'SI

9. SPONSORING ORGANIZATION NAME AND COMPLETE ADDRESS (Street. City. State, ZIP)

Kin. Eon.ce ICAM Pn.ogn.am (Integrated. Computen Aided Manufacturing), Wright- Patter on

Ain. Eon.ce Bate, Ohio 45433

10. SUPPLEMENTARY NOTES

I I Document describes a computer program; SF-185, FIPS Software Summary, is attached.

11. ABSTRACT (A 200-word or less factual summary of most significant information. If document includes a significant

bi bliography or literature survey, mention it here) This publication Is a technical, bnleflng on the Initial Gnaphlcs Exchange

Specification (IGES) which was published as NBSIR 80-1978 (R) . The bnleflng senves

two punposes: (1) to give the neaden a bnoad overview of the Initial GnapEu.cs Exchange

Specification and (2) to pnovlde matenlal fon use In pnepanlng bnleflngs about I GES

fon pnesentatlon to technical gnoups.

The bnleflng Is divided Into two pants. Pant 1 consists of a set of slides and

associated text. The slides and text one onganlzed In tandem. The Intent of the

text Is to funnlsh associated Infonmatlon (fon each slide) as opposed to funnlshlng

specific text that Is to be nead venbatim. The Information In this section Is "soft"

(not overly technical). Pant 2 consists of mone technical matenlal. In tEils sectcon

text that can be nead venbatim Is pnovlded fon each slide.

12. KEY WORDS (Six to twelve entries; alphabetical order; capitalize only proper names; and separate key words by semicolons)

computen aided design (CAV)

computen aided manufactunlng (CAM), exchange

format, geometry, Intenface, gnaphlcs, file, entity

13. AVAILABILITY

Uni imited

| 1 For Official Distribution. Do Not Release to NTIS

1 Order From Superintendent of Documents, U.S. Government Printing Office, Washington, D.C.

20402.

Q J Order From National Technical Information Service (NTIS), Springfield, VA. 22161

14. NO. OF

PRINTED PAGES

15. Price

USCOMM-DC 6043-P80


1JIJ