NBSIR 88-3'

AlllDE

A Collection of Technical Studies

Completed for the Computer-aided

Acquisition and Logistic Support

(CALS) Program

Fiscal Year 1 987

Volume 4 of 4

Thomas Wright, Editor

U.S. DEPARTMENT OF COMMERCE

National Bureau of Standards

Institute for Computer Sciences and Technology

Information Systems Engineering Division

Gaithersburg, MD 20899

March 1988

Stimulating America's Progress

JENT OF COMMERCE

iU OF STANDARDS
iii
NBSIR 88-3729

A COLLECTION OF TECHNICAL STUDIES

COMPLETED FOR THE COPUTER-AIDED

ACQUISITION AND LOGISTIC SUPPORT

(CALS) PROGRAM

FISCAL YEAR 1987

VOLUME 4 OF 4

Research Information Center

Aalionai Bureau of Standards

Gaithersburg, Maryland 20899

CiC'lOO

.- >0 , ^

Thomas Wright, Editor

U.S. DEPARTMENT OF COMMERCE

National Bureau of Standards

Institute for Computer Sciences and Technology

Information Systems Engineering Division

Gaithersburg, MD 20899

March 1988

U.S. DEPARTMENT OF COMMERCE, C. William Verity, Secretary

NATIONAL BUREAU OF STANDARDS, Ernest Ambler, Director
If

r><i\imt i»t «iii^i*'!i^:-«i>«‘ •i^

Wv ‘^. ** , I wi' -I ' ' <lf Iflll-- »’(

'..JR' V

' ''TNMHHK

'•* ' ^ f % •.

V i i‘ift

J)' 'jV^.

i v-'*

• * ft4 ^ > T . >if *' V . ,' r ,'“j.v ' A ^ /

• ^ • '.•V^''|^ . 4?f ,-.-i*:v .’jr.

m -r ' } J, Y

M '-'Mr-*

CV.;*T? . .<,ti-> r« _• V

• ^ ii^VJ WMri

.4 , '’

. *40 v>A3 ' <a

' * -' j^^-’mtu .ift av>!i" :3«-j;'‘ * rov

.v;.->

. •

' > '*

' »
e:::ecuttvi: summary

The overall objective of the Department of Defense Computer-aided

Acquisition & Logistic Suppc.rt .CALS) Irogram is to inue-rate the

design, manufacturing, and logistic functions through the

efficient application of computer technology. CALS is a program

to apply existing and emerging communications and computer-aided

technologies in DoD and industry' tc : o Integrate and improve design, manufacturing, and

logistic functions; thereby br-dging existing "islands

of automation."

o Actively influence the design process to produce weapon

systems that are more reliable and easier to support

ana maintain.

o Shift from current paper-intensive weapon support

processes to a highly autcmiated mode of operation,

based on a unified DoD interface with industry for

exchange of logistic technical information in digital

form.

The CALS program was established by the Deputy Secretary of

Defense in September 1985 to implement the recommendations of a Joint Industry/DoD Task Force. Management is provided by a DoD

Steering Group, an OSD CALS Policy Office, and their counterparts

in each Military Department and the Defense Logistics Agency.

The CALS Policy Office has obtained the support of the National

Bureau of Standards in the selection and implementarion of CALS

standards. An Industry Steering Group has also been established

to focus the work of key industrial associations and the defense

contractor community in CALS implementation.

The Bureau has been funded since Spring 1986 to recommend a suite

of industry standards for system integration and digital daca

transfer, and to accelerate their implementation. NBS activinies

during 1936 were primarily aimed at:

o familiarizing NBS technical staff with key DoD logistic

functions and CA.LS demonstration projects,

o briefing DoD personnel, contractors, and other

interested parties on Federal, national, ar d

international standardization efforts that arc expected

to support CALS objectives,

o identifying a preliminary^ set of standards required for

data interchange in support of CALS, and

o developing reports on the four broad categories of

standards required to support the interchange cf CALS

digitized technical information: (1) product definition

data, (2) graphics, (3) text, and (4) data management.

As a result of these efforts, NBS made a preliminary

identification of several high-priority standards implemientations

1
needed for CALS data interchange and access.^ Building cn

knowledge and experience gained during FY86, NBS fo-..used on the

following activihies in FY87: developing a CALS Framework,

Develc.mert Plan and Core Requirements Package; providing

technical support fcr standarcs development and implementation;

£~d conducting workshops and meetir.gs no promote dialogue with

hhf: Services, the Defense Logistics Agency, and industry.

A major FY87 thrust was the completion of initial documentation

of the high-priority stc.ndards required in the CALS environment.

Some of these standards (e.g., SGML, IGSS) required tailoring or

enhancement. Other standards required a "push” (e.g., CGEK) fcr

their development in a timely fashion. These four volumes are a collection of the final reports presented to the CALS Policy

Office.^ The collection is divided as follows:

VOLUME 1:

Text

Evaluation of Text Interchange Methods

Plan for Conformance Testing for DoD Implementation of SGML

Guidelines for the Development of Tags for SGML

The- NBS FIPS - SGML Validation Suite

The NBS FIPS - SGML Reference Parser

Using SGML - Application Guidelines

ODA/ODIF Implementation Agreement a Dccumer.r Applicaricn

Profile

Data Management

CALS Report on Data Management Standards

Suppcrning Logistic Support Analysis (LSA) Using nhs

Information Resource Dictionary System (IRDS)

Media

ICST Recommendations on Optical Disks and Inrerface

Requiremencs for Planned EDMICS Procurement, Final

Report

Kemmerer, S., Editor, "Final NBS Report fcr CALS

FY86," U.S. Department of Commerce, National Bureau of

Standards, NBSIR 87-2566, May 1987.

The publishing of this collection of reports does nor

imply the CALS Policy Office has endorsed she

conclusions and recommendations presented.

11
Raster Compresr ion

Reporr on Raster Graphics

Tiled Raster Interchange Format, TF.IF Version 1.0, Rev. 1.2

Ccnforr.ance Testing

NFS Plaxn for Validation (Conformance Testing) of Computer

Products in Support of the CALS Program

VOLUME 2:

Graphics

Raster-to-Vectc.r Conversion: A State-of-the-Art Assessment

Development of CGM Validation Routines

CALS Application Profile for CGM

CALS Requirements Reflected in the Extended CGM (CGEM)

Standards Effort

A Reference Implementation for CGM, Functional Requirements

and Conceptual Design

IGES to CGM Translator Design Specification

VOLUME 3:

Graphics

CGM Registration For CALS Requirements

VOLUME 4:

Product Data

Guidelines for Testing IGES Translators

Guidelines for IGES Application Subsets

111
The fcllowirc' are additional deliverables completed by 3S du

FY87 but under separate cover. They are available through

CALS Policy Office.

CALS Core Requirements, Phase I.O

CALS Framework'

CALS Program Integration of Logistic Support Analysis and

Reliability and Maintainability Data Deliverables

CALS Current State of Digital Technology (Phase I.O)

CALS Workshop Proceedings:

Graphics Data Interface for Engineering Design and Tecnn

Publication Systems (January 13/14)

Introduction to the Core Requirements Package (April 23)

MILSTD-1840A, Automated Intercnange of Technical Infozrmation

MILSPEC-D-23000 , Digital Representation for Communication of

Product Data: Application Subsets

MILSPEC-M-280C1 , Manuals, Techrkcal: Markup Requirements and

Generic Style Specification for Electronic Printed Ou

and Exchange

ing

the

ca_

IV
C^T^TRIBI^TIONS

NBS would like tc acknowledge the major technical contributors to

this volume. In alphabetical order they are:

Jesse Crusey

Clarence Joiinscn

Bradford Smith

Thomas Wright
o:f

- r'- * n

r>.« tr* .'*'* ^#1 < _

"i#Mo l40x:t»ctBrtf;;n It I .eati-fXov mid^ » ,\

' CJIX^ ^’Bguir«0T - vtikcr:rtl»«i3BC

1^ . ^ "r\

Cy.lS rrA3Bi#«Js* (iPAniiot* tona^iBlD

Of'lba* "It

1/ CXi-S I^ro>5^r«a S'ipporr: Xnalf»l« ar»<s ^ t

p.€ixabxXitiy ane fteia‘tft:r*Bbil;tty C^n « ve: oJ>: vt J^j

i^dri *iW «Bi30flT

CM«$ Current fltAtB t>C *-.si '/^.ir^diiji^y (VliBBt ~.0>

CAtS MorK«|i9p Pri>oe>4X«isrf » •, Graphira inttc-fac » fcr tncrtfr^crln . amt

Pi«.’wr*«£af: ior.

Kt:>3Tn-.

Intirodv^rrirn

.9

»io Cora raxar^a »ac^a9a {AptiX W

40Ai X-fitBaatM tr tax4:-"..'r*^4f cf Tav-httioal rnioi-:?ietic!?^

4*<IZ^irKC*l>-“-J^OOO , ClbixaX Rapraaartatin for 'C«vmini-:a*:icn of

rrc»5ac^ Is*'.,. Applicaei^^n

.'Ci

Har^vai*^ Ti*;r^- v,:_.

* -srkvp Sll':;i:,raaan*:.5 and '

r. -4Tf- Jtyla spaeafiae-^c: fir ZI^zzt^t,\c <ktrut

IX-'iAn^a

C T*i \=-

«>*

V <

Vi

ir ’: <

•V

- ..^

i 'f ’

‘

. ef- *" ’ »

' ’ ^TK &':,


PRODUCT DATA

GUIDELINES FOR TESTING IGES TRANSLATORS

GUIDELINES FOR IGES APPLICATION SUBSETS
.J*

t
{.2. 1

' >.._-;-'w •* i‘ ,*i ». i sJ» /.• I 1*1^ f

pt^:r V

?:f

' ’

• -^ K~ .

^ - t

. ,, , : •^- «;•-* H V'V .' .

'

S'-rf-’'

•’ isr * ' X -

^ ,kt

% ^ . * • «i*

^.' >

—

• v-, Sfv-A^v -: .

,

, V M -± .

•

. tXf-* (•

b'-Ji" l::ra^, ^Tcirf in UMkvt$*

f/ ..

• -" ' . f -» . C- .... . ...

-

- frrof/sou4^<’«=* ’•‘•-‘.'s^inif. eyrt<^

'- ^

" -A^-S 1‘

'i,#^cjj4- ,d£ ;l:T-S »r^;4tSr!^Tt*Af.t:r4

' ^

- .' «£ -.‘-

.

^ 'b- tJi ^v« ,

.*» '

- f • ^ y^-

t.

"’T J y « '*t

' i' A.-r^4^i> to<^U to T^tins

:'3P<J

sT -i.^rr " '

. ' V*-,'*''' .., •* “' ; *K

J^'r . ^i’

'kv.\.'i‘0-V.''.. '.. *<41.“ • . 'Ji- 1'/ ' : -w

IGES TRANSLATOR TESTING

TABLE OF CONTENTS

1 . Introduction

2. Reference Model for CAD Data Exchange

3 . Error Sources in CAD Data Exchange

Error sources from sending system

Error sources from receiving system

Summary

4. The Hierarchy of IGES Translator Testing

5 . Verification Level Testing

6. Application Level Testing

7. Acceptance Level Testing

8. Software Tools to Support Translator Testing

APPENDICES

1
1. Introduction : This report presents results from the F/ 87 project c* digital product data undertaken by t'-.t Engineering CAD/CAM Group at tne

National Bureau of Standards (NBS). The work was sponsored by the

Department of Defense program on Computer al-ed Acquisition and '.rristics

('7ALS) and concerns the development of methods for testing t: qua.;ty

and completeness of Computer aided Design CAD) data en: range throug- the

Initial Graphics Exchange Specification \ i£S).

CALS resources were used to augment and a_celerate the NBS-lcd, voluntar;-

IGES/PDES Organization involving over 600 experts from 260 companies.

The goal of the FY £7 CALS sponsored program was to establish a National

Testing Program for ICES translators. The CALS funding produced

significant deliverables in the development of testing methodology for

ICES translators and in the development of the ICES application suoser concept and its incorporation into a formal military specification for

procurement of datasets.

The testing methodology being developed by the IGES/PDES Organization

committees recognizes three inter-related levels of translator testing:

Verification Testing

Application Testing

Acceptance Testing

The testing of vendor claims and conformance

of ICES translators to the ICES Specification

through individual entity tests.

The testing of functionality in

specific application areas through entityentity and entity-attribute interactions

User testing that assesses t" e degree

of com.patibility of different CAD/CAM systems

in the users' shop and operational

environment

The CALS objective in the verification task is to establish a National

Translator Testing Program under the direction cf the Society of

Automotir’e Engineers (SAE). Necessary ccnditicrs for t'-is include the

existence cf comprehensive testing procedures approved the IGES/PDES

Organization, the training of knowledgeable test teams, and the

development of veil documented test cases. The first was developed -ly

NEC under the CALS program and is reported here as the "Quicks tart

program.. This effort, presented in June 1987, integrated divergent views

in several ICES Committees and moved the organization towards consensus.

The approach was next refined and extensive _y tested under the name of

tC’. "Quic'xstart jr" program. The methodology is presently viewed as

fi: i.ched and ready for use by the SAE in tne trial phase testing program.

The verification methodology was thoroughly tested in the "Qui jks t.:-r t jr"

program against four CAD systems. Presentations of the methccologp' to

the various testing committees and outside observers resulted in

im.r rovemients to the. test scheme and its imp len.entar ion . During a live

2
demonstration of the verification two test incidents were encountered

chat caused an error report to be sent to one vendor.

1.1. Background

To the greatest extent possible, this document

represents both the philosophy and intent of the IGES Organization and

the NBS Center for Manufacturing Engineering. Readers are reminded chat

future progress in the implementation of the methodology as well as mutual development with the International Standards Organization

committee TO 184/SC4 testing effort make the material herein subject to

change and refinement.

The work has benefited from the collective experience in IGES testing

developed at companies participating in the voluntary effort. Three

important contributors were: 1) the Department of Energy DOEDEF project,

2) the General Motors Testing Program, and 3) the British effort at the

University of Leeds. Active discussions with representatives of these

projects continue to identify and incorporate the best features of each

program.

In 1986 the IGES Testing Committee determined that in order to achieve

its mission goals in a reasonable time frame, it needed to reorganize

into six separate IGES committees:

o Verification Testing Committee

o Application Validation Testing Committee

o Acceptance Testing Committee

o Test Case Committee

o Methodology Testing Committee

o User Information Committee

These six committees now comprise a formal IGES testing project

gives the IGES organization four projects 1.- IGES, 2.-PDES, 3.

.Methodology, and 4.- ISO activities,

NBS is working intensively with the committees in an effort to accelerate

the development of the methodologies and initiate a National IGES

Translator Testing Program under the control of the Society of Automotive

Engineers

Other work of the Testing Methodology Project includes or will include

the IGES Version 4.0 and 5.0 entities into the Verification Testing

program, development of Application Testing Programs, generation of

.Acceptance Testing Guidelines, and PDES testing.

1.2. Status

Verification testing requires both a methodology for

performing the test and test cases to be used for specific CAD systems.

Nnile developing and validating the methodology is a manageable task, the

development of test cases for all possible entities, form numbers and

attributes would require years of concentrated work. Clearly, this is

Th i s

- Testing

3
unacceptable for DOD , NBS , and the ICES community. To avoid this

proi-^em, the NBS IGES office developed e plan to put in place a simplified National Testing Program during the first quarter of 1988.

This plc.n, called "Quicks tart " , is complete in terms of the methodology

and procedures, and makes use of a subset of test cases capable of

surporting CAD systems and application sv -sets in typical use today.

The "Quickstart” approach was designed to verify those IGES entities

selected from the proposed DOD application subsets (Technical Publication

Illustrations, Engineering Drawings and Electrical/Electronic

Applications) . The effort developed anc used the same testing procedures

that will be used by the Society of Automotive Engineers. This allov-d

the testing effort to "shake out" the system with a reduced load of

entities and readily achievable goals.

The "Quickstart jr." approach was initiated in July with the intent to

produce the detailed orocedures required by the Society of Automotive

Engineers, (SAE) , and their testing agencies. To accomplish this, five

IGES test cases, a set of formal preprocessor and postprocessor test

procedures, four sep.^rate CAD systems and different ZAD users were used

to define and develop the testing process. The results of this work are Giscussed at length in this document.

Future testing activities will concentrate on developing and documenting

the complete set of test cases needed by the SAE. Attempts will alsc be

made to reconcile and utilize the efforts from DOEDEF, General .Motors

and the University of Leeds. The testing program at the University

Leeds is of particular importance because of their established base of

testing tools and testing experience.

.Accitionai efforts will be aimed at initiating the SAE testing program,

stabilizing the testing procedures, generating test cases for IGES

Version 4.0 entities, acquiring testing tools, and designin.g an

inform*ation system for manipulating the test results.

4
2. A Reference Model for CAD-Based Data Exchange: When dealing with the

issues of data exchange, it is usually beneficial to define a universe of

discourse in order to establish a common frame of reference. To that

end, the reference model shown in Figure 1 was created. The model was designed in the context of current IGES usage. That is, knowledg-. able

human inter\’’ention is a prerequisite for the information transfer

process. Human intervention is manifested in establishing local site

procedures for design control, user conventions for application-oriented

constructs, and the use of "common sense" to interpret the intended part

functionality

The reference model uses boxes to represent information formats such as the IGES format and the native CAD database formats. Arrows represent the

flow of information between these representations. Identifiers enclosed

in small circles are used to indicate the significant functions of the

model

Shown at the fop of Figure 1 is the representation known as product data.

Product data is assumed to be a fuzzy concept that requires the agency of

a knowledgeable human to translate its imprecise representation into that

of a local CAD system. The representation of product data is in the

domain of PDES and is beyond the scope of this effort.

2.1. A Typical IGES Data Exchange : The model shows the CAD data exchange

process to be a nearly symmetrical sequence of representations and

interface processes. The first element, labeled 1, represents the

designer, engineer, or CAD operator. It designates the iterative

processing performed by a user to translate the concepts embodied by the

part model into a valid CAD representation. The actions of the users are governed by design goals, application conventions , local procedures, and

the interface capabilities of the CAD system.

Element number 2 in the model symbolizes the local CAD database

representation, its support systems, and general capability. CAD

representation and functionality is of particular concern for acceptance

testing. Users need a good understanding of what functionality they

require and how that functionality is represented internally. These

issues will be discussed later in this report.

The third element identifies the conversion process from the native CAD

representation of the originating system to the IGES format. This

process, know as IGES preprocessing, may be an integrated module of CAD

system or a separate stand-alone utility.

The fourth element is the data representation defined by the IGES

specification "as seen by the sending system". The IGES representation

was designed to be a neutral format, rich in data elements to encompass

all CAD-related applications. However, due to application conventions,

different methods of encoding information, and ambiguity in the IGES

5
V j|> f enclose figure 1

r-’'- ,*r .“ <ir- ^vr^c:-

' r' '' vt;-/ ’ •

, •;

j. '’ • ''

A'pp UttAI- '

".'nJIt 'ifiil t

b 1 * 0

^' '--.'Vj -^ 5.'ll* .?:* -

; • •- c’ J . r- r: i i 4 H' .i^F’ /.

•

• n

*,,^4 I -f af, . . ;

.3&^

^rt 7 " M

. ^

$r*|t »cu

rr;***'-

i. . x-i. ML.'qJ. <yr. .r' . . ..^». i 34 i . \o' «^ttl

, > icl«. ^ r^., i l->

'

•?».. ,v: : _ i?jr.r4l«»b

t* /' -.• I J :*?'•. T :;-i

^. . -^ ' ^ *' ^

^ '. ‘ ’

. cgi^^V 70 . r i-# 7i.‘b 5 ..v j;

s . 3

’:•*•''• *•' *:•/,

‘ •¥z%. rhii V .

'

: iv ...4 ir'

^ • . 7''l't>i .olrri 5^

A..',rl -A-r i .•»#; Vi

k • •" » _

V’ r . . 1

.' •

( u . u?

.. ihlA. 51'

.-a -1

’ .-a qp

' - A . r'

. ^ li-i.' ; j <-' vi'r i)** i.v^\

; -

. . ! •'‘3* / ? CIi\J :i>C ii

" y ..

.: " •

.

- *

-

. • b

j

'. " '• ^

• •• • • •'’

' 9 ; f. . -sv:*,

0 7 '. _ -i

1 ;V ? VI " j..' . ::i5_T; . vsa ' * «*

!f i>-' _ ,. 7 r,-^ - 1 „ >.1 > f . t

’ *. f) ;

M r i.,., . •' <-.'.

. ,.Ar7:.,V; 7 . .-^j,

IrJitaVs iVj

C- Ja J 0 J M »w 1 1 i

.' V'J- . : *d

:' ’ .' '.;m , u

'- * • id r*

*” •T j lo'i trr-‘ fj T i» -

’

. .’ : J *. .> vj ^

• “

: i:

' . •» w' P

L'-;; -(7 : i 3 ’TC J . rtifiw I0 ^

>o*; 33 '' >»2«*iT . / J .ii.T^ie.

'•

• i.s-jnst »xq» : «i

fi.- ;

OAD a%* i 3A,n .•/! 1 3:v'':' jA,ji;>0Tq .fiot»?^.' *ff7 5sili.'‘'5bu jrar^I- l>7i i-* pldT MOT */»? «'» 9f*^ryu gn:ji»niaiTt > 4 : 'i " '/c

3 ivjn; ' »• OaO 20 uJoi*' .-' D'& 0 i- 7 ;3c»‘» 7 * ill •f^-j :sivt 39oiq^btq.

.\'*.J :u 9/Toi-ft *b/Mk?f 6 XO

w 3 ''I 'A <'..9 r i"' .a:.’ i';^!-''.r; ru-s-iqs; ^t».b »d^ a

r;ci:*ir r.'rsir'jjq"-:

2.'. Aqoo'. na e,j ,.:n .,;.

. .'ro f 7 n t» v;:u 7 7 a

•*. ” v»*^Yi- ,^nJlKjA« ofta lMt'7 2 ;» & 3 K0/ at .ti'.': Zj^xr^-3't !^^ZU-y r, iv o7 t

v->jf tstjO , reVf'vi.. !-’

. M'n“'

i qc 5 b-dl*

I dfi.'* ai rjii/i.l ivs* :>rn: rrtSM.'O^tri ^j;' bo-;.;!© l.> .'bo

‘. biiA no - .'!• ? 9 iqai

I..' o*> -. »> L<**n ;i*5 ' ;. TiJts:

l,Atc'’' • "J ::>.T L :'

:-;"L.l ' 9

‘.' - - - £^»s-? 2 l
specification, there can be multiple, correct interpretations of the

information contained in an IGES file. For example, at one site the

conventions may dictate using connected line segments to indicate fluid

flow. At another site with different conventions, this information may

be lost. For this reason the IGES representation as seen by sending and

receiving system are separated. The difference in IGES usage is often

referred to as "flavoring".

The fifth element is the transmission of the IGES file from the sending

to a receiving system. The manner of transmission is unspecified. It can be via magnetic media, optical disk, local area networks, or telephone link. Typically an error detection and correction scheme is

utilized to ensure data integrity.

Elements six through nine are reflections of elements one through four.

Item six is the representation of an IGES file as seen "by the receiving

system". For reasons previously stated, the IGES neutral format can be

interpreted differently by the sending and receiving systems.

Element seven designates the IGES postprocessing step which converts the

IGES format into that of the receiving CAD system. There is one significant difference between the interactions of elements two and three

versus the interactions between elements seven and eight. For the

preprocessing step, the software implementors will typically have a firm

conceptual grasp on the information to be translated to the IGES format.

It then becomes a matter of finding the most appropriate data elements in

IGES to do the job. On the other hand, designers of the postprocessors

need to be ready for a wide variety of entities, forms, and

functionalities

The final element identifies the operations of a CAD operator who

inspects the CAD database and assesses its correctness. Errors are fixed

according to the operators interpretation of the CAD database and value

is added to the part data. Again as in element one, local application

conventions and site procedures are applied.

7
3 . Error Sources in Data Exchange: Errors in data exchange can be

thought of as the failure to accurately transfer information from a sending system to a receiving system. The failures can be caused by

errors of commission and errors of omission on the part of implementors

and users of CAD systems. They can also be caused by ambiguities in the

standards \ised to encode and transfer the data such as ICES and the data

media protocols.

The reference model illustrated in Figure 1 is particuiary useful in

looking at error sources. All errors can be associated with the

representation of data or the communication processes between the

representations . Representation errors arise from ambiguity, logical

errors, and incompleteness. Process and interface errors can be

procedural errors, software bugs, and human misunderstanding. These

error sources will now be expanded from the point of view of the sending

and receiving systems.

3.1.

Error Sources from Sending system : Error sources on the sending

side can be thought of as origination errors. They include software bugs

design flaws, improper local design conventions, and errors induced by

tolerancing and precision problems. Most of the error sources in this

class, especially those concerned with engineering and design practices,

are not within the scope of data exchange errors.

3.1.1.

Human errors

Human errors as described in the model shown in

Figure 1 are errors introduced by human mistakes. These include errors

in the local site conventions, misuse of the software and the inability

to represent part model information through the CAD system interface.

Some of these errors are subtle and not really errors in their own right

For example, a local site convention may use a particular set of

geometric elements and associativities to describe a high pressure steam

pipe. When transferred as a series of drawings to another site, this

information is lost and requires human interpretation to reconstruct its

intent. Because the operator on the receiving must guess, a possible

error source is introduced because the original intent has become

unclear

3.1.2.

CAD Representation errors : CAD representations present us with

another error source. There are of course software bugs, which when

found, can be fixed. Other problems of a more difficult nature involve,

change control, inadequate representation functionality, and missing

functionality. As mentioned before, these latter error sources are not

necessarily errors on the part of the CAD system. They arise due to a mismatch of expectations between the sending and receiving CAD users and

sending and receiving CAD implementors.

Change control error sources occur when a system is modified and an unexpected change in functionality occurred. An example occurred when a vendor changed his text handling technique. Normally this would be a

8
trivial concern, except that in one application a small position shift

occurred on the lettering of a printed circuit board. At the new

position, the lettering shorted out two conducting paths which, in turn,

caused a board failure.

Missing, inadequate, and mismatched functionality occurs when a user

cannot represent desired part functionality in the CAD database. It can

also occur when the functionality inherent in the database cannot be

transferred either to ICES or to the receiving CAD system. Mismatched

functionality occurs when the representation forms on the sending and

receiving systems are sufficiently different so that identical

functionalities can not be transferred. Examples of this have recently

surfaced on two systems that had different conventions for handling level

and color information. One popular CAD system associates color and level

so that only one color can be defined for a given level. While this is

not an error, test cases designed to transfer information to a level

using colored entities were not successful.

3.1.3.

ICES preprocessing : The ICES translators are the most obvious

and most often cited sources of error. Historically, this was caused by

the general poor quality of translator software and the lack of support

given to ICES translators by the CAD companies. Modern translators are vastly improved over their predecessors and are undeserving of their poor

reputations. What this discussion will show is that many of the errors occurring in the exchange process are introduced by differences in

expectations on the receiving and sending systems and not due to faulty

software

Errors introduced by preprocessing include: improperly constructed ICES

files, poor choice of entity mappings, and the inability to represent

native functionality in the ICES format.

3.1.4.

IGES format errors : As stated previously, element four

identifies the IGES format as seen by the sending system. The class

includes generic IGES problems such as erroneous and ambiguous

specifications. These problems have received a great deal of attention

in the user community and will not be elaborated. A second source of error occurs because there are multiple, correct IGES representations for

a given CAD database element. When compounded across the entire CAD

database, a very large set of correct IGES files can be generated to

represent the same part. In a data exchange, the implementor of a preprocessor has the advantage of knowing the intent of the native

database. To him, having multiple representations will be seen as flexibility. He will merely choose the IGES entities which most closely

match his native entities. The implementor of the postprocessor does not

have this advantage and must make assumptions about the intent of the

file. Thus, a possible error source is introduced.

3.1.5.

Transmission Errors: Transmission error occurs when data files

9
transmitted from the sending system do not match the data files received.

These errors are of two types, transmission and interpretation.

Transmission errors are usually induced by noise or device malfunction.

It can include magnetic media failure, improper head alignment on a floppy disk drive or a lightning burst over a telephone line. With

current error correcting protocols and modem device drivers, these are usually not a problem. Errors are more likely to occur through the

misinterpretation of the file structure of the correct data files.

Each computer operating system has its own definition of what a file

should look like. Larger systems will have several choices of file types

to choose from. When files are transferred to other systems (electronic

bulletin boards, local area networks, and magnetic media), a file

structure change can occur that is invisible to the user. This was dramatically demonstrated during IGES testing at NBS when valid IGES

files could not be pos tprocessed. Fortunately, when the file type is

misused, the error is so severe that it cannot remain undetected.

3.2.

Error Sources from Receiving Systems : The list of possible error

sources from a receiving system accurately mirrors the error sources from

the sending system. The major difference between the two sides is that

the sender, knowing what to communicate, must select a representation to

capture his intent. The receiving system has an open-ended task. From a large set of choices, all reasonable constructs must be interpreted and

higher orders of information associated.

3.2.1. Transmission Errors : As mentioned in section 2.1.5, transmission

error occurs when data files transmitted from the sending system do not

match the data files received. The errors are of two types, transmission

and interpretation. Transmission errors are usually induced by noise or device malfunction. It can include magnetic media failure, improper

head alignment on a floppy disk drive or a lightning burst over a telephone line.

Interpretation errors typically occur because of differing expectations

of file and carriage control. Interpretation errors can be induced by

either the operating system or application programs.

3.2.2.

IGES format errors : This identifies error sources inherent in

the IGES format as seen by the receiving system. Included are the generic

IGES problems such as erroneous and ambiguous specifications and those

induced by multiple correct representations of CAD functionality.

3.2.3.

IGES Post-processing : The IGES pos tprocessor and preprocessor

share the dubious distinction of being the best known and most often

cited error source. As with many examples of "common knowledge" this may

be untrue. Development of this representational model has shown that

most exchange errors may occur at the logical level. However, this

10
assertion of this needs to backed up facts and such facts are not

available

Errors introduced by postprocessing include: improperly constructed IGES

files, no support for specific entities, and the inability to represent

all entity functionality inherent in the IGES construct.

3.2.4. CAD Representation errors : Error sources for CAD representations

on the receiving system include software bugs,

inadequate representation functionality, and missing functionality. As

mentioned before, most arise due to a mismatch of expectations between

the sending and receiving CAD users and sending and receiving CAD

implementors

3.2.5. Human errorsHuman errors are mainly derived from

misinterpretations and errors associated with site specific and

application specific conventions. When human intervention is necessary

to correct or restore a part model, the operator must detect those items

that require change and modify them. Since this is an iterative process,

the operator mirrors the originator of the part. Consequently, he must

follow local conventions and be subject to the same error sources.

3.3. Conceptual Grouting : As with any complex process, there are multiple ways to classify its behavior. The error sources discussed so far have been presented along sequential and functional lines of data

flow. If viewed conceptionally , another useful grouping of error sources emerges with the concept of functional intent.

Functional intent can be defined as the process of transferring the

original design intent from one system to another. This involves the use of a representational form and a translation to and from the form as shown below.

This process occurs between each representational form. From figure 1,

these are the product data model, the sending and receiving CAD

databases, the human operators internal modeling, and the IGES format. can now be collected into these five categories for each operation

in the data exchange process. However, since two of these five

categories deal with functional intent and another two deal with

11
translation choices we can reduce the errors groupings to three error

classes. A functionality class including error sources that derive from

the capabilities of the CAD systems to capture the intent of the original

part model, a translation class that includes errors generated by

translation and interpretation, and finally a representation class that

includes error sources induced by the representational format.

For completeness, a fourth class is added to include general operational

errors. This includes human error, software configuration management

errors, and transmission noise and media failure. The following table

summarizes these error sources by class.

12
4. The Hierarchy of IGES Translator Testing : Before starting to use

IGES as a mechanism for CAD data exchange for production quality

information, it is prudent to test the translators that will be used. As

has been the case with General Motors, Boeing, Hughes, the Seawolf

project, and others, testing is a laborious and demanding task. The task

is also extremely complex and if approached without a formal plan, will

consume tremendous amounts of manpower.

4.1. Three Level Strategy : The IGES/PDES Testing Methodology project

has developed a three level strategy for translator testing that produces

detailed test results with a minimum of resources. It is based upon a division of workload into portions that are generic to all users and CAD

systems, portions that are common to a specific application, and portions

that can only be tested in the user's own system environment. As

previously defined, the strategy divides testing into three levels:

verification - which focuses on individual entity tests,

application - which deals with entity-entity and entity-attribute

interactions , and

acceptance - which looks at system to system exchanges.

Each level builds upon work done at the lower levels. For instance, the

application level testing cannot proceed unless verification testing has

been completed on each entity and form number that is in the application

subset. Furthermore, this three level strategy allows the common aspects

of all testing to be done at a single site and thus supports ail users of

the IGES translation. Such a site is the envisioned SAE national testing

program to do verification level testing. Test results from the SAE can

be used by all application level testing and those in turn are used in

acceptance level testing.

4.2. Gatherinz Data on CAD Error Sources : A comprehensive data gathering

effort must be looked at from several different perspectives. The first,

and the basic building block for the others, is gathering data on specific CAD systems. Specific error sources induced by specific

systems need to be cataloged in both preprocessor and postprocessor

modes. This is the verification test which includes a comprehensive

approach for intra-system testing and data gathering to accurately

characterize the features of a given system and check those features for

conformance with the IGES Specification. At this time, these tests are being developed and tested. Specifics of the "Quickstart" implementation

will be discussed in the next section on verification level testing with

the actual results presented in Appendix C.

The second front for data gathering is in the area of application level

testing. IGES application subsets have been defined for three candidate

applications. It is expected that as the necessary information models

become available and usage guides written, error analysis will begin.

13
The final front is concerned with errors generated on specific systems at

specific test sites. Data gathering and analysis of inter-system data

exchange is the subject of acceptance testing. This process is the most

important to the end user because it will show what errors he can expect

in his own shop and provide guidance for avoiding them. Error detection

and correction lies at the heart of the acceptance testing concept.

Consequently, it will be discussed with the acceptance testing section in

this report.

The verification test is a very important component of the acceptance

test. Basic operations done during the verification process must also be

performed for the acceptance test, (the derivation and testing of the

entity map being the most significant) . Without the verification results-,

the end user would have to design his own site specific verification test

to gage ICES performance and characterize his CAD systems prior to

investigating inter- system data exchange. This burdensome function would

be further duplicated at other sites that are attempting to come to terms

with their CAD data exchange needs. Acceptance testing is discussed in

Section 6 and Appendix E.

14
5. Verification Level Testing : Verification Testing is the first part

of a three part process aimed at improving the quality of digital product

data transfer. It addresses the concept of vendor claims, the

correctness of individual entities read into and written from CAD/CAM

systems, and overall conformance to the IGES specification.

5.1. Approach : The goal of the Verification Testing effort is to

establish an independent, national program to test IGES translators. The

trial phase of the program, which will be run by the Society of

Automotive Engineers will help establish a defined level of quality for

IGES translators.

A key concept in Verification Testing is that of the vendor claim. Unlike

most standards, IGES is not designed to be fully implemented by system

implementors. This circumstance arises from the richness and

application-specific entities in the IGES specification. System

designers implement those entities which are meaningful for their

application areas. As a consequence, it is necessary to determine what an IGES translator supports and what restrictions are placed on its use. To

capture this information, the concept of the vendor claim was developed.

It consists of the following.

o Postprocessor Entity Map

o Preprocessor Entity Map

o Definition of functionality for the maps

o Statement of system limits

It is the objective of the Verification Test to take the vendor claims

and "verify" that they are correct through the use of the IGES test

library and analytical comparisons. The actual tests will be run by a testing agency selected by the SAE.

Results from the testing agency will be reviewed by the IGES Verification

Panel, which is made up of IGES members, IGES users, and industry

representatives. The panel will evaluate the results of the tests and

produce its findings. If necessary, a 30-day review period will be

granted for negotiations with the vendor and retesting. Following that

period, a verification report is issued stating the claims that have been

'verified. The Verification Panel will be under the jurisdiction of the

SAE Review Board which monitors the activity of the testing program.

The Verification program will have to ramp up for complete Version 3.0

testing over a period of two years. Over two thousand test cases and

test scripts with accompanying documentation and expected results must be

produced. This will clearly take time and effort. Since it is

unreasonable to delay the start of testing until all IGES capabilities

can be evaluated, a phased approach will be used. An initial selection

of Phase I entities has been chosen from the DOD Technical Publication,

Engineering Drawing, and Printed Circuit Board application subsets.

15
The different phases of the testing program are defined below. The

Preliminary Phase and Phase I. are described in detail by the appendices.

This approach allows for a trial testing period during Phase I., which

will accommodate the need for internal testing and debugging.

Preliminary Establish the testing program and develop supporting

documentation and test cases. This phase is running now and will continue through the end of calendar 1987.

Phase I Start program in "trial mode" and add increasing levels

of testing complexity. Most testing will be manual.

Phase will run all of calendar 1988.

Phase II Add software tools to do more complete analysis of IGES

processors. Begin adding Version 4.0 entities. Phase

will run all of calendar 1989.

Phase III Begin automating the testing sequences. Add Version 5.0

entities and new tools for analyzing surfaces.

Phase will run through 1990.

5.2. Methodology Development : The basic concepts of Verification

testing have been in place since 1986. The next step required that these

concepts be expanded and translated into detailed instructions for those

persons performing the test. To this end, two projects were undertaken

to develop and test these procedures. They have since been dubbed

"Quickstart" and "Quickstart jr."

5.2.1. "Quickstart" : The "Quickstart" approach was defined so that a National Verification Program could be started in the near future. This

approach, led to the development of the material in Appendix A.

"Quickstart" broke verification testing into smaller problem domains and

created a time table for addressing unresolved technical issues.

It is important to recognize that the "Quickstart" approach did not

replace the existing testing methodologies. It produced an implementation strategy for those methodologies. Furthermore, even though

subsets were used to defined the initial set of entities to be tested,

"Quickstart" testing must not be confused with application subset

testing.

5.2.2. "Quickstart ir." : The SAE program requires clear and detailed

instructions to guide its testing. Creating and testing these

verification procedures on real systems was the subject of the three

month effort called "Quickstart jr."

The purpose of "Quickstart jr." was to provide a validation of all the

relevant material on testing methodology developed for the planned SAE

Test Program and to assess its completeness and technical quality on a narrow set of entity types. Qnce the methodology was proven using a few

16
test cases, the full breadth of test cases needed for a national testing

program could be developed.

Specific tasks accomplished in the "Quickstart jr." project included:

o Production of a detailed overview of entire verification process.

o Creation of detailed step-by-step pre and postprocessor testing

plans

o Production of five complete test cases with documentation,

construction scripts, and verification criteria - line, arc,

general note, angular dimension and subfigure.

o Tests of procedures on 4 CAD systems.

o Production of a prototype SAE Verification Report.

o Presentation of results to ICES testing committees

The project produced a detailed set of step-by-step procedures for

testing both preprocessors and postprocessors as well as suggestions for

revising the various ICES testing methodology documents. Also resulting

from the project were a set of all forms needed for data gathering, five

fully completed test cases and an example "SAE Style" test report on each

of four CAD systems.

NBS in conjunction with the IGES/PDES Methodology Testing Committee, two

CAD Vendors, and staff from the Naval Surface Weapons Center, the Navy's

David Taylor Research and Development Center, and Army's Labcom at Ft.

Monmouth initiated a test of the SAE procedures using five ICES test

cases, a specific set of test instructions , and four separate sites.

The first steps were to develop the detailed test procedures and select a group of sample test cases. The test cases chosen for the effort were

the line, general note, angular dimension, circular arc, and subfigure.

The procedures were derived from the testing methodology document. The

test procedures are included in Appendix A.

17
The first iteration uncovered a series of problems that had to be quickly

dealt with. These included:

o difficulty in following the test procedures,

o errors in test cases,

o difficulty with the construction details for preprocessor tests

on some systems,

o difficulties in design philosophy of one CAD system that made the

postprocessor test cases useless.

The problems encountered on the first iteration led to a much improved • second iteration. For this pass a series of entity test cases were

created that contained no extra colors, line fonts, levels or text fonts.

Next, a system of forms was designed to help guide the testing teams

through the procedures and help the reporting of results. It was felt

that the most efficient way to capture the intent of the testing

methodology was to embed it in forms rather than text. This led to the

development of a new forms packet which is included with the verification

procedures in Appendix A.

The results of the second iteration were far superior to the first. Some

minor problems with the test cases remained but very useful data was

obtained. These results will form the basis for developing the

verification methodology in the coming months. Results of "Quickstatrt

jr" are shown in Appendix C. and were presented at the St. Louis meeting.

5.2.3. Methodology Review : In order to demonstrate our methods and

bring more members of the ICES community into active participation with

the testing effort, a live verification test was performed and a homework

exercise was created. The live test featured two CAD vendors, Autodesk

and Cadkey, who supplied their systems and an operator for the test. The

procedures specified in Appendix A of "Testing Methodology of ICES

Translators and ICES Formatted Data Files Version 0.5" were followed with

a set of verification test forms contained in the Verification Request

Packet. These were filled out during the test, except for the vendor

claims, which had been entered prior to the test.

A verification test is a tedious process. Briefly, the test proceeded as follows

o The test team, vendors, and observers were assembled and a test

log was initiated.

o The hardware and software configurations were verified.

o The Volunteer Entity Test was run.

o The Global Section values were checked against those expected

from the vendor claims.

o The test plan was run for preprocessor testing of the line and

18
o general note entities.

The test plan was run for postprocessor testing of the line and

general note entities,

o The results were analyzed.

Both systems behaved well and produced a credible showing. The Autocad

system displayed more of the functional sub -components of the general

note than the Cadkey system. This gave the illusion that it handled the

test better. The observers were reminded that verification testing is

not a competitive event, and the test results are not a judgement of

system quality.

Two Incident Reports were generated on the Autocad system for the general

note postprocessor test . The entities were displaced from their expected

location. Analysis of the incident produced three differing views. 1

- the test case is in error, 2 - the Autocad postprocessor is in error, and

3 - the general note definition is ambiguous. Further discussion will

resolve the issue. Autodesk has stated that, if the problem is in their

software, they will fix it immediately.

From this demonstration two important points were illustrated. The first

is that verification is a slow, yet vital process requiring care and

commitment on the part of the testers. The second is that many of the

incidents reported in the early phases of testing will be about the test

cases. Discovery of ambiguity in test cases and procedures are welcome.

Once discovered, they can become the subject of corrections and

recommended practices.

The data gathering by the "Quicks tart jr" effort established the

information needed for the SAE program. Building on this work, a homework exercise was created to get more testing committee members

involved in the effort and to gather data from a wider range of CAD

systems. The exercise packet contained test cases, blank verification

forms, and the verification procedures.

5.2.4. Lessons Learned : The development of the implementation approach

and the public demonstration highlighted the following points.

o Test cases are much harder to design and perfect than first

imagined.

o A complete and comprehensive set of forms is necessary to capture

the testing methodology and guide testers through the procedures.

o Verification is a slow process.

o Verification forms are numerous and the results are massive. It

will be necessary to have computer assistance for the testing,

data gathering, and data analysis process.

o CAD system limitations and design features play a larger role in

19
test case design and selection than expected.

Nevertheless , the testing methods have been developed and validated, the

set of forms printed and tested, and several live tests performed. The

remaining testcase suite development is underway and should be complete

under the "Quickstart" scope in time to support the SAE program.

5.3. Role of the Society of Automotive Engineers: The IGES testing

program will be sponsored by the Society of Automotive Engineers. It is one of several testing programs administered by them. There are four

groups which participate in the testing program: the SAE staff, the

Performance Review Board, the IGES Verification Panel, and the testing

agency (ies).

5.3.1. SAE Staff: The staff of the SAE has administrative

responsibility for the testing program. These responsibilities include:

o Provide administrative services and support.

o Arrange logistics of meetings including meeting facilities.

o Maintain detailed financial information on incomes and

expenditures of the IGES Verification Program. Provide such

information to the Technical Board to assist it in establishing

appropriate fee structures.

o Arrange for appropriate legal counsel and report the findings and

recommendations of legal counsel to the IGES Verification Panel.

o Arrange for appropriate indemnification insurance for the IGES

Verification Panel.

o Assure compliance with all prescribed forms and Procedures

involving the IGES Verification Program.

o Hire a capable agency(ies) to perform the testing and provide

contract administrative support.

o Maintain appropriate records.

o Establish and maintain procedures to ensure the confidentiality

of certain results as appropriate.

5.3.2. Performance Review Board: The SAE Performance Review Board

serves as an overseer for the various review Panels sponsored by the SAE.

The Board reviews and approves the operating procedures of the review

panels as well as their membership.

20
5,3.3.

IGES Verification Panel: The IGES Verification Panel shall come under the jurisdiction of and report directly to the SAE Performance

Review Board. It shall be composed of people who are technically

competent in the area of IGES and CAD data exchange.

Subject to approval by the SAE Performance Review Board, the IGES

Verification Panel shall formulate operating procedures, rules and

operating guidelines. These guidelines will ensure that the testing

program adequately serves all interested parties, including industry and

the general public, while adhering to the principles, policies, and

objectives of the SAE.

The work of the IGES • Verification Panel is to review the test criteria,

testing techniques, and the results of the testing agency to verify that

IGES pre and postprocessors satisfy the requirements of data exchange as referenced in the NBS IGES specification. It is the responsibility of the

IGES Verification Panel to issue the formal verification results based on

the findings of the testing agency(ies). The panel may issue a statement

setting forth the review and the determination it makes to verify or dispute the conclusion reached by the testing agency(ies). It is not

anticipated that the scope of the Verification Panel's work will include

verification of ail the underlying hardware and supporting software for

the translators.

The IGES Verification Panel shall consist of adequate membership to

reflect the views of the users, interested agencies, laboratory testing,

and other interested and affected parties. Initially, the membership

shall be appointed by the SAE Performance Review Board. Subsequent

membership will also be approved by this Performance Review Board.

Specific obligations and duties of the IGES Verification Panel are given

in Appendix F.

5.3.4,

Testing Agencv: The testing agency shall be responsible for

verifying the hardware and software configurations, assembling the

appropriate test cases, performing the tests, and reporting the results

to the IGES Verification Panel.

5.3.5.

Scheduling of Verification Tests: Schedules for testing are to

be arranged by the testing party. However, due to the frequency at which

software releases are made and the number of vendors potentially seeking

verification, it is suggested that if verification tests cannot be

arranged on demand, that verification periods be regularly scheduled on

at a least quarterly basis.

21
5,3.6. Funding

The charges for this service shall be such that the

IGES Verification Program is self-supporting. Fiscal policy for the

program shall be established and monitored by the SAE Performance Review

Board.

22
6. Application Level Testing : Work during FY 87 on application subsets

resulted in the creation of a military specification on IGES application

subsets covering technical illustrations, engineering drawings and

electrical/electronic applications. Testing of translators at the

applications level builds upon the earlier verification level but places

additional conditions on completeness and range of values. Each

application subset specifies entity and form number requirements, entity

construction details, and ranges for parametric values within certain

entities. Each of these requirements has a corresponding testing

procedure. Details of the test procedures for the three applications

mentioned are documented in the same military specification. See section

4.0 of MIL-D-28000.

23
7. Acceptance Level Testing : Acceptance testing differs in three major

aspects from application testing. The first is that it is site-specific

and involves known parameters: specific systems, specific releases of CAD

software, and known applications. The second aspect is that data is

transferred across application areas. This leads to the third aspect,

which is ”100% data transfer is often not required nor possible”

When data is transferred from one application to another, only a certain

amount of the available information is useful to the new application.

The other data may be useful to other applications, but not to the target

application. For example, when a fully annotated part model is sent from

design to NC production, only the part geometry and manufacturing details

are of interest. The fact that the NC generation system does not fully

implement the general note entity or support line fonts may be of little . consequence. This allows the local engineers and technicians to narrow

their testing focus to the most important aspects of their data flow.

7.1. Introduction to Acceptance Testing .

It is the responsibility of the end users, (those people who have the

responsibility for moving CAD data between dissimilar systems, and for

validating the results of those transfers) , to determine the suitabili cy

of IGES translators for their applications and operating environments.

It is impossible for a single, independent agency to provide the level o testing required to make this determination for all users. Therefore, i is up to the end users to examine their own environments and to devise

appropriate tests to ensure that the proposed translators will perform

adequately. However, the task is simplified if verification and

application level testing has been accomplished previously.

The objective of an acceptance test is to determine whether a specific

pair of IGES translators adequately preserve the intended information

content while moving the associated data between sending and receiving

systems. In this context, the information content of interest in a part

model is that which will be required by applications running on receiving

systems downstream from the sending system.

Another way of looking at this situation is that we are trying to answer

the question: "Is this way of transferring product data better than the

current way of doing it?” In many cases, the baseline for data transfer

is the engineering drawing along with additional textual documentation.

Therefore, we are interested in comparing the total costs to effect the

data transfers. In both the baseline case and the case being evaluated,

the costs should include such factors as the costs to create the

information initially, to transfer the information, to repair any damaged

information and to recreate any missing information.

Testing of the IGES translator pair is necessary to determine the

reliability of the information exchange. The amount of testing done

should be directly related to the cost to the enterprise of any erroneous

or lost information. In accordance with this idea, the test cases should

24

rt
be reviewed and updated periodically to reflect the increased demands on

the information exchange, and the entire test suite should be rerun

periodically to identify any degradation of the translators as well as to

certify new versions of the translators. Because of this need to perform

acceptance testing repeatedly, a significant concern to the test designer

should be the ease of running and evaluating the test cases. A more

detailed discussion of acceptance test procedures and the design of

acceptance tests will be found in Appendix E.

The IGES Verification Program described elsewhere in this document will

provide a solid basis for acceptance testing by assuring that the entity

mapping claimed by the implementor of a translator accurately reflects

the processing carried out by that translator, and, in the case of

preprocessors, that the iGES entities are correctly formed. Once the end

user is aware of the capabilities and limitations of the translators, a more controlled and effective data exchange can take place between

dissimilar systems.

The results of the verification testing for a translator play an important role in assessing how effective the data exchange will be.

These results include the translator's entity map along with the findings

of the verification testers concerning the preservation of functional! ty

and the correctness of the entity formulations.

7.2. Use of entity Manning in Data Exchange : In general, entity mapping

can be described as the manner in which the implementor of a translator

has defined the correspondence between native entity forms (i.e., the

entity form maintained within a system) and the IGES entity forms (i.e.,

the entity form contained in the IGES specification). For example, a string of curve and line segments on a system may be translated into a Composite Curve entity (Type 102) by a preprocessor. This correspondence

of a string in the native form to a Composite Curve in the IGES form is

the preprocessor's entity mapping for the native string entity.

Similarly, a postprocessor may translate a Copious Data entity (Type 106)

into a 3D line entity on the receiving system under some circumstances.

Thus, the correspondence of the Copious Data entity to the line entity is

the postprocessor's entity mapping for the IGES Copious Data entity.

The forms for the preprocessor entity map shall include the names of the

native entities supported and the names of their corresponding IGES

entities along with the letter designation which identifies the degree to

which the functionality of the native entity is preserved in the

translation. The forms for the postprocessor entity map shall include

the names of the IGES entities supported and the names of their

corresponding native entities along with the letter designation which

identifies the degree to which the functionality of the IGES entity is

preserved in the translation with respect to the local site. These

letter designations are explained in the section dealing with reporting

the results of the verification tests.

25
The entity maps can be used as a first step in determining how well data

can be exchanged between two systems. Knowing the native entities which

are to be used on the sending (or initiating) system, the end user can

follow each entity through the entity map for that system's preprocessor

and the corresponding entity map for the receiving system's postprocessor

to see what the resulting entity will be. The end user can also get an indication of how good the translation of each entity will be by looking

at the corresponding letter designations for both translators.

Depending on the end user's application of the information being

exchanged, imperfections in the mapping and translations may be

tolerable. Acceptance tests should be performed to determine the effects

of imperfections on the overall information exchange. Based on the

results of the acceptance testing, the end user can strive to improve the

quality of the information exchange by:

o making use of options provided by the translator,

o exploring alternative entity mappings with the translator

implementors

o docuimenting errors found in translators during acceptance

testing,

o adding to and deleting from the list of native entities being

used, and/or,

o developing intermediate processors to deal with "flavoring"

during translation.

Flavoring is a term that is used to describe particular practices built

into translators to handle situations which are not covered by the IGES

specification, or situations where the native system has a peculiar

method of handling some data. For preprocessors this may be the case where the underlying system supports entities or relationships which are not directly supported by IGES . For postprocessors this may be the case where the underlying system does not handle the specific entities or relationships supported by IGES. Since the manner in which these

situations are handled are not standardized, other knowledge is needed

than that available in the IGES specification. This additional knowledge

is frequently built into the translators.

7.3. The Design of an Acceptance Test : The seeds for success of an acceptance test lie in constructing suitable test cases which will

adequately reflect the user's need for information exchange. The first

step in designing an acceptance test, then, is to identify the

information content of the data files to be passed. One way to begin

this task is to identify ail of the entities which are used by the people

who create these files on the sending system. The question is then asked

for each entity, "What information does this entity convey in the content

of the data file?" In some cases, the information content may be

conveyed by a group of entities instead of by a single entity. In a similar manner, the information requirements of the receiving system are identified. Finally, the intersection of these two sets of information

26
may be determined. It is this final list of information which provides

the basis for both the design of the test cases and the evaluation of the

results

The identification of the information content is an iterative process

which may involve negotiations between the senders and receivers of the

data files. Some of the negotiations may involve making modifications to

the modeling standards and conventions of one or both of the parties to

the information exchange.

7.4. The Design of the Acceptance Test Models : For the purposes of this

work, a test model is defined as a test case which resides on either the

sending or receiving system in that system's native data form. These

test cases will vary considerably in complexity, but, in general, will be

more complex and more application specific than the test cases used for

verification testing.

There are several, general principles which should be followed in

creating the acceptance test models:

o Each different entity, or group of entities, which occur in the

information model should appear at least once in the collection

of test models.

o Several, small, simple test models are preferred over one, large,

complex test model. The smaller models will be easier to build,

easier to validate, and their results easier to evaluate. In

addition, the results of large, complex test models have to be

examined much more carefully to ensure that no errors have been

caused as a secondary effect of another error in processing the

model. Some complex models may be required as a part of the

test, but these should be kept to a minimum.

o Include limiting (or boundary) conditions if they are important

to the information exchange. Into this category fall models of

large objects with small tolerances (e.g., 1597 +/- 0.00001). As

another example, if the use of layers is important in the user

environment, include in a model the use of layers which fall at

each end of the range of available layers.

o Where possible, test models should be self-checking . Redundant

data should be included in the model to simplify its evaluation.

For example, a test model with a surface could also contain

several curves which define the intersection of the surface with

specific planes. (This assumes, of course, that an earlier test

model has validated the use of the curves.)

o Create a script describing how to generate each test model. This

could be in the form of a command file for these systems which

support this feature. This script, along with an annotated

display of the test model, should be included in the

27
documentation for the test model.

o Each test model should be accompanied by a script describing how

to evaluate the results of the test. The script should contain

specific evaluation procedures and the quantifiable results where

possible. This script should also be included in the

documentation for the test model.

A sample suite of test models (and their corresponding IGES files) for an acceptance test is included in Appendix E.

It is important to recognize that the intent of an acceptance test is not

to exercise the translators exhaustively for all possible occurrences of an entity, but rather to seek assurance that the subset of occurrences

that the user is likely to see can be accommodated. As a result of this

understanding, pathological problems (e.g., a zero-length line or a zero- radius arc) need not be considered unless they are to be used to convey

specific information.

7.5. The Evaluation of the Results : The results of the acceptance tests

should be evaluated in the light of preservation of information content

(i.e., "Has the information content of the test model been preserved?").

This is most easily done by examining the errors which were identified

during the test and asking whether the errors diminish the information

content of the model for the application on the receiving system. As an example, if the application on the receiving system is N/C programming,

the preservation of text parameters in the drawing annotation (e.g.,

height, width, and intercharacter spacing) may not be important, while

the preservation of accuracy in the geometry would be.

A useful measure of the effectiveness of a transfer is given by comparing

the amount of time required to translate a test model from the sending

system (both pre- and post-processing , tl) and the time to repair the

test model on the receiving system (t2) with the amount of time required

to recreate the entire test model on the receiving system (t3)

tl+t2

( 1 ) * 100 %

t3

28
8, Software Tools : The development and use of software tools is an important concern for the IGES Testing Project. The existence of a set

of software tools that is useful and of reasonable cost is crucial to the success of the project.

Ideally, the tools for IGES testing should be in the public domain or readily available, supported, commercial products. To some extent this

has happened. Figure 4 shows a list of IGES-related software products

that are known to be available.

To date, there have been a number of attempts to completely specify and

describe the requirements for testing tools. These attempts have been

useful but not completely successful. This arose from two factors. The

first is that the IGES testing methodology has not stabilized

sufficiently to prove technical soundness and financial practicality. The

next reason is cost. Some of the tools and approaches proposed involved

levels of funding greatly exceeding anticipated resources.

8.1. Available Software Tools : Regardless of the structure of the final

testing methodology, some tools are known to be needed and are currently

available. These are shown in Figure 3. Briefly, the list includes

three different Syntax analyzers , three different IGES viewers and

plotting packages, an application subset checker, and an IGES transfer

forecaster. In addition there are some utilities including an IGES file

generator, a file compression utility, and a public domain IGES editor.

An important addition to this list is an IGES file comparator. This tool

is derived from a thesis by Rainer Glatz and purports to compare two IGES

files for equality. The comparator tool is not well known. The first

public discussion of it was presented at the St. Louis IGES meeting.

Currently there are no known U.S. installations of the product.

8.2. Validation of Software Tools : The case of the IGES comparator

brings an important issue into focus. How are software cools validated

for use in IGES testing. Though not formally documented, tool validation

is performed through usage by the IGES/PDES Methodology Testing

Committee. At a future time this validation will be performed by the SAE

Verification Panel in conjunction with the IGES Testing Project and the

testing agencies.

Not all tools will require validation. Certainly the IGES editor and

file compression do not. Those that will require validation are chose

chat judge aspects of the systems under test. The most obvious tool that

requires validation is the syntax checker. Ail files produced from a vendors preprocessor will be sent through the IDA analyzer or the IGES -QC

checker. These software packages must be correct. The IGES comparator

will require validation.

Its job will be to compare IGES file input to IGES file output. A

software tool error would seriously distort the testing results.

29
8.3. Desired Tools Do Not Yet Exist : It Is anticipated that a fully

operational testing program will need the following, additional software

tools

o A full screen IGES editor that Is sensitive to the construction

details of IGES files. The current NBS IGES editor is useful but

not practical for routine operations.

o A test case selector that extracts IGES test cases based on vendor claims.

o A test case generator that ran extract vendor claim information

and build valid IGES test cases from component parts. The tool • should operate automatically with little human intervention.

o A test reporting system capable of guiding the test team through

the test plan and logging the results of the test.

30
Currently Available ICES Software Tools

Program Type Name Source Type

Plotting IGES Files BASEVIEW Digital Equipment Co. C

IGESVIEW IGES Data Analysis Co. C

IGES View Loye and Associates C

ICES Syntax Checkers Verifier IGES Data Analysis Co. C

IGES QC Leeds CADETC C

IGES Check Loye and Associates C

Application Subset IGES Subset Loye and Associates C

Conformance

IGES Transfer LUDDITE Leeds CADETC C

Forecaster

IGES File Comparator IMDES Rainer Glatz C

! File Compressors COMPRESS National Bureau of Standards P Data Compress Signum Microsystems ?

IGES Editor IGES EDITOR National Bureau of Standards ? FILIGREE Interactive Design Consult c

1

1 IGES File Generator LUIGI Leeds CADETC

=

i

C = Commercial Product

P = Public Domain Product

Figure 3.

31
Appendix A. Verification Testing of IGES Processors

32
Appendix B.

Test Cases for Quickstart Jr.

This appendix contains the IGES file listings for the test cases used in

the Quickstart jr. testing. Tae test cases are for:

Circular Arc 100

Line no

Angular Dimension 202

General Note 212

Subfigure Definition 308
Appendix C

Test Results File

The following material was collected during the verification test of the

Autotroll S7000 CAD system. The methodology used was that described by

the "Quicks tart" and "Quicks tart jr" implementation schemes. The system

under test is owned by the Engineering CAD/CAM group at NBS . The

verification forms and instructions are contained in Appendix A.

Appendix B contains the test cases and their plots.

The following is a listing of the packets of information contained in

this appendix.

o

o

o

o

o

o

o

o

o

The packet delivered to the testing agency containing a Verification Request Form and the vendor claims.

Information filled in by the testing agency: The Test Results

File cover sheet, Test Plan Specification, Verification Test Log,

Test Incident Reports, and the Pre and Postprocessor Entity

Results Forms

Volunteer Entity Test with plots.

System printouts from the circular arc tests

System printouts from the line test

System printouts from the angular dimension test

System printouts from the general note test

System printouts from the subfigure definition test

Prototype of the SAE Summary Test Report
Appendix D

Appendix D contains the exercise given to members of the IGES/PDES

Testing Project. The package is not replicated in its entirety because

most of the material is included in other appendices in this report. The

specified material can be found as follows:

Appendix A - Verification procedures and forms

Appendix B - Test cases and plots

Appendix C - Examples of the procedures on a real system
Appendix A

Verification Testing of IGES Processors

Interim Verification Methodology

A. 1 . Introduction.

The following provides a detailed view of the interim Verification

Testing Methodology. Two related ideas should be kept in mind. First,

Verification Testing works with one translator at a time and thus does

not speak to the success of end-to-end data transfer in a users'

environment. System- to-system data transfer capability is the concern of

Application Validation and Acceptance Testing described in "Testing

Methodology of IGES Translators and IGES Formatted Data Files".

Verification Testing is concerned with a translator's completeness and

correctness in terms of the IGES Specification and the implementor's

claims of such. Second, while functionality, as defined in this document,

is important to data transfer, the concept is difficult to define in the

context of testing a single translator for compliance to the IGES

Specification. That is to say, a vendor may have several valid options

for mapping an IGES entity into a native entity in full compliance with

the IGES specification. However, users of the system may experience data

loss. For example, a circle translating to line segments may be

acceptable for a technical documentation system and disastrous for a system that generates NC cutter paths. Consequently, the implementors'

functionality claims will only be used to assist in the selection of

appropriate test cases for postprocessor verification.

The results from a verification test should provide enough information

about IGES translators so that users and vendors can make their own functionality assessment in the context of their applications and user

environments. It is only at the level of specific applications and

specific user environments that unambiguous functional assessments can be

made. Furthermore, the presentation of the testing results in the public

domain provides a sound basis for application and acceptance testing

analysis. This frees users from the burden of having to design and run

their own verification tests.

A. 2

Preprocessor Verification Procedure.

The preprocessor verification is initiated by an implementor (called the

presenter) filing a Verification Request Package with the IGES

Verification Panel. The Verification Request Package will contain a cover

sheet, (Form 1), a set of entity mapping forms, (Forms 8 and 9), and any

necessary system, application, and user documentation. Additionally, the

presenter must designate a knowledgeable technical representative to be
Appendix A

present at the test site for the testing period. The company technical

representative is an essential resource for the testing team to draw.

The Verification Request Package cover sheet contains identifying

information about the presenter and the processor to be tested. It also

contains a checklist of the information required to support the

verification testing. The documents required will vary from system to

system but ail documents submitted should be listed on the cover sheet.

The Verification Request Package contain both preprocessor and

postprocessor Entity Mapping Forms (Form 8 and Form 9) . These forms

contain an extensive listing of entities and their various attributes

(Note that these forms may not be available in time for release of

version 0.4 - Ed) that the translator purports to implement. The test cases selected will be chosen to confirm the accuracy of these forms and

the translators conformance to the IGES Specification.

When completed, the entire package is sent to:

IGE3 Verification Panel

Society of Automotive Engineers

400 Commonwealth Dr.

Warrendale, Pa. 15096

Attn: Gary Poliak

After reviewing the Verification Request for completeness, the IGES

Verification Panel will schedule the test and select a testing author! cy.

Negotiations between the presenter and the SAE and its agents will

determine the fees and location of the test. Based on the contents of

the Verification Request Packet and the IGES test case library a representative of the Verification Panel will create a test plan of the

tests to be run and the test cases to be used. These are listed on the

Verification Test Plan Specification, (Form 2) . The testing authority

then receives the test plan and performs the following functions;

Testing agency staff, a technical representative from the presenter,

and any observers (IGES Verification Panel members, other vendor

representatives) meet, review the test plan detailed on Form 2, and

coordinate their activities. This group constitutes the Test Team.

A test log (Forms 3 and 3a continuation sheet) is initiated by the

senior technical person from the testing agency. The meeting of the

test team in the preceding step is noted in the test log. This log is

to be kept in the format presented in IEEE Std 829-1983. The contents

of the log are discussed later.

A current, certified test case suite, on a suitable storage medium

(ascii, 9 track, magnetic tape or 5 1/4 inch floppy diskette) for the

system under test, is obtained from the National Bureau of Standards.
Appendix A

The test team inspects the hardware/software environment, including

the translator under test and doctomentation, and attests to the fact

that it complies with that described in Form 1 from the application

package.. This is noted in the Test Log.

A folder is prepared to hold the results of the tests to be performed.

This folder is commonly referred to as the 'results file'. The first

item in the results file is the cover sheet, Form 7.

The Volunteer Entity Test, described later in this appendix, as prescribed in the Test Plan is followed to construct a simple native ' model in the CAD system. The ICES file and a listing of the model is

next generated by running the Preprocessor according to the system's

operating procedures. A Test Log entry is made to note the start and

finish of the test. The IGES listing is placed in the results file

and identified by a reference in the Test Log. While the naming

convention for these and other entries are not defined, they must be a unique English name/number combination written on the paper copy and

in the test log. Use a Test Incident Report (FORM 4) to document any

operator input required for this task and any error messages or anomalies encountered. Extensive operator input or error messages

should be documented, if possible, by a printout placed into the Test

Results file and referenced by a Test Log entry or Test Incident

Report

Record in the Test Log the values for Global Section System ID (Field

5) , Preprocessor Version (Field 6) , and IGES Version (Field 23)

Compare these values against those obtained from the IGES files

supplied by the presenter if any were sent with the vendor request

package. The Volunteer entity test is one of these - Ed.) Note any

discrepancies between volunteer test results and the vendor- supplied

files on a Test Incident Report. In cases of extreme disagreement,

the test agency and the presenter will make a decision whether or not

to proceed with the test.

Record in the Test Log the resulting values for Global Section Date

and Time of Creation (Field 18) and Maximum Coordinate Value (Field

20). Compare against expected values and log any discrepancies.

Rerun the Volunteer Entity Test for each Preprocessor mode of

operation that will be used during the test. Document the volunteer

entities that are generated for each Preprocessor mode.

In a similar manner, run each test specified in the Test Plan. Follow

the construction script given in each test case to generate a native

part model in the CAD system. If any step in the script cannot be

accomplished, note the limitation and proceed. Collect screen plots

of each native part model and put them in the results file. Compare

the screen plot against the test case plot and note discrepancies in a Test Incident Report. Include all items in the Test Results file and

reference each item by a Test Log or Test Incident Report entry.
Appendix A

Use the verification or inquiry capability of the CAD system to

identify the entity content of the native model. Record the native

model entity content on the Preprocessor Entity Results Form (Form 5)

Convert the native part model to an ICES file using the system's ICES

Preprocessor. Carefully collect and label all printouts of operator

input and IGES file output. Collect a computer readable copy of each

resulting IGES file for later analysis. Include all items in the Test

Results file and reference each item by a Test Log or Test Incident

Report entry.

In later analysis work, run all IGES files produced through the IDA

and the IGES-QC Analyzers. Include printouts in the Test Results

file. Record the count of all errors and warnings. Subtract the

volunteer entities from the list of entities in the file to get the

Test Set of entities generated by the preprocessor for each test case.

Docioment the Test Set on the Preprocessor Entity Results form.

Analyze the Test Set as follows:

o Compare entities obtained against those expected for the

test case.

o Analyze Global Section against paragraph 2. 2. 4. 2 of the

IGES Version 3.0 specification for the following:

Product ID from Sender (Field 3)

System ID (Field 5)

Preprocessor Version (Field 6)

o Analyze Entity DE Section against mandatory fields and

permissible defaults given by Table 2-3 of the specification

and for specific content given in the individual test case.

A. 3 . Postprocessor Verification procedure.

The postprocessor verification is initiated in the same manner as a preprocessor test. An implementor (called the presenter) fills in and

sends a Verification Request Package to the IGES Verification Panel. The

Verification Request Package will contain a cover sheet, (Form 1) , a set

of entity mapping forms, (Forms 8 and 9), and any necessary system,

application, and user documentation. Additionally, the presenter must

designate a knowledgeable technical representative to go to the test

site for the testing period. The company technical representative is an essential and necessary resource for the testing team to draw upon.

The Verification Request Package cover sheet contains identifying

information about the presenter and the processor to be tested. It also
Appendix A

contains a checklist for the information required to support the

verification testing. The documents required will vary from system to

system but all documents submitted should be listed on the cover sheet.

The Verification Request Package contain both preprocessor and

postprocessor Entity Mapping Forms (Form 8 and Form 9). These forms

contain an extensive listing of entities and their various attributes

(Note that these forms may not be available in time for release of

version 0.4 - Ed) that the translator purports to implement. The test cases selected will be chosen to confirm the accuracy of these forms andthe translators conformance to the IGES Specification.

When completed, the entire package is sent to:

IGES Verification Panel

Society of Automotive Engineers

400 Commonwealth Dr.

Warrendale, Pa. 15096

Attn: Gary Poliak

.After reviewing the Verification Request for completeness, the IGES

Verification Panel will schedule the test and select a testing authority.

Negotiations between the presenter and the SAE and its agents will

determine the fees and location of the test. Based on the contents of the

Verification Request Packet and the IGES test case library a representative of the Verification Panel will create a test plan of the

tests to run and the test cases to use. These are listed on the

Verification Test Plan Specification, (Form 2) . The testing authority

then receives the test plan and performs the following functions:

Testing agency staff, a technical representative from the presenter,

and any observers (IGES Verification Panel members, other vendor

representatives) meet, review the test plan detailed on Form 2, and

coordinate their activities. This group constitutes the Test Team.

A test log (Forms 3 and 3a continuation sheet) is initiated by the

senior technical person from the testing agency. The meeting of the

test team in the preceding step is noted in the test log. This log is

to be kept in the format presented in IEEE Std 829-1983. The contents

of the log are discussed later.

A current, certified test case suite, on a suitable storage medium for

the system under test, is obtained from the National Bureau of

Standards

The test team inspects the hardware/software environment, including

the translator under test and documentation, and attests to the fact

that it complies with that described in Form 1 from the application
Appendix A

package. This is noted in the Test Log.

A folder is prepared to hold the results of the tests to be performed.

This folder is commonly referred to as the 'results file'. The first

item in the results file is the cover sheet, Form 7.

The test case suite (or as much of it as on-line storage permits) is

loaded onto the system and converted to the system's internal coding

in accordance with the vendor documentation provided. A hard copy of

the command sequence and responses to accomplish this will be saved in

the test results file.

The first test case is now processed by the translator in accordance

with the documentation provided with the test case. If additional

information is required from the vendor technical representative to

accomplish the translation, the exact additions will be recorded in a Test Incident Report and so noted in the log. Any error messages or other anomalies will also be logged.

The resulting part file will then be "activated" and displayed. Again,

any error messages, etc., will result in an incident report and be

logged.

At this point, a visual comparison between the screen display and the

plot of the test case furnished with the test case documentation will

be made and differences reported. A plot of the screen display will

be made for inclusion in the test results file.

Using all the verification capability available in the receiving

system, the part file is checked to determine the entity mapping and

f’anctionality claims from form 9 and the results recorded on the

Postprocessor Entity Mapping Form, Form 4. Functionality will be

verified in terms of geometry, structure, and annotation per J.

Fleming position paper of 7/87 (Again, this is the functionality issue

- Ed) . Details of what is to be verified will be found in the start

section of the test case under consideration. All verifications will

be supported with hard copy in the test results file.

The remainder of the testing will consist of repeating the above steps

for each test case in the suite. As before, all steps, problems, and error messages are recorded in the test log and all problems and error messages result in the generation of an incident report.

At the completion of testing, the test results file will be forwarded

to the test team leader or his designee for analysis, interpretation,

and the preparation of the summary test report.

. 4 . Documenting the test
Appendix A

A. 4.1. Test Results File .

There will be a file maintained for each test conducted under the SAE

Verification Testing Program and it will consist of 1) a cover sheet

(Form 7), 2) a copy of the application package cover sheet (Form 1), 3)

the test log (Forms 3 and 3a), 4) all incident reports (Form 4), in

chronological order, each with appropriate hardcopy supporting

documentation, and 5) ail entity mapping forms (Forms 5 and 6) , again,

each with appropriate hardcopy supporting documentation.

The results file cover sheet (Form 7) will contain the unique test

identification nximber and the names (signatures) and affiliations of the

test team and observers. The signatures are under a statement to the

effect that those signing attest to the fact that the file contains all

of and only those materials associated with the particular test

identification number.

The application package cover sheet is Form 1. The purpose of having it

in the results file is to define the hardware/software environment in

which the tests began. Any changes to that environment would be

documented in the test log and incident reports.

The test log will follow IEEE Std 829-1983. Form 3 with Form 3a as a continuation sheet, will be used for this purpose. The log will contain

the test identifier and a prose description of the test at the top of the

first page followed by three columns, 1) date/time, 2) event, and 3)

incident report reference. Subsequent pages will have the test identifier

and the three columns. The event entries will record the who, what, and

whys of all testing actions. Where any event results in an incident

report, the incident report number will be recorded in column three. For

an example of event entries, see Appendix A of IEEE Std 829-1983.

The Test Incident Report (Form 4) will also follow IEEE Std 829-1983. The

report will contain 1) the incident identification number, 2)

identification of the translator (with version number) under test, 3)

identification of the test procedure guiding the test, 4) specification

of the test case resulting in the incident, 5) reference to the test log,

6) a detailed description of the test incident, and 7) the incident's

impact on the tests. The description should include the inputs, expected

results, actual results, anomalies, date and time, procedure step

number, environment, attempts to repeat, testers and observers. Again, an example of an appropriate incident report may be found in Appendix A of

IEEE Std 829-1983. The incident reports should have sufficient detail to

be an aid to implementors in locating and fixing translator problems.

The Entity Mapping Results Forms record the results of processing the

test cases. Forms 5 (preprocessor) and 6 (postprocessor ) have been

prepared for this purpose. The forms will record the test identifier, the

translator identification, the IGES entity being tested, the test case identifier, the resulting native entity or entities, a statement of the

extent to which the result matches vendor claims, and a functionality
Appendix A

statement in terms of geometry, structure, and annotation. In addition,

there will be space for remarks, explanations, or comments from members

of the test team. Test incident reports generated as a result of the

particular test case should also be recorded.

A. 4. 2. The Summary Test Report .

The work of the testing agency on a translator verification will be

covered by a report which accurately, clearly, and unambiguously presents

the test results and ail other relevant information. The report will have

the test results file as an appendix but will stand alone as a document.

The testing agency is responsible for the generation of this document.

The summary report will contain at least the following information:

1) name and address of the testing agency;

2) unique identification of the report (such as a serial number)

and of each page of the report;

3) name and address of the presenter/ implementor

4) description and identification of the translator tested;

5) date of receipt of the translator test request and the date(s) of

performance of the tests;

6) description and identification of the hardware/software test

environment

7) a statement to the effect that the test results relate only to

the single translator tested when used in the specified

environment; 8) identification of the test methodology and

procedure followed;

9) a results section containing:

a) the test cases used;

b) the test cases for which expected results were obtained;

c) the test cases for which expected results were not obtained;

d) test cases for which results were inconclusive;

e) the number of "information only" tests run;

f) the number of planned tests not run;

g) the total number of tests run;
Appendix A

h) any additions to, deviations or exclusions

case specifications that took place;

from the test

i) disclosure of any non-standard test method

used; or procedure

j) a test discrepancy summary.

any disclaimers

11) a signature and title of person(s) accepting technical

responsibility for the test report and date of issue;

12) a statement delineating reproduction rights to the report.

Corrections or additions to a test report after issue by the testing

agency, whether because of objections on the part of the implementor,

ICES Verification Panel actions, or any other reason, shall be made only

by a further document, suitably marked, e.g., "Supplement to Test Report

Serial Number . . .

. " and shall meet the relevant requirements of the

preceding paragraphs.

Upon completion, the test agency will forward a copy of the test summary

report and the appended test results file, via the SAE, to the ICES

Verification Panel for review and concurrence. Upon completion of the

panel's review and the addition of any supplements that result from that

review, the panel will prefix its imprimatur to the document and forward

a copy to the presenter for review and comment. This action will begin

the 30 day review period in which the vendor can take reply to the test

results. After the review period and the addition of any supplements

required thereby, the test report will be ready for release. The final

report will contain:

1) The imprimatur of the ICES Verification Panel;

2) The Summary Test Report with Supplements to date;

3) The appended Test Results File.

A. 5

Volunteer Entity Test.

A. 5.1. Description

The objective of the volunteer entity test is to discover extra entities

present in the IGES file as generated by an IGES preprocessor. While

Volunteer Entity is a term that may have a very broad meaning, for this

test plan we will define Volunteer Entity as; IGES entity information

that has been added/created by the translator and placed in the directory
Appendix A

entry (D) and parameter data (P) section of the IGES file that is not

resident on the native data file.

The test begins with a simple set of construction details that are to be

executed on the CAD system to be tested. The model is then preprocessed

to create an IGES formatted file. A listing of this file will then be

analyzed.

Any additional entities contained in the listing that have not been

specified by the construction detail are volunteer entities.

A. 5. 2. Running the Volunteer Entity Test .

The test is executed by performing the following actions:

o Create a line between the following coordinates (1, 1, 1) and (3,

4, 5). If points are used to construct the line, delete the

points from the native data file before processing the IGES file.

0 Set line font as solid.

o If system is 2-D ignore Z values.

o Generate IGES formatted file.

o Generate a paper copy of the file

o Specify the CAD System and IGES Software products, their revision

level/release , and the hardware which generated the IGES file, on the file listing or on a separate cover sheet.

A. 6 . Imolementors * Privileges and Obligations.

It is important to the credibility of the Verification Program and the

IGES Organization that commercial implementors represent their support of

IGES appropriately. After completing the verification process, an

implementor has the privilege of so claiming in documentation and

advertising. The following wording is suggested for use by implementors

to designate their support of the IGES work:

"(Implementor's name) supports the work being done by the IGES

Organization. Our IGES conforming translators (insert version

identifications) have been verified by (insert name of independent

testing agency) in accordance with the procedures established by the

IGES Organization Testing Methodology Project. Detailed test results

are available on request from the ( name of sponsoring government
Appendix A

agency )

.

Implementors have an obligation to resubmit their translators for

verification upon changes to the software which might materially affect

the product's verification status.

If in a subsequent use of a verified translator, a user has reason to

believe that the translator is not working as verified, the user should

notify the Chairperson of the ICES Verification Panel. Such notification

should include sufficient information to recreate the fault. The panel

shall forward the notification to the presenter for response, and to the

test authority for review. If the presenter does not adequately resolve

the problem, the verification for the translator will be revoked.
IGES Verification Request

Company Name:

Conlact:

Address:

Phone: ( ) Dale:

Request for Verification of:

Preprocessor

Postprocessor

IGES Specification Version:

Configuration Information

CAD Software:

Version/Release ID: Release Date:

IGES Processor Name:

Version/Release ID: Release Date:

Computer Mfg: Model:

CPU: Memory Size:

Operating System: Version:

Supporting Information

Postprocessor Entity Maps System Limit Form

Preprocessor Entity Maps ' _ 'General Entity Test

Processor Documentation Volunteer Entity Test

Tape Access Documentation

Other (itemize)

For SAE Use Only

Vendor Request Number:

Assigned to: Date:

Form 1
Verification Test Plan Specification

Snee; o«

Vendor Request Number:

Vendor Name:

Test Log Identification Number:

Test Cases

Form 2
Verification Test Log

Sheet 1 ot

Test Log Identification Number;

Test Description:

Date/Time Incident Report

mm/dd/yy-hh:mm Activities and Event Entries Reference

Form 3
Verification Test Log Continuation Sheet

Test Log Identification Number:

Date/Time

mm/dd/yy-hh:mm Activities and Event Entries

Incident Report

Reference
Test incident Report

Incident Identification Number:

Test Log Identification Number:

Description of Incident:

Impact of Incident:

Form 4
Pre-processor Entity Results Form

Sheet of

Test Log Identification Number;

Native entity being translated:

Test Case Name:

Entity or entities in resulting IGES file:

Results agree with vendor entity map? Yes No

Description of functionality retained:

Incident Reports generated:

Remarks (with originator initials)

Form 5
Post-Processor Entity Results Form

Siiee; ot

Test Log Identification Number:

IGES entity being translated:

Test Case Name:

Entity or entities in resulting data base:

Results agree with vendor entity map? Yes No

Description of functionality retained:

Incident Reports generated:

Remarks (with originator initials)

Form 6
Test Results File

Test Identification Number:

Translator Identification:

The Undersigned certify that the materials and records contained in this file are all those . and only those associated with the above identified translator test.

Team Leader Affliliation

Vendor Reresentative Affliliation

Observer Affliliation

Form 7
IGES Processor Mapping Form

Global Section Characteristics

''“ndor Request Number:

stem Name/Version:

Date:

Field Attribute Supported Comments

Mark last column if continuation Name If ff Name Pre Post Sheet is used

Parameter Delimiter 1 Record Delimiter 2

Product ID 3

KjES File Name 4

Vendor System ID 5

Preprocessor Version 6

--

Bits per Integer 7

Single Precision Mag. 8

Single Precision Signf. 9

Double Precision Mag. 10

- Double Precision Signf 1

yroduct ID (receiver) 12

Model Space Scale 13

Units Flag 14 1 INCH

2 MM

3

4 FEET

5 MILES

6 METERS

7 KILOMETERS

8 MILS

9 MICRONS

10 CENTIMETERS

11 MICROINCH

Units 15 2HIN —

2HMM

2HFT

2HMI

Form 8A Sheet 1 of 3
IGES Processor Mapping Form

Global Section Characteristics

"ndor Request Number:

Field Attribute Supported Comments

Mark last column if continuation Name ff ft - Name Pre Post Sheet is used

Units (continued) 15 1HM

2HKM

3HMIL

2HUM

2HCM

3HUIN

Line Wt Grads. 16

Max Line Width Units 17

Date/Time Stamp 18

Min. User Resolution 19

Max. Coord. Value 20

Name of Author 21 Organization 22

"S Version Number 23 1 1.0 ^

2 ANSI Y14.26M

3 2.0

4 3.0

Orafting Standard 24 0 None

1 ISO

2 AFNOR

3 ANSI

4 BSI

5 CSA

6 DIN

7 JIS

1 1

Form 8A Sheet 2 of 3
IGES Processor Mapping Form

Global Section Characteristics

''endor Request Number:

Continuation Sheet

Field Comment

- -

Form 8A Sheet 3 of 3
Preprocessor Mapping Form

Directory Entry Characteristics

Vendor Request Number: Date:

Field Attribute Supported Comments

Name /i^ Name Pre Post

Mark last column if continuation Sheet is used

Structure 3

Line Font 4 1 Solid

2 Dashed

3 Phantom

4 Centerline

5 Dotted

Level 5

View 6

Matrix 7

Label 8

S Blank 9a

ta Subord. 9b

tu Use Flag 9c

s ,

1 Hierarchy 9d

Line Weight 12

Color 13 0 unassigned

1 Black

2 Red

3 Green

4 Blue

5 Yellow

6 Magenta

7 Cyan

8 White

Label 18

Subscript 19

I '•cirriucf of Wuilipic Ehiiiies Pet Levei Permiiled;

Number of Multiple Colors Per Level Permitted:

Total Number of Levels Permitted:
Preprocessor Mapping Form

Directory Entry Characteristics

Vendor Request Number:

Continuation Sheet

Field Comment

•

Form 8B
Sheei

Preprocessor Entity Mapping Form

Vendor Request Number:

Vendor Entity IGES Entity

ID Name (f Form

. ^ Name

«

•

Form 8C
Sheet

Postprocessor Entity Mapping Form

Vendor Request Number:

IGES Entity Vendor Entity n Form Name ID Name

Form 9
Appendix B.

Test Cases for Quickstart Jr.

This appendix contains the IGES file listings for the test cases used in

the quickstart jr. testing. The test cases are for:

Circular Arc 100

Line no

Angular Dimension 202

General Note 212

Subfigure Definition 308
s F ElOOOOOO.AOl S A S V IGES 3.0 S

I Entity Test designed to show correct geometry only without S attributes such as level, font, and color. The entity is S IGES 100, Form 0--the circular arc. S E Entity Form Type Counts

100 0 4S

P Visually verify, comparing with the accompanying plot, S that four circular arcs were generated as follows: S A full circle in solid line font S A 270 degree arc through quadrants II, III, and IV S in solid line font S A 90 degree arc through in quadrant III in solid S line font S A 180 degree arc through quadrants II and III in S solid line font S Using the system's verification commands, verify that: S The full circle is in the Z=10 plane, is centered at S (15,15,10) and starts and ends at (15,5,10 or S degrees. The radius should be 10. S The 270 degree arc is in the Z=-10 plane, is centered at S (15,-15,-10), starts at (15, -5, -10 or 90 degrees), S and ends at (25,-15,-10 or 0 degrees). Its radius S should be 10. S The 90 degreee arc is in the Z=-10 plane, is centered S at (-45,15,-10), starts at (-55,15,-10 or 180 S degrees) and ends at (-45, -5, -10 or 270 degrees). S Its radius should be 10. S The 180 degree arc is in the Z=0 plane, is centered S at (-45,-15,0), starts at (-45, -5,0 or 90 degrees), S and ends at (-45,-25,0 or 270 degrees). Its radius S should be 10. _ S R Post processing this file should produce four circular arcs S of radius 10 located as indicated in the P section above. S The 360 degree arc may be mapped to a circle on some systems. S C To prepare this test case for a preprocessor test, create S a geometric data base on the system hosting the translator S according to the following script (Level, font, and color S are default) : S 1) Construct a circular arc of radius 10 in the Z=10 S plane, centered at (15,15,10), starting and ending S at (15,5,10 or 90 degrees). Some systems may S require this to be constructed as a "circle". S 2) Construct a circular arc of radius 10 in the Z=-10 S plane, centered at (15,-15,-10), starting at S (15. -5.-10 or 90 degrees), and ending at (25,-15,-10 or S 0 degrees) . S

12

34

5

6

7

89 10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49
3) Constxruct a circular arc of radius lOin the Z=10 S plane, centered at (-45,15,10), starting at (-55,15,10 S or 180 degree's), and ending at (-45,5,10 or 270 S degrees) . S 4) Construct a circular arc of radius 10 in the Z=0 S plane, centered at (-45,-15,0), starting at S (-45, -5,0 or 90 degrees), and ending at (-45,-25,0 or S 270 degrees) . S 5) Hake a plot of the resulting graphics model and S compare it with the plot accompanying the test case S N WARNING: This file has been accepted as a candidate test S file by the Test Case Development Committee but it has S not been approved as a member of the Test Case Library. S D Not available S H 02-0ct-1987 DOR created this file S L These data were prepared in conjunction with work sponsored S by an agency of the United States Government. Neither S the United States Government nor any agency thereof, nor S any of their employees, makes any warranty, express or S implied or assumes any legal liability or responsibility S for the accuracy, completeness , or usefulness of any S information, apparatus, product, or process disclosed, or S represents that its use would not infringe privately owned S rights. Reference herein to any specific commercial S product, process , or service by trade name, trademark, S manufacturer, or otherwise, does not necessarily constitute . S or imply its endorsement, recommendation, or favoring by S the United States Government or any agency thereof. S

S

, .8HE1000000, ,12HHANDMADE 1 . 0 , 3H1 .0 , 32 , 38 , 6 , 38 , 15 , 8HE1000000 , 1 . 0 , 1 , G

4HINCH, 1,0. 001, 13H021987. 074640, 0.0001, 100. 0000, , ,4,0; G

100 1 10 0 OOOOOOOOOD

100 ' 0 0 1 0 CIRCARC ID

100 2 1 0 0 -•OOOOaflQaOD.

100 0 0 1 0 CIRCARC 2D

100 3 10 0 OOOOOOOOOD

100 0 0 1 0 CIRCARC 3D

100 4 10 0 OOOOOOOOOD

100 0 0 1 0 CIRCARC 4D

100 . 10 . 0000

15 . 0000 . 15 . 0000 . 15 . 0000 . 5 . 0000 . 15 . 0000 . 5 . 0000 , IP

100 , - 10 . 0000 , 15 . 0000 , - 15 . 0000 , 15 . 0000 , -5 . 0000 , 25 . 0000 , - 15 . 0000 ; 3P

100 . 10 . 0000

-45 . 0000 , 15 . 0000 , -55 . 0000 , 15 . 0000 , -45 . 0000 , 5 . 0000 ; 5P

100.0.

0000 , -45 . 0000 , - 15 . 0000 , -45 . 0000 , - 5 . 0000 , -45 . 0000 , -25 . 0000 ; 7P

S 78G 2D 8P 4 T

50

51

52

53

54

55

56

57

58

59

60

61

62

6-3 64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

12

121

4

56

7

8

12

34

1
s F EllOOOOO S AOl S V IGES 3.0 S

I The intent is to check the LOCATION, ORIENTATION. LENGTH and END S POINTS to be within the Limits specified in field 19 of the Global S Section. The model cube is X = 3.75, Y = 4.875, Z = 0.0 . S E ENTITY FORM COUNTS

no 0 2s

P Verify the following: S * The correct TEST FILE has been loaded,

* The correct IGES VERSION is being used,

* That a line exists from (1 . 5 , 1 . 0 , 0 . 0) to (3.75,1.0,0.0) , * That a line exists from ( 1 . 5 , 1 . 0 , 0 . 0) to (1.5,4.875,0.0) . R The results should be a line 2.25 long and parallel to the X axis at an offset distance of Y = 1.0. A second line should be 3.875 long and

parallel to the Y axis at an offset distance of X = 1.5 . C Construct a LINE from (1 . 5 , 1 . 0 , 0 . 0) to (3.75,1.0,0.0) and a LINE

from (1.5, 1.0, 0.0) to (1.5,4.875,0.0) . D Not available

H 28-Sept-1987 JLC wrote this test case.

N WARNING: This file has been accepted as a candidate test file

by the TEST CASE DEVELOPMENT COMMITTEE but it has not been

approved as a member of the TEST CASE LIBRARY.

L This data was prepared in conjunction with work sponsored

by an agency of the United States Government. Neither

the United States Government nor any agency thereof, nor

any of their employees, makes any warranty, express or implied or assumes any legal liability or responsibility

for the accuracy, completeness, or usefulness of any

information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned

rights. Reference herein to any specific commercial —product, process, or service by trade name, trademark,-

manuiacturer , or otherwise, does not necessarily constitute

or imply its endorsement, recommendation, or favoring by

the United States Government or any agency thereof.

IH, ,1H; .9HLINE TEST, 12HE1 100000 .AOl , 12HHANDMADE 1 . 0 , 3H1 . 0 , 32 , 38 , 6

38.15.1.0.1. 4HINCH, 1,0. 030, 13H870928. 161357, l.OE-04, 5. 5E+02,

8HJ CRUSEY,3HNBS,4,0;

110 1 110 0

110 0 0 1 0

110 2 110 0

110 0 0 1 0

110.1.5.1.0.

0.0.3.75.1.0.0.0.0.0;

110.1.5.1.0.

0.0.1.5.4.875.0.0.0.0;

S 38G 3D ^P 2

Ss

s

s

ss

ss

ss

s

s

s

s

s

s

s

ss

s

s

s

s

s

s

ss

sG

G

G

OOOOOOOOID

LINE X-XD

OOOOOOOOID

LINE Y-YD

IP

3P

12

34

56

789 10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

12

3

12

34

1
F E2020000.A01

A

V IGES 3.0

I TEST CASE FOR .\NGULAR DIMENSION, IGES ENTITY 202 WITH NO FRILLS

E ENT FORM SUBTYPE

202 0 0

212 0 0

214 2 0

106 40

110 0

P Visually verify, comparing the display with the accompanying

plot, that two lines were generated as follows:

a horizontal line in the Z=0 plane and extending from

(5.68326.3.207) to (10.9673,3.207) and a non-horizontal

line from (5.68326,3.207) to (8.52258,7.6743).

Visually verify that three angular dimensions were generated

as follows: the text string, "57 . 56" , in default font, should

be located at (4. 214377 , 5 . 800756 , 0) , (8 . 749586 , 5 . 201729 , 0) , and

( 11 . 7294 , 6 .44752 , 0) ; the arrow heads should all be inside the

lines (or witness lines) and should be .15 long by .05 wide.

For the first leaders, DE7 and DE9 , the arrow heads should

should be at (9.60104,9.37112) and (12.9871,3.207) with the

tails at (12.0971,6.70102) and (12.2762,6.35002). For the

second pair of leaders, DE19 and DE21, the arrow heads should

be at (9.77381,3.207) and (7.87744,6.65927) with the tails at

(9.30722,5.10423) and (9.10058, 5.45523). For the third leader

"pair", DE27 and DE29, the arrow heads should be at

(8.53908.3.207) and (7.21513,5.6172) with the tails at

(5.23229,6.02699) and (8.1863,4.58195). The horizontal witness

line should leave a .093 gap to (11.0609,3.207) and extend

to (13.1138,3.207). The other witness line extends from

(8.57278,7.75329) to (9.66903,94781). All coordinate are inches.

R The resulting data base/display should contain two lines,

coincident at^..the±i; left ends, with the angle between them . dimensioned in three different positions, first, above the

lines, second, between the lines, and third within the angle

formed by the lines but beyond their end points. The angular

dimension is 57.56 degrees.

C To prepare this test case for a preprocessor test, create a geometric data base on the system hosting the translator to be

tested according to the following script:

1) Create two lines with end points as designated in the

P section above.

2) Using the host systems dimensioning commands, place an angular dimension on the lines with the text located as indicated above. Use default attributes for the dimensions

(text font, text size, etc.) The radii of the leaders are 2.85582, 4.09055. and 7.30379.

3) Make a plot of the resulting graphics model and compare

it with the plot accompanying the test case.

N WARi^ING : This file has been accepted as a candidate test

file by the Test Case Development Committee but it has

not been approved as a member of the Test Case Library.

D Not available

S

S

ss COUNTS

3S

3S

3S

2S

2S

S

SS

S

S

S

S

s

ss

s

s

ss

s

s

ss

s

s

s

s

s

s

ss

ss

s

s

s

ss

s

s

s

ss

s

s

s

s

ss

12

34

56

78

9 10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34 . 35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54
H 03-0ct-1987 DOR created this; file s 55

L These data were prepared in conjunction with work sponsored s 56

by an agency of the United States Government.. Neither the s 57

United States Government nor any agency therof, nor any of s 58

their employees, makes any warranty, express or implied, or s 59 assumes any legal liability or responsibility for the accuracy. s 60

completeness, or’ usefulness of any information. apparatuss 61

product, or process disclosed. or represents that its use s 62

would not infringe privately’ owned rights. Reference herein s 63

to any specific commercial product, process

or service by s 64

trade name. trademark, manufacturer, or otherwise, does not s 65

imply its endorsement, recommendation, or favoring by the s 66

United States Government or any agency thereof. s 67

, .12HE2020000. AOl , 25HWO . IGES . TESTCASE . E202 . AOl

G 1 4 5 HCOMPUTERVI S I ON CADDS4X REV 5.0 GRAPHIC SYSTEM, 16HIGES VERSION 3.0, G 2 16,8,24,8,56, 12HE2020000 . AOl ,

.0, 1,4HINCH, 32767, 32 .767. G 3 13H8710 2. 75054,0 .000001 , ,3HDOR,4HNSWC,4,

G 4

110 1 1 1 0 0 0 0 ID 1 no 0 0 1 0 D 2- no 2 1 1 0 0 0 0 ID 3 no 0 0 1 0 D 4

212 3 1 0 0 0 0 0 lOlOOD 5 212 0 0 2 0 D 6 214 5 1 1 0 0 0 0 lOlOOD 7 214 0 0 1 2 D 8 214 6 1 1 0 0 0 0 lOlOOD 9 214 0 0 1 2 D 10

106 7 1 1 0 0 0 0 lOOOlD 11

106 0 0 1 40 D 12

106 8 1 1 0 0 0 0 lOOOlD 13

106 0 0 1 40 D 14

202 9 1 1 0 0 0 0 OOOIOID 15

202 0 0 1 0 D 16

212 10 .n- 0 - 0 0 0 0 lOlOOD 17

212 0 0 2 0 D 18

214 12 1 1 0 0 0 0 lOlOOD 19

214 0 0 1 2 D 20

214 13 1 1 0 0 0 0 lOlOOD 21

214 0 0 1 2 D 22

202 14 1 1 0 0 0 0 OOOIOID 23

202 0 0 1 0 D 24

212 15 1 0 0 0 0 0 lOlOOD 25

212 0 0 2 0 D 26

214 17 1 1 0 0 0 0 lOlOOD 27

214 0 0 1 2 D 28

214 18 1 1 0 0 0 0 lOlOOD 29

214 0 0 1 2 D 30

202 19 1 1 0 0 0 0 0001010 31

202 0 0 1 0 D 32

110,5.68326,3. 207, 0.0,8.52258,7.6743,0.0; IP 1 110,5.68326,3. 207,0.0,10.9673, 3.207,0.0; 3P 2 212,2,5,0.78,01. 156 ,1,1.5708,0. 0.0 .0.11.7294,6.44752,0.0,5H57.56, 5P 3 1.0.1404,0.156,1002,1.5708,0.0 .0. 0,12.5094,6.44752 .0.0, 1H$; 5P 4

214,1,0.15,0.05,0. 0,9.60104,9. 37112,12.0971.6.70102; 7P 5
214.1.0.

15.0.05.0.0.12.9871.3.207.12.2762.6.35002; 9P 106.1.3.0.

0.8.52257.7.83229.8.57278.7.75329.9.66903.9.4781; IIP 106.1.3.0.

0.10.9673.3.207.11.0609.3.207.13.1138.3.207; 13P

202.5,11,13,5.68326,3.207.7.30379.7,9; 15P

212. 2. 5.

0.

78. 0.156. 1.1. 5708. 0.0. 0.0. 8. 74959. 5. 20173. 0.0.5H57. 56, 17P

1.0.

1404.0.156. 1002. 1.5708. 0.0. 0.0. 9. 52959. 5. 20173. 0.0. 1H$; 17P 214.1.0.

15.0.05.0.0.7.87744.6.65927.9.10058.5.45523; 19P 214.1.0.

15.0.05.0.0.9.77381.3.207.9.30722.5.10423; 21P 202.17.0.

0.5.68326.3.207.4.09055.19.21; 23P

212. 2. 5.

0.

78. 0.156. 1.1. 5708. 0.0. 0.0. 4. 21438. 5. 80076. 0.0.5H57. 56, 25P

1.0.

1404. 0.156. 1002. 1.5708. 0.0. 0.0. 4. 99438. 5. 80076. 0.0.1H$; 25P

214.1.0.

15.0.05.0.0.8.53908.3.207.5.23228.6.02699; 27P

214.1.0.

15.0.05.0.0.7.21513.5.6172.8.1863.4.58195; 29P

202.25.0.

0.5.68326.3.207.2.85582.27.29; 3 IP

S 67G 4D 32P 19 T
s F E2120000 S AOl S V IGES 3.0 S

I Test the General Note (Type 212, Form 0) for all functionality S with a single Font Code FC=1 . Functions exercised include: S Text Height Vertical Text Slant Angle Mirroring S Text Width Horiz Text Rotation Multi Line S The working cube for this test extends from S X = -180 to X = 280, Y = -180 to Y = 320, Z = 0 . S E Entity Form Ty*pe Counts

212 0 28S

P Verify the following: S * Ail character strings read as, 5 MM TEXT, 10 MM TEXT or 20 MM TEIXT S except for the MULTI -LINE text. S * A 5 MM TEXT string located at (20.0,20.0,0.0), 0 slant and S string length 50 nun . S * A 10 MM TEXT string located at (20.0,40.0,0.0) 0 slant and S string length 100 mm . S * A 20 MM TEXT string located at (20.0,60.0,0.0), 0 slant angle and S string length 200 mm . S A 7 character rosette of 5 MM TEXT rotating each string 45 degrees S from 0 thru 360 degrees for S VERTICAL text with rosette center at (-100.0,200.0,0.0), S HORIZONTAL text with rosette center at (-100.0,-80.0,0.0). S * A COMPRESSED 20 MM TEXT string with 0 slant angle S located at (20.0,280.0,0.0) and string length = 50 mm, S located at (20.0,250.0,0.0) and string LENGTH = 100 mm, S located at (20.0,220.0,0.0) and string LENGTH = 150 mm . S * A SLANTED 20 MM TEXT string with string length = 200 mm and S 45 degree SLANT angle located at (20.0,170.0,0.0), S 30 degree SLANT angle located at (20.0,140.0,0.0), S 15 degree SLANT angle located at (20.0,110.0,0.0) . S —* A. MIRRORED 10 MM TEXT -^tiiag-J-ocated at (20.0,40.0,0.0) and.is .. S mirrored about the Y axis at (-20.0,40.0,0.0) with each string S length = 100 mm . S * A MIRRORED 20 MM TEXT string located at (20.0,-60.0,0.0) and is S mirrored about the strings baseline, each string length = 200 mm. S * A 10 MM MULTI -LINE text string located at (20.0,-120.0,0.0), S each line starting at X = 20.0 and maximum string length = 100 mm. S R The results should be : S Font 1 characters. S Two rosettes of 8 text strings showing horiz 6t vertical characters. S Two groups of 3 20 mm text strings showing text width & slant angle.

One 10 MM text string showing vertical mirroring , S One 20 MM text string showing horizontal mirroring , S A simple Multi -line text string example . S C All TEXT input requested for this test is shown between " "DO NOT S enter the QUOTE symbols with the Text. Some Text request a leading S BLANK . S Prepare to generate text strings as follows: S Set text height 5mm, aspect ratio 1.0, slant 0, horizontal text S Generate a text string reading " 5 MM TEXT" at X = -100, Y = -80 S Replicate 7 times at 45 degree increments about normal at given XY S

12

34

56

789 10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34.

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54
Generate a text string reading " 5 MM TEXT" at X = 20, Y = 20

Set text height 5mm, aspect ratio 1.0, slant 0, vertical text

Generate a text string reading " 5 MM TEXT" at X = -100, Y = 200

Replicate 7 times at 45 degree increments about normal at given XY

Set text height 10mm, aspect rac.io 1.0, slant 0, horizontal text

Generate a text string reading "10 MM TEXT" at X = 20, Y = 40

Generate a text string reading "10 MM TEXT" at X = -20, Y = 40

Mirror this string about a vertical line through the given XY

Set text height 20mm, aspect ratio 1.0, slant 0, horizontal text

Generate a text string reading "20 MM TEXT" at X s 20, Y = 60

Generate a text string reading "20 MM TEXT" at X = 20, Y = -60

Mirror this string about a horizontal line through the given XY

Set text height 20mm, aspect ratio 1.0, slant 15, horizontal text

Generate a text string reading "20 MM TEXT" at X = 20, Y = 110

Set text height 20mm, aspect ratio 1.0, slant 30, horizontal text

Generate a text string reading "20 MM TEXT" at X = 20, Y = 140

Set text height 20mm, aspect ratio 1.0, slant 45, horizontal text

Generate a text string reading ”20 MM TEXT" at X

Set text height 20mm, aspect ratio .75, slant 0,

Generate a text string reading "20 MM TEXT" at X

Set text height 20mm, aspect ratio .50, slant 0,

Generate a text string reading "20 MM TEXT" at X

Set text height 20mm, aspect ratio .25, slant 0,

Generate a text string reading "20 MM TEXT" at X

Set text height 10mm, aspect ratio 1.0, slant 0,

= 20, Y = 170

horizontal text'

=20, Y = 220

horizontal text = 20, Y = 250

horizontal text

=20, Y = 280

horizontal text

Generate a text string at X = 20, Y = -120 reading: "THIS IS A TEST'

"OF MULTIPLE"

"LINE TEXT"

N WARNING: This file has been accepted as a candidate test

file by the Test Case Development Committee but it has

not been approved as a member of the Test Case Library.

D Not available

H 30-SEPT- 1987 JLC Wrote this TEST CASE as requested . L This data was prepared in-conj-unction with work —

by an agency of the United States Government. Neither

the United States Government nor any agency thereof, nor

any of their employees, makes any warranty, express or implied or assumes any legal liability or responsibility

for the accuracy, completeness , or usefulness of any

information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned

rights. Reference herein to any specific commercial

product, process, or service by trade name, trademark,

manufacturer, or otherwise, does not necessarily constitute

or imply its endorsement, recommendation, or favoring by

the United States Government or any agency thereof.

IH, ,1H; ,17HGENERAL NOTE TEST , 12HE2 120000 .AO 1

, 14HTEST HAND MADE.3H1.0,

32,38,6,38,15, ,1.0,2, 2HMM, 1,0. 045, 13H870930. 110545, 0.0010, 300,

8HJ CRUSEY,3HNBS,4,

212

212

212

212

Ss

s

ss

s

s

s

ss

s

s

s

s

ss

s

ss

s

s

s

ss

s

s

ss

s

s

s

s

ss

s

ss

s

ss

ss

s

s

s

s

sG

G

G

OOOOOOIOID

GENNOTE ID

OOOOOOIOID

GENNOTE 2D

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

' 99

100

101

12

3

12

34
212 3 0 1 212 0 0 1 212 4 0 1 212 0 0 2

212 6 0 1 212 0 0 2

212 8 0 1 212 0 0 2

212 10 0 1 212 0 0 1 212 11 0 1 212 0 0 1 212 12 0 1 212 0 0 1 212 13 0 1 212 0 0 1 212 14 0 1 212 0 0 2

212 16 0 1 212 0 0 1 212 17 0 1 212 0 0 2

212 19 0 1 212 0 0 2

212 21 0 1 212 0 0 2

212 23 0 1 212 0 0 2 212 25 0 1 212 0 0 2

212 27 0 1 212 0 0 2

212 29 0 1 212 0 0 - 2 212 31 0 1 212 0 0 3 212 34 0 1 212 0 0 2 212 36 0 1 212 0 0 2

212 38 0 1 212 0 0 2

212 40 0 1 212 0 0 2

212 42 0 1 212 0 0 2

212 44 0 1 212 0 0

212 46 0 1 212 0 0 2 212 48 0 1 212 0 0 2 212,1,10,50.0 ,5.0,1,, ,0.0, 0,0,20.0,20.0,

212,1, 10,100. 0,10.0, 1, ,0. 0,0,0,20.0,40.

0 0 OOOOOOIOID 5 GENNOTE 3D 6 0 0 OOOOOOIOID 7 GENNOTE 4D 8 0 0 OOOOOOIOID 9 GENNOTE 5D 10

0 0 OOOOOOIOID 11

GENNOTE 6D 12

0 0 OOOOOOIOID 13

GENNOTE 7D 14

0 0 OOOOOOIOID 15

GENNOTE 8D 16

0 0 OOOOOOIOID 17

GENNOTE 9D 18

0 0 OOOOOOIOID 19

GENNOTE 13D 20

0 0 OOOOOOIOID 21

GENNOTE 14D 22

0 0 OOOOOOIOID 23

GENNOTE 16D 24

0 0 OOOOOOIOID 25

GENNOTE 17D 26

0 0 OOOOOOIOID 27

GENNOTE 18D 28

0 0 OOOOOOIOID 29

GENNOTE 19D 30

0 0 OOOOOOIOID 31

GENNOTE 20D 32

0 0 OOOOOOIOID 33

GENNOTE 2 ID 34

0 0 OOOOOOIOID 35

GENNOTE 22D 36

0 0 OOOOOOIOID 37

GENNOTE- - 23D 38

0 0 OOOOOOIOID 39

GENNOTE 24D 40

0 0 OOOOOOIOID 41

GENNOTE 29D 42

0 0 OOOOOOIOID 43

GENNOTE 30D 44

0 0 OOOOOOIOID 45

GENNOTE 3 ID 46

0 0 OOOOOOIOID 47

GENNOTE 3 2D 48

0 0 OOOOOOIOID 49

GENNOTE 3 3D 50

0 0 OOOOOOIOID 51

GENNOTE 3^D 52

0 0 OOOOOOIOID 53

GENNOTE 35D 54

0 0 OOOOOOIOID 55

GENNOTE 36D 56

.0,10H 5 MM TEXT,,0,0; IP 1 ,0.0, lOHlO MM TEXT, 0,0; 3P 2

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0
212.1.10.200.0. 20.0.1. .0.0. 0.0. 20. 0.60. 0.0.0. 10,20 MM TEXT. 0.0; 5P

212.

1.10.200.0.

20.0. 1 .1.308996939. 0.0. 0.0. 20. 0.1 10. 0.0.0. 10,20 M 7P

M TEXT, 0,0; 7P

212. 1.10. 200.

0.

20. 0.1. 1.047197551. 0.0. 0.0. 20.0. 140. 0.0.0.10,20 M 9P

M TEXT, 0,0; 9P

212. 1.10. 200.

0.

20. 0.1. 0.785931634. 0.0. 0.0. 20. 0. 170. 0.0.0.10,20 M IIP

M212.1.10.150.0. TEXT, 0,0; IIP

212.1.10.100.0. 20.0.1. .0.0. 0.0. 20. 0.220. 0.0.0. 10,20 MM TEXT, 0,0; 13P

212.1.10.50.0. 20.0.1. .0.0. 0.0. 20. 0.250. 0.0.0. 10,20 MM TEXT, 0,0; 15P

212.1.10.200.0.20.0.1. .0.0. 0.0. 20. 0.280. 0.0.0. 10,20 MM TEXT, 0,0; 17P

212.1.10.100.0. 20.0.1. .0.0. 2. 0.20. 0,-60. 0,0.0, 10H20 MM TEXT, 0,0; 19P

10.0.1, ,0.0, 1,0, -20.0, •-40. 0,0.0, lOHlO MM TEXT.O, 21P

0; 21P 212.1.10.50.0.

5.0.1. .0.0. 0.0, -100. 0,-80. 0,0.0, lOH 5 MM TEXT, 0.0; 23P 212.1.10.50.0.

5.0.1. .0.785398163. 0.0, -100. 0,-80. 0,0.0, lOH 5 MM T 25P

EXT, 0,0; 25P

212.1.10.50.0.

5.0.1. .1.570796328. 0.0, -100. 0,-80. 0,0.0, lOH 5 MM T 27P

EXT, 0,0; 27P

212.1.10.50.0.

5.0.1. .2. 356194490. 0.0, -100. 0,-80. 0,0.0, lOH 5 MM T 29P

EXT, 0,0; 29P

212.1.10.50.0.

5.0.1. .3. 141592654. 0.0, -100. 0,-80. 0,0.0, lOH 5 MM T 31P

EXT, 0,0; 31P

212.1.10.50.0.

5.0.1. .3. 926990817. 0.0, -100. 0,-80. 0,0.0, lOH 5 MM T 33P

EXT, 0.0; 33P

212.1.10.50.0.

5.0.1. .4. 712388980. 0.0, -100. 0,-80. 0,0.0, lOH 5 MM T 35P

EXT, 0,0; 35P

212.1.10.50.0.

5.0.1. .5. 499787144. 0.0, -100. 0,-80. 0,0.0, lOH 5 MM T 37P

EXT, 0,0; 37P

212.3.14.120.0.

10.0.1. .0.0. 0.0. 20. 0,-120. 0,0.0, 14HTHIS IS A TEST 39P

,11,110.0,10.0,1, , 0.0, 0,0, 20.0, -135. 0,0.0,11HOF MULTIPLE , 9 , 90 . 0 , 39P

10.0.

1. .0.0.0.0.20.0, -150. 0,0.0, 9HLINE TEXT, 0.0; 39P

212.1.10.50.0.

5.0.1. .0.0. 0.1, -100.0, +200. 0,0.0, lOH 5 MM TEXT,0, 41P

0; 41P

212.1.10.50.0.

5.0.1. .0.785398163. 0.1, -100.0, +200. 0,0.0, lOH 5 MM 43P

TEXT, 0,0; 43P

212.1.10.50.0.

5.0.1. .1.570796328. 0.1, -100.0, +200. 0,0.0, lOH 5 MM 45P

TEXT, 0,0; 45P

212.1.10.50.0.

5.0.1. .2. 356194490. 0.1, -100.0, +200. 0,0.0, lOH 5 MM 47P

TEXT, 0,0; 47P

212.1.10.50.0.

5.0.1. .3. 141592654. 0.1, -100.0, +200. 0,0.0, lOH 5 MM 49P

TEXT, 0,0; 49P

212.1.10.50.0.

5.0.1. .3. 926990817. 0.1, -100.0, +200. 0,0.0, lOH 5 MM 51P

TEXT, 0,0; 51P

212.1.10.50.0.

5.0.1. .4. 712388980. 0.1, -100.0, +200. 0,0.0, lOH 5 MM 53?

TEXT, 0,0; 53P

212.1.10.50.0.

5.0.1. .5. 499787144. 0.1, -100.0, +200. 0,0.0, lOH 5 MM 55P

TEXT. 0,0; ^

. 55P

S lOlG 3D 56P 49 T
F E3080000.A01 S 1 A S 2 V IGES 3.0 s 3 I Test the subfigure definition (Type 308) and the subfigure instance s 4

(Type 408) entities. The resulting graphics model should have the s 5 the same positioning, orientation and elements as indicated by the s 6 plot and the elements listed in the PD section. All the elements s 7 of the subfigure should act as a part of the whole for rotation, s 8 translation, moving, coping and scaling. s 9 E Entity Form Type Counts 10

100 35 11

no 45 12

124 IS 13

308 IS 14

408 IS 15

410 IS 16

P Visually verify against the plot that a smiling face is generated s 17

consisting of the following entitiess 18

Three circular arcs s 19

Four lines s 20

Also used to create this file were: s 21

One subfigure definition s 22

One sub figure instance s 23

One transformation matrix s 24

One view entity s 25

s 26

R Using the system's verification commands, verify that: s 27

there is only one occurance of the subfigure, with no translation s 28

that every element in the subfigure rotates when the subfigure is s 29

rotated s 30

that every element in the subfigure translates when the subfigure isS 31

translated s 32

that every element in the subfigure moves when the subfigure is s 33

moved s 34

that every element in the subfigure copies when the subfigure is s 35

copied s 36

that every element in the subfigure changes size when the subfigure S 37

scaled s 38

s 39

C To recreate the figure: s 40

Generate

Generate

Generate

Generate

Generate

Generate

Generate

a full circle with center = (10,10,0) and radius =5 S 41

(z=0 plane, counterclockwise direction, center point (10,10) S 42

start point (15,10), term, point (15,10)) S 43 a full circle with center = (-10,10,0) and radius =5 S 44

(z=0 plane, counterclockwise direction, center point (-10,10)5 45

start point (-5,10), term, point (-5,10)) S 46

a circular arc with center = (0,0,0) and radius = 10 with S 47

a start angle of 180 and a terminate angle of 360 degrees S 48

(z=0 plane, counterclockwise direction, center point (0,0) S 49

start point (-10,0), term, point (10,0)) S 50

a line from (20,20,0) to (20,-20,0) S 51 a line from (20,-20,0) to (-20,-20,0) S 52 a line from (-20,-20,0) to (-20,20,0) S 53 a line from (-20,20,0) to (20,20,0) S 54
D Not Available S 55

H 15-Sept. -1987 created S 56

N Not Available S 57

L This data was prepared in conjunction with work sponsored by an agencyS 58

of the United States Government. Neither the United States Governments 59

nor any agency thereof, nor any of their employees, make any warranty, S 60

express or implied or assumes any legal liability or responsibility S 61

for the accuracy, completeness, or usefulness of any information, S 62

apparatus, product, or process disclosed, or represents that its use S 63

would not infringe privately owned rights. Reference herein to any S 64

specific commercial product, process , or service by trade name, S 65

trademark, manufacturer, or otherwise, does not necessarily constitutes 66 or imply its endorsement, recommendation, or favoring by the United S 67

States Government or any agency thereof • S 68

, , IHl , 12HE3080000 . AOl , 4HN0NE, G 1 16HIGES VERSION 3 . 0 , 16 , 8 , 24 , 8 , 56 , 1H2 , 1 . 0

1.4HINCH, 32767, 32.,767,13H87 915G 2

. 92738,0.000001, ,7HUNKNOWN,17HTEST CASE LIBRARY, 4, 3; G 3 no 1 1 1 0 0 0 0 lOOOlD 1 no 0 0 1 0 D 2

no 2 1 1 0 0 0 0 lOOOlD 3 no 0 0 1 0 D 4

no 3 1 1 0 0 0 0 lOOOlD 5 no 0 0 1 0 D 6 no 4 1 1 0 0 0 0 lOOOlD 7 no 0 0 1 0 D 8 100 5 1 1 0 0 0 0 lOOOlD 9 100 0 0 1 0 D 10

100 6 1 1 0 0 0 0 lOOOlD 11

100 0 0 1 0 D 12

100 7 1 1 0 0 0 0 lOOOlD 13

100 0 0 1 0 D 14

308 8 1 0 0 0 0 0 20201D 15

308 0 01 0 D 1

124 9 1 0 0 0 0 0 lOlOlD 17

124 0 0 ' 1 0 D 18

410 10 1 0 0 0 17 0 OOlOlD 19

410 0 0 1 0 D 20

408 11 1 1 0 19 0 0 ID 21

408 0 0 1 0 D 22

110,20.0,20.0,0.0,20.0,-20.0,0.0; IP 1 110,20.0,-20.0,0.0,-20.0,-20.0,0.0; 3P 2 110,-20.0,-20.0,0.0,-20.0,20.0,0.0; 5P 3 110,-20.0,20.0,0.0,20.0,20.0,0.0; 7P 4

100,0.0,10.0,10.0,15.0,10.0,15.0,10. 0; 9P 5 100,0.0,-10.0,10.0,-5.0,10.0,-5.0,10 • 0; IIP 6 100,0.0,0.0,0.0,-10.0,0.0,10.0,0.0; 13P 7 308,0, 12HE3080000 .FIG, 7, 1,3, 5, 7, 9, 11, 13; 15P 8 124,1.0.0.0,0.0,0.0,0.0,1.0,0.0,0.0, o o o .0,1. 0,0.0: 17P 9 410.2.1.0.0.0,0.0,0,0; 19P 10

408,15,0.0,0.0.0.0,1.0; ‘ ' 21P 11

S 68G 3D 22P 11 T 1


m

-.j

LTI

l)

It

tJ |tMUHU

tt

t>

ilu

It MI
1

X

3

L

l-lilXfX

Uj

JV I> 0?^^ '?fc '>• X31 rei

m•V

'A I" LU il

5 MM TEXT

THIS IS A TEST

OF MULTIPLE

L 1 NE TEXT

Appendix C

Test Results File

The following material was collected during the verification test of the

Autotroll S7000 CAD system. The methodology used was that described by

the "quickstart" and "quickstart jr* implementation schemes. The system

under test is owned by the Engineering CAD/CAM group at NBS. The

verification forms and instructions are contained in Appendix A.

Appendix B contains the test cases and their plots.

The following is a listing of the packets of information contained in

this appendix.

o The packet delivered to the testing agency containing a Verification Request Form and the vendor claims.

o Information filled in by the testing agency: The Test Results

File cover sheet, Test Plan Specification, Verification Test Log,

Test Incident Reports, and the Pre and Postprocessor Entity

Results Forms

o Volunteer Entity Test with plots,

o System printouts from the circiriar arc tests

o System printouts from the line test

o System printouts from the angular dimension test

o System printouts from the general note test

o System printouts from the subfigure definition test

o Prototype of the SAE Summary Test Report
IGIZS Vcrilicaiion Request

Company Name:

Contacl:

Address:

Phone:

/7uro -

rCy~^£yy<y>Z> 7^/!2><f

7^//3

{So/Lj 97S - 3S^C Date:

^per /9^7

Request for Verification of: ^

Preprocessor ' IGES Specification Version:

Postprocessor

Configuration Information

CAD Software: ^trro • Tj^aA

Version/Release ID: /Ao Release Date: 3/z/^7

IGES Processor Name: ^7^ T^osT^

Version/Release ID: ^£/g/^o(^

Computer Mfg: ^77^07/

Release Date: 3^//9/s7

Model: D//Ss<7

CPU:

Operating System:

Memory Size: 77

Version: 9^ z- ^

Supporting Information

y Postprocessor Entity Maps —hi-t-, i . System Limit Form

X_ Preprocessor Entity Maps General Entity Test

Processor Documentation ^ Volunteer Entity Test

Tape Access Documentation

Other (itemize)

For SAE Use Only

Vendor Request Number: 7^OO 'Z Assigned to: Date: /9S7
IGES Processor Mapping Form

Global Section Characteristics

'endor Request Number: "7^ S 7

2

Dale: '7 OCT /fS7

/stem Name/Version;

Field Attribute Supported Comments

Mark Last column It contnualion

Name a Name Pre Post Sheet is used

Parameter Delimiter \ •P T>£f/9yLTCh /r^£

Record Delimiter 2 7)

, 1 ••

Product ID 3

K3£S RIe Name 4

- Vendor System ID 5

Preprocessor Version 6

Bits per Integer 7

Single Precision Mag. 8 ly^

Single Precision Signf. 9 Ly^

Double Precision Mag. 10 ly^

Double Precision Signf 11 Product ID (receiver) 12

Model Space Scale 13

Units Flag 14 1 INCH

2 MM y'

3

r"

4 FEET

5 MILES

6 METERS

7 KILOMETERS

8 MILS

9 MICRONS

10 CENTIMETERS

11 MICROINCH

Units 1 2H!N

2HMM -----

2HFT

2HMI

Form 0A Sheet 1 of 3
IGES Processor Mapping Form

Global Section Characteristics

*'endor Request Number: <3 ^

Field Attribute Supported Comments

Mark last column If continuation Name /y /If Name Pre Post Sheet Is used

Units (continued) 15 IHM

2HKM

3HMIL

2HUM

2HCM

3HUIN •

Line Wt Grads. 16 •P

uses r®

y

Max Line Width Units 17 T> ( T£V VohJ^CjZ .. Oate/Time Stamp 18 •

Min. User Resolution 19

Max. Coord. Value 20

Name of Author 21 T?

Organization. < 22

sES Version Number 23 1 1.0

y

2 ANSI Y14.26M

3 2.0

4 3.0

Drafting Standard 24 0 None

1 ISO

2 AFNOR

3 ANSI

4 BSI

5 CSA

6 DIN

7 JtS

1 1

Form 8A Sheet 2 of 3
IGES Processor Mapping Form

Globa! Section Characteristics

Form 8A Sheet 3 of 3
Preprocessor Mapping Form

Directory Entry Characteristics

Vendor Request Number: <57Soo Z Dale: 7 <7^-^ /fS7

Field Attribute Supported Comments

Name a fi Name Pre Post

f/.ork last column It ccntinuatusn Sheet Is used

Structure 3 V p 'D^

Line Font 4 1 Solid 1^

2 Dashed f 3 Phantom

4 Centerline

5 Dotted

Level 5 X

View 6

• TYre , fom </ X

Matrix 7 i— X

Label 8

S Blank 9a OO, Of

ta Subord. 9b OO. of

iu

> Use Flag 9c . OO, of

s , Hierarchy 9d of

Line Weight 12 X

Color 13 0 unassigned

1 Black

2 Red t

3 Green

4 Blue

5 Yellow

6 Magenta

7 Cyan

8 White

Label 18

Subscript 19 T> 7>

NumDer ol Muliipie Emilies Per Level Permitted:

Number of Multiple Colors Per Level Permitted:

Total Number of Levels Permitted:

( • ( 1 1 1 1 1 ''.II
Preprocessor Mapping Form

Directory Entry Characteristics

Vendor Request Number: TP 87 ^

Continuation Sheet

Field CommenI

To^ r- Z<fjrs- lsy££s

jr^zs ££i££^ <:zu- £j<.

'p^r

^x/r//y ^ ^ jyp^

7 7=>o£7 — 7^/^/dSPb/eA//^/y^:^'0 ^A/r/r/£^

tZxXy.

I ( » r n 1 8 M
Sheet / of

Preprocessor Entity Mapping Form

Vendor Requesi Number: ^ OO 2.

1 Vendor Entity iGES Entity

iO Name tf Form Name

C/^clE /oo

-

•

Form 8C
Sheet ^ of

Preprocessor Entity Mapping Form

Vendor Request Number: "7^ <3 V S OO 2

1 Vendor Entity ICES Entity

ID Name tf Form Name

%

/ AJ E-. //O I-/AJ£

% « f

Form 8C
/

/

Preprocessor Entity Mapping Form

Vendor Request Numtjer: <5^7 ^ OO 2.

Sheet

^

of

^

ID

Vendor Entity

Name

73

' 0 .

IGES Entity

Form

zoz —

Name

/P^/(^UL/P^

^/^£yUS/OyO

2/Z Z>'>T^

/O^ Cop/cc^S

^o)

Z/i

(paiA/s /- fj

Form 8C
Sheet ^

of 3^

Preprocessor Entity Mapping Form

Vendor Request Number: 'JP c57 '2.

! Vendor Entity

1 IGES Entity

ID Name , ^ Form Name

N

slE^TiC^C Tcjcr

Oor So??oj(T^ . SLAAfT" AAJ(;iL

F/xn Ft z^-

fif££o/i £>-f TfiCT"

A)0T ^ £'0

ZJZ O

A/or£

tbxt //s/<iMr

T£XT W/DTMy/£^/7C>34 TEXT

HoKl'io/iTfU TEXT

£lfiJ0T yfM^^CE

TEXT ^oTAVoX>

text Xf/X£oA/*^

VEX-T/oil

/'iotdTAL

TEXT

f^uLT ! -L/xj£ text

Form 8C
Sheet

^

of /

/ Preprocessor Entity Mapping Form

Vendor Request Number: SOO 2.

Vendor Entity IGES Entity

ID Name Form Name

>

A/oT Suf>rb<Z7fi^b

So& S'u'Q /=/qu££

L/aj£S

fl^CS

T^jiiSL^r/o ^

£oTAT/^77o^Z

€.

Form 8C
Sh«ct / of

l__ Postprocessor Entity Mapping Form

Vendor Request Number: <^"7 S OO 'Z.

1 IGES Entity Vendor Entity

Form Name ID Name

/oq — C/£CLC

no — L /AJ£ Lja^ ^

Zoz — i>/n. ^2> jji/£jur/o^

z/z S^£jL>^jeAL fJor£

T£j(7

V/ /'t>TH

'^OTftTloAJ

V£ji.T.

^/<J£

^

AJo 7

”

/tfzT”. AJcr S’ f/7Po4QT.ti

S^a/T AaJCHS. fZX£i> (? /S°

/i/4j£o/Cy*!(^ 0 / 7XXT~

A/or s^afTa/^ch

SoS

L/OtS

<J/zC

~TJ2/}MJSOTT7a^

£oVfr/o^

SC^C^

.

“^BCoAfCS /? (^/2otJP

^//y tD'r»^fi>oAL

^

AJ TjT ^

.

Form 9
Appendix D

Appendix D contains the exercise given to members of the IGES/PDES

Testing Project. The package is not replicated in its entirety because

most of the material is included in other appendices in this report. The

specified material can be found as follows:

Appendix A - Verification procedures and forms

Appendix B - Test cases and plots

Appendix C - Examples of the procedures on a real system
IGES Testing Project

October 7. 1987

An informative Exercise in Verification Testing

and

Test Case Design

To: All interested parties

From: Methodology Testing Committee and the NBS

The following packet of information contains directions for building an IGES test case and

running an IGES Verification Test. This exercise is necessary for anyone who wants to understand IGES testing and IGES test case development beyond a general level. The

tasks of writing a test case and defining a Verification Test are immutably bound together,

and accordingly, presented together.

You will need a copy of the IGES Testing Methodology Document Version 0.5 and the

materials contained in this packet. These include:

Instructions for the exercise,

Set of Verification Testing Forms

One Example

Listing of test cases.

Plot of test cases

Extractions from IEEE std 829-1983

After completing the exercise, the results ne_ed to be sent in for compilation, analysis, and

distribution. Testing comments and results should be sent to NBS. Test case comments

and results should be sent to Julia Terry.

IGES Testing

National Bureau of Standards

Sound A-101

Gaithersburg, Md. 20899

Julia Terry

Martin Marietta Energy Systems

Bldg 9103 MS 4

PO Box: Y

Oak Ridge, Tenn. 37831

Good Luck.

Thomas Wright. NBS
IGES Testing Project

October 7. 1987

Instruction for Verification Test and Test Case Design

Verification Test: In order to run the Verification Test it is necessary to get a copy of Testing Methodology of IGES Translators and IGES Formatted Data Files, Version 0.5. Particular attention needs to be paid to chapter 5 on verification testing, chapter 9 on the IGES Verification Panel, and appendix A

on performing a verification test. The other materials contained in this packet will need to be reviewed

as well.

As you go through this exercise, you will wear the hat of each group mentioned. Be a CAD vendor

when filling out the preprocessor and postprocessor mapping forms; be the SAE when receiving the

forms and results; be the testing agency when running the test; and so forth. If you have an IGES

verifier available to you or have access to one, use it to analyze IGES files. There is a company that

will analyze your files for a fee that can be used. If all else fails, skip this step and proceed.

There are five test cases available for this test. These will be available through the IGES bulletin board

and on floppy disk at the St. Louis IGES meeting.

Keep track of your questions and comments and send them in with your results. Comments without

results can also be sent, but please indicate how much of the procedures you went through. These

comments are an important part of this alpha test cycle.

As part of the Testers Forum in St. Louis, we will try to run a demonstration Verification Test with one

or more vendors of P.C. products. It is possible that modifications to these instructions will occur at that time.

Cautions: 1 - Do not try to assess the functionality of the entity maps. This represents an important

issue' that will be addressed in St. Louis. An approach has been developed that will use a more

comprehensive claim form to get specific details about each entity. Unfortunately these forms will not be available to be placed in this packet. In their place will be the old forms from version 0.3 of the

testing document. An attempt will be made to have these forms available in St. Louis.

Test Case Development: To develop a test case, first read Appendix D, Guide to Developing IGES

Test Cases. Pay particular attention to the documented iest cases in this packet—Using.one .of these cases as a model, redesign it for the same entity and test it on a CAD system. Remember that enough information must be provided about the test case to clearly determine its intent. This is important for preprocessor scripts that may define illegal operations on some systems. For example,

some systems with circle entities can not accept 360 degree arcs as input. When finished, send the

completed test case to Julia Terry for comment.

The second part of the exercise involves modifying or extending the collection of candidate test cases. When comments are returned, the IGES Test Case Committee will assign a test case to be modified or a test case to be developed. Complete the assignment and return it to Julia Terry.

Cautions: There is a proposal to change the definition of the ’C’ area of the Start Section from

Comments to Construction Scripts. Comments will be moved to the Note area. Also there needs to be

emphasis placed on the intent of the test case for the T area of the Start Section.
.

• ?.-••' 'J'iS'

'

‘ cr

' i ->

.{

’ll.

1,7.

.* -’. • if.' *• . V7,- t3*r ,t iimoO

wm

i .:

io: AW pwil^

’' l^n<l

oi et)*«n iwuneiw tx,»»^nr!T 230t v> A x»>nwna t>"6 nO')»3'*"»V ZA** ««tj no 6 >*iQiMlo 0'-..u»i noim3lW>fiv no e loKjBrto oi a.»« so

t»9*>oiv«i e<J a, bean lliw i9«Btj irti fit Ii«f«»ln03 •l•l'l•m wmo ei^T .!*•) ooil*aniwv » ooimiolToa no

A »8 0UO18 to ffr'i ttM itew fw uoy .eesnox* rtpooirtl Ofl uoy f*

^.„ .... .... *>«• 'o«««»oiq«H5 ort, luo of**l non*

2301 ni OYBri uoy II .rtno> o« Bn» •»() omnrvu' nenw iiO<v>p» pfHit*, Ort) *0 ;eHusoi bo« ermrt

•inrwHJ auoi,to5«><>fVn|(oitMt'iTtt>»

iftsks ol wribnig » test ca^ arxi 4 txia

afKf accOfOingty, prc»emed ^ ^

)uofU*w tjnemmoO ft»ue«i luoy fVm* nt rn#nj iy>«f boa tnwrvnoo tvi* tr^isuip mo\ io

•w^n” .nouovti h>®w uoy ea^ftOQ?^ v W> (tsv^ '•ort Jud .»n»» •<! otia n«o

;marirfJ%t5 contaknid<i \n r4r. pacKdt, Include: ^ r .a

' eno rtjiw JwT oc?»«o«Th*V rToWB7><rtom«r& • fvui o* yU Biw »w .tigoj ,J3 ni nwx)^ »rti To n*q tA

,. 1UOOO Uiw Wc*^st •' *' '^.’nTJS

* Sol of vof)r,e£lior> Ta I'Tie inanoqmi n» s-'WfiWXiiMiiiflSef'’ vKto* '« yHlancuonul «ni tietae o> y« Jon oO - I .jnolhj^

*iOfn A t^u Miw *|f* rtOAOioq* «'uoJ .)S,(V 0#«s»i!Jt)* *d Otw tertJ *o*»l

100 »« «mio» •»»(ffyft«*ufr«jTnO' .'y?fr*''toe* tvod» Al'nwo al.oM* ;*5 of mvjt mteto •viwwioiqmoo

«m Io E.O nolzi««^^^f^l5»W»d I8W . 908,0 Wn, .moK t.fll nt t»o«J Od w 9W»«nv9 9d

.»iuoJ?nfca>ff5lBea,i»or»:tS*isom AfciM6«lijm »o »»« lomono nA .fn*muooD t.ufttf

0 oT :ifiBmqol«v*Q BtbO Jt#T

' UbT

“ '"llwrT^drrtdtT^oR^ of’»» twwiwwA w --«.**- and rgSiil^ itot wit mob b^oivcAc 6diJ?um nwunn^^oi ^-QoonB

,»<qmexB .tmoTtya BfTKje no r>oto«^#Qo emT»b y«m Jati: e^qiiOB .ottdooTqBtQ lot nsnoqrM.

•/If joool W »«nOBb 08£ 7Qt3oa^ n«o a«tMo« miw ifn«lfy« btoob

- ytieT sHot o) eeso )«•! oeJBkjmoo

National Bureau of Sun^tanis Nfartin Marietta Bnerfy Synems

.eeeeifM»4>awt3ra* >0 noitoanoo v> onfe^Jftp<9TW*?PE5

boco^

10 bBiBWjWT peke* #a®b5WI|i ti*w crdbifrimoO ,t)0muw btb «JfMjnvnoo

^

.^T tiiuL 0) bms

^ ***^ *

mo>i noltoee r^ttt Bfij )o b«ib ’0' iwtt jo ooijin^)«b ®c««f1o 01 »a«oq<y»q a » ei^

30 OJ fbe«rf o«iA .m^b e»ol^ -#m OJ typvom *d einemmoO .£^0^*32 oJ iinammoQ

r. _k. a . ^ ^L3KM.^TJ^Lfin^ ,noiJ09^ pbiB flfTtt k> '1' vj» b2 «o Je«t Bfli k> me>nl »t1! r>o beoaiq ai«ar*om«

Good UiOk.

ThortkKi Wfighu NBS

,*'’^3' (VV' ^
;. .

• «^ (L

Sa‘

• “J • ..- ^ ^ -I ' Ti- r«

,V,^. ' v

v'V - ' ^i'K

ir -

Jt’* » *

'’’ ! • J*'

,5.- . % ‘- e^-ilsT #•*>*?

uuiiii,r:;?^Kj IWi igEs AiFiJCATioji ioa5*/:'S

A.

_

- • 1»^, • ^

“ • <*' ,

>,

.. ^,, v.r- , -».. »

f'- »

'n'ji . i‘. ' fc»' wn"^-fc- i . ', -•

•

' *"?‘j

-^i .

'“‘i

Prepared jfor tci^ ' b* jXiCb:, CAX3 PtPjSjraw p.Sil^Cd V

StradfottS- M.

'^" Uji*'—irs’>; T^rioht '' f<^^v'-

Sd Jidt^Hsa?

'-Vf_.’<f V» ‘i :

GUIDELINES FOR IGES APPLICATION SUBSETS

Prepared for the

DOD CALS Program Office

Bradford M. Smith

Thomas P. Wright

29 March 1987

TABLE OF CONTENTS

PREFACE

FOREWORD

Acknowl edgements

1.0 SCOPE AND PURPOSE

2 . 0 BACKGROUND

2 . 1 Importance to CALS

2.2 Digital Product Data

2.3 Life Cycle Use

2 . 4 Product Data as a Resource

3 . 0 APPLICATIONS SUBSETS

3.1 Definition and Importance

3.2 Present Use of Application Subsets

3 . 3 IGES Subsets of Interest to DOD

3 . 4 General Subset Requirements

Information Mapping

Entity Content

Restrictive Set

3.5 Specific Technical Content

3 . 6 Prioritization of Development

3 . 7 Example Application Entity Subsets

Technical Publications

Engineering Drawing

Electrical PC Boards

4.0 TESTING METHODOLOGY FOR APPLICATION SUBSETS

4 . 1 Testing Methodology Concepts

4.2 Use of Entity Mapping in Data Exchange

4.3 Requirements for a National Verification Program

4.4 The Verification Process

4.5 Current Efforts and Status

5 . 0 TECHNICAL ISSUES

5 . 1 Control over Operator Data Entry

5.2 Requirements on IGES Translator Design

5 . 3 Flavoring and Deflavoring Requirements

5.4 Software Tools for Acceptance Testing

5.5 Testing of Datasets for Conformance

6.0 POLICY CONSIDERATIONS

6.1 Policy on Purchase of Datasets

6.2 Acceptance Testing of Datasets

6.3 Verification of Source Preparation Systems

7.0 ACTION REQUIRED TO IMPLEMENT

8.0 REFERENCES Glossary Bibliography

9.0 APPENDICES
PREFACE

The enclosed material represents ideas and

concepts that are under active discussion by

members of IGES Technical Committees. Your

comments and ideas are solicited on these topics

and should be addressed to the author.

It should be noted that this document has been

submitted for detailed review by the IGES

Organization and, as a result, may undergo

major changes during technical review. In its

present form, the document represents opinions

of the authors only and should not be taken as

representing any wider consensus such as from an

IGES committee.
FOREWORD

This document addresses the specification, purchase and

acceptance testing of product data in digital form. It has been

prepared by the National Bureau of Standards under a contract

from the Computer Aided Logistics Program in the Department of

Defense. The document reports on the IGES application subset

concept, identifies several urgently needed subsets, itemizes the

required technical content of any subset, and gives several

examples of draft application subset documents.

It is intended that this report be reviewed widely by the

Department of Defense, by its industrial contractors, by

committees of the IGES Organization and by interested professional

associations. While the document has been prepared for DOD use,

the information is generic and usefull for by all parties

involved with the transfer of digital product data files.

Suggestions for additions and corrections to this document should

be sent to Mr. Bradford Smith, AlOl Sound Building, National

Bureau of Standards, Gaithersburg, MD 20899

Acknowl edgement

This document draws heavily from thousands of man-hours of

experience gained by members of the IGES Organization who have

volunteered their time and energies to solve the problems of

digital product data exchange.

Particularly important has been the work of the Testing

Methodology Committees under Jim Fleming of Cummins Engine

Company, the Electrical Committee under Larry O'Connell of Sandia

National Laboratories, the Technical Publications Committee under

Kelly Chi of McDonnell Douglas MDAIS and the Drafting Committee

under Bob Colsher of IGES Data Analysis Company. In addition, Ron

Downer's work on application subsets at Hughes Aircraft EDSG has added

much to this document.

Special thanks also go to Phil Kennicott from General Electric

Company, to J C Kelly from Sandia National Laboratories and to

Mark Palmer from the National Bureau of Standards.
£.

rv X.: r f -.

Ci?owawo^ ' '

tnii •rf^ ^^mssoob slrfT

na*d aari dl .»nol i».tJfcpib ni aJab dooboTtq 5o ?«i3aai aonaaqaaoe

dOB^Jnoo a ^»bno si«**naSE io oa*i 0a lanoiJaH arid yo bMaqaiq

lo 3n»nl::Bqsa »tU ni aaivarq aaiJalpcJ babiA fiuqt^ add coi3

daadirc nojtdesUqqe 32tl>: and no a^-ioq»-j 3n»«i/50b ariT .aana^aa

arid asiiaaJJi ,«daacf0« b*ba«n y^dTi«Bi0 laTavaa aaxSldnabi

Xanavaa aavip bni ,d*adba yna lo dnadnoo laoinrtaad

a S3MdJJM no2^<6oJ^ iqcjA io

Th«®enclo##d mnrBt^ontJi ld^-?sa

lenoiaaalO««Bb*eaa»**rti *yc.

.aaw ao«;3o»i-i>«ta(qb»q.v»-.*i.«<» ^n9KiP>h>A^r*Mf* t!

eald^eq IXa yd Tu>4 liulaau bfU onanap ai noxdetrjolni arid

laaifcbuAdabadaiifcaaBj 'SmtXtih bavlovni

oubaittjid roi cictai^«4 rWi«w m» tli# ^ ^ biuorie

...preaar.t toT», eeaoc -«lB«eTO^t?ia4fti*’«fe'??A'?iS® ua«o«

<rf 'Lh^ onl> «r>i' fb3al<l not be es » any v.dor con*4in«* a nich as frcr An

Xa£^ e<SHLltt4MI.

aJ rt4ie 9 beXvon;U>A

lo 2-xiiorl-n«« io ebnaatJOrti ocni siivB»si awKnb jfl#««oob eirfT

avAri ortv noiJasi/iAptxO S30I srli io aTadaa« Y<i

5o B«9 ldo-tq arid avXo« od »aip^ana bna aaiJ

'-i .apnarioxa flJab i^uboxq lA^ipJb

fc,a«r;s ^ pnideaT arid ^o jhjow f*tld niad «»rf

©niPfia aninrebS lo pniaan «iti uabnw aaaddiMoO , albnaE lo XIanhoO'O.'rnaJ dafcrtb Xwoid^ ' •sabnw aeddimaoo 8noXdaaiX*riJ XaoxnnsaT arid

i«»

, aeddlmwoD poidSaia arid bna aiAOM aaXpuoQ XXannoObK lo ItD yXX^

noH,,noidlbbB nl .ynsqiaod aiayXBoA

bb^ a^ri oaaa dl«o,iA -ripaH d» adaadua

oiidoeia XB^anaO ffloil ddooinnaS XXtN ^

i od fans ealdodBiooU XBnoldBM elbneE cwja yXXaX 0 Z *^"“2^^ •

-

- ,zbTJ6bfiBJ2 io uaaxifS Xenoi-^&M noxl xanXe^? Xxaff

i. v/^
1.0 SCOPE AND PURPOSE

This document has been prepared for the Department of Defense

program on Computer Aided Logistics. The report addresses

mechanisms for incorporating the exchange of digital product data

into the normal procurement and business operations of the DOD.

Requirements are given for the specification, purchase and

acceptance testing of product data in digital form. The document

calls for the use of application subsets of the Initial Graphics

Exchange Specification (IGES)

The report defines the general content and use of an IGES

application subset and presents the rationale for technical

choices made. Present use in government and industry is

documented, and several urgently needed subsets are specifically

identified. The report itemizes the required technical content of

any subset, enumerates several application subsets for future

development, and presents draft application subsets for Technical

Illustrations, 2-D Engineering Drawings and Electrical Printed

Wiring Boards.

Finally, this document addresses the implementation of the

application subset concept. A draft policy statement is given in

Appendix A as a model for adoption. The policy addresses digital

data exchange for internal transfer within an organizational

element, external transfer to contractors, acquisition of new

parts/systems, data transfer from design to product support, and

archival storage of parts/assembly product data.

Appendix B contains an updated DOD Standard addressing the use of

digital product data. It generalizes the earlier Air Force work

on MIL-STD 1840 which was primarily concerned with exchange of

technical documentation in digital form. The standard calls for

the use of SGML, IGES, CGM and CCITT for technical documentation

and IGES, CGM and CCITT for 2-D engineering drawings. Other

product data is specified to use the existing IGES standard and

the evolving standards PDES, EDIF and VHDL. Where IGES or SGML

is specified, a reference is made to a separate DOD specification.

Appendix C contains the recommended draft DOD Specification for

IGES Application Subsets. The document identifies the general

content for any subset and specifically gives the requirements

for three initial subsets; Technical Illustrations, 2-D Engineering

Drawings and Electronic Printed Wiring Boards. More application

subsets are expected to be added in the future.

1
2.0 BACKGROUND

2 . 1 Importance to CALS

The objective of the CALS program in digital product data is the

effective exchange of data throughout the life cycle of weapons

systems development and deployment through the use of computer

readable datasets describing the systems, their individual piece

parts and their product support data. A central issue here is

the technology of digital representation of product data in its

many forms of illustrations, drawings, 3-D wire frame models,

surfaced models, solids models and complete product models.

The NBS CALS Program in product data exchange addresses

the exchange, archiving and future use by DOD of digital product

data. Major thrusts are:

development of a comprehensive program of testing and

evaluation

identification and solution of problems encountered in

intersystem data exchange

research into the unique requirements for long-term

archiving

development of software tools to assist users in making

routine production use of digital product data

continued development of new applications capability

validation of new applications areas

developmental work for complete product model data.

Throughout the DOD and its partners in industry, an increasingly

larger number of computer aided design systems are being used in

all phases of design, analysis, manufacture and test of weapons

products. Over a hundred vendors offer these CAD systems. And

it is natural that different DOD activities or different

companies would choose different vendor systems to meet their

varying needs. Hence, there is a requirement in the normal

course of business to be able to exchange the digital part models

that are developed on one system to be used on another system.

Estimated at $4.3 billion in gross sales for 1986, the CAD

industry is expanding quickly, and the capabilities of CAD

systems are similarly changing. But the need for part model

exchange among these systems has not diminished. Rather, with

over 10,000 new CAD systems being sold each month, portability of

data is even more important to the DOD and its contractors each

day. The exchange of digital product models is expected to

become as commonplace in the 1990 's as the exchange of paperbased engineering drawings is today.

2
It is essential for CALS to be able to fully utilize these

automation resources both at contractor and subcontractor

facilities as well as inhouse for design review, second sourcing,

overhaul planning and spare part production. Digital product data

exchange plays a key role in each of these areas. 2.2

Digital Product Data

Two terms will be used; product definition data and product data.

Product Definition Data (PDD) denotes the totality of data

elements to completely define the product. Product definition

data includes the geometry, topology, relationships, tolerances,

attributes and features necessary to completely define a

component part or an assembly of parts for the purposes of

design, analysis, manufacture, test, inspection. Very little, if

any, process data is included, with the exception being reference

to a process standard (MILSTD) or reference to a procedure which

results in a product condition that is not easily specified,

e.g., heat treating for 1 hour at 320 degrees. The product

definition is expected to be sufficiently complete as to enable

the generation of all downstream process data.

Product Data is more broadly defined than Product Definition

Data. Product data includes all of the product definition data

plus a larger class of data elements necessary to fully support

the product for all applications over its expected life cycle.

2.3

Life Cycle Use

Indicative of this larger class of product data are engineering

analysis models or results and illustrations of the product to be

used in documentation regarding operation, maintenance and

engineering change control. Product data spans the entire range

of disiplines from conceptual design and engineering analysis to

manufacturing planning, production, test, inspection and

deployment. Data packages are expected to go through repeated

exchanges between primes, subs, government project managers, test

labs, and consultants.

2 .

Product Data as a Resource

The CALS Program requires the ability to deal with digital

product data for four generic applications:

Internal transfer of product data among DOD components

The acquisition of new manufactured parts/systems

Data transfer fom Design systems to Product Support systems

Archival storage of parts/assembly information

3
Numerous internal transfers of product models are found in R&D,

prototype design, overhaul and retrofit planning, and each is a candidate for digital exchange in the immediate future.

Digital product data is becoming an important consideration in

DOD's contractual relationship for purchase of manufactured

parts, assemblies or whole systems. Considerable work is

evolving in the area of electronic publication and digital

exchange of technical documentation. MIL-STD 1840 is being

coordinated for DOD-wide approval and makes use of a subset of

IGES for the exchange of the illustrations in a document. This

is thought to be quite appropriate since many of these

illustrations are derived directly from the 3-D CAD product

model

.

DOD has significant investments in data archives necessary to

support its deployed forces. Presently this data consists of

millions of drawings stored in data repositories, but many

agencies are beginning to address the problem of long-term

archiving of digital product data.

The economic significance of digital product data is easily seen

from these examples. Efficiency, accuracy and leadtime

improvements are all substantially enhanced through the use of

CAD and CAM technology made possible by the sharing of product

data. The CALS Program addresses this importance and is expected

to produce deliverables of use by all of US industry.

4
3 .

APPLICATIONS SUBSETS

Even with the great variety of CAD systems in the marketplace

today, no one system has the depth and breadth of capability to be

able to satisfy the needs of all users. Hence, an organization

tends to purchase a variety of CAD systems, each one thought to be

best suited for its intended application. Data must be

transferred among these business entities at major milestones of a project - design to engineering, manufacturing to inspection,

prime to subcontractor or vendor to customer. When IGES is used

for the exchange, a range of entities are needed to convey the

application's information content. This list of entities, a

subset of the IGES entity list, becomes of priority importance to

the successful exchange of the application.

3 .

Definition and Importance

The range of applications for digital product data is extremely

large. Missile nose cone geometries, tank tread designs,

footware sole pattern molds, machining geometries, technical

illustrations and architectural floor plans each have their own

requirements for data content and organization. Some

applications like drawings make use of simple modeling techniques

like wireframe geometry while more sophisticated applications

like tank vulnerability analyses require a solids modeling

approach.

Each of these applications areas has different requirements for

the data needed to describe the product model. The first step in

specifying how an applications area can exchange its product

description as a digital dataset is to carefully define the

information content to be transmitted. The second step is to

specify how this information is mapped unambiguously into

each IGES entity. The resulting list of IGES entities and their

meaning in the context of the application forms what is termed

the application subset.

An application subset of IGES can then be defined as a set of

specific IGES entity types which are used to completely and

unambiguously represent the information requirements of the

product for the named application purpose.

3.2

Present Use of Applications Subsets

Application subsets are a natural way of organizing the

informational needs for product data transfer and are being used

already by several companies and government projects. Among

these are CAD system procurement specifications from the Naval

Sea Systems Command and from Hughes Aircraft, the Boeing TOP

Technical and Office Protocols specification for product data

exchange, and the draft Military Standard 1840 for Automated

Interchange of Technical Information.

5
The impending Navy procurement of CAD workstations recognizes

that there are five major application areas to be addressed - mechanical design, aeronautical design, architectural engineering,

electrical/electronic design and technical publications. It is

felt that no one vendor system can effectively meet the Navy

specifications in all areas. Hence, the Navy strategy is to

allow multiple vendor awards and require IGES for internal

transfer of product data among the dissimilar CAD systems.

Because it is unrealistic to require each vendor to support all

IGES entity types, application subsets of IGES will be specified.

Conformance to Version 3.0 is re<^ired. Conformance to future

versions of IGES are called for within six months of publication.

The Hughes Aircraft Company makes use of multiple CAD systems in

all phases of their mechanical design, electrical design,

engineering and manufacturing processes. To be able to make use . of the best tool for each job, they have stressed the need for

digital data exchange through IGES entity subsets as mandatory

requirements of their CAD system procurements. Version 3.0 of

IGES is specified. Application subsets have been defined for

solids modeling, mechanical design/drafting and printed circuit

boards. Future work will develop subsets for finite element

modeling, manufacturing process planning and NC tool paths.

The TOP Specifications are being developed by an industry

consortium administered by the Boeing Company to address the

exchange of typical data in the engineering, manufacturing and

general office environments over telecommunications networks. One

problem, of course, is the identification of standard formats for

product data description. TOP views product data exchange as

critical to the successful implementation of an integrated

business strategy. In the TOP 3.0 Specifications, product data is

to be exchanged via a defined subset of IGES 3.0 entity types with

explicit constraints on file format, structure and content.

Two additional subsets are given in the appendices of IGES

Version 3.0 and Version 4.0 documents. These are the Process

Plant Flowsheets and the 3-D Piping System application subsets.

The piping material has been influenced by the work of the Navy

Seawolf Project (SSN21) and has been approved by the IGES

Architectural Engineering Committee.

Table 1 compares the IGES Entity Type content of the above

subsets. The application subsets listed across the top have been

assigned acronyms as:

MLSTD MIL-STD 1840 of 11 Sept 1986

T PUB IGES Tech Pubs Application Guide - Draft Feb 87

HA/EL Hughes Aircraft Electrical Subset - V 1.5

ELCAG IGES Electrical Application Guide - Draft June 86

SOLID Hughes Aircraft Solid Modeling Subset - V 1.5

DES/D Hughes Mechanical Design/Drafting Subset - V 1.5

TOP Technical & Office Procedures - Draft Feb 87

FLOW Flowsheet & Instrumentation Diagrams - IGES 3 . 0 App C

PIPE 3-D Piping Systems - IGES Version 4.0 Appendix

6
E

N

T

I

T

Y

100

102

104

104

104

104

106

106

106

106

106

106

106

106

106

106

108

108

108

110

112

114

116

118

118

120

122

124

125

125

125

125

125

126

132

202

206

210

212

214

214

214

214

214

214

X =

TABLE 1 IGES ENTITY CONTENT FOR SUBSETS

F

O

R

M ENTITY NAME

M

L

S

T

D

T

P

U

B

H

A

/

E

L

E

L

C

A

G

S

0

L

I

D

D

E

S

/

D

F P

T L I OOP

P W E

Circular Arc X

Composite Curve X

Conic Arc - General X

1 Conic Arc - Ellipse ?

2 Conic Arc - Hyperbola ?

3 Conic Arc - Parabola ?

1 Coordinate Pairs

2 Coordinate Triples

11 Linear Planar Curve X

12 Linear Curve

13 Linear Curve/Vector

20 Centerline Thru Points

21 Centerline Thru Centers

31 Section Lines

40 Witness Line

63 Simple Closed Area X

0 Unbounded Plane

1 Bounded Plane

-1 Planar Hole

Line X

Parametric Spline Curve X

Parametric Spline Surf

Point X

0 Ruled Surface - Eq Arc

1 Ruled Surface - Eq Param

Surface of Revolution

Tabulated Cylinder

Transformation Matrix

0 Flash - Ref Entity

1 Flash - Circular

2 Flash - Rectangle

3 Flash - Donut -

4 Flash - Canoe - Rat B-Spline Curve X

Connect Point - Angular Dimension

Diameter Dimension

General Label

General Note X

1 Leader Arrow - Wedge -

2 Leader Arrow - Triangle

3 Leader Arrow - Fill Tri

4 Leader Arrow - None

5 Leader Arrow - Circle

6 Leader Arrow - Filled C

X X

X

X

X

X

X

X

X

X

X

X

X X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X>X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

XXX

X - - X X - - X ? - - x ? - - X ? - - R _ _ _ R - - - R - - - R - - -

X - - - X - - - - R - - - X X - - R - - - R ? - - R ? - - X X X X

X X - -

X X - -

X X X X

- X - - -XX

X X - - X X - - X X - - X X X - X ? - - x ? - -

X ? - -

Supported on Input & Output R = Supported on Input Only

7

X

X
TABLE 1 - IGES ENTITY CONTENT FOR SUBSETS

(Continued)

E

N M T H E s D

T F L A L 0 E F p

I 0 S P / c L S T L I

T R T U E A I / 0 0 p

Y M ENTITY NAME D B L G D D p w E

214 7 Leader Arrow - Rectangle — —

’ — — — — 7 — - 214 8 Leader Arrow - Filled R - - - - - - 7 - - 214 9 Leader Arrow - Slash - - - - - - 7 - - 214 10 Leader Arrow - Integral - - - - - - 7 - - 214 11 Leader Arrow - Open Tri - - - - - - 7 - - 216 Linear Dimension - - X - - X X

' - - 218 Ordinate Dimension - - X - - X - - - 220 Point Dimension

222 Radius Dimension - - X - - X X - - 228 General Symbol - - X - - X - - - 230 Sectioned Area X X - - - X - - - 302 Associativity Def - - X X - - - - - 308 Subfigure Definition X X X X - X - - - 312 0 Text Template - Abs - - X X - - - X - 312 1 Text Template - Rel - - X X - - - - - 320 Network Subfigure Def - - X X - - - X - 402 1 Group w BP Instance - - X - R R - - - 402 3 Views Visible Inst - - - - X - - - - 402 4 Views Vis, Color, LW - - - - X - - - - 402 7 Group wo BP Instance - - X - X X - - - 402 9 Single Parent Inst - - X - X R - - - 402 18 Flow Associativity - - X X - - - X X

404 Drawing X X X - - X - - - 406 2 Property - Region Res - - X X - - - - - 406 4 Property - Region Fill - - X X - - - - - 406 5 Property - Line Widen - - - X - - - - - 406 6 Property - Drill Hole - - X X - - - - - 406 7 Property - Ref Desig - - X X - - - - - 406 8 Property - Pin No. - - X X - - - - - 406 9 Property - Part No. - - X X - - - - - 406 11 Property - Tabular Dat - - X - - - - - - 406 12 Property - Ext Ref FL - - X - - - - - 406 13 Property - Nominal Size - - - - - - - X 7

406 14 Property - Line Spec - - - - - - - X 7

406 15 Property - Name - - X - - - - - - 408 Subfigure Instance X X X X - X - - - 410 View X X X - X X - - - 412 Rect Array Sub Inst X X X X - - - - - 414 Circ Array Sub Inst X X X X - - - - - 416 0 External Reference — — — - - - - X X

416 1 External Reference

416 2 External Reference - 420 Network Subfigure Inst - - - - - - - X X

X = Supported on Input & Output R = Supported on Input Only

8
As can be seen from Table 1, several inconsistancies remain to

be resolved among the different application subsets:

1. MIL-STD 1840 has chosen to allow only default identity

Transformation Matrices while the IGES Tech Pubs Subset

allows arbitrary Transformation Matrices to move entities

from Definition Space to Model Space position.

2. MIL-STD 1840 and the IGES Tech Pubs Subset use a simplified

form of Drawing and View entities to make the illustration

file acceptable to most CAD systems. The Hughes Solid Subset

is missing the Drawing entity.

3. The IGES Electrical Application Subset and the TOP

Mechanical Subset contain neither the View nor the Drawing

entities. This makes it impossible to construct a part

model on some CAD systems.

4. The TOP Specification calls for an application subset to be

implemented in accordance with a list of IGES Recommended

Practices which further specify the processing algorithms to

be used. These include:

1 Delimiter

2 Witness Line Suppression

4 Transformation Matrix Processing

5 System ID Parameter

7 Maximum Coordinate Value

8 Independent Witness Lines

15 Zero Radius Arcs

16 Translation Vector

17 Model Space Scale

19 Independent and Dependent Processing

20 Back Pointers in View Associativity

21 Comments in PD Records

22 Bounded Planes

24 Representation of Linear Strings

5. The TOP Specification calls for implementation of RP 12 on

Flag Notes without requiring the Flag Note entity.

6. The TOP Specification is not specific as to which Leader

Arrow Form Numbers are required.

7. MIL-STD 1840 and the IGES Tech Pubs Subset both call for

adherance to IGES Version 3.0 yet ask for Line Font 5

(Dotted) in Global Field 4. This capability exists only in

IGES Version 4.0

8.

The Hughes Aircraft Specification for Electrical and for

Mechanical Design/Drafting requires three new Leader Arrows

(2pts, 3pts and 4pts) not in IGES.

9
9 . The Hughes Aircraft Specification for Electrical and for

Mechanical Design/Drafting requires General Note Fonts

1, 1001, and 1002 to be fully supported with Font 0 only

processed when reading in an IGES file. No other subse":.

requires these fonts to be fully supported, although two

others restrict the value of the PD Index to these fonts.

10. MIL-STD 1840 and the IGES Tech Pubs Subset both call for a DE

Field 4, Line Font Pattern, value restriction of 0 for Entity

type 414, Circular Array Subfigure Instance. But neither

subset places a similar restriction on Entity type 412,

Rectangular Array Subfigure Instance.

11. Only the Hughes Aircraft Specifications place, requirements on

the Global Section parameters. Notable among these are:-

Field Value Required

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

1-4

0-7

1.0

1-11

Y

Y

Y

Y

N

Y

Y

Y

Y

Y

Y

N

N Default to Field 3

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

10
3.3 IGES Subsets of Interest to DOD

The list of application areas of interest to the Department of

Defense is expected to be quite long and to grow with experience

as digital product data exchanges become commonplace. But a controllable population is expected. Historically, the IGES

Organization has worried about the proliferation of entity types

as new application areas express their requirements. Fortunately,

this has not been found as major a problem as anticipated, and the

same is expected with application subsets.

Presented here are several subset definitions known to have a following in the DOD. Undoubtably, there are others. And no

special effort has been made to eliminate an overlap of

requirements. They are by no means specific only to DOD needs

and will benefit from industry collaboration as well.

Technical Pxiblication Illustrations - The exchange of figures for

a technical document requires 2-D geometry plus annotation.

Emphasis is on visual clarity for human interpretation.

Engineering Drawing - The 2-D Engineering Drawing is presently the

backbone of product definition. Information is presented to

conform with certain standards of style and content as set

forth by ANSI Y14.5, MIL-SPEC 's and MIL-STD's. Exchange

emphasis is on completeness, visual equivalency and

functionality of the received drawing model.

Electrical Printed Wiring Boards - This subset handles both the

physical description of printed wiring assemblies as well as

the logical information describing connectivity and schematic

representation. Design, engineering, manufacturing, testing

and inspection processes are supported. Cabling and

connectors can also be modeled.

Process Plant Flowsheets - Process flowsheets identify the process

streams, their direction and instrumentation lines flowing

through a plant. They identify the equipment names and the

positions on the equipment where the lines connect.

Properties can be attached to the lines or to the equipment.

Mechanical Design/ Drawing - Frequent exchanges are made of 3-D

mechanical part models along with a drawing derived from the

model. Part geometry is given as a 3-D model in either

wireframe and/or surfaced form. The drawing must be able to

meet ANSI Y14.5 or MIL-SPEC requirements. Data requirements

include those of 3-D mechanical models, those of 2-D

Engineering Drawings and other entities which define how the

views on the drawing are derived from the part model.

Architectural Engineering and Construction - Many AEC applications

exist and are rich in non-geometric data content. Progress is

being made in Tabular Data, Connectivity and External File

Reference to assist these future application subsets.

11
3-D Piping and Tubing - Found in buildings, refineries, ships and

trucks, piping and tubing systems direct fluids to various

pieces of equipment. The information content of these systems

includes equipment nomenclature, connect nozzles, connecting

pipes and the pipe line attributes.

Mechanical Solid Modeling - Solid modeling is predominently used

for conceptual design of mechanical devices and assemblies.

.The solid model allows the user to check for clearance

problems, compute mass properties and generate shaded images

of the product. Data generated in the solid model application

is often passed to other solid model based applications. This

application subset addresses the Solid-to-Solid information

exchange

.

NC Data Generation - The mechanical part model and the

manufacturing process plan form the input for numerical

control machining data preparation. Outputs include the

required fixtures, the cutting tools and the toolpath control

data for the selected machine. The input requirements for the

part model are addressed by this IGES NC Data Generation

Subset. They include 3-D wireframe geometry, 3-D surface

geometry and first order continuity along part geometry.

Finite Element Modeling - Exchange between a product design system

and a product structural analysis system requires capability

to describe the 3-D finite element mesh, the engineering

parameters of each finite element and the nodal analysis

results

.

This list of applications is far from complete and will grow with

experience and time. No priority order is inferred by this list

although Technical Publication Illustrations is becomming quite

mature with the coordination of MIL-STD 1840 for DOD-wide use.

The Electrical PC Board subset represents years of work by the

IGES Electrical Committee and is ready for prototype trial.

Process Plant Flowsheet has been reviewed as an appendix to IGES

Version 3.0, and 3-D Piping is a recent product of the IGES AEC

Committee to appear in IGES 4.0 The Hughes Aircraft procurement

specification is the source for the remaining subsets and has been

reviewed by knowledgable staff and vendor implementors.

Remaining to be done is to poll the DOD community for additional

ideas on IGES application subsets and their priority needs. This

can best be done through the NSIA CALS committees, the DOD

Manufacturing Technology Advisory Group, inhouse program managers

from all service components concerned with each application, CALS

service contacts and members of the IGES Organization who are in

the DOD or affected companies.

12
3 . 4 General Requirements

It is important that the specification of any application subset

be complete, precise and unambiguous. Incomplete translator

implementations or differing interpretations of entity meaning will

degrade the quality or will limit the quantity of information which

can be exchanged between sender and receiver. The application

subset specification must be complete in that it be designed to

stand alone as a document referencable in a legal contract for

deliverables. It must be precise so that the accuracy and

functionality of the received data is sufficient to support the

intended use of the data. And the specification must of course be

unambiguous so that application information which was mapped into

IGES entities can be fully recovered without any loss at the

receiving site.

An application subset is thought to be a mechanism which will

substantially improve the completeness of data exchange in the

specified area of use over what can now be transferred. For this

end-to-end data exchange to happen:

The information to be transferred must be identified.

The information must be uniquely mapped into IGES entities.

The entities must be exchanged accurately and completely.

The receiving system must be capable of processing each

entity in the subset.

The receiving system must be capable of representing each

information construct.

The most demanding of these steps is that of identifying the

information content of a prescribed application area. Formal

modeling techniques such as IDEFIX, NIAM and EXPRESS which are

being used in the IGES Organization are certainly of help for

this

Next the information must be mapped into a series of IGES entity

types. It is important that this mapping be unique, for if a

dashed line is represented in any of three different ways as IGES

now allows, a receiving CAD system must be very intelligent to

recognize they are identical.

This leads to a restrictive entity subset for each application

area. No entities can be used which are not enumerated in the

application subset. While it is recognized that this places

burdens on the software developer and on the CAD operator, no

other way guarantees the needed completeness of data exchange.

See Section 5.0 of this report.

A last requirement of an application subset is to properly limit

the range of entity type numbers and their parameter values. The

entity descriptions which result are called the application subset.

13
3.5 Technical Content of an Application Subset

An application subset must be sufficiently precise and comprehensive

in its definition to serve as a portion of a contract between the

two parties of the data exchange. At a miminum, the documentation

requirements for an application subset include the following:

SCOPE - A general introduction of the application and the

discipline being served. Statements of purpose of the subset

and a specific description of the industry and range of

applications to be served will be given.

INFORMATION REQUIREMENTS and DATA FUNCTIONALITY - A detailed

list of what must be transferred through the use of the subset.

This could include 3-D geometry, associativity elements denoting

fluid flows, view transforms, fonts, and so forth. This section

must be filled out with considerable care because it will serve

as the basis for deciding which entities will be included in

the IGES subset.

IGES ENTITY SUBSET SPECIFICATION - The description of the

entities to be used for the subset. An optional section

describing why these specific entities and not others were

used, can go here. Limits on parameter range.

MAPPING of INFORMATION CONTENT to IGES SUBSET ENTITIES - This is the specification of how the application functions and

related information is to be mapped into an IGES subset. As

an example "All steam lines will be represented by copious

data entities of Form 3 denoting x, y, and z coordinates".

The Implementors of IGES translators will use this section

as a guide for designing their products.

DATA ACCURACY REQUIREMENTS - A description of data

accuracy requirements not covered by the data functionality

section. Such items as the minimum number significant digits

would be included here

USER CONVENTIONS and DATA ORGANIZATION - A listing of the

required usages not normally covered by the IGES specification.

An example would be; "Electrical details are presented in level

4, plumbing in level 5"

TESTING REQUIREMENTS - A detailing of the test cases used and

their purpose. The concept and its implementations must be

tested. Each functional component should be covered by one or

more test cases. This section describes them and the results.

EXAMPLES of APPLICATION SUBSET USE - An instructional set of

examples showing typical use of the subset.

REFERENCES

14
4.0 TESTING METHODOLOGY FOR APPLICATION SUBSETS

The development of IGES validation testing methods is one of the

major projects of the IGES Organization. This section summarizes

the current efforts in testing methodology, summarizes the

concepts developed for the program, and provides a more detailed

look at how application subsets can be tested. Version 0.3 of the

Testing Methodology working paper is included as an appendix.

This document is now being coordinated by NBS and will be

substantially revised and expanded by March 1987.

4 . 1 Testing Methodology Concepts

IGES Testing is concerned with developing and maintaining test

procedures which deal with verification testing, validation of

processors for specific application subsets, and application specific,

user performed acceptance testing.

Verification testing is aimed at ensuring that the implementor's

claims for entity mapping and functionality of translation are

accurate. Validation testing is aimed at ensuring that application

subsets of IGES are treated in a manner consistent with the

application. And acceptance testing is aimed at ensuring that

particular IGES processors will work adequately in a user's

environment. The immediate goal of the Testing Methodology

Committee is to establish a verification program for translators.

Objectives of this testing are to verify the correctness of the

implementor's claims for individual entity processing, to measure

the precision of data translation and to assess the degree to

which the functionality of the entities have been maintained.

Functionality of the results of a translation is defined as the

degree to which received entities can be manipulated as if they

had been generated on the receiving system.

There are several major reasons why testing IGES processors is

necessary. Both implementors and users of the processors are

interested in testing. Implementors need a set of widely accepted test

procedures and data in order to ensure that their products conform to

and adequately support entity subsets for a specific application area

of the IGES standard (i.e., verification and validation testing).

Users and implementors need a set of widely accepted test procedures

to determine if the processors in question will adequately support the

user's data exchange requirements (i.e., acceptance testing). In

addition, users frequently desire advice on how to construct test data

sets which will accurately reflect these data exchange

requirements. Finally, since much data exchange, worth millions of

dollars, will be accomplished using IGES translators, users are

requiring more assurance that the data is not being modified or lost

during the exchange process.

15
The objective of IGES testing is to expose flaws in the IGES

products (i.e., to show where products do not work as they

should) . In his book, "The Art of Software Testing" (MYER79)

,

Glenford Myers cites the following basic principles:

. Testing is the process of executing a program with the

intent of finding errors.

. A good test case is one that has a high probability of

detecting an as yet undiscovered error.

. A successful test case is one that detects an as yet

undiscovered error.

In the context of generalized IGES translator testing, the test

cases developed will be aimed at exposing flaws in important

features of the translators. A broad range of test cases will be

validated and thoroughly documented.

This section has been condensed from the working papers of

the testing methodology committees with modifications to

incorporate recent progress and to specifically address the needs

of application subsets. The intent is to provide a background in

testing concepts for the reader. More detailed information can

be found in the working document (TESTS 6)

.

4.2 Use of Entity Mapping in Data. Exchange

Entity mapping can be described as the manner in which the

implementor of a translator has defined the correspondence between

native entity forms (i.e., the entity form maintained within a system)

and the IGES entity forms (i.e., the entity form contained in the IGES

Specification) . For example, a string of curve and line segments on a system may be translated into a Composite Curve entity (Type 102) by a preprocessor. This correspondence of a string in the native form to a Composite Curve in the IGES form is the preprocessor's entity mapping

for the native string entity. Similarly, a postprocessor may translate

a Copious Data entity (Type 106) into a 3-D line entity on the

receiving system under some circumstances. Thus, the correspondence of

the Copious Data entity to the line entity is the postprocessor's

entity mapping for the IGES Copious Data entity.

The entity maps can be used as a first step in predicting the expected

completeness of data exchange between two systems. Knowing the native

entities which are to be used on the sending (or initiating) system,

the end user can follow each entity through the entity maps for both

the preprocessor and the postprocessor to see what the resulting

entity will be on the receiving system.

16
4.3 Requirements for a National Verification Program

It is proposed that the thrust of the verification of a processor

be the substantiation by an independent agency of an implementor's

claims for th*e entity mapping and other processing carried out by a

translator. The method proposed here is to collect this information

from an implementor for each processor to be verified, and then to

perform sufficient testing so as to verify that the claims made are

correct and that the entity mapping is correctly described.

The IGES verification program will be sponsored by the Society of

Automotive Engineers (SAE) . It is one of several verification

programs administered by them. There are four groups which

participate in the verification program: the SAE staff, the

Technical Board, the IGES Verification Panel, and the testing

agency (s)

The SAE Technical Board serves as an overseer for the various

review panels sponsored by the SAE. The Board reviews and approves

the operating procedures of the review panels as well as their

membership. The Technical Board is also responsible for ensuring

that, in the event of dispute, the appeals procedure as outlined in

the SAE Technical Board Rules and Regulations apply and are carried

out.

The IGES Verification Panel will come under the jurisdiction of

and report directly to the SAE Technical Board. It will be

composed of people who are technically competent in the area of

IGES and CAD data exchange.

Subject to approval by the SAE Technical Board, the IGES

Verification Panel will formulate operating procedures, rules and

operating guidelines ensure that the verification program

adequately serves all interested parties, including industry and

the general public while adhering to the principles, policies, and

objectives of the SAE.

The work of the IGES Verification Panel is to review pertinent test

criteria, testing techniques and test results to verify that IGES

pre- and postprocessors satisfy the requirements of data exchange

as referenced in the NBS IGES specification. The Panel may issue a

statement to the interested party setting forth the review and

determination it makes to verify or dispute the conclusion reached

by the testing agency (s). It is not anticipated that the scope

of the Verification Panel's work will include verification of all

the underlying hardware and supporting software for the translators.

The IGES Verification Panel will consist of adequate membership to

reflect the views of the users, interested agencies, laboratory

testing, and other interested and affected parties. Initially the

membership will be appointed by the SAE Technical Board.

Subsequent membership will also be approved by this Technical Board.

17
4.4 The Verification Process

Initially the SAE Testing Program is directed at providing a

verification that a vendor claim of IGES entity processing is

correct. This has the effect of testing on an entity level only and

leaves a user to verify, first, that the required entities are present

for a prescribed application subset and, second, that the information

is being mapped correctly into and out of those entities. In later

stages of the SAE Program, subset testing may be possible.

The verification process is initiated by an implementor completing

a Verification Request Package and submitting it to the with the

IGES Verification Panel of the SAE. The verification package

contains all the needed information including the implementors

entity maps and native forms. This information is necessary to

enable the verification testers to determine which test cases need

to be executed.

The IGES Verification Panel will schedule the test and assign a tester. Using the information on the request form, the tester

will identify the test cases needed from the test library and

execute a test plan and record the results. These results will be

returned to the IGES Verification Panel for a decision on whether

the processing of the translator has been verified.

The IGES Verification Panel will notify the Presenter of its

findings prior to any public release of the verification material.

The Presenter will than have an opportunity to respond to any

problems encountered or to appeal the decision of the Panel.

When a translator has been successfully verified, the Verification

Package (the request, test results, and summary report) will be

forwarded to a sponsoring government agency for distribution. This

agency will distribute copies of the Summary Report and the

Verification Package on request.

4.5 Current Efforts and Status

Prior to the fall, 1986 IGES meeting in Huntsville, the decision

was made to split the Testing Methodology Committee into six

separate committees. This action was deemed necessary because of

the massive effort needed, the slow progress in reaching our final

goal, and the difficulty in conducting technical meetings with

fifty to sixty people in attendance. The functions of the six

committees can be summarized as follows:

- Verification Testing Methodology Committee which is

responsible for establishing verification policy and

procedures for translator testing. This is the general

translator testing where vendor claims are verified

against test libraries.

18
- Application Validation Methodology Committee which is

responsible for developing the concepts of application

subset testing and the procedures for validating

translators for specific applications.

- Acceptance Testing Methodology Committee which is responsible

for developing the mechanisms where users can verify

that systems will work correctly in their user environment.

- Methodology Testing Committee which is responsible for

verifying that all of the developed procedures are

valid. They will also inspect the test cases and audit

the IGES verification program.

- Test Case Development Committee which is responsible

for devising the guidelines for developing and

documenting test cases, developing the test cases, and

distributing the test cases.

- User Information Committee which is responsible for

developing documentation, gathering and distributing

information, and developing tutorials.

Application subset testing requires a known testing environment

before its special problems can be addressed. This decision may

adversely impact MIL-STD-1840 development. A possible interim

method will be discussed in a following section.

The Society of Automotive Engineers is actively pursuing the

initiation of an IGES Verification Program by the summer of 1987.

They have designated members for the Technical Board and are putting

together a list of candidates for the IGES Verification Panel.

Universities have also been contacted as possible sites for the

translator testing. NBS is looking for a way to provide some seed

money for this program. The major problem for the SAE is the lack

of a completely defined testing program with ample test cases.

NBS is sponsoring two meetings in February 1987 to help accelerate

the testing program. The first meeting is geared to developing the

criteria for test cases, test case documentation, and the

generation of prototype test cases. These cases will be used the

following week for a meeting that is designed to revise the testing

documentation and to do a trial run of the verification test on a

CAD system at NBS. The results of these two meetings will provide

the basis for the testing methodology committee agenda at the

April IGES meeting.

Through the User Information Committee, NBS has been contacting major CAD vendors seeking vendor entity maps, permission to use the

maps to develop IGES testing methods, and permission to release the

maps to the public as part of the reporting and education process. The vendor response has been very positive with seven vendors having

given their verbal permission to use their mapping data. As of yet

NBS has not received written approval from these vendors.

19
5.0 TECHNICAL ISSUES

The restrictive nature of the application subset concept calls

for some mechanism to limit the entity content of the IGES file

to only those entities specified in the subset. Further

restrictions exist for some parameter value ranges in some

specified entities. Enforcing this requirement can be done in

several ways:

1. Require that a CAD operator generate a native CAD Model

with no entities that will be mapped to IGES entities

outside of the subset.

2. Configure the vendor IGES output translator to enforce

the desired subset by converting native entities into

conforming IGES entities.

3 . Develop separate software routines to convert an

IGES file resulting from a "best try” on some CAD

system into a conforming subset IGES file.

No other methods are known for assuring that the needs of a prescribed IGES subset are met. Each of these methods places

serious restrictions on a class of users, and these drawbacks are

sure to cause much debate. It is not essential that one method be

chosen over all others. Rather, it would be entirely appropriate to

use a combination of the three. The Pros and Cons of each

alternative are explored in the sections to follow.

5.1 Control Over the Operator Selection of Entities

A CAD system offers a large range of functionality to its user

community, and conventions for its use vary from shop to shop. An

operator can with equal ease prepare a drawing to Y14.5

specifications or intentionally violate accepted drafting

principles. The question is one of enforcing a policy, and the CAD

systems of today generally cannot enforce a company or a national

policy on how a part model is created.

Similar problems exist when a part model is being created to satisfy

a policy on application subsets. If the operator makes use of CAD

menu functions which create entities outside of the prescribed

subset, the IGES file created by a general purpose translation

process will be noncompliant . In the absence of any other

technique, compliance to a subset absolutely requires that an

operator not be allowed to use certain CAD system capabilities.

This requirement can only be relaxed if one of the other two

methods can aid in the conversion of entities to those in the

subset.

20
5.2 Requirements on IGES Translator Design

IGES translator designs have focused on faithfully representing the

native CAD mo^el in the IGES entity set so that it could be made

available to a "foreign" process. If both the input and the output

translators are done well, an IGES file generated by a CAD system

can be read back into the same system to create a part model

indistinguishable from the first.

As our attention turns to generating correct application subsets, it

should be understood how a CAD system translator could be of

assistance. An IGES output translator could be configured to do any

or all of the following:

Flag any noncompliant entities.

Throw away any native entity not mapping directly to a

conforming IGES entity.

Approximate native entities with the closest conforming IGES

entity.

Approximate native entities by a set of conforming IGES entities.

While these would be valuable functions for any user wishing to

prepare an IGES file conforming to an application subset, they place

a tremendous burden on the developer of IGES translator software.

Consider the problem of developing and maintaining separate IGES

translators for each of umteen application subsets.

5 . 3 Flavoring and Deflavoring Requirements

Flavoring is a term that is used to describe particular practices

built into a translator in situations where, for preprocessors, the

underlying system supports entities or relationships which are not

directly supported by IGES, and, for postprocessors, the underlying

system does not handle specific entities or relationships supported

by IGES. Since the manner in which these situations are handled is

not standardized, other knowledge than what is available in the IGES

document is needed. This additional knowledge is frequently built

into the translators and results in files that have a noticable

style of IGES entity construction.

Flavoring can also be taken to mean that an IGES file contains legal

IGES entity types outside the range of a particular application

subset, i.e. a Linear Dimension entity in the Tech Pubs subset. One

method of correcting the problem is to write a flavor converter

which reads a tainted IGES file and writes a correct one. In the

example given, the offending Linear Dimension is approximated in

appearance by Line entities and a General Note.

21
Construction of flavor converters is not trivial, but it is not by

any means an enormous project. And it places a user in a position

of control. Standardized input and output routines can be used to

ease the work* Additional functions other than entity manipulation

can be performed such as quality control over all datasets shipped

to a customer. Certainly it is a valuable tool to have at one's

disposal should a CAD system not provide all the functionality

needed for a particular job.

5.4 Software Tools for Acceptance Testing

Since the DOD will soon be purchasing and accepting IGES files, they

will need a software package that can verify that the entities in

the dataset conform to both the application subset and to the IGES

specification. This can either be accomplished by creating new

software or through modification of one of the commercial IGES

syntax checkers.

To demonstrate both options, the CALS Product Data Exchange project

at NBS has developed a PC-based program and has made changes to the

IDA Analyzer. Using a test file library, several datasets were

tested with the modified IDA analyzer for conformance to the

technical publishing subset. The analyzer correctly identified the

undefined entities and ran to completion. This result indicates

that separate software modules do not have to be used to check

different conformance aspects of application datasets. The IGES QC

analyzer from the University of Leeds has not been used to test

subset conformance. However, representatives from the University

indicate that the changes to do so would be simple.

But while this represents a good start, the tools require

considerable refinement in concert with the evolving application

subsets. In the future a better array of tools need to be developed

to properly test the processors producing the datasets and the

datasets themselves. The software needed for the processor

validation will be expensive to develop. Cost estimates to date

significantly exceed the funds available to the IGES office.

Software for the functionally testing will take longer to develop

because the process is not well defined. The impact of the lack of

these software tools will be that testing will be less rigorous and

be much more labor intensive.

22
5.5 Testing of Datasets for Conformance

Because IGES entity subsets are being created and developed to

address specific application areas, the concepts of dataset

acceptance issues will also have to be developed in parallel.

Agencies such as the DOD and large corporations typically build

conformance safeguards into their contracts so that they know

they are purchasing correct data and products. IGES in its

attempt to serve as broad a user segment as possible incurs

special conformance problems in being all things to all users.

For example, not only is geometry being communicated but also

presentation information, associativity information, annotations,

and transformations.

Acceptance testing represents the attempt on the part of receiving

agencies to guarantee that all of the information in the sending

system is correctly interpreted in the target system. To this end,

acceptance can be broken down into three areas; they are

functionality, logical, and physical. Functionality is the highest

level and the most difficult to test. It refers to the semantics or

the information content of the model in the native database of the

sending system. Logical testing refers to the entity mapping and

system limits of a vendors system - does the vendor correctly handle

all of the entities in the subset correctly and does the system

generate entities not included in the subset. Physical checking

refers to the structure of the data file and its syntax. Files

must be constructed properly with all entities, forms, pointers and

associated information correctly positioned. Alphanumeric rules

must be rigorously followed, data type conventions followed, units

used consistently, and precision rules followed. This type of test

is conceptually simple but very complex because of the allowable

freedom in the IGES specification.

Functional checking to an application subset specification is a complicated process that is currently ill-defined and impossible

to test exhaustively. The evaluation system for such functional

testing has also no clear consensus at this time. Such subjects

as visual equivalence, pictorial accuracy, data functionality,

application functionality and information functionality will need

further discussion and evaluation.

At this time the testing method for IGES transfer of any kind is

the visual comparison of a drawing from both the sending and the

receiving systems. This will not verify that the functionality

associated with entities remain intact. For example collections

of lines may represent a cooling system. This shortcoming is

serious because the need to transfer functionality unambigiously

is the primary reason for the existence of application subsets.

It has been proposed to use a neutral database to compare IGES

files built from standard reference models with those generated

for reference scripts on a vendors CAD system. This tool would

then have application to both translator verification testing and

application validation testing. Though potentially useful, such

a verification tool is expensive and not currently funded.

23
Actually much of the functionality checking is for application

subsets is done in the formulation of the application subset

and conventions for its use.

m Most problems with IGES files are rooted in the inherent

ambiguities of the specification and imprecise vendor

translations of IGES entities. With subsets, constraints on

allowable constructs reduce semantic difficulties reducing the

potential for error. There is no longer redundant constructs and

as a consequence the translators will be smaller and easier to

maintain.

Physical conformance testing is an exhaustive process where IGES

files are checked for strict adherence to the IGES specification.

Such programs are large, tedious, and absolutely essential. These

syntax checkers must check all of the entities, their forms,

attributes, associations, structures, construction details and

organization. Fortunately, there are two commercial products that

can do these tests. They are the 'IGES Analyzer' from IGES Data

Analysis Corporation and 'IGES QC' from the University of Leeds

in the UK. Both checkers are available at a reasonable

cost to run on Vax based systems. The IDA analyzer also runs on

UNIX based systems. Both systems have been exercised with sample

IGES test files and found to be satisfactory. These checkers have

the additional benefit that they can check subset conformance

with their syntax check.

Conformance of entities to the application subset is the easiest

test. A conformance checker must be able to read an IGES file and

and extract the data from it. Next the program must inspect the

entities in the file and verify that they are members of a target

subset. Such a conformance program has been written at NBS in the

Basic language. This program is in the public domain and when

documentation is complete can be copied freely. The program is

expected to be the first building block in what will be a series

of IGES utility programs. It is important to bear in mind that,

although checking subset conformance to the subset specification

is necessary, it is by no means a sufficient test. IGES files are

more likely to be in error syntactically or functionally.

24
Table 2 Summary of Testiag Levels

type of

f f Physical ! Logical Functional

TEST

: Entity Mapping

WHAT IS Syntax and ! and End- to-End

tested Structure 1 System Limits Data Exchange

: IGES Application

BASIS FOR IGES ! Specification Requirements and

test data Specification! and Implementor ’

! Implementor’s Entity Map

! Entity Map

TESTER Implementor ! Verifying

! Agency

End User

TEST Preprocessors

METHOD Modeling script-to-IGES File

Postprocessors

IGES f i le- to-database

evaluation

t Preprocessors Before and after

Error Log ! IGES model comparison with

- ! comparisons respect ta user

criteria

- Visual comparison

Postprocessors - Operational and

- Syntax ! - CAD model functional tests

Checker ! comparisons

! - Operational

- Database content

! tests

! - Geometric

! verification

1 PURPOSE OF

1 Error ! Formal Applicability in

TEST AND Detection ! Verification specific appiicaUSE OF 1 tion povironment

RESULTS f
" wf

^

X*i^i»mjt Sg»id*T

• r W*^

l<sSing i- » ^ ^ Ication

C

. ,

. i. ’’0, 3ori

rtjotad ijs ^iSi inh«f4’7’*3T

Y4^ndor

tt<ifbk t ^1: SpHi t»j^n . On*

niot« and^

Mytt

C:

!^y54ls7?«st?|iMSJfe‘”"*-

“

; -m**%

4*on»Ji:x^r~tlon ddtai-.*

t4 ^iTi^iiCtS “thOtt

ri.1

:4«

r?: ^** ?““ '> , 74'» - - *"« liB*- ohal,y4« ai*o ?2 ‘ 'IS

“^-^ S^rtat-.»f.ctory-. Vh*!^ cheO^r* .M'*

%oplicaxiofi> tiUba*it is tna. a4|iai?i

f( 1 i w

'^tftfA?-*?Sffl<^as«

n*. i«nW<A#-.f«jO §^ to Cl.-- 4S«o.^

»jco9 'itf toa-'iinaij'rjeir »y*t.j'?«4S«*jC9 c« jttwct-.oni- ly.

0'^-

. ljinOl:iy*’»»40 "' • - ««J«^3sl«f«^' - ,.. "! ^

' •->

'.< -' I, -I --:l^if.;;.jj c»

'' .''^V;'^f

1*1^'# ' -! “'^i

' *

'

' '• ? *** ~ ' ^ "%7-' '• »^ ' . Tf- f

jf " ; ) ' ^ tons X " 10 aaoqs^

U-qq,# cioi2f«'Oa1 V OVIA TBTT

niyls

^

,

'

' : ..

' —, >T(1,_5,W, ' *i yiiu., Jt^' <nfa 'K^ 10 36’J

;? « 8TJUE35J

}{ "±*

i
6 . 0 POLICY CONSIDERATIONS

6.1 Policy on Purchase of Datasets

DOD's stated intent is to begin use of digital product data files by

1990. A draft Policy Instruction for product data is given in

Appendix A. This refers to a draft MIL-STD on Product data given

in Appendix B and to a series of IGES application subsets given

by a draft MIL-SPEC in Appendix C.

Service elements have already started prototype exchange as early as

1985, and a 1984 NAVSEA Policy Instruction states that IGES is to be

invoked on all new contracts involving transfer of CAD/ CAM data.

But in dealing with dataset transfers in a contract situation, the

problem is compounded with questions of data rights, liability and

dual authority.

While there may be many issues raised as to data rights, it is

believed that the use of digital transfers introduces no change

over the traditional use of engineering drawings. But invariably

contractors will be more reluctant to part with their CAD databases.

The liability issue is seen not in the purchase of datasets as much

as when the government furnishes the datasets to a contractor as

part of a contractual relationship. If the data exchange is

perfect, it seems there is no more of a liability problem than. when

a drawing is furnished. However, the question of liability for

wrongful or incomplete information as a result of less than perfect

software translators is difficult to prejudge.

Intriguing questions abound on the issue of dual authority - drawing or dataset. The formal engineering drawing of today is

still the authority for product definition. Steeped in

tradition, codified by ANSI standard, tested in the courts and

cited by MIL-SPEC and MIL-STD, the drawing will remain a useful

tool so long as man wishes to interpret the geometry, topology,

tolerances and features of a product design. Yet few will argue

that someday we will place far more imortance on the exchange of

digital product descriptions than we do paper. Drawings will

become a by-product derived from the received dataset for the

purpose of aiding human understanding of the dataset. The drawing

will not be a primary method for information exchange. However, no

one is able to cite exactly when this will happen.

The term "dual authority" alludes to the interim period of time

when datasets and drawings are both in typical use in data

exchanges. Which should take precedence if an inconsistency is

found? Experience is that this happens often enough to require

serious consideration. One instance was reported in which

digital information in IGES format was in typical use. A last

-minute change to a critical dimension was made to the text note

of a linear dimension in the CAD system rather than by modifying

the part geometry being dimensioned. Since the part was made

from the received geometry rather than from a model created from

the received CAD generated drawing, the part was wrong.

25
6 . 2 Acceptance Testing of Datasets

Acceptance testing of datasets by the government must be complete

enough to ascertain that the datasets are of sufficient quality to

meet the contract specifications for payment. Acceptance testing

represents the attempt on the part of receiving agencies to

guarantee that all of the information in the sending system can be

correctly interpreted by the target system.

At this time the typical testing method for IGES transfer is

the visual comparison of a drawing from both the sending and the

receiving system. This will not verify that the functionality

associated with entities remains intact. The limitation is serious

because the need to transfer functionality unambigiously is the

primary reason for the existence of application subsets.

Fortunately, software tools are beginning to be developed to meet

this challenge. These are already in the prototype stage.

Priority should be given to supporting their creation.

6.3 Verification of Source Preparation Systems

Procedures are needed by those who will be producing IGES

application subset files as contract deliverables to verify the

ability of their systems to conform.’ A first step is to require

SAE application subset validation as a part of each new system

purchase. But this does not address all those systems in the

installed base. Certainly the same procedures used by SAE could

be followed, but the skilled personnel resources may not be

available to the smaller firms.

26
7.0 ACTION REQUIRED TO IMPLEMENT

A formal strategy is needed to effectively implement digital

exchange of technical data within the DOD. A draft policy

instruction on the subject is given in Appendix A.

Technical data can be divided into unstructured text, technical

docximentation and product data. Unstructured text is outside the

scope of this report. The exchange of technical documentation in

digital form is addressed by MIL-STD 1840 which already exists

and is in final stages of coordination. Product data exchange is

the subject of this report. It is thought that this can best be

addressed by creating a DOD-wide MIL-STD similar to 1840 but which

addresses the entire range of digital product data applications,

not just technical documentation. This is given in draft form in

Appendix B. This document represents a major rewrite of 1840.

To fill the need for a complete and precise specification on IGES

application subsets, a new Military Specification is proposed.

This is given in draft form in Appendix C. It contains subsets

for technical illustrations, 2-D engineering drawings and

electronic printed wiring boards. These three subsets, are only

the start of several which will form the completed MIL-SPEC.

A number of actions are necessary to provide implementation of

this strategy for application subsets throughout the DOD. A list

is given here for consideration by the CALS Office:

The draft DOD Policy Instruction for Digital Product Data

Exchange given in Appendix A should be reviewed by the CALS

Office and circulated for adoption by all commands.

The draft Military Standard for Digital Product Data

Exchange given in Appendix B should be reviewed by the CALS

Office and circulated for adoption. This MIL-STD references

the MIL-SPEC on IGES application subsets in Appendix C.

The draft Military Specification on IGES Application Subsets

given in Appendix C should be reviewed by the CALS Office

and circulated for adoption.

The DOD community should be polled for additional

engineering disiplines requiring IGES application subsets

including a request for priority ranking of needs. This can

best be done through the NSIA CALS committees, the DOD

Manufacturing Technology Advisory Group, inhouse program

managers from all service components concerned with each

application, CALS service contacts and members of the IGES

Organization who are in the DOD or affected companies.

27
REFERENCES

Glossary

m Acceptance Testing - The testing performed by a user to

determine the suitability of a translator for a specific

environment.

Application Validation - The testing which is aimed at

ensuring that application subsets of IGES are treated in a

manner consistent with the application on the system under

test. See also Conformance Testing.

CAD Model - The representation of a product definition

model in a CAD system's native form. See also IGES Model.

Certify - To guarantee the quality or worth of; to vouch

for. Webster's New World Dictionary-1972U

Conformance Testing - The testing which is aimed at

ensuring that the processing of individual entities and

data items accurately reflects IGES specification.

Entity - The basic unit of information in an IGES file. This

term applies to single items which may be individual elements of

geometry, collections of annotation to form dimensions, or

collections of entities to form structured entities.

Entity Mapping - The change of entity definition during

conversion between data formats. This conversion may result

in a change of mathematical definition but maintains the same

information content.

Evaluation Criteria - The set of items in the test results

which are to be examined, along with the means of

measuring how these items indicate the performance of the

processor under test. These criteria will typically be

defined on a test-by-test basis and will describe the

features of the test that are of interest. For example,

the Evaluation Criteria for a line might be its position

in the model and its length. Here, a comparison of the

expected position with the resulting position would be

defined for the test. See also Validation Criteria.

Functionality - The ability to edit, move, scale or otherwise

manipulate a postprocessed entity as if it were created

originally on the receiving system.

IGES Model - The representation of a product definition

model in IGES format. This is usually in the form of an

IGES file. See also CAD Model.

Standard Reference Model - The representation of a product

definition model prior to being processed by an IGES

translator. See also Test Results Model.

28
Test Data Library - The collection of data sets, along

with the documentation for the data sets, which are to be

used in the testing of processors. Data sets in the Test

Library exercise specific features of the standard and

include both correct and incorrect data. A given data set

may take part in more than one Test Script.

Test Methodology - A high level definition of testing

philosophy, practices, issues and general procedures. It

contains the rationale of test procedures, the kind of

testing that is necessary, and, in general terms, how to

conduct tests.

Test Procedures - Descriptions of the various tests that

are necessary to test a particular aspect of

implementations of the standard. These procedures

identify the test data and the processes that are to be

used in testing. This will generally contain reference to

a set of specific Test Scripts.

Test Result Model - The representation of a product

definition model after being processed by an IGES

translator. See also Standard Reference Model.

Test Scripts - The detailed, step-by-step instructions

which describe how to conduct a test. Scripts will

contain references to specific data sets in the Test

Library which are to be used. A log for documenting each

test should also be provided. Discussion of specific

Evaluation Criteria will also be included.

Validation Criteria - The specifications that a test

analyst will use to determine the applicability of a piece

of software for a specific application. These are based

on the results of applying the Evaluation Criteria (q.v.)

and usually identify a minimum acceptable level of

performance. For example, if the Evaluation Criterion for

a line is its position, then the Validation Criterion for

the test might be that the position may not vary by more

than .001 inches, or perhaps by more than 1% of the

coordinate value.

Verify - To test or check the accuracy or correctness of,

as by investigation, comparison with a standard or

reference to the facts. Webster's New World

Dictionary-1972U.

Verification Criteria - The specific criteria that a

verifying body will use to assign functionality ratings to

a processor. These criteria will be defined by the

Testing Methodology Committee.

29
Bibliography

BRADS 5

m Bradford, J. ”IGES Translator Analysis for

Autofact 'S5", Detroit, MI: Society of

Manufacturing Engineers, 19S5. Available from

the National Technical Information Service.

BRIGS

5

Briggs, D. "Subsets of IGES." Washington, D.C.:

National Bureau of Standards. Published in

Minutes of IGES Test, Evaluate, and Support

Committee Meeting, 29APRS5-3MAYS5 , Atlanta, GA,

19S5. Available from the Chairman.

DOWNS

6

Downer, Ronald G. , "Hughes/EDSG IGES

Requirements Specification", Hughes Aircraft

Company, Electro-Optical and Data Systems

Group. Available from the publisher.

ELECS6 Electrical Application Guide, IGES Version 3.0

(Preliminary) . Published by the IGES

Electrical Applications Committee (EAC)

.

Available from the Chairman.

FLOWS

6

Plant Flow Sheet Product Representation, IGES

Version 3.0, Appendix C, Apr S6.

GRABS

4

Grabowski, H. and Glatz R. "Test and Validation

of IGES Processors." Karlsruhe, West Germany:

Institute fur Rechneranwendung in Planning and

Konstruktion. University of Karlsruhe, 1984,

Available from the Chairman.

HANSS5 Hansen, D.L. Correspondence, Cincinnati, OH:

Applicon, March 4, 1985. Available from the

Chairman

MILST86 Military Standard MIL-STD-1840 , "Automated

Interchange of Technical Information" , HQ

AFLC/SITA, Wright-Patterson AFB, Ohio 45433.

MYER79 Myers, G. J. "The Art of Software Testing."

New York, NY: John Wiley & Sons, 1979. Available

from the publisher

NSEAS4 NAVSEA INSTRUCTION 5230, Department of the

Navy, Naval Sea Systems Command, Washington,

D. C. 20362. Subject: Transferring Technical

Data Among Navy and Contractors' CAD/ CAM

Systems, 23 Aug 84.

PIPES6 Piping Model Example, IGES Version 4.0

Engineering Change Order 430, NBS, Nov 86.

30
TECHS

TESTS

T0PSS7

Technical Publications Application Guide, IGES

Version 3.0 (Preliminary). Published by the

IGES Technical Publications Committee.

Available from the Chairman.

Testing Methodology of IGES Translators, Draft

0.03, 19 Sept S6, Testing Methodology

Committee, Available from the Chairman.

TOP 3.0 Specification for Digital Product

Data, Preliminary Draft, Feb S7, Boeing

Computer Services, TOP Chairman, PO Box 24346,

MS 7C-16, Seattle, WA 9S124-0346.

31
• \ 7- ^

f> *i < wri

\nitlv9 %M fovjir

AtruiiAble ffrpa;

Slatta-titO^Aliliiis'it Smtviltt^.

deiibHT

, 'y?oXoI)OXW#H .eO[i4MT..' ,d8 Sq»B ex .co.q,

.n««r»lac»**il#,*l^;*ii4»W*^^^ w**hltwjtoa,;. O-C^i

«?6|i!El It of st^ari*. p;^i«h*<i i» : ^'ioubon i»Sieia 'aa1;niO«^»q^4T»««®'X<i.W%>^f^lUttt^ftSWa- Support

»,^k‘',,«'- pfti**o8 ..,« (i^'i '•s*;»*ftas-Mixta3 „ Atisor« , ,. <sa., ^,4at*X'- sfos^v Chair^^an-.' pjf^|||||

•.--ai OOWJBfe- ^ ,;.v •'tv

a>c o**;Hi5i.B $ , A’w ^ • I:t 5 » a I --OT an

T.idMal4 /i. ICIJfs ' v;1 ^

3p«ciJ*icat.l<5'f\’*> su<jfhfc*s Aircraft: J 0*T,a Systems

^y^'^a lsbXe tram t>j« iiublitiMiLrc

'3j0L4^r Itmt A^l'iceti.

,

lOES V «frsion 3., o

<]^el,ij»di^aj£:y) T’liblifciied by t:h« IC5ES

8i^x'XOf i :^rpX'icst;ian», cow^iitix^ {tAO . *» a, irow CJnairwAm ‘

Plant r'ldw- "theet Prodact: suif^<i«<»ntAtton . 'IQKte,’

'•irsir-'’ i»s?pp«nttiat C$ Apr 86. ’ ^ 6^

g. and cuts Rt nnd V»i ..•^;,t iorv?J

^ 4CS.S ProdiHisoT^ a

** Karlsr;^^m, West 0«r»aD>*t

f^2tJ.“etii^• fyr 1?f»chrareovferultirtfi in Planning and

^^OTV•trv3lMio^^. Univatraity x>t Karlsinihe^ l3f4r-j‘

‘ atrls- frc"^» tbs ChmliHRan*

* '

,HXMS32i ®;g4,n»wn, ^D*L. V'G-U'rrespendei'c Ctncinnat‘i out

1^ , Applit?<sn» Hasch illfl. AvaiUbXa from that

, ““vr“**/. ,, . . «„,

mil:T6*o> kK: ‘ 3Mc-'i^. Miv-r.n>-xe4C,

tr.tsrtrhang® 7#is#^]iioaJ Infornction" , HQ^*-

'C'^ OMO 4S43

pK1!ER7»^i»' ’^r«V'5W, 0,. J'i' if Softvare Tustin^i—

torJJi VKi ,'i^ *ri:«y fc £orW(,_ JMft. ;• AvatiSjlTM 1 pttWii«*»r , ' : - • i"" ; —

X«rm^ 4J30,«.D*p»i:tiae_nt of th«

.p%-yf, iftttval $i!W' -iiystsaifl coM^nd, wssninqftoivSr

t, -Sobjsctf transCsrri/rwj TschnicM

Oontraators' C&O/CMI

'MX ^4.' '

fawirtpla. lOES- Vsrsioa* 4 .t)

" i ordsr 4 l 0^, Kov
DRAFT POLICY INSTRUCTION FOR DOD ADOPTION APPENDIX A

SCOPE:

This instruction addresses the specification, purchase and

acceptance testing of product data in digital form throughout the

DoD. It promulgates mechanisms for incorporating the exchange of

digital product data into the normal procurement and business

operations of the DOD. Requirements are given for the

specification, purchase and acceptance testing of product data in

digital form. Use of application subsets of the Initial Graphics

Exchange Specification (IGES) Version 4.0, 1987 is directed bycitations to appropriate MIL-STD's and MIL-SPEC' s.

OBJECTIVE:

The objective of the Computer Aided Logistics program in digital

product data is the effective exchange of data throughout the

life cycle of weapons systems development and deployment through

the use of computer-readable datasets describing the systems,

their individual piece parts and their product support data. A

central issue here is the technology of digital representation of

product data in its many forms of illustrations, drawings, 3-D

wire frame models, surfaced models, solids models and complete

product models.

BACKGROUND:

The CALS Program in product data exchange addresses the exchange,

archiving and future use by DOD of digital product data. Major

thrusts are:

Development of a comprehensive program of testing and

evaluation

Identification and solution of problems encountered in

intersystem data exchange

Research into the unique requirements for long term

archiving

Development of software tools to assist users in making

routine production use of digital product data

Continued development of new applications capability

Validation of new applications areas

Developmental work on methods for complete product model

data representation

33
Throughout the DOD and its partners in industry, an increasingly

larger number of computer aided design systems are being used in

all phases of design, analysis, manufacture and test of weapons

products.. Over a hundred vendors offer these CAD systems. And

it is natural that different DOD activities or different

companies would choose different vendor systems to meet their

varying needs. Hence, there is a requirement in the normal

course of business to be able to exchange the digital part models

that are developed on one system to be used on another system.

It is essential for CALS to be able to fully utilize these

automation resources both at contractor and subcontractor

facilities as well as inhouse for design review, second sourcing,

overhaul planning and spare part production. Digital product

data exchange plays a key role in each of these areas.

DIGITAL PRODUCT DATA:

Two terms will be used; product definition data and product data.

Product Definition Data denotes the totality of data elements to

completely define the product. Product definition data

includes the geometiry, topology, relationships, tolerances,

attributes and features necessary to completely define a component part or an assembly of parts for the purposes of

design, analysis, manufacture, test, inspection. Very little, i

any, process data is included, with the exception being referenc

to a process standard or reference to a procedure which results

in a product condition that is not easily specified, e.g., heat

treating for 1 hour at 320 degrees. The product definition is

expected to be sufficiently complete to enable the generation

of all downstream process data.

Product Data is more broadly defined than Product Definition

Data. Product data includes all of the product definition data

plus a larger class of data elements necessary to fully support

the product for all applications over its expected life cycle.

LIFE CYCLE USE:

Indicative of this larger class of product data are engineering

analysis models or results and illustrations of the product to be

used in documentation regarding operation, maintenance and

engineering change control. Product data spans the entire range

of disiplines from conceptual design and engineering analysis to

manufacturing planning, production, test, inspection and

deployment. Data packages are expected to go through repeated

exchanges between primes, subs, government project managers, test

labs and consultants.

34

4-1 (1)
EXTENT OF USE:

The CALS Program requires the ability to deal with digital

product data for four generic applications:

Internal transfer of product data among DOD components

The acquisition of new manufactured parts/ systems

Data transfer fom Design systems to Product Support systems

Archival storage of parts/assembly information

Numerous internal transfers of product models are found in R&D,

prototype design, overhaul and retrofit planning, and each is a candidate for digital exchange in the immediate future.

ECONOMIC BENEFITS:

Digital product data is becoming an important consideration in

DOD's contractual relationship for purchase of manufactured

parts, assemblies or whole systems.

DOD has significant investments in data archives necessary to

support its deployed forces. Presently this data consists of

millions of drawings stored in data repositories, but many

agencies are beginning to address the problem of long-term

archiving of digital product data.

The economic significance of digital product data is easily seen

from these examples. Efficiency, accuracy and leadtime

improvements are all substantially enhanced through the use of

CAD and CAM technology made possible by the sharing of product

data.

APPLICATION SUBSETS:

Each application of CAD/CAM has different requirements for

the data describe the product model. The Initial Graphics

Exchange Specification provides a mechanism for representing

product data in a neutral public domain format. Subsets of IGES

entities will be used as required to support the information

exchange needs of different design, engineering, manufacturing

and product support areas.

An application subset of IGES is defined as a set of specific

IGES entity types which are used to completely and unambiguously

represent the information requirements of the product for the

named application purpose.

35
APPLICABLE MILITARY STANDARDS:

MIL-STD 1840 defines the digital representation of technical

documentation with associated drawings. MIL-STD 184x addresses

the exchange of digital product data. Both MIL-STD 's make

reference to IGES application subsets given in MIL-SPEC nnnn.

POLICY:

Application Subsets of IGES Version 4.0 as expressed by

implementing Military Specifications and Standards shall be used

for exchanging product data.

ACTION:

MIL-STD Application Subsets will be invoked on all contracts

calling for exchange of digital product data.

All offices, activities and detachments shall ensure that all

sollicitations , proposals and contracts for new construction,

conversion, modification, modernization and overhaul require

delivery of any generated digital product data in the appropriate

MIL-STD format.

Renegotiation of existing contractural agreements is encouraged

where cost effective and feasible.

All DOD repositories of technical information on product

definition including engineering drawings shall formulate plans

and implement mechanisms for accepting, archiving and furnishing

as necessary digital product datasets in MIL-STD format.

Where digital product data along with appropriate engineering

drawings is made available to a contractor by a DOD component as

government furnished equipment, it shall be marked for reference

purposes only with the drawing made prime authority.

In those situations where spare parts are purchased from an

inhouse facility or from a contract source, extra incentives

should be offered to develop and capture the digital product data

in MIL-STD format for future logistics use.

EXCEPTIONS

:

In situations where both sender and receiver possess the same

hardware and software, native CAD system database files should be

requested in addition to the IGES MIL-STD Application Subsets.

The native data will satisfy the present need while the IGES will

serve longer range or unforeseen future needs.

36
DRAFT MILITARY STANDARD FOR DOD ADOPTION APPENDIX B

NOTE: This draft, dated 23 February 87 prepared by Div 732

National Bureau of Standards, has not been approved and is

subject to modification. DO NOT USE FOR ACQUISITION PURPOSES.

Project NBS CALS Product Data.

MILITARY STANDARD

EXCHANGE OF DIGITAL PRODUCT DATA

Beneficial comments ( recommendations, additions deletions)

and any pertinent data which may be of use in improving this

document should be addressed to Bradford Smith, Bldg. 220,

Rm A353, Bureau of Standards, Gaithersburg, MD 20899 by

using the self-addressed Standardization Document

Improvement Proposal (DD Form 1426) appearing at the end

of this document or by letter.

DISTRIBUTION STATEMENT A. Approved for public release;

distribution is unlimited.

37
MIL-STD-184X

FOREWORD

The CALS Program in product data exchange addresses the exchange,

archiving and future use by DOD of digital product data. Major

thrusts are:

Development of a comprehensive program of testing and

evaluation

Identification and solution of problems encountered in

intersystem data exchange

Research into the unique requirements for long term

archiving

Development of software tools to assist users in making

routine production use of digital product data

Continued development of new applications capability

Validation of new applications areas

Developmental work on methods for complete product model

data representation

Throughout the DOD and its partners in industry, an increasingly

larger number of computer aided design systems are being used in

all phases of design, analysis, manufacture and test of weapons

products. Over a hundred vendors offer these CAD systems. And

it is natural that different DOD activities or different

companies would choose different vendor systems to meet their

varying needs. Hence, there is a requirement in the normal

course of business to be able to exchange the digital part models

that are developed on one system to be used on another system.

It is essential for CALS to be able to fully utilize these

automation resources both at contractor and subcontractor

facilities as well as inhouse for design review, second sourcing,

overhaul planning and spare part production. Digital product

data exchange plays a key role in each of these areas.

38
MIL-STD-184X

1. SCOPE

1.1 Scope. This standard addresses the specification, purchase

and acceptance testing of product data in digital form throughout

the DOD. It promulgates mechanisms which shall be used when

digital product data is to be exchanged in normal procurement and

business operations.

1.2 Purpose. The purpose of this standard is to specify the

representation of digital product data to facilitate the effective

exchange of this information throughout the life cycle of weapons

systems development and deployment. This is accomplished through

the exchange of computer readable datasets describing the systems,

their individual piece parts and their product support data. A

central issue here is the technology of digital representation of

product data in its many forms of illustrations, drawings, 3-D wire

frame models, surfaced models, solids models and complete product

models.

39
MIL-STD-184X

2 . APPLICABLE DOCUMENTS

2 . 1 Government documents

.

2.1.1 Specifications, standards, and handbooks. The

following specifications, standards, and handbooks form a part

of this specification to the extent specified herein. Unless

otherwise specified, the issues of these documents shall be

those listed in the issue of the Department of Defense Index of

Specifications and Standards (DODISS) and supplement thereto,

cited in the solicitation.

a. MIL-STD-100 Engineering Drawing Practices

b. MIL-STD-D-1000 Engineering Drawings and Associated Lists

c. MIL-STD-804B Formats and Coding of Aperature Cards

2.1.2

Other Government documents, drawings, and publications.

The following other government documents, drawings, and publications

form a part of this specification to the extent specified herein.

Unless otherwise specified, the issues of these documents shall be

those in effect on the date of the solicitation.

2.2

Other Publications. The following documents form a part of

this standard to the extent specified herein. Unless otherwise

indicated, the issue in effect on the date of invitation for bids or

request for proposal shall apply, or as otherwise specified in the

contract.

a. Initial Graphics Exchange Specification, Version 3.0, NBSIR

86-3359, April 1986, U.S. Department of Commerce, National

Bureau of Standards.

(Application for documents should be addressed to National

Technical Information Service, 5285 Port Royal Road,

Springfield, VA 22161, Document Number 86-199-759)

2.3

Order of precedence. In the event of a conflict between the

text of this standard and the references cited herein, the text of

this standard shall take precedence.

40
MIL-STD-184X

3 . DEFINITIONS

»

3.1

Acronyms used in this text. The acronyms used in this text

are defined as follows:

a. IGES - Initial Graphics Exchange Specification

b. ASCII - American Standard Code for Information Interchange

c. EDIF - Electronic Design Interchange Format

d. VHSIC - Very High Speed Integrated Circuit

3.2

Application Subset. An application subset of IGES is

defined as a set of specific IGES entity types which are used to

completely and unambiguously represent the information

requirements of the product for the named application purpose.

3.3

Initial Graphics Exchange Specification. IGES provides a mechanism for representing digital product data in a neutral

public domain format. Information is represented as geometry,

annotation and structural relationships among the entities.

3.4

Product Data. Includes all of the product definition data

plus a larger class of data elements necessary to fully support

the product for all applications over its expected life cycle.

3.5

Product Definition Data. The totality of data elements in

a digital dataset necessary to completely define the product.

Product definition data includes the geometry, topology,

relationships, tolerances, attributes and features necessary to

completely define a component part or an assembly of parts for the

purposes of design, analysis, manufacture, test, inspection. Very

little if any process data is included, with the exception being

reference to a process standard or reference to a procedure which

results in a product condition that is not easily specified.

41
MIL-STD-184X

4. GENERAL REQUIREMENTS

4.1 General. Throughout the DOD and its partners in industry,

an increasingly larger number of computer aided design systems are

being used in all phases of design, analysis, manufacture and test

of weapons products. Over a hundred vendors offer these CAD

systems. And it is natural that different DOD activities or

different companies would choose different vendor systems to meet

their varying needs. Hence, there is a requirement in the normal

course of business to be able to exchange the digital part models

that are developed on one system to be used on another system.

4.2 Digital Product Data. Product Data includes the totality

of data elements in a digital dataset necessary to completely

define a piece part, an assembly of parts or an entire weapons

system. The term includes the geometry, topology, relationships,

tolerances, attributes and features necessary to completely define

the product and support its lifetime use.

4.2.1 Extent of Use. Product data spans the entire range of

disiplines from conceptual design and engineering analysis to

manufacturing planning, production, test, inspection and

deployment. Data packages are expected to go through repeated

exchanges between primes, subs, government project managers and

test labs.

4.3 Digital Data Exchange. Product data can be exchanged by

way of the neutral data formats. IGES is in widespread use for

Mechanical part models and has extensions to technical

illustrations, electrical printed wiring boards, architectural

engineering, manufacturing and finite element analysis. EDIF and

VHSIC are being developed for integrated circuit product designs.

4.4 IGES Data Exchange. In a data exchange with IGES,

information is carried as a series of entities describing

geometry, annotation and relationships. The sending system

places its part model into the IGES entities, and the receiving

system extracts the information to construct its part model.

Incomplete data exchange results when either system fails to

adequately transform its native representation to or from the

IGES representation. Since all systems do not, or cannot,

support all IGES entities, narrower subsets of entity types are

selected to support common data exchange requirements.

4.5 EDIF Product Data Exchange. << To Be Developed >>

4.6 VHSIC Product Data Exchange. << To Be Developed >>

42
MIL-STD-184X

5 .DETAILED REQUIREMENTS

5.1 Exchange of IGES Product Data. Where IGES is used for

product data exchange, the detailed requirements of MIL-SPEC-nnn

shall be used.

5.2 Application Subsets. Each engineering application

has different requirements for the data needed to describe the

product model. The first step in specifying how an applications

area can exchange its product description as a digital dataset is

to carefully define the information content to be transmitted.

The second step is to specify how this information is mapped

unambiguously into each IGES entity. The resulting list of IGES

entities and their meaning in the context of the application forms

what is termed the application subset. An application subset of

IGES can then be defined as a set of specific IGES entity types

which are used to completely and unambiguously represent the

information requirements of the product for the named application

purpose.

5.2.1 Restrictive Nature of Subsets. For each application

subset, no IGES entities shall be used which are not enumerated in

the defined subset. Systems generating IGES data conforming to

these subsets shall not generate IGES entities outside the

specified subset. Systems designed to interpret these subsets

shall be able to handle all IGES entities within the specified

subset.

5.2.2 F^equirements on Subsets. All IGES application subsets

shall comply with the IGES Specification for entity syntax and

file structure. They shall also comply with the detailed

specifications of MIL-SPEC-nnnn. IGES files are composed of five

sections, Start, Global, Directory Entry, Parameter Data and

Terminate. This standard places additional requirements on these

sections.

5.2.2. 1 Start Section. The following information shall be

given in the Start Section of the file:

a. Statement of conformance to the relevant application

subset and the revision date of the subset.

b. The identification of the product being described.

c. Date the file was prepared.

d. Performing organization, date and contract number.

e. Data organization method used with contents of each level.

43
MIL-SPEC-nnnn

5. 2. 2.

2

Glgbal Section. The following fields in the Global

Section are required and shall not be defaulted:

Field

1

2

3-11

12

13

14

15

16

17

18-22

23

24

Value

1.0

1-11

1-4

0-7

Required

Y

Y

Y

N Default to Field 3

Y

Y

Y

Y

N

Y

Y

N s

5. 2. 2.

3

Directory Entry Section. The following capabilities

shall be provided and shall be supported for all entities:

a. The Level Number Field. All values shall be positive except

where necessary to maintain the truest meaning of the

referenced entity.

b. The Logical and Physical Subordinate Entity Switch.

c. The Entity Use Flag.

d. The Hierarchical Status Flag.

e. The Line Weight Number.

f. The Color Number.

5. 2. 2.

5

Parameter Data Section. No restrictions of a general

nature are placed on the parameters in the Parameter Data Section.

5. 2. 2.

6

Terminate Section. No restrictions of a general

nature are placed on the parameters in the Terminate Section.

5.3

Testing Requirements. Start, Global, Directory Entry,

Parameter Data and Terminate Sections shall each be analyzed for

conformance to the IGES Specification with an appropriate software

utility. The Start Section and the Global Section shall be

printed out and checked visually with requirements of the

applicable MIL-SPEC-nnn application subset.

44
MIL-SPEC-nnnn

5.4 EDIF Product Data Exchange. « To Be Developed >>

5.5 VHSIC Product Data Exchange. << To Be Developed >>

45
;>v^^«.s?.t'»'.''-V';J.:,'=^^^ TIPfllM ©•'F'

.. . '^•'T ‘/iL^pJiny*^

)>

fif!nfi-<5ii*Sr^^8ra«'nrnr.

5 ,a,^,x.a'«^ci!%%fe

^

-^^jftAfflvwisnrieiUfcfciiaiTO* a»o»»v -i

' 3#ot;ion iiXiJ r^'>^rr«« ttnd b% 4«f«.uxt«di •’’ « 5«^)^Vk3 oT >:2^'’V€^ftrt3xa ?lfirecia:fe^i^ dIBK’/ e.€

TM ^ - r»ic

1, 0

1 "^11

1-4

1-7 '4 >'' '

I

n

Y

T

I

t’

<<; IIY

Y

M

*V.

biiiiitlt: r.o ?i#ld ? ; W* s

»

.. C l 5. 2. 2.

3

Dlr*<»itory T^tvy Smctlon* Tr*a foilovif^ cap»‘.

»hali Jsh» provided, am rh^.11 i^pparz^^i tor all

ft. Tna Lavel Huab^r Tiaid* AX*, valua* p^Tt;i‘ a^cap^.

vi!ifti,a nacaftiiarv t,o auaintalit trua<3^ Ddmnin^ '* r*fftr»*nca4 ontlty, . 4^ rhG Lo^ic^&l and ?h'/«ic\l Sul rdl'»«ta rntity Svltich,

Thft Sntlty Uaa Fla^.

;

i- Yh« Hi tirarchi -%:!' Statu* nag.

*. Thft tina " ‘ *'

<PK .. 1^'. *

r:

.. -. i. ttsa Calor Kuiebar.

t. ‘’ ’ I, il '.tir . i« '•HV *':*. j" A ‘iMw * .'n-’

*'M-r*^ S.jt'.SiS !^:^fi.iB«t*r Sactltm. Ko pestrlctions of « ^n«

nalfeiixa aar« pVao«d;«?n pariwotara :‘n tha JParafiAtar Data

^35j/' *

. J : «

.'X '< yj h'

"

' * ' * ' ^*Z,2 .€ Tftii^rtinatw: .^laction. Ho £>ftftt|tietju^r,s otf/ a crc^naral *v

rt'acad on fcbft »araiwt%ra in t.hft"’Tarmir.ata Stctlon.

Xaptln^. Start, Global, Diractory Entry, , . '".y Pajaaittcrtdr i?ata and tarmlnat^ Sat- 1 lone shall aac^ ba analyf«4 for

cottfprjiiiftno# to tha XO£S Spocif Icatlon with an appruprlat# softwara

"# vU^ T\v:. Start Sapitiafif and th« dlobal Sactlon fthall b#

‘ prints put apd cbaoktd visually with raquitftiiants Of th#

drrpiicabia Ml !.* SFEC-nrm applloatlon axibaat,

ii • . I H

'

p-A. j

X
DRAFT MILITARY SPECIFICATION FOR DOD ADOPTION APPENDIX C

NOTE: This draft, dated 27 February 87 prepared by Div 732

National Bureau of Standards, has not been approved and is

subject to modification. DO NOT USE FOR ACQUISITION PURPOSES.

Project NBS CALS Product Data.

MILITARY SPECIFICATION

IGES APPLICATION SUBSETS

Beneficial comments ( recommendations, additions deletions)

and any pertinent data which may be of use in improving this

document should be addressed to Bradford Smith, Bldg. 220,

Rm A353, Bureau of Standards, Gaithersburg, MD 20899 by

using the self-addressed Standardization Document

Improvement Proposal (DD Form 1426) appearing at the end

of this document or by letter.

DISTRIBUTION STATEMENT A. Approved for public release;

distribution is unlimited.

47
The Appendix C submitted in February 1987 was accepted as the base document for a new

^

military specification. The approved document,

MIL - D - 28000, was approved on 22 December 1987.

48
NBS.1T4A (REV. 2 »ac) U.S. OEPT. OF COMM.

BIBLIOGRAPHIC DATA

SHEET (See instructions)

1. PUBLICATION OR

REPORT NO.

NBSIR 88-3729

2. Performing Organ. Report No. 3. Publication Date MARCH 1988

4. TITLE AND SUBTITLE

A Collection of Technical Studies Completed for the Computer-aided

Acquisition & Logistic Support (CALS) Program - Fiscal Year 1987

(Vol. 4 of 4)

5. AUTHOR(S)

Edited by Thomas Wright

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

NATIONAL BUREAU OF STANDARDS

U.S. DEPARTMENT OF COMMERCE

GAITHERSBURG, MD 20899

7. Contract/Grant No.

8. T>^e of Report & Period Covered

NBSIR, 10/86 through

9/87

9.

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

Office of Assistant Secretary of Defense (A&P) /WSIG

Department of Defense, Pentagon

Washington, DC 20301-8000

10.

SUPPLEMENTARY NOTES

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

11.

ABSTRACT (A 2QQ~word or less factual summary of most significant information. If document includes a significant

bi bliography or literature survey, mention it here)

The overall objective of the Department of Defense Computer-aided

Acquisition Sc Logistic Support (CALS) Program is to integrate the

design, manufacturing, and logistic functions through the

efficient application of computer technology. The National

Bureau of Standards has been funded since Spring 1986 to

recommend a suite of industry standards for system integration

and digital data transfer, and to accelerate their

implementation. A major FY87 thrust was the completion of

initial documentation of the high-priority standards required in

the CALS environment. This volume is one of four providing a

collection of the final reports presented to the CALS Policy

Office. Major topics contained within this product data volume

include: the acceleration of testing methodology for IGES, the

development of the IGES application subset concept, and the

acceleration of PDES deliverables. The other three volumes

include reports on text, data management, media, raster

compression, graphics, and a conformance testing strategy.

12.

KEY WORDS (Six to twelve entries; alphabetical order; capitalize only proper names; and separate key words by semicolon s) CADCAM; CALS; conformance; DoD; IGES; PDES; testing; verification

13.

AVAILABILITY

f Y i Unlimited

I

1 For Official Distribution. Do Not Release to NTIS

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

20402.

1"^ Order From National Technical Information Service (NTIS), Springfield, VA. 22161

14. NO. OF

PRINTED PAGES

155

15. Price

$18.95

USCOMM-OC 8043-P80
D

•y aeei HOflAM

‘»»WAiu»«*T

AM TlUJ^i^

es«-68 »ue*

VKWt

.«*K>: %# ,^mMC

AUa 3IHHAH90Lm

»2>713r:«,

BjTi rQLt? OI4A SJtit

b9bi*-3*3uq«o0 Arti :ioi b*»eXqi»0 «s>il>u^2 teoiralsaT *o noiJaotio^A |

. Vflei •3S9? iMal'9 - »ei?otiq lE.I^t S’foqquS Oj;^*Xpoa a nol^xaio^ ^

(c>wOKTUA . Bi&AoriT Yci

.oH >na«|^''J9itiiinA3 .t »*f ,tA» *»*«•• v**tto >o m\o\\M HOlT^IHAOiSO Oi^lKHO^

'^2 ^OjlAOKATg ^O UiwaJdfH JAWOITAM

a:>jUD^Mo'^ to tnat-tniA^o jlu

TKi tiiV.iSn»»ia

«c.|it«<i 4W th* •-*»• oa ,noJgnirie»W

mlilLJr? »T-^cti>:A;Loa TH» tpprt?v#ti ;*»ocu3mr.t

jsll, - D - 28QOO. va# Approve- on H D**cMd><tr

V»Ar»4^^Q .ti

.MMM ti .g8>»^ .-nrit»>q •>*»<<»<»»> * t»^»ag»»

bsblA-itsttfqmoO 6»n»59a 5o jnsm.n»q»a »ri3 So svijsotdo ' 8d? 93Ai59Sni, 03 ai m53poi5 leOAO) JtoqqyE

9dl ripueixld »aoi3onwS oi3oipoX htit.

XfiflOi:t£U sriT la^i/qmoo io noi:»ADiiqq* 5a«lol*ia

ci -^861 rnX^tqS 9onl« nj>©d atr* 5o ju^XuS

nOJ 3 fi-ipojfii 8»3«Ye 105 .ab«fcn*r£ Y^jeubiti So *^-^*. *

139113 93e3si*O06 os - 0«* . IsSsOtlS S3if>

So noXdaXanoo sris bkw 3ai/iri3 TSV^ loc*TM A .ooiseaniwtaXqial

ni b9ixi.p?Tt£>i«fcft*38 »^1S 5o

irf3

£ pnifcivoiq luoS So ano ai sirwXov etiW

,, volXoq eJAO 9.-13 03 fc93«!M9iq aiioqai Xaaii arts So noxi^IAoo

emrXov 63*b Sowboiq axds nixlSXw baaiBinoo aoiqoS lo^ -9oi«0

arts ,eaS5 joi YPoiot-ortSam paxSaaS So

odd £>a» ,3qsone» saacWa aoXSaoXiqqa 3301 arid So Sr.amqoxovsb

Esmoxov P9id3 19/130 9rtT . aeXdii isvllsb 3305 ’®

is38£i .*xb*Hn , 3nemB9*n*m aseb ,3X93 no aSioqai sboXoax

.yp93*l3s pnl38*3 sonamoSaoo 6 bn» „aoXriq»i® AOoXaasiqtnoo

Ikl

VI

noi3£OXSil9V ipnX3893 i3aC5 ;330I iOofl ; 9ort£CnoSnOO »3JA0 sKAOW^IZi

YtfJOlAjlAVA'.ll

^

Ji' ^0,0M.>1

^^OA'«^ 03TV»^;i^ :ex

;vt' ^«^(nU 3p

EfTM OS *-Mi»oll oQ Q

0.0 >»»ommovoO,il.U .«now»u>«0 »n*en»jftiso«o^

ir 'vU I AlXt .AV ,<2>TI^) «pif.*m4^nl l#»l»vt»»T l*«Oi>0M imn*l ^»»0 iJl .-

s

?

%

r'\

. H

'[I

>

I

i

I •»

7