NAT

L INST. OF STAND & TECH R.I

C

NATIONAL INSTITUTE OF STANDARDS &

TECHNOLOGY

Research Information Center

Gaithersburg, MB 20699

IR 88-3844

RESTRICTED

IR 88-3845

RESTRICTED

NISTIR 88-3846

Guidelines for the

Specification and Validation

of IGES Application

Protocols

Randy J. Harrison*

Mark E. Palmer

U.S. DEPARTMENT OF COMMERCE

National Institute of Standards and Technology

(Formerly National Bureau of Standards)

National Engineering Laboratory

Center for Building Technology

Gaithersburg, MD 20899

*Sandia National Laboratories

Albuquerque, NM 87185

January 1989

75 Yaara Stimulating Amtnui Progress

1913-1988

NISTIR 88-3846

Guidelines for the

Specification and Validation

of IGES Application

Protocols

Randy J. Harrison*

Mark E. Palmer

U.S. DEPARTMENT OF COMMERCE

National Institute of Standards and Technology

(Formerly National Bureau of Standards)

National Engineering Laboratory

Center for Building Technology

Gaithersburg, MD 20899

*Sandia National Laboratories

Albuquerque, NM 87185

January 1989

National Bureau of Standards became the

National Institute of Standards and Technology

on August 23, 1988, when the Omnibus Trade and

Competitiveness Act was signed. NIST retains

all NBS functions. Its new programs will encourage

improved use of technology by U.S. industry.

U.S. DEPARTMENT OF COMMERCE

C. William Verity, Secretary

NATIONAL INSTITUTE OF STANDARDS

AND TECHNOLOGY

Ernest Ambler, Director

Preface

This document explains the concept of IGES (Initial Graphics Exchange Specification)

application protocols, specifies the technical content of an IGES application protocol,

and describes a validation methodology for these application protocols. This publication provides the baseline for broader review and analysis of these ideas by organizations and standards making bodies that may adopt them.

The enclosed material represents ideas that are under active discussion by the

IGES/PDES (Product Data Exchange Specification) Organization and the

IGES/PDES AVM (Application Validation Methodology) Committee. Once the

IGES/PDES Organization has completed the necessary review and approval procedures, this document will be published as an official document of that organization.

Your comments on this document are encouraged and should be addressed to:

Mark Palmer

IGES/PDES AVM Committee Chairman

Building 226 Room B306

Center for Building Technology

National Institute of Standards and Technology

Gaithersburg, MD 20899

(301) 975-5858

(FTS) 879-5858

First Printing: January 1989

IGES/PDES AVM Version: 0.07
r
Abstract

This document provides a background discussion of product data, describes the concept of IGES (Initial Graphics Exchange Specification) application protocols, specifies

the technical content of an IGES application protocol, describes a validation methodology for these application protocols, and provides guidelines for the implementation of

an IGES application protocol. A key conclusion of the background discussion of

product data is that IGES application protocols must be developed in order to achieve

consistent and reliable exchanges of product data within specified application areas.

The technical content of an IGES application protocol includes a conceptual information model for the application area with its supporting documentation, an application

protocol format specification with a protocol usage guide, and a set of application

protocol format test cases. These test cases must be used in concert with a well-defined

testing methodology.

Since no complete IGES application protocols currently exist, this document describes

a current implementation of an application protocol process that is based on a partially complete application protocol. The document also includes a specific example of a simple application protocol that meets the technical content requirements.

Key words: application validation; CAD data exchange; computer-aided design and

drafting; data exchange standards; data translation quality assurance; data translators;

IGES; IGES application protocols; information management; validation of data translators

v

Table of Contents

PREFACE iii

ABSTRACT v

LIST OF FIGURES ix

1.1 Scope 1

1.2 Background 2

2. FUNDAMENTAL CONCEPTS 3

2.1 Product Data as a Resource 3

2.2 User, Implementor, and Purchaser Views of Product Definition Data . . 4

2.2.1 User Perspective 4

2.2.2 Implementor Perspective 5

2.2.3 Purchaser Perspective 6

2.2.4 Summary 6

2.3 Concept of IGES Application Protocols 6

3. IGES APPLICATION PROTOCOLS 8

3.1 Process for Developing IGES Application Protocols 8

3.2 Required Technical Content of an IGES Application Protocol 9

3.2.1 Conceptual Information Model 10

3.2.2 Application Protocol Format Specification 11

3.2.3 Set of Test Cases 12

3.3 Application Protocol Validation 13

3.3.1 Application Protocol Validation Procedures 14

VII
3.4 Application Protocol Approval Procedures 17

4. GUIDELINES FOR THE IMPLEMENTATION OF AN APPROVED IGES

APPLICATION PROTOCOL 19

4.1 Example of an Application Protocol Process ...................... 27

4.2 Example of a Simple Application Protocol 34

4.3

User, Implementor, and Purchaser Views of Application Protocols ... 35

5. REFERENCES . 38

APPENDIX A Glossary cGceoooooccoeeeoeeceeoeeoeeoccceeeccocceGOoce .... A- 1

APPENDIX B.l Feature Control Frames - Application Protocol Information

Model oeceeeG»cGeec>ccooce®«ceeoeecoe€GoeQOOQcecoeecoeeeee>oceeeee .... B“ 1

APPENDIX B.2 Feature Control Frames - Application Protocol Format

Specification ........ ©©©©©©©©co©©oe©e©eG©c©e©oo®®oo©e> ................. B" 13

APPENDIX B.3 Feature Control Frames - Application Protocol Format Test

Cases ....... ©oe©®e®©o©©o©oe©©e©®©©©©© B-37

viii
List of Figures

Figure 1 - Mapping of Information from an Information Model into an Application

Protocol Format 12

Figure 2 - Application Protocol Process Structure Based on "Generic" IGES

Translators 21

Figure 3 - Application Protocol Process Structure Based on Application Protocol

Format Translators ............. .25

Figure 4 - Application Protocol Process Developed by DOE/NWC 28

Figure 5 - Feature Control Frame .......... ... 34

Figure B1 - Application Reference Model B-4

Figure B2 - Application Implementation Model (Initial) B-5

Figure B3 - Application Implementation Model (Final) B-6

Figure B4 - Application IGES Implementation Model B-7

Figure B5 - Feature Control Frame Test Cases B-38

IX

1. Introduction

A major objective of many users of CAD/CAM equipment is the effective exchange of

data throughout the life cycle of products. This may include the use of computer

readable data sets describing the products, their assemblies, subassemblies, and the

product support data. A central issue is the exchange of digital representations of

product data in various forms: illustrations, 2-D drawings, 3-D edge-vertex models, sur- faced models, solids models, and complete product models.

Throughout industry, an increasing number of computer-aided design systems are

being used in all phases of design, analysis, manufacturing, and testing of products.

Over one hundred vendors offer CAD systems, and most industries have already committed themselves to working in heterogeneous CAD environments.

Even with the great variety of CAD systems available today, no single CAD system possesses the depth and breadth of capabilities to satisfy the needs of all users for all applications. Because of this, users tend to purchase a variety of CAD systems, each

selected to support a particular application. Complexity is introduced into the use of

CAD systems when product data must be exchanged between different business units

and outside participants at major milestones of a project; design to engineering, engineering to manufacturing, manufacturing to inspection, prime contractor to subcontractor, or vendor to customer.

There is a requirement in the normal course of business to be able to exchange the digital product models and drawings that are developed on one system with another dissimilar system. This may be for the internal transfer of product data or for the purchase

of product data from external sources. The exchange of digital product models is ex- pected to become as commonplace in the 1990’s as the exchange of paper-based engineering drawings is today. In order to effectively integrate CAD technology, industry

requires comprehensive and reliable data exchange mechanisms.

1.1 Scope

This document contains a background discussion of product data, specifies the technical content for an IGES (Initial Graphics Exchange Specification) application protocol,

describes a validation methodology for IGES application protocols, and provides

guidelines for the use of IGES application protocols.

Since no complete IGES application protocols currently exist, this document describes

a current implementation of an application protocol process that is based on a partial1
ly completed application protocol. The document also includes a specific example of

a simple application protocol that meets the technical content requirements.

1.2 Background

IGES is a neutral representation format for the exchange of product definition data between CAD systems. Since the release in 1980 of the first version of IGES, the

IGES/PDES (Product Data Exchange Specification) Organization has added increasingly sophisticated data constructs to the IGES specification. As the capabilities of

IGES have been expanded to accommodate more applications, the specification has

become more pliable. Some of these changes have added to the complexity and ambiguity of the specification, and this has increased the difficulty of using IGES effectively.

At present, no vendor supports all of the entities in the entire specification with their

IGES processors. Each vendor has implemented a subset of the specification which

best matches the salient capabilities of their CAD system. Hence, there is only limited

IGES entity correspondence between the processors of dissimilar CAD systems and

no definition for conformance to the IGES specification. This situation has forced

users to limit their data exchanges to only those entities that are uniformly supported

by both the sending and receiving systems.

Implementations of IGES translators for different CAD systems continue to be uneven

in quality and capability. Additionally, the majority of industries have not adopted the

level of information control that is required for successful exchanges of CAD information using IGES. IGES application protocols are being developed as a mechanism to

address these problems.

2
2. Fundamental Concepts

In order to successfully use IGES for CAD information exchanges, organizations must

have well-defined technical information management plans and documented procedures for creating, delivering, and maintaining technical information in digital form.

This documentation must include the standardized modeling conventions by which

product information is created and the protocol for precisely transferring that information via the IGES format.

A protocol is a set of conventions or rules that govern the operation of functional units

to achieve communication. [1] The concept of IGES application protocols provides a

formal procedure for specifying neutral, IGES-based, application specific formats. The

procedure for developing application protocols involves identifying the information re- quirements of an application area and documenting them in an information model.

The information model is then used to select the IGES constructs for representing the

required information.

2.1 Product Data as a Resource

Industrial users must be able to deal with digital product data in six generic applications: - Internal transfer of product data; - Data transfer from design systems to product support systems; - Acquisition of new manufactured parts and systems; - Competitive reprocurement of spares; - Purchase of data for a product; and - Archival storage of parts and assembly data.

Digital product data is becoming an important consideration in contractual relationships for the purchase of manufactured parts, assemblies, or whole systems and projects.

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.

The economic significance of digital product data is easily seen from these examples.

Efficiency, accuracy, and lead time improvements are all substantially enhanced by

providing the methods for the reliable interchange of digital product data.

3
Two terms will be used for classifying data: product definition data and product data.

Product Definition Data denotes the totality of data elements that 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, and inspection. 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.2 User, Implementor, and Purchaser Views of Product

Definition Data

The creation, exchange, and archival storage of product definition data in the form of

digital data sets can be viewed from three perspectives: the User, the Implementor, and

the Purchaser. In some cases, different units within the same organization may hold

each of the perspectives. In other cases, each of the perspectives may be held by individual organizations that have a contractual relationship.

2.2.1 User Perspective

The User perspective is the view held by an end-user of the product definition data

(PDD). End-users have specific requirements for the structure and content of PDD.

These requirements are a function of the end-user’s discipline and application area. An end-user of PDD will be supporting a certain discipline, such as Mechanical or

Electrical, and will be working within a certain application area, such as Drafting or

Numerical Control Machining. The end-user will also have an application-based view

of the information requirements through the use of application specific terminology

and rules.

To understand the User perspective of PDD, it is necessary to carefully consider the

current environment of hardcopy engineering drawings. In the paper-based environment, the official PDD for any of the disciplines exists as drawings that give the product

definition data as prepared by the Drafting application area. Actually, these drawings

are only part of the PDD that is necessary to support the needs of the end-user’s discipline.

Currently, each end-user must perform an application-based interpretation of the

drawing, extract the available information for the receiving application area, and create

the missing information that is necessary to satisfy the end-user’s information requirements.

4
One deficiency of paper-based PDD (i.e., drawings) is that in most cases each end-user

is required to repeatedly perform an interpretation, extraction, and augmentation of

an incomplete set of product definition data. These repeated end-user actions result

in more incomplete paper-based PDD.

Initial attempts at preparing digital PDD sets were aimed at providing all of the information that was represented on the paper drawing. However, in the preparation of the

digital PDD sets, information was lost, and end-users were forced to perform the same

interpretation, extraction, and augmentation of the information contained in the data

sets as had been necessary for the paper drawings.

Key concerns of users of digital PDD are: 1) that the requirements for data structure

and content are well-defined and stable; 2) that reliable systems and software to use

the data are available, and 3) that the data are prepared and read completely and correctly. In order for digital PDD sets to be a valid replacement for paper-based PDD,

the information contained in any digital PDD set must be at least as complete as the

information on the paper drawing. The other perspectives discussed in this section will

rely on this conclusion.

2.2.2 Implementor Perspective

The Implementor perspective is the viewpoint held by an individual who develops systems and software for Users to employ in producing and reading digital PDD. Implementors strive to provide systems and software that meet the end-user’s needs for

producing and utilizing digital PDD.

In order for the Implementor to develop systems and software to produce and read

digital PDD, the implementation requirements for the structure and information content of the digital PDD sets must be given in a well-defined and stable form. These implementation requirements must be based on providing application-based views of a complete set of information that describes the product for a certain discipline(s).

The Implementor must provide the User a set of instructions for using the systems and

software appropriately so that complete and correct digital PDD sets can be produced.

Users that receive digital PDD sets through an exchange must be able to read them

with Implementor developed systems and software with the assurance that the data sets

were correctly prepared using the Implementor-supplied instructions.

5
2.2.3 Purchaser Perspective

The Purchaser perspective is the viewpoint held by an individual or organization that

must purchase digital PDD sets. The Purchaser’s primary requirement is that the PDD

sets contain a complete set of information that describes the product for a certain discipline and provides support for an application-based view of the information. These

PDD sets will have been produced by Users with Implementor developed systems and

software according to the Implementor-supplied instructions.

The Purchaser must be sure that the received PDD sets were completely and correctly prepared by the Users. Also, the Purchaser must be sure that the Implementor supplied systems and software have the capability to correctly produce and read the digital PDD sets. In addition, the Purchaser requires that User produced PDD sets can be

placed in long-term archival storage for future retrieval and use with Implementor

developed systems and software.

2.2.4 Summary

In summary, the User must be able to correctly produce and read digital PDD according to the information requirements of the discipline and its associated application

areas. The User must depend on Implementor developed systems, software, and

documentation to produce and read digital PDD. The Implementor must provide systems and software according to a well-defined and stable set of implementation re- quirements. The Purchaser must be able to acquire digital PDD, produced by Users

with Implementor developed systems, software, and documentation for use by other

end-users or long-term archival storage. The Purchaser must depend on both Users

and Implementors for acquiring complete and correct digital PDD sets.

Finally, the structure and information content of digital PDD sets must be sufficient to

completely describe the product for a certain discipline(s) and must provide support

for an application-based view of the information. The implementation requirements

for systems and software to produce and read digital PDD must be based on a welldefined and stable information model. Users and purchasers require comprehensive

methods for ensuring that digital PDD is produced according to a well-defined set of

requirements.

2.3 Concept of IGES Application Protocols

Information, either in the form of a sentence or in the form of a digital product model,

consists of syntax and semantics. The IGES specification defines the basic syntax and

6
core semantics of the representation format. In order to ensure complete and reliable

information exchange within a specified application area, the application specific data

structures and semantics must also be documented and controlled. IGES application

protocols (APs) are a formalized methodology for defining this semantic content and

the mappings to the data structures of IGES.

Application protocols allow the definition of logical subsets of IGES and their usage,

as well as providing a mechanism for validating implementations. The use of an application protocol for the exchange of product information provides a mechanism for

participating agencies to agree on the types of information to be exchanged and to

employ corresponding information control procedures.

The key concept of application protocols is to explicitly link the application area’s information content to the entities and data structures to be exchanged. The procedure

for developing application protocols involves identifying the information requirements

of an application area and documenting them in an information model. This application reference model is then used to select the corresponding constructs of the standard for representing the required information.

The components of an IGES AP are: 1) an application protocol information model, 2)

an application protocol format specification with a protocol usage guide, and 3) a set

of application protocol test cases. These test cases must be used in concert with a welldefined testing methodology. The application protocol format consists of a "subset" of

IGES entities including the restrictions on the global, directory entry, and parameter

data section field values, and a detailed guide for the use of each IGES entity in the

"subset" in carrying information from the conceptual information model.

7
3. IGES Application Protocols

Experience shows that when the IGES format alone is used for the exchange of product

definition data, a wide range of entity types are usually required to convey the information for an application area. Vendor IGES processors implement subsets of the

IGES specification and express the user’s information in these IGES entities. Invariably there is a mismatch between the entities implemented in a preprocessor and those

implemented in a postprocessor of a different system. In addition, the wide range of

IGES entities used by different processors makes translator implementation an open

ended task.

Product information is usually encoded differently by IGES processors, and this results

in the loss of some of the information content of the original data files. It is necessary

and desirable to exchange the intended information content and not just an IGES data

set. Finally, experience suggests that full and functional information exchange for any

application area will not, in general, be accomplished by simply abutting the vendor

supplied IGES processors of different CAD systems.

IGES application protocols can help solve the above problems and accomplish the successful exchange of product definition data for a specific application area. Because application protocols are based on information engineering techniques, application

protocols can be said to allow the exchange of "information," while the use of IGES

alone allows only the exchange of "data."

An IGES AP describes the information content that is expected to be encountered in

the application area, identifies the mappings of the information content into its representation by particular IGES entities and constructs, and describes the restrictions and

conventions to be observed in the use of the supporting IGES entities.

3.1 Process for Developing IGES Application Protocols

The first step in specifying how an application area can exchange its product definition

in a heterogeneous computer environment is to define the information content to be

exchanged. The definition of information requirements must be done independently

of any computer system or product data format. The information content can be

described by the use of a conceptual information model. The conceptual information

model must be developed by an analysis of the information that is required to support

the application area of interest. When the conceptual information model has been

produced, it must be validated conceptually as well. This validation must be done using

the information model and all of its supporting documentation.

8
The second step in defining an IGES AP is to specify the AP format, i.e., how the information content from the conceptual information model is to be carried by a subset

of IGES entities. The many options for the use of the entities within this subset must

be restricted so that only one method is available for carrying each element of information from the conceptual information model. The set of IGES entities and the

necessary restrictions on the global, directory entry, and parameter data section field

values must be determined by using the conceptual information model as a basis.

The third major step in this process is to develop and document a set of AP test cases. The test cases must successfully implement all of the information content of the accompanying conceptual information model. These test cases will be used to validate the

proposed IGES AP and trial implementations of IGES AP processors.

3.2 Required Technical Content of an IGES Application Protocol

An IGES application protocol includes a conceptual information model, an AP format

specification with a protocol usage guide, and a set of test cases. The AP format

specification must consist of a "subset" of IGES entities, including the restrictions on

the global, directory entry, and parameter data section field values, and a detailed guide

for the use of each IGES entity in the "subset" in carrying information from the conceptual information model. An example of a simple AP with each of these components

is included in Appendices B.l - B.3 of this document.

An issue in the use of IGES AP formats is whether the formats must be "restrictive".

The notion of restrictive AP formats means that a conforming file is allowed to contain

only the IGES entities that are identified to carry the required information. Thus, the

notion of restrictive AP formats would not allow any other entities, e.g., "volunteer" entities to be included in an AP format file.

Considerable experience with the use of IGES translators for product definition ex- change suggests that difficulties will be encountered if the AP formats are not restrictive. Difficulties such as translator failure and/or loss of information may be encountered if the software units are forced to deal with IGES entities not within their

capabilities.

The current consensus of the IGES/PDES AVM Committee is that the AP formats will

not be completely restrictive. The consensus position is that: additional IGES entities,

not in the AP format, which do not detract from the completeness or correctness of the

information contained in the AP format, may be included in an AP format file.

However, none of the additional IGES entities may point to or be pointed to by entities that carry information for the AP format. This requirement is to ensure that

9
software which is intended to read files in a particular AP format can correctly process

the files by completely ignoring any entities which are not part of the AP format.

3.2.1 Conceptual Information Model

The conceptual information model is called the Application Protocol Information

Model (APIM) and will consist of at least two models, the Application Reference

Model (ARM) and Application IGES Implementation Model (AIIM). The ARM

documents the information requirements of the subject application and provides the

baseline from which candidate format implementation models are developed.

A valuable intermediate model is an Application Implementation Model (AIM). The

AIM describes the explicit identifiers that will be required for manipulating the product

definition data for the subject application. The concluding model is the AIIM, which

shows how the information content from the ARM is to be carried by a subset of IGES

entities.

A rigorously defined package of supporting documentation must be provided with the

completed conceptual information model. This package must be used in the validation

of the model and therefore must consist of the following:

a. The information model must be provided in one of the approved information modeling languages, NIAM, IDEF1X, or Express. The PDES project has

done modeling work in all of these languages and has designated Express as the

documentation language for the integrated models.

b. The information model must be provided with detailed definitions for all of

its objects (for NIAM) or entities (for IDEF1X). This documentation must also

be supplied for a model in the Express language. A detailed glossary of

acronyms and abbreviations, and a detailed list of the assumptions that are inherent in the model must be provided. This glossary must be easily understandable by an expert from the application area under validation.

c. The constraints (for NIAM or Express) and business rules (for NIAM and

IDEF1X) must be detailed either in the model itself or in additional supporting documentation. The constraints and business rules must include the

relationships between the objects or entities in the information model.

10
3.2.2 Application Protocol Format Specification

The application protocol format specification includes the list of required IGES entity

types, the restrictions on the IGES entities, and the usage guide for the AP. The AP

format must be based explicitly on the conceptual information model. The IGES entity list and usage guide must include the restrictions on the global, directory entry, and

parameter data section field values.

An AP format specification must use IGES entities that exist in the current IGES

specification where possible. It is permissible to specify "gray page" (IGES Version 4.0;

Appendix J, Untested Entities [2]) entities for preliminary APs. New entities can be

defined for an AP only where there is no existing IGES entity that can be used to carry

the necessary information. The IGES entities selected for use in the AP format must

be selected so as to minimize the size of resulting files. This means that the "simplest"

IGES entity should be selected when there is more than one possible choice.

As part of an AP format specification, a detailed "protocol usage guide" must be

developed for the users and implementors of the AP format. This usage guide must

specify in detail which IGES entity(s) from the subset is to be used to represent each

element of information from the conceptual information model. An AP information

mapping table must be included as a summary of these specifications. A sample AP

information mapping table for some possible Mechanical Drafting Application

Protocol information requirements is shown.

Information Mapping Table for a

Mechanical Drafting Application Protocol

Conceptual Information Model’s

Information Requirement

Drawing Format

Feature Control Frame

Application Protocol’s IGES

EnmkiRequired

302/402 Associativity Definition and Instance

consisting of:

110 Line

212 General Note

302/402 Associativity Definition and Instance

consisting of:

102 Composite Curve

110 Line

212 General Note

214 Leader

11
APPLICATION

PROTOCOL

INFORMATION

MODEL

—iIGES

APPLICATION

PROTOCOL

FORMAT

MAPPING OF INFORMATION FROM AN INFORMATION

MODEL INTO AN APPLICATION PROTOCOL FORMAT

Figure t

This mapping of information from the information model to the IGES entities is represented in Figure 1. The top pane of the diagram represents the APIM, and the lower

pane represents the AP format with its selected entities and data structures. The ar- rows represent the mappings. The usage guide makes explicit these mappings between

the application information content and the constructs of the AP format.

3.2.3 Set of Test Cases

A set of test cases, containing examples from the application area, must be included.

These test cases must successfully implement all of the information content of the accompanying conceptual information model using the IGES entities in the AP format.

The test cases must correctly implement the syntax and restrictions of the AP format

according to the usage guide.

12
The documentation for the test cases must include the following:

a. the objectives of the test case and a description of the data contained within

the test case;

b. the expected results of the test case;

c. a pictorial representation of the test case data;

d. the evaluation criteria and variance bounds;

e. a script file for preprocessor testing, and

f. an IGES file for postprocessor testing.

3.3 Application Protocol Validation

The AVM (Application Validation Methodology) Committee of the IGES/PDES Organization is responsible for developing procedures for the application validation of

IGES translators and the translation process. As part of these duties, the AVM Committee is charged with reviewing and approving proposed IGES APs. This committee

will only approve those candidate APs that have met all of the technical content re- quirements, specified in Section 3.2, and the success criteria of the validation methodology, described in Section 3.3.1.

The AVM Committee will not perform a detailed validation of the information content of the candidate AP. The detailed validation of the AP information content must

be performed by the IGES/PDES technical committee that is responsible for developing the AP. Those organizations planning to implement an AP must validate the AP’s

correspondence with their information requirements and must develop the necessary

digital data quality assurance procedures.

The AVM Committee will perform a limited evaluation of the AP information model

set, the AP format specification, and the set of test cases. This review and evaluation

will be done for the purpose of assisting the IGES/PDES technical committees in

preparing and refining APs.

Asummary list of the individual components necessary for APvalidation is given below.

a. APs application-based NIAM, IDEF1X, or Express information model.

b. Detailed glossary and supporting documentation for the information model.

c. Detailed specification of the constraints and business rules for the information model

d. AP format’s list of IGES entities and AP information mapping table.

13
e. AP format’s detailed restrictions for the global, directory entry, and

parameter data sections for the IGES entities.

f. AP format’s detailed usage guide for the IGES entities.

g. AP format’s test cases and accompanying documentation.

3.3.1 Application Protocol Validation Procedures

A summary of the validation procedures for a candidate AP is given below in one sentence statements, followed by a more detailed description of the complete methodology:

1. Content validation is done for the purpose of evaluating the completeness and correctness of the conceptual information model’s representation of the information re- quirements for the application area.

2. Information representation validation is done for the purpose of evaluating the application protocol format’s representation of the information requirements as specified

by the conceptual information model

3. Application verification is done for the purpose of

evaluating the completeness and syntactical correctness of the implementation of the

AP format in the test cases.

Part 1, the content evaluation part of this validation, will be manpower intensive. Due

to the current state of information modeling software tools, it is not possible to simply

use a computer program to evaluate the information model for completeness or correctness. This validation will involve a team of experts from the subject application

area.

The authoring committee and the AVM Committee must jointly designate the members of this content validation team. For an optimum validation of the information

model, these application experts should not be the same experts that participated in

the development of the information model. When it is not possible to obtain application experts that did not participate in the information model development, this re- quirement may be waived if both the authoring committee and the AVM Committee

are satisfied with the submitted content validation documentation.

In either case, a group of experts from the application area must be called upon to perform the task of evaluating the content of the conceptual information model and its ac- companying documentation. Most, if not all of this evaluation will have to be done

manually. It is however possible to provide the group of application area experts some

14
computer tools to aid in the task of preparing different forms of the information model

for analysis. For example, a NIAM model is based on the structure of English language

sentences that contain a subject and a predicate and give information about the structure and meaning of the information that is required in the application area. For a NIAM model, it may be helpful to use a computer tool to process the entire model into

the form of grouped and structured English language sentences that contain the structure and meaning of the information.

This part of the validation most likely will have to be done on a paper form of the model.

The conceptual information model must be evaluated on the basis of information re- quirements, before the AP format is evaluated. It makes no sense to attempt an evaluation of the AP format without validating the candidate conceptual information model

first. The success criteria for this validation is that the information model accurately

specifies all of the information requirements for the application area.

The evaluation must be done in an incremental way such that each expert will study

and evaluate a section of the information model and produce an evaluation report on

that section of the model. These experts must use all of the information from items a. through c. in Section 3.3. The evaluation report must identify that expert’s assessment

of any deficiencies in the information model.

If this step in the validation is not passed successfully, the evaluation report must include a high level summary of the areas where emphasis is required in the next iteration of the AP’s conceptual model development. In this case, the validation will not

continue into Part 2.

When this step in the validation process is passed, a summary report must be produced

to describe the successful information model validation. This must include the incremental validation reports for the sections of the conceptual model, as completed by

the application area experts.

Part 2, the information representation validation of the AP, involves the evaluation of

the AP format’s ability to carry all of the information requirements specified by the

validated conceptual information model. This validation must check that all items of

information specified by the information model can be carried in the AP format as specified by the usage guide. This part of the validation will require both application

area experts and experts in the capabilities and use of IGES.

This validation procedure will include traversing the information model and identifying each element of required information. The AP format specification is required to

contain a usage guide for the IGES entities. The usage guide must be used to find the

location in the AP format’s IGES entity set where each element of information is to be

carried. The IGES entity must then be evaluated on its ability to carry the required information, embedded as specified by the usage guide.

15
This procedure must be completed for the entire conceptual information model. The

experts that perform this validation step must use all of the information from items d.

through f. in Section 3.3. As an aid in completing this procedure, the AP information

mapping table (described in Section 3.2.2) shall be used to check the IGES entity type

or types that are specified to carry each element or group of information from the information model.

This validation step will be passed when all information requirements specified by the

conceptual information model are verified to be accurately carried by the AP format.

If any single information requirement from the conceptual information model cannot

be supported by the AP format, this validation step will be failed.

When this step in the validation is passed, a summary report must be produced, consisting of the verified AP information mapping table and a description of the successful AP format validation. If this step in the validation is not passed, the report must

give a high level summary of the areas where emphasis is required in the next iteration

of the AP format’s development. In this case, the validation must not continue into

Part 3.

Part 3, the AP format compliance verification, evaluates the completeness and syntactical correctness of the implementation of the AP format in a set of AP format test cases. Test cases must be provided for testing both pre- and postprocessors.

This part of the AP validation must use all of the information in items d., e., and f. in

Section 3.3. The protocol usage guide must be used to verify that the semantics (the

meaning) from the conceptual information model have been accurately represented in

the set of test cases. The supporting documentation for the test cases will be absolutely necessary in this part of the validation. This step must also include checking the syntactic correctness of the AP format test cases.

One tool to assist in this verification procedure would be an IGES file syntax checker.

A standard IGES file syntax checker could be modified to use the syntax and entity

types of an AP format. Since no AP syntax checkers currently exist, and until IGES file

syntax checkers are robust enough to check for AP formats, much of this verification

will have to be done manually.

It is imperative that the protocol usage guide be followed to correctly embed the information in the required list of IGES entities. Therefore, if the set of AP format test

cases can be verified to: (i) contain syntactically and semantically correct information

per the conceptual information model and the protocol usage guide, and (ii) contain

an implementation of all information requirements of the AP s conceptual information model, this evaluation will be passed. If any syntactic or semantic deficiency is

found, or any information requirement is not implemented, this part of the process will

be failed.

16
This set of AP format test cases may be used as part of the necessary set of test cases

for a future AP conformance program for vendors, developers, users, etc. These test

cases will undoubtedly not be all of the test cases that would be needed for such a

program.

When this step in the validation is passed, the results must consist of a verified set of

AP test cases and a summary report documenting the successful verification of the AP

format test set. If this step is not passed, the report must give a high level summary of

the areas where emphasis is required in the next iteration of the AP format test case

development.

3.4 Application Protocol Approval Procedures

The AVM Committee will accept candidate AP packages from the IGES/PDES technical committees that prepare them. Upon receiving an AP package, the AVM Committee will inventory the AP package for the required technical content before any

technical evaluation is performed.

If any of the required items are absent from the AP package or are evaluated as insufficient per Section 3.3.1, the AVM Committee will prepare a summary list including an

explanation of the missing items. The AP package, with this summary report, will be

returned to the appropriate IGES/PDES technical committee. The AVM Committee

will work with those committees that are submitting candidate APs to resolve any identified deficiencies.

Application protocols will go through distinct stages of development, testing, and approval. These stages are classified as Preliminary, Trial, Draft, and Recommended,

with following meanings.

- Preliminary AP: Under development, not completely validated by the

authors - Trial AP: Submitted by the authors for full testing and validation by interested organizations - Draft AP: Approved by the lead IGES/PDES technical committee

- Recommended AP: Approved by the IGES/PDES AVM and Edit Committees

17
Before an AP can be approved by the IGES/PDES Edit Committee, the protocol must

be implemented on at least two dissimilar systems, and those two systems must exchange files in both directions according to the protocol. This exchange may require

reprocessing the IGES files with software tools in addition to system provided IGES

translators, or it may require custom modification of the system provided IGES translators.

Once a candidate AP has been specified and validated per these guidelines, it can be

approved by the AVM Committee. With this approval, the candidate AP can be

presented to the Edit Committee of the IGES/PDES Organization for approval as a

Recommended IGES Application Protocol.

18
4. Guidelines for the Implementation of an

Approved IGES Application Protocol

The exchange of product definition information between dissimilar CAD systems is

greatly affected by the sequence of the format translations in the exchange. In order

to successfully implement an application protocol process, it is necessary to implement

a reliable approach for Information Configuration Control and Software Configuration Control. For some product definition exchange environments, component parts

of such an approach are in place or under development. However, for an application

protocol process to be successful, the participating organizations must establish Information Configuration Control and Software Configuration Control for their product

definition creation and exchange systems.

To understand why Information Configuration Control and Software Configuration

Control are needed in an application protocol process, it is necessary to examine the

sequence of steps and software units through which CAD information must pass in the

translation from the database format of one CAD system through an IGES application

protocol format to the database format of another CAD system. In an application

protocol process, documentation is required to define each format and the information

mappings between the formats. The Application Protocol Information Model and the

Application Protocol Format Specification must be used to prepare this documentation.

For an application protocol process, there are two essential points to be made:

1. The syntax (the format) and semantics (the meaning) at each format step must

be specified by documentation which is under configuration control. This approach will be called Information Configuration Control (ICC).

2. The Application Protocol Format Specification specifies the IGES entities

and the restrictions on the entities that will be used to carry each element of information from the application protocol information model. The ICC

documentation provides a basis for documentation of the information mappings

between the formats. Therefore, the software that translates the information

between the formats must be written on the basis of the ICC syntax and semantics specified in that documentation. This is a first step in Software Configuration Control (SCO.

There are two ways to implement an application protocol process for translating CAD

information from the database format of a System A into an IGES AP format, and then

translating that information from the IGES AP format into the database format of a System B. Each of the two ways is based on a specific AP process "structure" that consists of certain formats and software units.

19
Figure 2 illustrates the first AP process structure. Figure 2 shows five rectangles that

represent the formats used in translating information from the database format of System A into the IGES AP format, and then into the database format of System B. ICC

must be imposed by specifying the syntax and semantics to be used in the creation and

translation of CAD information between these formats. For use in SCC, the ICC syntax and semantics documentation must have a version number and a date of release.

The first rectangle in Figure 2 represents CAD information created in System A. The

purpose of this format step is to create the information using a well-defined set of

capabilities available on System A such that the constructs in the CAD database conform to the ICC specifications. The ICC syntax and semantics for this format step could

be contained in the document called "CAD Standards and Practices for System A".

These user modeling standards must define:

syntax - the choice of the format and structure for creating and manipulating

each item of CAD information for the application protocol using the user interface available on System A.

semantics - what each item of CAD information that is to be created and

manipulated means for the application protocol.

The second rectangle in Figure 2 represents the CAD information in the IGES representation format of System A. The purpose of this format step is to represent the CAD

information from System A in a nonproprietary format for subsequent manipulation

as required. The IGES representation format does not have well-defined semantics

for the CAD information produced by System A. Therefore, the semantics for this format step must be derived from analysis of the CAD information produced by System

A after translation into the IGES representation format. The ICC syntax for this format step is contained in a document called "The Initial Graphics Exchange Specification." The ICC syntax and semantics for this format step must define:

syntax - the choice of the format and structure for representing each item of

CAD information in the IGES representation format for System A. This syntax is a function of the application protocol, the structure of System A, the user

interface of System A, and the software unit for System A that translates the

CAD information into the IGES representation format.

semantics - result of how each item of CAD information is dispersed when it is

translated into the IGES representation format for System A due to the variables associated with the ICC syntax.

The third rectangle in Figure 2 represents the CAD information from System A in the

IGES AP format. The purpose of this format step is to prepare the CAD information

in an application specific format that is independent of any individual CAD system.

20
21

BASED

ON

"GENERIC"

IGES

TRANSLATORS
The ICC syntax for this format step must be contained in the AP format specification.

The semantics for this format step must be contained in the AP information model.

The ICC documentation for this format step is required as part of an approved AP. For

an approved Mechanical Drafting AP, this documentation could be called the

"Mechanical Drafting Information Model" and the "Mechanical Drafting Application

Protocol Format Specification." The ICC syntax and semantics for this format step

must define:

syntax - the choice of the format and structure of how each item of CAD information from the AP information model is to be carried in the AP format.

semantics - what each item of CAD information in the AP format means according to the AP information model.

The fourth rectangle in Figure 2 represents the CAD information in the IGES representation format as required by System B. The purpose of this format step is to provide

the CAD information from the application specific IGES format into the form required

by System B. Again, the IGES representation format does not have well-defined

semantics for the CAD information. Therefore, the semantics for this format step must

be determined on the basis of how the CAD information must be embedded into the

IGES entities as required by System B. The ICC syntax for this format step is contained

in a document called "The Initial Graphics Exchange Specification." The ICC syntax

and semantics for this format step must define:

syntax - the choice of the format and structure for representing each item of

CAD information for the AP in the IGES representation format for System B.

This syntax is a function of the AP, the structure of System B, the user interface

of System B, and the software unit for System B that translates the CAD information from the IGES representation format.

semantics - result of how each item of CAD information must be dispersed when

it is translated from the IGES representation format for System B due to the

variables associated with the ICC syntax.

The fifth rectangle in Figure 2 represents the translated CAD information in the format of System B. The purpose of this format step is to provide the CAD information

in System B format such that the original CAD information can be manipulated in the

same way as if it were created on System B. The ICC syntax and semantics for this format step could be contained in a document called "CAD Standards and Practices for

System B" and must define:

syntax - the choice of the format and structure for creating and manipulating

each item of CAD information for the AP using the user interface available on

System B.

semantics - what each item of CAD information that is to be created and

manipulated means for the AP.

22
The four circles in Figure 2 represent the software units that translate the CAD information from the System A database format through the IGES AP format to the System B database format. SCC must be imposed by requiring that two of these software

units, the IGES AP format preprocessor and the IGES AP format postprocessor, be

written on the basis of the ICC syntax and semantics defined in the documentation

above.

The first circle in Figure 2 represents the "generic" IGES preprocessor for System A

that translates CAD information from the CAD database format for System A to the

IGES representation format. Ageneric IGES translator is an application independent

IGES translator. In general, a generic IGES preprocessor and a generic IGES

postprocessor for a certain CAD system can be used to implement different application protocols.

The generic translator implements a single mapping association between an entity in

the CAD database format and an entity(s) in the IGES format, or vice versa. The single

mapping association is based only on the similarity of the CAD database structure and

the IGES data structures. Because the IGES format does not have well-defined

semantics, the mapping results in a dispersion of the information in the IGES representation.

The second circle in Figure 2 represents the IGES AP format preprocessor that translates CAD information from the IGES representation format for System A to the IGES

AP format. This software unit must be written on the basis of the ICC syntax and semantics contained in the "CAD Standards and Practices for System A" the ICC syntax contained in the IGES specification and the ICC syntax and semantics contained in the AP

format specification and the AP information model. The ICC syntax and semantics

specified by these documents plus the mappings documented for the generic IGES

preprocessor provides the basis for a document called "The Mapping of CAD Information from the IGES Format to the Application Protocol Format for System A." The

IGES AP format preprocessor must implement these mappings to prepare the CAD

information in the AP format.

The third circle in Figure 2 represents the IGES AP format postprocessor that translates CAD information from the IGES AP format to the IGES representation format

for System B. This software unit must be written on the basis of the ICC syntax and

semantics contained in the CAD Standards and Practices for System B, the ICC syntax

contained in the "Initial Graphics Exchange Specification", and the ICC syntax and

semantics contained in the AP format specification and the AP information model.

The ICC syntax and semantics specified by these documents plus the mappings for the

generic IGES postprocessor for System B provides the basis for a document called "The

Mapping of CAD Information from the Application Protocol Format to the IGES Format for System B." The IGES AP format postprocessor must implement these mappings to read the CAD information from the AP format.

23
The fourth circle in Figure 2 represents the generic IGES postprocessor for System B

that translates CAD information from the IGES representation format to the CAD

database format for System B. The generic IGES postprocessor is supplied by the vendor of System B and is based only on the capabilities of the CAD system and the system structure. The result of this is that the syntax for the "mapping" of information from

the IGES representation format to the CAD database format for System B is based on

only the syntax of the CAD database format for System B and the IGES representation

format.

Figure 3 illustrates the second application protocol process structure. This AP process

structure is a "direct" process for translating CAD information from the CAD database

format of System A into an IGES AP format, and then from the IGES AP format into

the CAD database format of System B. Figure 3 illustrates the long-term objective of

AP methodology.

Figure 3 shows three rectangles that represent the formats used in transforming CAD

information directly from the System A database format through the IGES AP format

to the System B database format. ICC must be imposed here by specifying the syntax

and semantics to be used in the creation and translation of CAD information between

these formats. Again, for use in SCC, the ICC syntax and semantics documentation

must have a version number and a date of release.

The first rectangle in Figure 3 represents the creation of CAD information in System

A. As shown in Figure 3, the ICC syntax and semantics for this format step are based

explicitly on the AP information model. Therefore, the creation of the CAD information in System A is based on embedding each

item of information from the AP information model into the CAD database format of

System A. The ICC syntax and semantics for this format step could be contained in a

document called "CAD Standards and Practices for an Application Protocol for System A" and must define:

syntax - the choice of the format and structure for creating and manipulating

each item of CAD information for the AP using the user interface available on

System A.

semantics - what each item of CAD information in the CAD database format of

System A means according to the AP information model.

The second rectangle in Figure 3 represents the CAD information from System A in

the IGES AP format. The purpose of this format step is to prepare the CAD information in an application specific format that is independent of any individual CAD system. The ICC syntax for this format step must be contained in the AP format specification.

24
LU

CZ

H

o

ZD

CZ

h~

CO

CO

CO

IdOO

CZ

CL

I o

o

oI

o

cz

CL

25

BASED

ON

APPLICATION

PROTOCOL

FORMAT

TRANSLATORS
The ICC semantics for this format step must be contained in the AP information model.

The ICC syntax and semantics must define:

syntax - the choice of the format and structure for representing each item of

CAD information for the AP in the AP format.

semantics - what each item of CAD information in the AP format means according to the AP information model.

The third rectangle in Figure 3 represents the translated CAD information in System

B. As shown in Figure 3, the ICC syntax and semantics for this format step are based

explicitly on the AP information model. Therefore, the translation of the CAD information into System B is based on embedding each item of information from the AP information model into the CAD database format of System B. The ICC syntax and

semantics for this format step could be contained in a document called "CAD Standards and Practices for an Application Protocol for System B" and must define:

syntax - the choice of the format and structure for creating and manipulating

each item of CAD information for the AP using the user interface available on

System B.

semantics - what each item of CAD information in the CAD database format of

System B means according to the AP information model.

The two circles in Figure 3 represent the software units that translate CAD information directly from the CAD database format for System A through the IGES AP format to the CAD database format of System B. The first circle in Figure 3 represents

the IGES AP format preprocessor for System A that translates CAD information from

the System A format directly to the IGES AP format. This software unit must be written on the basis of the ICC syntax and semantics contained in the CAD Standards and

Practices for the AP for System A and the ICC syntax and semantics contained in the

AP format specification and the AP information model. The ICC syntax and semantics specified by these documents provides the basis for a document called "The Mapping of CAD Information to an Application Protocol Format for System A."

The second circle in Figure 3 represents the IGES AP format postprocessor for System B that translates CAD information from the IGES AP format directly to the

database format for System B. This software unit must be written on the basis of the

ICC syntax and semantics contained in the CAD Standards and Practices for an AP for

System B, and the ICC syntax and semantics contained in the AP format specification

and the AP information model. The ICC syntax and semantics specified by these documents provides the basis for a document called "The Mapping of CAD Information

from an Application Protocol Format for System B."

Figure 2 and Figure 3 describe AP processes that are based on the use of "generic" IGES

26
translators and special AP format translators, respectively. Neither Figure 2 or Figure

3 is intended to imply that a computer-understandable reversible mapping exists between the information in the AP information model and the information contained in

the AP format IGES file.

A crucial point of both figures is that there must exist a human-understandable reversible mapping between the information requirements in the AP information model and

the system entities needed to carry the information in System A. When obtained, this

mapping can be used by a human to develop usage conventions for creating AP information in System A. There must also exist a second human-understandable reversible

mapping between the system entities in System A and the IGES entities in the AP format. In addition, since both mappings are reversible, the mappings can be used by a human to prepare computer software to automatically perform the reverse mapping

between the IGES entities in the AP format and System A entities or system entities

in a dissimilar System B.

The existence of both mappings is critical to accomplishing the successful exchange of

the information in the AP information model between System A and System B. With

the first mapping established, the second mapping, between the System A entities and

the IGES entities in the AP format, can be developed. With human-developed usage

conventions for System A, a human can prepare computer software to automatically

perform the mapping.

4.1 Example of an Application Protocol Process

Currently, it is not possible to implement an application protocol process based on the

structure of Figure 3. This is because no approved IGES APs exist, and because no

APs have been implemented by vendors of CAD systems. Therefore, AP processes

must currently be developed and implemented by users, and these processes must be

based on the structure of Figure 2.

Consider an example of a user developed AP process, shown in Figure 4, and based on

the structure shown in Figure 2. The AP described in this example is partially complete, as per the technical content requirements of Section 3.1. This example does not

have a complete AP information model with all of the required supporting documentation. It does include an AP format specification, which consists of the IGES entity

set, the restrictions on the global, directory entry, and parameter data section field

values, and a partial usage guide for the IGES entities.

27
28

APPLICATION

PROTOCOL

PROCESS

DEVELOPED

BY

DOE/NWC
The example is of an AP format called the "Department of Energy Data Exchange Format, Mechanical Products/Drafting."

1 Specifically, this is an example of a partially complete AP for mechanical part/product drawings. In terms of Figure 2, the AP format

will be called the Department of Energy Data Exchange Format, Mechanical

Products/Drafting.

This example is based on one of the CAD systems currently in use at Sandia National

Laboratories, Albuquerque, New Mexico, the Applicon AGS/880 IMAGE CAD system. For simplicity, this example will discuss the AP process with the notion of "looping" the CAD information out of and back into the AGS/880 system. Therefore, in

terms of Figure 2, System A and System B will both be the AGS/880 system.

The first rectangle in Figure 4 represents the creation of mechanical part/product drawing information in the AGS/880 system. The purpose of this format step is to create

the information using a well-defined set of capabilities available on the AGS/880 system. The creation is done such that the constructs in the AGS/880 database conform

to the ICC specifications. The ICC syntax and semantics for this format step are contained in a document called "General CAD Practices and File Standards" [4], for the

AGS/880 system. This documentation defines:

syntax - the choice of the format and structure for creating and manipulating

each item of mechanical part/product drawing information using the user interface available on the AGS/880 system.

semantics - what each item of mechanical part/product drawing information that

is to be created and manipulated means for the mechanical part/product drawing application.

The second rectangle in Figure 4 represents the mechanical part/product drawing information in the IGES format for the AGS/880 system. The purpose of this format step

is to represent the information in a nonproprietary format for subsequent manipulation as required. The IGES format does not have well-defined semantics for the information.

The syntax for this format step was derived from analysis of the information as it was

1 Certain commercial equipment, software, or materials are identified in this

document in order to adequately specify existing CAD software and data

exchange mechanisms. Such identification does not imply endorsement by the

National Institute of Standards and Technology or the IGES/PDES

Organization, nor does it imply that the software or equipment are necessarily

the best available for the purpose.

29
represented in the IGES format. The ICC syntax for this format step is based on a document called "The Initial Graphics Exchange Specification."^] The ICC syntax and

semantics for this format step are contained in a document called "Requirements for

the Applicon AGS/880 IMAGE CAD System Deflavor Translator."[6] The ICC syntax and semantics for this format step define:

syntax - the choice of the format and structure for representing each item of

mechanical part/product drawing information for the AGS/880 system in the

IGES format. This syntax is a function of the variables: the mechanical

part/product drawing application, the structure of the AGS/880 system, and the

AGS/880 IGES preprocessor.

semantics - what each item of mechanical part/product drawing information that

is to be created and manipulated means for the mechanical part/product drawing application. The semantics cannot be determined by the types of the resulting IGES entities. This is because each item of information is dispersed when

it is translated by the AGS/880 IGES preprocessor, due to the variables as- sociated with the ICC syntax.

The third rectangle in Figure 4 represents the mechanical part/product drawing information in the Department of Energy Data Exchange Format, Mechanical

Products/Drafting. The purpose of this format step is to prepare the information in an

application specific format that is independent of any individual CAD system. The ICC

syntax for this format step is contained in the Department of Energy Data Exchange

Format. The partial semantics, i.e., the partial mechanical part/product drawing information model, for this format step are also contained in the Department of Energy

Data Exchange Format. The ICC syntax and semantics for this format step currently

define:

syntax - the choice of the format and structure for encoding each item of information from the mechanical part/product drawing information model in the

Department of Energy Data Exchange Format.

semantics - what items of information in the Department of Energy Data Exchange Format mean according to the partial mechanical part/product drawing

information model.

The fourth rectangle in Figure 4 represents the mechanical part/product drawing information in the IGES format. The purpose of this format step is to provide the information in the IGES format as required by the AGS/880 system. Again, the IGES format does not have well-defined semantics for the information. The syntax for the information in this format step was determined by how the AGS/880 IGES postprocessor expects the information to be embedded in IGES entities. For the AGS/880 system, the required syntax for this format step is the same as that of the second rectangle

in Figure 4. The ICC syntax for this format step is based on a document called The Initial Graphics Exchange Specification. The ICC syntax and semantics for this format

30
step are contained in a document called "Requirements for the Applicon AGS/880

IMAGE CAD System Reflavor Translator."[7] The ICC syntax and semantics for this

format step define:

syntax - the choice of the format and structure for representing each item of

mechanical part/product drawing information for the AGS/880 system in the

IGES format. This syntax is a function of the variables: the mechanical

part/product drawing application, the structure of the AGS/880 system, and the

AGS/880 IGES preprocessor.

semantics - what each item of mechanical part/product drawing information that

is to be created and manipulated means for the mechanical part/product drawing application. The semantics cannot be determined by the types of IGES entities required by the AGS/880 IGES postprocessor. This is because each item

of mechanical part/product drawing information must be dispersed when it is translated by the AGS/880 IGES postprocessor, due to the variables associated

with the ICC syntax.

The fifth rectangle in Figure 4 represents the translated mechanical part/product drawing information in the AGS/880 system. The purpose of this format step is to represent the information in the AGS/880 system in the same way as if it were created on

the AGS/880 system. Again, the ICC syntax and semantics for this format step are contained in a document called General CAD Practices and File Standards for the

AGS/880 system. The ICC syntax and semantics for this format step define:

syntax - the choice of the format and structure for creating and manipulating

each item of mechanical part/product drawing information using the user interface available on the AGS/880 system.

semantics - what each item of mechanical part/product drawing information that

is to be created and manipulated means for the mechanical part/product drawing application.

The four circles in Figure 4 represent the software units that must perform the translation of mechanical part/product drawing information. The translation occurs from

the CAD database format for the AGS/880 system through the Department of Energy

Data Exchange Format, to the CAD database format for the AGS/880 system. SCC

has been imposed by requiring that two of these software units, the AGS/880 Deflavor

Translator and the AGS/880 Reflavor Translator, be written on the basis of the ICC

syntax and semantics defined in the documentation above.

The first circle in Figure 4 represents the "generic" IGES preprocessor for the AGS/880

system. This software unit translates the mechanical part/product drawing information

from the AGS/880 system into the IGES format. The IGES preprocessor was originally supplied by Applicon-Schlumberger, the vendor of AGS/880 system. The software

unit is based only on the capabilities of the AGS/880 system and the system structure.

31
This IGES preprocessor was partially rewritten at Sandia using the originally supplied

software as a basis.

The syntax for the "mapping" of information from the AGS/880 system into the IGES

format is based on the syntax of the AGS/880 database format and the IGES format.

The analysis of how the information is translated and dispersed into the IGES entities

provided the basis for documenting the mappings for this software. Many of these mappings are contained in a document called Requirements for the Applicon AGS/880

IMAGE CAD System Deflavor Translator.

The second circle in Figure 4 represents the AGS/880 Deflavor Translator. This

software unit translates mechanical part/product drawing information from the IGES

format to the Department of Energy Data Exchange Format. This software unit was

written using the knowledge of the ICC syntax and semantics contained in several documents: (a) the General CAD Practices and File Standards document for the AGS/880

system, (b) the ICC syntax contained in the Initial Graphics Exchange Specification,

and (c) the ICC syntax and semantics contained in the Department of Energy Data Exchange Format.

The ICC syntax and semantics specified by these documents, plus the mappings documented for the IGES preprocessor in Requirements for the Applicon AGS/880

IMAGE CAD System Deflavor Translator, provided the knowledge to document the

necessary mappings from the IGES Format to the Department of Energy Data Exchange Format. The mappings are included in Requirements for the Applicon

AGS/880 IMAGE CAD System Deflavor Translator. The AGS/880 Deflavor Translator implements these mappings to prepare the mechanical part/product drawing information as defined in the Department of Energy Data Exchange Format.

The third circle in Figure 4 represents the AGS/880 Reflavor Translator. This software

unit translates mechanical part/product drawing information from the Department of

Energy Data Exchange Format to the IGES format. This software unit was written

using the knowledge of the ICC syntax and semantics contained in several documents:

(a) the General CAD Practices and File Standards for the AGS/880 system, (b) the ICC

syntax contained in the Initial Graphics Exchange Specification, and (c) the ICC syntax and semantics contained in the Department of Energy Data Exchange Format.

The ICC syntax and semantics specified by these documents, plus the mappings documented for the IGES postprocessor in Requirements for the AGS/880 IMAGE CAD

System Reflavor Translator, provided the knowledge to document the necessary mappings from the Department of Energy Data Exchange Format to the IGES Format.

The mappings are included in Requirements for the Applicon AGS/880 IMAGE CAD

System Reflavor Translator. The AGS/880 Reflavor Translator implements these

mappings to read the mechanical part/product drawing information from the Department of Energy Data Exchange Format.

32
The fourth circle in Figure 4 represents the "generic" IGES postprocessor for the

AGS/880 system. This software unit translates the mechanical part/product drawing

information from the IGES format to the CAD database format of the AGS/880 system. The IGES postprocessor was originally supplied by Appiicon-Schlumberger, Inc.,

the vendor of the AGS/880 system. The software unit is based only on the capabilities

of the system and the system structure. This IGES postprocessor was partially rewritten using the original software as a basis.

The syntax for the "mapping" of information from the IGES format to the CAD

database format of the AGS/880 system is based on the syntax of the CAD database

format for the AGS/880 system and the IGES format. The mappings implemented in

this software unit are based on reversing the mappings implemented by the IGES

preprocessor. Therefore, the structure of the mechanical part/product drawing information must be identical to the structure that resulted from the work of the IGES

preprocessor. The knowledge of the necessary CAD information structure for the IGES

postprocessor makes it possible to document the necessary mappings for the AGS/880

Reflavor Translator.

After considering the single example above, it is clear that a comprehensive approach

for ICC and SCC is necessary to successfully implement an AP process.

Currently, users have only one option for the implementation of an AP process, the

structure shown in Figure 2. To successfully implement an AP process based on the

structure shown in Figure 2, the user must first become familiar with the CAD system

and the vendor supplied IGES translators. This knowledge is necessary to develop the

ICC documentation for information creation and translation. The user must then

prepare the AP format translators based on the ICC documentation.

Presently, users must do the entire job of developing and implementing AP processes.

When approved IGES APs exist, options will also exist for the development of AP

processes using vendor supplied AP format translators.

For example, if an approved, "standardized" IGES AP did exist, a contractor or vendor

could complete the implementation work. Specifically, a CAD system vendor could be

contracted by a user to develop both the ICC documentation and the AP format translators. This would allow users to purchase a "ready made" AP process based on the

structure in Figure 3.

Finally, for any AP process, either user developed or purchased, users must become

familiar with their ICC documentation for information creation, manipulation, and

translation. A successful AP process will always require that users implement and follow ICC policies and procedures.

33
4.2 Example of a Simple Application Protocol

This section provides an introduction to an example AP for Feature Control Frames.

This example will look at one small portion of the domain that a complete AP for the

drafting application would encompass.

The mission of the drafting application is to prepare detailed renderings of the necessary information about a product (part, assembly, or sub-assembly) so that it can be

used to analyze or manufacture the product. The first step in accomplishing this mission is to accept the geometry, features, dimensions, tolerances, and other necessary

information as input from designers, engineers, etc., and to determine the best way to

present the information on a traditional paper drawing sheet. The second step in accomplishing this mission is to actually prepare the rendering, subject to procedures,

standards, and rules that are intended to make the resulting drawings more consistent

and easier to understand.

In the drafting application, a Feature Control Frame is a means of conveying the

geometric tolerance information for an individual feature on a drawing. The Feature

Control Frame is one aspect of the rendering of dimensions and tolerances that has

been standardized to make drawings more consistent. The rendering of a Feature Control Frame includes the use of graphics, numerals, text, and symbols to represent the

information about a geometric tolerance.[8] A typical Feature Control Frame is illustrated in Figure 5.

<> 0 .005® A B® C®

FEATURE CONTROL FRAME

Figure 5

34
This example contains the required technical content for an AP as described in Section

3.1. As per Section 3.1, the required technical content consists of an Application

Protocol Information Model (APIM) with its supporting documentation, an application protocol format specification (APFS), and a set of application protocol format test cases.

The Application Protocol Information Model for Feature Control Frames is given in

Appendix B.l and consists of three models, the Application Reference Model (ARM),

the Application Implementation Model (AIM), and the Application IGES Implementation Model (AIIM). The supporting documentation for the APIM is also given in

Appendix B.l and consists of the NLAM object definitions and the business rules for

the APIM.

The NLAM model constraints are given on the graphical NIAM diagrams of Figures

B1-B4. In general, the business rules give an explanation of the context of the APIM.

For the Feature Control Frame, the basis of the APIM is the American National Standards Institute’s Y14.5M (1982) Standard for Dimensioning and Tolerancing. No

acronyms and abbreviations were used in the APIM. No assumptions were made that

affect the structure or information content of the APIM.

See Appendix B for the complete Feature Control Frame example.

In summary, in a complete AP for the drafting application, this example would be only

one small portion. Other portions would be included to handle other information such

as dimensions and manufacturing information. This example is intended to illustrate

how each small portion of an application domain can be addressed individually, and

that, when taken together, all of the small portions can be used to build the complete

AP.

4.3 User, Implementor, and Purchaser Views of Application

Protocols

Section 2.2 provided a discussion about the creation, exchange, and archival storage of

product definition data (PDD) in the form of digital data sets. That discussion ex- amined these aspects of digital PDD from three perspectives: the User, Implementor,

and Purchaser perspectives.

This section will examine the same three perspectives of the use of IGES APs for

producing and reading digital PDD. Additionally, this section will present some conclusions about the requirements for implementing APs in software systems and for

producing and reading digital PDD using AP-based processes.

The User perspective of APs is the viewpoint held by an end-user who is interested in

35
building an AP process to produce and read digital PDD. As stated in Section 2.2, each

end-user has requirements for the structure and content of digital PDD, and these re- quirements are a function of the User’s discipline and application area. The User’s objective is to build an AP process to produce and read AP formatted data that describes

the product for a certain discipline.

The Implementor perspective is the viewpoint held by an individual that develops systems and software for Users that must develop AP processes. For APs, the objective

of the Implementor is to provide software systems that support the AP information

model and AP format translators that will allow the User to implement an AP process.

The Implementor will provide the initial verification of the software components for

the AP processes.

The Implementor’s main requirement for developing AP systems and software is to

have a well-defined and stable set of implementation specifications. These implementation requirements are given by the AP information model and the AP format

specification. It will be much easier to develop quality systems and software to support

the AP if these requirements are stable. The Implementor cannot guarantee the

capability of the software if the support of an AP requires an open-ended development

process.

With the AP software, the Implementor will provide to the User instructions for preparing digital PDD in AP processes. The Implementor-supplied instructions must be

validated in conjunction with the systems and software for use in AP processes.

The Purchaser perspective is the viewpoint held by an individual or organization that

must purchase digital PDD along with the products themselves. These data sets will

have been produced by User developed AP processes consisting of systems and

software developed by Implementors. The Purchaser’s primary requirement is that the

data sets meet the specifications of the validated APs.

The Purchaser will be dependent on the correctness of the AP itself, the Users’ implementation of the AP process that produced the data, and the Implementors’ systems

and software that were used as part of the Users’ AP process. The Purchaser will re- quire that User implementations of AP processes be validated before the Purchaser

agrees to purchase the User’s data. In addition, the Purchaser may require that User

produced data sets be placed in long-term archival storage for future retrieval and use

with User developed AP processes. The Purchaser will be dependent on the validation of the AP, of the Implementors support of the AP, and of the User’s AP process.

In summary, the User, Implementor, and Purchaser have different views of APs for use

in producing and reading digital PDD. The User must be able to build AP processes

for producing and reading digital PDD. The User must depend on Implementor

developed systems, software, and documentation to build the AP processes. The Implementor must develop systems, software, and documentation to support validated

36
APs that allow the User to build AP processes. The Implementor, in order to assist the

User in building AP processes, must develop the systems, software, and documentation according to stable APs. The Purchaser must be able to acquire digital PDD in

AP formats, produced by Users with AP processes that include Implementor developed

systems, software, and documentation. The Purchaser will depend on both Users and

Implementors for acquiring complete and correct AP formatted data sets.

Finally, it must be understood that the specification, validation, and implementation of

IGES APs will in many cases require that organizations revise their policies and procedures for the creation, exchange, and archival storage of product data.

37
5. References

[1] "Software Engineering Standards: ANSI/IEEE Std 729-1983, Glossary of

Software Engineering Terminology," The Institute of Electrical and

Electronics Engineers, Inc.; 1984.

[2] Smith, B.; Rinaudot, G.; Wright, T.; Reed, K.; "Initial Graphics Exchange

Specification (IGES), Version 4.0," National Bureau of Standards (U.S.)

NBSIR 88-3813; June 1988.

[3] "Department of Energy Data Exchange Format, Mechanical Products/Drafting, Version 1.2.2," Sandia National Laboratories; September 1987.

[4] "General CAD Practices and File Standards," Sandia National Laboratories;

January 1986.

[5] Smith, B.; Wellington, J.; "Initial Graphics Exchange Specification (IGES),

Version 3.0," National Bureau of Standards (U.S.) NBSIR 86-3359; April 1986.

[6] Harrison, R.; "Detailed Requirements for the Applicon AGS/880 IMAGE

CAD System Deflavor Translator," Sandia National Laboratories; August 1987.

[ 7] Harrison, R.; "Detailed Requirements for the Applicon AGS/880 IMAGE

CAD System Reflavor Translator," Sandia National Laboratories; August 1987.

[8] "American National Standard, Engineering Drawings and Related Documentation Practices, Dimensioning and Tolerancing, ANSI Y14.5M - 1982," The

American Society of Mechanical Engineers; December 1982.

[9] "Guide to Developing Entity Test Cases, Draft Version 0.2," IGES Test Case

Development Committee; November 10, 1987.

38
Appendix A. Glossary

Application - A specific function or work area such as Design, Drafting, Analysis, Testing, or Manufacturing that contributes to realization of the product definition data

and/or finished product deliverables for one or more disciplines; also, any one of a group of activities that is a part of Design, Drafting, Analysis, Testing, or Manufacturing such as Geometric Modeling, Finite Element Analysis, Dynamic Response of Articulated Machinery, or Numerical Control Machining. The nature of an application

may differ depending on several factors, one of which is the discipline(s) that it must

support.

Application Area - See Application

Application-based view - A means of interpreting product definition data that is based

on an information model for a specific application. In application protocols, the application protocol information model provides this means by facilitating the interpretation of product definition data using the application area’s terminology and rules. This

term does not include or require a completely computer-understandable representation of the application protocol information model.

Application Implementation Model (AIM) - An information model that is directed

towards an implementation of information structures for a particular application area. The information model is based on an application reference model and uses application specific terminology and rules. The information model also contains implementation-based detail that is necessary to specify the items of information that must be

identifiable in an application protocol format.

Application IGES Implementation Model (AIIM) - An information model that

describes the information structures required to accomplish an implementation using

IGES entities. The information model is based on an application implementation

model and is prepared at a level of abstraction that is appropriate to select the necessary IGES entities for an application protocol format.

Application Protocol (AP) - A method to achieve consistent and reliable exchange of

product definition data within a specified application area. The key components of an

application protocol are a conceptual information model for the application area with

its supporting documentation, an application protocol format specification, and a set

of application protocol format test cases.

Application Protocol Format (APF) - An application specific format that is based on

the embedding of items of information from a conceptual information model into IGES

entities.

A - 1
Application Protocol Format Specification (APFS) - A specification that provides a

complete, rigorously defined, and unambiguous means to represent the information

that is required for a specific application area; consists of an application subset, the

restrictions on the global, directory entry, and parameter data sections, and a usage

guide for the application subset.

Application Protocol Format Translator - An application specific translator that is

based on the imbedding of CAD information from the application protocol information model into the CAD database format and the IGES entities in an application

protocol format. The translator implements a single mapping association between a

certain entity in the CAD database format and a certain IGES entity (APF preprocessor), or between a certain IGES entity and a certain entity in the CAD database format (APF postprocessor) to satisfy the needs of one application protocol and its as- sociated application protocol format.

Application Protocol Information Model (APIM) - A set of information models that

are developed for an application protocol. The information models are an application

reference model, an application implementation model, and an application IGES implementation model.

Application Protocol Usage Guide - A set of instructions describing how the IGES entities from the application subset are to be used to carry the information described in

the conceptual information model. The usage guide is one required component of the

Application Protocol Format Specification.

Application Protocol Validation - The evaluation of a candidate application protocol,

including the constituent components (refer to Application Protocol) to confirm its

suitability. The goal of the evaluation is to ensure that all of the necessary information

requirements are supported by the candidate application protocol. See Validation.

Application Reference Model (ARM) - An information model that describes the information requirements and the information structure for an application area. The information model uses application specific terminology and rules familiar to an expert from

the application area. The model is independent of any physical implementation and

can be validated by an expert from the application area. See Validation.

Application Subset - An unambiguous set of IGES entities which span the data requirements of the specified application. The set of IGES entities is determined on the basis

of the Application Protocol Information Model (APIM). The documentation for an

Application Subset is required as part of the Application Protocol Format Specification (APFS).

A - 2
Application Validation Methodology (AVM) Committee - A technical committee of

the IGES/PDES Organization which is developing guidelines and methods to achieve

consistent and reliable exchanges of product definition data within a specified application area. This committee is also developing the methodology to validate candidate

implementations of these product definition data exchange methods.

Application Validation - The systematic investigation of a system or software capability

to determine whether it fulfills the requirements of a specific application area.

Application Validation Testing - See Application Validation

Computer-Aided Design (CAD) System - A unified collection of computer hardware

and software whose purpose is to facilitate the creation, storage, distribution, and use

of product definition data in digital form.

Conceptual Information Model - A description of the information requirements, information structure, and the relationships between the individual items of information

for an application area. Models are usually developed using a formalized, graphical

modeling language, such as NIAM or IDEF1X.

Discipline - An area or field of endeavor such as Mechanical Products, Electrical

Products, or Architecture, Engineering, and Construction, that has as its deliverable

both product definition data and finished products. The structure and content of

product definition data and the configuration of finished products for each discipline

are a function of the discipline itself.

Entity - The basic unit of data in an IGES file. The term applies to single units which

may be individual elements of geometry, individual elements of annotation, or collections of geometry or annotation elements that are combined to form more complex

data structures.

Generic IGES Translator - An application independent IGES translator that implements a set of mappings for CAD information from the CAD database format of a certain CAD system to the IGES format (IGES preprocessor), or from the IGES format

to the CAD database format of a certain CAD system (IGES postprocessor). The translator implements a single mapping association between an entity in the CAD database

format and an entity in the IGES format, or vice versa. The single mapping association

is based on the similarity of CAD database format and IGES format data structures.

IGES Postprocessor - A software unit that translates CAD data from the IGES format

to the CAD database format of a certain CAD system. The software is usually

developed and maintained by a commercial CAD system vendor.

A - 3
IGES Preprocessor - A software unit that translates CAD data from the CAD database

format of a certain CAD system to the IGES format. The software unit is usually

developed and maintained by a commercial CAD system vendor.

IGES Application Protocol Format Test Cases - IGES data files of product definition

data that meet all of the representational requirements of information for the application protocol. The files must be prepared such that they are in compliance with the application protocol format specification.

Information Model - See Conceptual Information Model

Information Configuration Control (ICC) - An approach that consists of specifying,

documenting, and controlling both the creation of information and the subsequent

translation and exchange of the information between different systems and formats.

The approach requires substantial documentation for both the syntax (the format) and

the semantics (the meaning) of the information items at each step in the process.

Product Data - The set of data elements that are necessary to provide full support for

a product and meet all of its in-service needs over its expected life cycle. This set of

data elements includes all of the product definition data plus other data pertaining to

the operation and maintenance of the product until it is removed from service.

Product Definition - See Product Definition Data

Product Definition Data - The set of data elements that completely define a product

for a certain discipline. This set of data elements includes the geometry, topology, features, tolerances, and relationships to completely define a component part or an as- sembly of parts. The data is structured such that it can be used by one or more applications.

Protocol - A set of rules that govern the operation of functional units to achieve communication. (ISO)

Semantics - The meaning that is given or assigned to an item of information. The meaning is assigned to an item of information on the basis its application area.

Syntax - The structure and organization of an item or items of information, as in a format. The format is described in a specification such as IGES.

Software Configuration Control (SCC) - An approach that consists of controlling the

capability and make-up of software systems and individual software units through the

use of requirements. For information creation, translation, and exchange, the software

requirements are prepared from ICC documentation.

A - 4
User Interface - The set of commands, menu choices, utilities, and options that exist to

create and edit information in a CAD system’s database.

Validation - The process of evaluating software at the end of the software development

process to ensure compliance with software requirements. (ANSI/IEEE Std 729-1983)

Validation Criteria - The properties of an application protocol that will be investigated

to determine success or failure in the validation of a candidate application protocol.

See Validation.

Verification - The process of determining whether or not the products of a given phase

of the software development cycle fulfill the requirements established during the previous phase. (ANSI/IEEE Std 729-1983)

A - 5

Appendix B.l

FEATURE CONTROL FRAMES - APPLICATION PROTOCOL INFORMATION MODEL

This Appendix will describe the Application Protocol Information Model

(APIM) for Feature Control Frames. The APIM consists of three information

models, the Application Reference Model (ARM), the Application

Implementation Model (AIM) , and the Application IGES Implementation Model

(AIIM) . These three models describe the information requirements and

logical structure of the information for Feature Control Frames.

The Feature Control Frames ARM represents the Drafting information that is

required for a Feature Control Frame. This ARM is a part of the complete

Drafting APIM. The ARM is a model of Feature Control Frames information

that can be validated by a Drafting application area expert. The ARM is

given in Figure Bl. The supporting documentation for this model is given at

the end of this Appendix.

From Figure Bl , the Feature Control Frame contains the Geometric

Characteristic, the Tolerance Specification, the Maximum Tolerance Value

Specification, and the Datum Reference. Also, the Feature Control Frame

belongs to a Feature Relationship, is represented by a Frame Box, and is

compartmentalized by a Frame Box Divider.

From Figure Bl, the Tolerance Specification contains the Tolerance

Cylindrical Form, the Tolerance Value, the Tolerance Material Condition, the

Tolerance Unit Length, and the Tolerance Unit Width. The Maximum Tolerance

Value Specification contains a Tolerance Cylindrical Form and a Maximum

Tolerance Value. The Datum Reference contains a Datum Identifier and a Datum Material Condition. The Feature Relationship contains a Feature and a Feature Relator. The Feature Relator can be one of four types, a Leader, a Plane Surface Extension, a Dimension of Size, and a Leader Directed Callout.

The Frame Box is defined by four coordinate pairs. The Frame Box Divider is

defined by two coordinate pairs.

The Feature Control Frames ARM of Figure Bl describes the information

requirement and structure for the Feature Control Frame - Feature Relationship

part of Feature Control Frames. For simplicity, this Feature Control Frames

Application Protocol example will not implement this information requirement.

Figure B2 illustrates the initial AIM. The initial AIM was developed on the

basis of the ARM and shows the Drafting information for Feature Control

Frames that must be "identifiable" in the IGES entities in the Drafting APF.

The meaning of "identifiable" in this context is that it must be possible to

have a reversible mapping of Feature Control Frames information from the ARM

into the IGES entities in the APF. The initial AIM provides a description

of the way that the Feature Control Frames information must be structured to

allow an explicit reversible mapping. The initial AIM contains the same

application-based information requirements and structure as the ARM, but

also contains additional implementation-based identifiers for the

information requirements.

B - 1
From Figure B2 , the Feature Control Frame is identified by a Feature Control

Frame Identifier. The Geometric Tolerance is identified by a Geometric

Tolerance Identifier. The Geometric Characteristic is represented by a Geometric Characteristic Symbol. The Tolerance Specification is identified

by a Tolerance Specification Identifier. The Tolerance Cylindrical form is

represented by a Diameter Symbol. The Tolerance Value is represented by a

Tolerance Value String. The Tolerance Material Condition is represented by

a Material Condition Symbol. The Tolerance Unit Length is represented by a

Tolerance Unit Length String. The Tolerance Unit Width is represented by a

Tolerance Unit Width String.

From Figure B2 , the Maximum Tolerance Value Specification is identified by a Maximum Tolerance Specification Identifier. The Maximum Tolerance Value is

represented by a Maximum Tolerance Value String. The Datum Reference is

identified by a Datum Reference Identifier. The Datum Identifier is

represented by a Datum Identifier String. The Datum Material Condition is

represented by a Datum Material Condition Symbol. The Frame BoxCoordinate Pair consists of an X Value and a Y Value. The Frame Box is

identified by a Frame Box Identifier. The Frame Box Divider-Coordinate Pair

consists of an X Value and a Y Value. The Frame Box Divider is identified by

a Frame Box Divider Identifier.

As previously discussed, the initial AIM contains implementation-based

identifiers for the information requirements from the ARM. Several

implementation constraints were used in this Feature Control Frames AP

example. These constraints were imposed to make the specification of the AP

format possible without major revisions and enhancements to the IGES

Specification. These constraints are given below.

Constraint 1 - The Application Protocol Format Specification must use

IGES entities that exist in the current IGES Specification, where

possible. It is permissible to define new IGES entities only where there

is no existing IGES entity that can be used to carry the necessary information.

Constraint 2 - The IGES entities selected for use in the Application

Protocol Format Specification must be selected so as to minimize the size

of AP format files as much as possible. This means that the ''simplest"

IGES entity should be selected when there is more than one possible choice.

Because of the implementation constraints given above, decisions and tradeoffs had to be made about the final IGES entity selections for this Feature

Control Frames example. This decision process resulted in a final AIM that

provides a less explicit "identification" of each item of Feature Control Frames

information in the APF entities. For the implementation described by the

APFS in Appendix B.2, the Tolerance Specification Identifier, the Maximum

Tolerance Specification Identifier, and the Datum Reference Identifier had

to be eliminated to produce the final AIM. The final AIM is illustrated in

Figure B3 . In reality, Figure B3 shows that it will not be possible to have

an explicit reversible mapping of Feature Control Frames information into

and out of the APF. It is possible to accomplish a reverse mapping of the Feature

Control Frames information, but the reverse mapping must be made without the

B - 2
explicit identifiers.

The AIIM is illustrated in Figure B4. The AIIM is a model of the logical

structure of Feature Control Frames information after it has been abstracted

to an appropriate level for use in selecting the necessary IGES entities to

carry the information. This AIIM was developed on the basis of the initial

AIM.

From Figure B4, a Feature Control Frame is a sub -type of Drafting

Annotation. Drafting Annotation must be identified by an Annotation

Identifier. Drafting Annotation must be comprised of two or more Linear

Curves and two or more Drafting Components. The Linear Curve must be

identified by a Component Identifier. The Linear Curve must be one of two

types, a Line or a Copious Linear Curve. The Drafting Component must be

identified by a Component Identifier. The Component must be signified by a Symbol or a String. Figure B4 illustrates the logical structure for the

Drafting Annotation- Feature Control Frame -Geometric Tolerance. This logical

structure will not be implemented in this example.

The AIIM of Figure B4 also illustrates the logical structure for the Feature

Control Frame-Feature Relationship structure from Figure B1 in the Drafting

Annotation-Feature Relationship. This logical structure will not be

implemented in this AP example for Feature Control Frames. As stated above,

this AIIM was developed on the basis of the initial AIM. As discussed

previously, the final AIM was developed on the basis of implementation decisions

and trade-offs that resulted in the elimination of several identifiers. The

"X-Outs" in Figure B4 represent the elimination of logical identifiers in

the AIIM as was done in the final AIM.

The AIIM of Figure B4 was used to select the IGES General Symbol, General

Note, Simple Closed Area, and Line entities for use in carrying the Feature

Control Frames information in the AP format. Appendix B.2, the Application

Protocol Format Specification, will describe the example Application

Protocol Format for Feature Control Frames.

B 3
nr

i-<Q

lU.<S X

rO <

UJ •• h- > 2 £0

0.< < l/l *3 UJ § 0 < s . u.

l/l X l/l cc< 'i

0. *—

UJ

tr 30

.. t- X U

Ul 3 £ < Q.

l/l UJ

h-oz 2>< B - 4
B - 5
X

UJ

(- iu

nn

h-<

crUJo<

u.<8 \

"thO <

UJ •• I- > < UJ o ir

1/1 a< < uiLU 2 2 <m 5ij.

in25 5 u I ^ t o 5 £ Q

Ui 2><

/•vV / uj ^ S i»|

N { r| ! : t} 1 \ > / \ > / B - 6

NIAM Modeling Guide for Information Analysis

fHOLOfl

HW4E

NON-LEXICAL OBJECT TYPE (NOLOT): CLASSES OF NON-LEXICAL

OBJECTS UKE PERSON, TOWN, ETC.

LEXICAL OBJECT TYPE (LOT): CLASSES OF LEXICAL OBJECTS UKE

SURNAME, TOWN-NAME, ETC.

HAS IS OF

4

<D

(A>^ HAS IS OF

HAS IS OF

HAS IS OF

1 1 2

EVERY "A" HAS ONE Sc ONLY ONE "B"

4 3

A "B“ IS OF ZERO, ONE OR MANY "A"

1 1 2

AN "A" MAY HAVE ZERO OR ONE "B"

4 3

A "B" IS OF ZERO, ONE OR MANY "A"

1 2

AN "A" HAS ZERO, ONE OR MANY "B"

3 2

A "B" IS OF ZERO, ONE OR MANY "A"

1 1 2

EVERY "A" HAS ONE OR MANY ,, B

U

3 2

A "B" IS OF ZERO, ONE OR MANY “A"

1 2

AN "A" HAS ZERO OR ONE "B"

4 3

A "B" IS OF ZERO OR ONE "A"

1 1 2

EVERY "A" HAS ONE & ONLY ONE MB"

4 3

A "B" IS OF ZERO OR ONE "A"

1 1 2

EVERY "A" HAS ONE Sc ONLY ONE “B"

4 4 3

EVERY U B" IS OF ONE Sc ONLY ONE "AM

1 1 2

AN "A" MAY HAVE ZERO OR ONE "B"

4 3

A "B" IS OF ONE OR MANY “A"
THERE IS AN ENTITY KNOWN AS “A".

"A" IS AN OBJECT OR A CONCEPT.

BRIDGE WHICH RELATES A NONLEXICAL OBJECT

TO A LEXICAL OBJECT THROUGH ROLES R1 3c R2.

THERE IS AN ENTITY KNOWN AS "B".

"B" IS A LEXICAL REPRESENTATION OF "A".

IDEA WHICH RELATES TWO NONLEXICAL OBJECTS

THROUGH ROLES R1 AND R2.

7"^ THE OBJECT "A" OCCURS ELSEWHERE

ON THIS OR ANOTHER NIAM DIAGRAM.

"B" IS A SUBSET OF "A".

TOTAL CONSTRAINT.

ALL OF THE MEMBERS OF "A" ARE

CONTAINED IN SUBSETS "B", "C"

AND "D". THERE ARE NO OTHER

SUBSETS OF "A".

B-9
EXCLUSION CONSTRAINT.

"B", "C" AND "DM ARE DISJOINT

SUBSETS OF “A".

“ONE AND ONLY ONE1

* CONSTRAINT.

"B'\ "C" AND "D" ARE DISJOINT

SUBSETS OF "A" AND THERE ARE

NO OTHER SUBSETS OF "A".

UNIQUENESS CONSTRAINT.

ENTITIES "B" AND "C" ARE

BOTH REQUIRED TO UNIQUELY

IDENTIFY "A11.

EQUALITY CONSTRAINT.

ALL MEMBERS OF "A" THAT ARE

RELATED TO "8“ THROUGH ROLE R1

ALSO ARE RELATED TO "C" THROUGH

ROLE R2.

EXCLUSION CONSTRAINT.

ANY “A" THAT IS RELATED TO "B"

THROUGH ROLE R1 CANNOT BE

RELATED TO MC" THROUGH ROLE R2

AND VICE VERSA.

B— 1 0
Application Protocol Information Model Supporting Documentation

I. Application Reference Model (ARM) Object Definitions

Datum - the origin of the dimensional relationship between a toleranced

feature and a designated feature on a part.

Datum Identifier - indicates a specified Datum; indicated by an alphabetic

letter, such as A, B, etc.

Datum Material Condition - the relative limit of size condition of the

designated feature that is to be used as the datum in the dimensional relationship.

Feature Control Frame - the means used in Drafting to specify a geometric

tolerance that consists of geometric characteristic symbols, a tolerance

value, and datum reference letters; where appropriate, other conditions on

the tolerance are expressed, such as material conditions, a maximum

tolerance value, and a maximum unit length or unit width.

Frame Box - the combined horizontal and vertical lines that make up the

perimeter of the complete Feature Control Frame.

Frame Box Divider - the vertical lines that divide the Feature Control Frame

into compartments

.

Geometric Characteristic - the aspect of the part feature that the tolerance

is directed to, such as straightness, flatness, circularity, etc., for form

tolerances, or position for positional tolerances.

Maximum Tolerance Value - the explicitly specified numerical value of the

maximum deviation from the specified ideal value.

Maximum Tolerance Value Specification - the explicit enumeration of the

maximum deviation, consisting of a Tolerance Cylindrical Form specifier and

a Maximum Tolerance Value.

Tolerance Cylindrical Form - precedes the tolerance value in a Feature

Control Frame and specifies that the tolerance gives the limit on the

deviation of the Geometric Characteristic relative to a cylindrical

tolerance zone.

Tolerance Value - the numerical value of the maximum allowed deviation from

the specified ideal value.

Tolerance Material Condition - the relative limit of size condition of the

feature for which the Tolerance Value is to be applied.

Tolerance Unit Length - the numerical value of the length-wise limit on the

part for which the Tolerance Value gives the maximum allowed deviation of

the Geometric Characteristic.

B - 11
Tolerance Unit Width - the numerical value of the width-wise limit on the

part for which the Tolerance Value gives the maximum allowed deviation of

the Geometric Characteristic; when combined with or multiplied by the

Tolerance Unit Length, it gives the size of the unit area for the

application of the Tolerance Value.

Tolerance Specification - the enumeration of the required tolerance,

consisting of at least the Tolerance Value; may also consist of the

Tolerance Cylindrical Form, the Tolerance Material Condition, the Tolerance

Unit Length, and the Tolerance Unit Width.

II. Application Reference Model (ARM) Business Rules

1. The structure, information requirements, and drafting representation for

a Feature Control Frame are given in the ANSI Standard for Dimensioning and

Tolerancing , ANSI Y14.5M, 1982. [6]

B - 12
Appendix B.2

FEATURE CONTROL FRAME - APPLICATION PROTOCOL FORMAT SPECIFICATION

This Appendix consists of a sample Drafting Application Protocol Format

Specification (APFS) for Feature Control Frames. This APFS example consists

of the required technical content for an APFS, including the Application

Protocol Format (APF) . This example for Feature Control Frames gives the

IGES entities, the restrictions on the use of the IGES entities, and the

usage guide for the IGES entities in carrying information for Feature Control

Frames

.

In a complete APFS, this section would be only a part of the total APFS that

would be required to give the complete IGES entity set for the AP , the

restrictions on the Global, Directory Entry, and Parameter Data sections for

the AP , and the usage guide for carrying all of the Drafting information

from the Application Protocol Information Model (APIM) . The AP Information

Model consists of three information models, the Application Reference Model

(ARM) , the Application Implementation Model (AIM) , and the Application IGES

Implementation Model (AIIM) . These three information models are required to

completely describe Feature Control Frames for the purpose of developing an

APFS

.

For maximum utility as an example of an APFS, this APFS will include an

example of the Global section restrictions that would normally be included

in a complete Drafting APFS. The Global section restrictions in this

example are not based on the Feature Control Frames APIM.

I. IGES Entity Set

The IGES entities that are to be used to carry Drafting information for

Feature Control Frames are given below. These entities are described in the

Initial Graphics Exchange Specification, Version 3.0. [3] These IGES

entities were selected on the basis of the final Application Implementation

Model (AIM) and the Application IGES Implementation Model (AIIM) from

Appendix B.l.

228 - General Symbol

212 - General Note

106 - Simple Closed Area

110 - Line

The General Symbol entity was selected as the "associativity" or "grouping"

entity for the Feature Control Frame because it supports the inclusion of a single General Note, one or more geometric entities, and zero, one or more

Leaders. These are the basic requirements that are given by the APIM for

Feature Control Frames.

The APIM also gives basic requirements that control the selection of the

B - 13
individual entities. The APIM requires the use of multiple text strings in

a single text entity, which the General Note entity supports with no problem.

The APIM also requires the use of four grouped straight line segments for

the frame box. This requirement can be met by the Simple Closed Area

entity. The APIM requires a variable number of individual straight line

segments for the variable number frame box dividers . This requirement can

be met easily through the use of Line entities.

II. Global, Directory Entry, and Parameter Data Section Restrictions

This section gives the restrictions on the Global, Directory Entry, and

Parameter Data section restrictions for each entity in the IGES entity set.

These restrictions were specified on the basis of the final AIM and the AIIM

from Appendix B.l.

The Global, Directory Entry, and Parameter Data section restrictions will be

given separate from the usage guide because the purpose of the restrictions

is different from that of the usage guide. The purpose of the restrictions

is to reduce the possible field and parameter values of the "general" IGES

entities to what is necessary for the APF, In this example for Feature

Control Frames, the restrictions are based on supporting only the needs of

carrying Feature Control Frame information. The restrictions are based

either explicitly or implicitly on the final AIM and the AIIM from Appendix

B.l. In contrast, the usage guide for the IGES entities is based explicitly

on the structure and meaning expressed in the ARM, the final AIM, and the

AIIM and specifies how the Feature Control Frame information is to be

carried in the IGES entities.

In a complete APFS , as in this example, the restrictions would be based

either explicitly or implicitly on the complete APIM so that the needs of

the APIM would be supported and no ambiguities would result. As in this

example, the restrictions would be specified for each of the entities in the

IGES entity set.

II.Global Section

This section gives the Global section restrictions for the APF. As stated

above, the Global section restrictions are only an example of the Global

section restrictions that would normally be included in a complete Drafting

APFS. These restrictions should not be taken as a specification of the

correct restrictions for a Drafting APFS. The Global section restrictions

given in this example are not based on the Feature Control Frames APIM.

B - 14
Global Section Field

Parameter Delimiter

Record Delimiter

Product ID From Sender

File Name

System ID

IGES Preprocessor Version

Number of Bits for Integer

Single Precision Magnitude

Single Precision Significance

Double Precision Magnitude

Double Precision Significance

Product ID for the Receiver

Model Space Scale

Unit Flag

Units

Maximum Number of Lineweights

Maximum Line Thickness

Date and Time of Creation

Minimum Resolution

Maximum Coordinate Value

Name of Author

Organization

Version Number

Drafting Standard Code

The Product ID From Sender, field 3, and the Product ID for the Receiver,

field 12, must contain the Part Number. Field 3 and Field 12 must always be

given values. Field 3 and Field 12 must be equal. The Part Number is

defined to be an alpha-numeric string which gives the number that uniquely

identifies the part contained in the Drafting APF file.

Examples : 10H0123456789 10H9999999999

The File Name, field 4, must contain the name of the file as it existed on

the originating system using the appropriate naming conventions of the

originating system. The naming conventions of the originating system may or

may not include disk identifiers, node names, directory names, etc.

Therefore, no limit is placed on the length of the alpha-numeric string used

to carry the name of the file. This field must always be given a value.

Examples : 43HDUA0 : [ CAD . DRAFTING . APF_FILES ] SPACER_ROD . DRW

12HTESTFILE.DAT

6HN002SA

20HSAMPLE XBPART21 Al

51H ' CADFILE . TEST . THIS . IS . A . FAIRLY . LONG . NAME (TESTPART)

The Global section fields that have Field Value Requirements consisting of

"As Per IGES, non-null" require that the field always contain a valid value

as described by the IGES specification. This means that the syntax and

semantics defined by the IGES specification must be used to prepare the required

Field Value Requirement

non

non

non

non

non

non

non

see

1H,

1H;

Part Number,

See below

As Per IGES

,

As Per IGES,

As Per IGES

,

As Per IGES

As Per IGES

As Per IGES,

As Per IGES

,

Part Number,

1.0

1 or 2

4HINCH or 2HMM

As Per IGES , non

As Per IGES

,

As Per IGES

See below

See below

As Per IGES

,

As Per IGES , non

As Per IGES , non

See below

see below

non

non

null

null

null

•null

null

null

null

below

null

null

null

non- null

null

null

B - 15
information for the field. This restriction pertains to fields 7-11, 16-18,

and 21-23.

The Minimum Resolution, field 19, must contain the value of the largest

geometric discontinuity for the geometry in the Drafting APF file, i.e., the

largest "gap". Because of the dual role of the Drafting APF, the Drafting

APF file is required to carry both the product data, geometry, tolerances,

etc., and the graphics necessary to produce a drawing. In many cases, the

product data geometry in the Drafting APF file must be used by manufacturing

applications to produce a product. Manufacturing applications must rely on

the continuity of the geometry, and this reliance requires that the value of

Field 19 be the largest geometric discontinuity in the Drafting APF file.

With this value, any manufacturing application can consider coordinate

locations less than this distance apart to be coincident. This field value

must be prepared on the basis of each APF file's contents and not on the

basis of the originating system's capability. This field must always be

given a value

Examples: 0.00001 1.0E-5

The Maximum Coordinate Value, field 20, must contain the value of the

largest X, Y, or Z geometric position in the Drafting APF file. This field

value must be prepared on the basis of each APF file's contents and not on

the basis of the originating system's maximum capability. This field must

always be given a value.

Examples: 1000.0 1.0E3

The Drafting Standard Code, field 24, must contain the value 3, because the

Feature Control Frame example is based on the American National Standards

Institute's Standard for Dimensioning and Tolerancing, ANSI Y14.5M, 1982. [6]

II.Directory Entry Section

This section gives the Directory Entry section restrictions for the IGES

entity set. The restrictions for the Directory Entry section of the IGES

entities in this example are based on the APIM for Feature Control Frames

and some assumptions about the remainder of the APIM for the Drafting APF.

These assumptions would not be necessary for a complete Drafting APF because

the complete APIM would be available for use in determining the

restrictions

The restrictions for fields 1, 11, and 15 were determined on the basis of

the IGES entity set that was selected to carry the information for Feature

Control Frames. The restrictions for fields 3, 4, 6, 7, 8, 9, 12, and 13

were determined on the basis of the APIM for Feature Control Frames.

The restriction for field 5 was determined on the basis of an assumption.

The assumption is that the complete Drafting APIM will require a method for

separating the Drafting information into specific information categories.

-•a

B - 16
The APFS will use the Directory Entry section level field to carry the information

category number. The information category number for tolerance information

(Feature Control Frames) is 250.

The restriction for fields 18 and 19 were determined on the basis of an

assumption. The assumption is that the complete Drafting APIM will require

a method for uniquely identifying each entity in the Drafting APF. The APFS

will use the entity label and subscript fields in the Directory Entry

section to carry the unique identifier. The requirement is that the

combination of the entity label value and the subscript value provide a unique

identifier for each entity in a Drafting APF file. This requirement means

that a unique entity label value must be identified for each IGES entity

type. Also, a unique subscript value N must be supplied for each entity in

the APF file, where N can have a value from 1 to the number entities of each

type in the APF file. The entity label values for the entities in this

example are:

The Directory Entry section fields that have Field Value Requirements

consisting of "As Per IGES" require that the field always contain a valid

value as described by the IGES specification. This restriction pertains to

Directory Entry section fields 2, 10, 14, and 20.

228 General Symbol

212 General Note

106 Simple Closed Area

"FCF_INF0"

"FCF_TEXT"

" FCF_B0X"

110 Line " FCF SEP"

B - 17
II. 2.1 General Symbol Entity

Directory Entry Section Field Field Value Requirement

Entity Type

Parameter Data Pointer

Structure

Line Font Pattern

Level

View

Transformation Matrix

Label Display Associativity

Status Number:

Blank Status

Subordinate Entity Switch

Entity Use Flag

Hierarchy

Section Code and Sequence Number

Entity Type

Line Weight Number

Color Number

Parameter Line Count Number

Form Number

Reserved Field

Reserved Field

Entity Label

Entity Subscript Number

Section Code and Sequence Number

228

As Per ICES

0

1

250

0

0

0

0

0

1

1

As Per IGES

228

0

0

As Per IGES

0

Blank

Blank

FCF_INF0

N

As Per IGES

B - 18
II. 2.

2

General Note Entity

Directory Entry Section Field Field Value Requirement

Entity Type

Parameter Data Pointer

Structure

Line Font Pattern

Level

View

Transformation Matrix

Label Display Associativity

Status Number:

Blank Status

Subordinate Entity Switch

Entity Use Flag

Hierarchy

Section Code and Sequence Number

Entity Type

Line Weight Number

Color Number

Parameter Line Count Number

Form Number

Reserved Field

Reserved Field

Entity Label

Entity Subscript Number

Section Code and Sequence Number

212

As Per IGES

0

1

250

0

0

0

0

1

1

1

As Per IGES

212

0

0

As Per IGES

0

Blank

Blank

FCF_TEXT

N

As Per IGES

B - 19
II. 2. 3 Simple Closed Area Entity

Directory Entry Section Field Field Value Requirement

Entity Type

Parameter Data Pointer

Structure

Line Font Pattern

Level

View

Transformation Matrix

Label Display Associativity

Status Number:

Blank Status

Subordinate Entity Switch

Entity Use Flag

Hierarchy

Section Code and Sequence Number

Entity Type

Line Weight Number

Color Number

Parameter Line Count Number

Form Number

Reserved Field

Reserved Field

Entity Label

Entity Subscript Number

Section Code and Sequence Number

106

As Per IGES

0

1

250

0

0

0

0

1

1

1

As Per IGES

106

0

0

As Per IGES

63

Blank

Blank

FCF_B0X

N

As Per IGES

B - 20

.4
II. 2.4 Line Entity

Directory Entry Section Field Field Value Requirement

Entity Type

Parameter Data Pointer

Structure

Line Font Pattern

Level

View

Transformation Matrix

Label Display Associativity

Status Number:

Blank Status

Subordinate Entity Switch

Entity Use Flag

Hierarchy

Section Code and Sequence Number

Entity Type

Line Weight Number

Color Number

Parameter Line Count Number

Form Number

Reserved Field

Reserved Field

Entity Label

Entity Subscript Number

Section Code and Sequence Number

110

As Per IGES

0

1

250

0

0

0

0

1

1

1

As Per IGES

110

0

0

As Per IGES

0

Blank

Blank

FCF_SEP

N

As Per IGES

B 21
II.

3

Parameter Data Section

This section outlines the Parameter Data section restrictions for the IGES

entity set. The restrictions given in this section are intended to reduce

the possible Parameter Data section field values to only what is necessary

for the Feature Control Frames APF. The usage guide assigns a specific

meaning to each Parameter Data section field for carrying Feature Control Frame

information. The usage guide is given in a later section.

The restrictions for the Parameter Data section of the IGES entitles in this

example will be based either explicitly or implicitly on the APIM for

Feature Control Frames and an assumption about the remainder of the APIM for

the Drafting APF.

The APIM for Feature Control Frames does not require the use of the IGES

associativity/general note backpointers or property backpointers. The

assumption is that no IGES associativity or general note backpointers will

be required by the remainder of the APIM for the Drafting APF. Also, the

assumption is that no IGES property backpointers will be required by the

remainder of the APIM for the Drafting APF. These assumptions would not be

necessary for a complete Drafting APF because the complete APIM would be

available for use in determining the restrictions.

B - 22
II. 3.1 General Symbol Entity

Parameter Data Section Field Field Value Requirement

ENTITY TYPE NUMBER 228

DENOTE Pointer to associated general note

N Number of pointers to geometry

GPNT1 Pointer to defining geometry

GPNTN

L 0; No pointers to Leader entities

NA 0; No pointers to Associativity or General

Note entities

NP 0; No pointers to Property entities

B 23
II. 3. 2 General Note Entity

Parameter Data Section Field Field Value Requirement

ENTITY TYPE NUMBER 212

NS Number of text strings in general note

NCI Number of characters in first text

string; must be greater than 0

WT1 Box width

HT1 Box height

FC1 Font Characteristic; must be equal to

1, 1001

SL1 Slant angle; must be equal to 1.5708

Al Rotation angle in radians; must be

equal to 0.0

Ml Mirror flag; must be equal to 0

VH1 Rotate internal text flag; must be

equal to 0

XS1 First text start point X

YS1 First text start point Y

ZS1 Z depth; must be equal to 0.0

TEXT1 First text string

NC2 Number of characters in second text string

TEXT2 Second text string

NCNS Number of characters in last text string

TEXTNS Last text string

B - 24
NA 0; No pointers to Associativity or General

Note entities

NP 0 ; No pointers to Property entities

The set of General Note Parameter Data section fields may be repeated as

many times as necessary to define all of the text strings.

B 25
II. 3. 3 Simple Closed Area Entity

Parameter Data Section Field Field Value Requirement

ENTITY TYPE NUMBER 106

IP Interpretation Flag; must be equal to

1

N1 Number of n- tuples; must be equal to 4

ZT Common Z displacement; must be equal

to 0.0

XI First data point abscissa

Y1 First data point ordinate

X4 Fourth data point abscissa

Y4 Fourth data point ordinate

NA 0; No pointers to Associativity or General

Note entities

NP 0; No pointers to Property entities

B - 26
II. 3.4 Line Entity

Parameter Data Section Field.

ENTITY TYPE NUMBER

XI

Y1

Z1

X2

Y2

Z2

NA

NP

Field Value Requirement

110

X coordinate of start point

Y coordinate of start point

Z coordinate of start point; must be equal

to 0,0

X coordinate of terminate point

Y coordinate of terminate point

Z coordinate of terminate point; must

be equal to 0,0

0; No pointers to Associativity or General

Note entities

0; No pointers to Property entities

B - 27
III. Usage Guide for the IGES Entities

This section specifies the use of the IGES entities in carrying Drafting

Feature Control Frame information as defined by the APIM. The use of the

IGES entities was determined by referring to the Feature Control Frames

Application Reference Model (ARM) , two Application Implementation Models

(AIM), and the Application IGES Implementation Model (AIIM) from Appendix B.l.

The Feature Control Frames ARM represents the Drafting information that is

required for a Feature Control Frame. This ARM is a part of the complete

Drafting APIM. The ARM is a model of Feature Control Frame information that

can be validated by a Drafting application area expert.

Appendix B.l contains two AIMs , the initial AIM and the final AIM. The

initial AIM is the AIM that was developed on the basis of the ARM and shows

the Drafting information for Feature Control Frames that must be

"identifiable" in the IGES entities in the Drafting APF. The meaning of

"identifiable" in this context is that it must be possible to have a

reversible mapping of Feature Control Frame information from the ARM into

the IGES entities in the APF. The initial AIM provides a description of the

way that the Feature Control Frame information must be structured to allow

an explicit reversible mapping.

Because of the implementation decisions and trade-offs as discussed in

Appendix B.l, the final AIM provides a less explicit "identification" of

each item of Feature Control Frame information in the APF entities. In

reality, this means that it will not be possible to have an explicit

reversible mapping of Feature Control Frame information. It is important to

realize that it will be possible to reverse the mapping, but the reverse

mapping will require "parsing" the embedded information.

Appendix B.l contains the AIIM that is based on the initial and final AIMs.

The final AIM and the resulting AIIM are based on implementation decisions

and trade-offs and can be implemented by using existing IGES entities. The

AIIM of Appendix B.l shows the Drafting information for Feature Control

Frames after it has been abstracted to an appropriate level for use in

selecting the necessary IGES entities to carry the information. This AIIM was

used to select the required IGES entity set for this APFS

The final AIM and the accompanying AIIM from Appendix B.l are the models

that were used to prepare this APFS for Feature Control Frames . In

addition, the final AIM and AIIM models illustrate the required structure

for the Feature Control Frame information as it must be carried in the IGES

entities in the APF.

Section II of this Appendix, the Global, Directory Entry, and Parameter Data

section restrictions, described the field value limitations. This section

gives a detailed description of how the information from the information

models must be embedded into each IGES entity for the Feature Control

Frames. This section will define the meaning of the necessary fields in the

Parameter Data section of each entity for carrying Feature Control Frames

B - 28
information. Any fields that do not require a specific meaning as per the

APIM will retain the description as given in Section II. Based on the

information models, the use of each IGES entity can be given in summary

statements as follows.

In terms of the final AIM, the General Note entity will be used to carry the

Geometric Characteristic, the Tolerance Specification, the Maximum Tolerance

Specification, and the Datum Reference. The Tolerance Specification

contains the Tolerance Cylindrical Form, the Tolerance Value, the Tolerance

Material Condition, the Tolerance Unit Length, and the Tolerance Unit

Width. The Maximum Tolerance Specification contains the Tolerance

Cylindrical Form and the Maximum Tolerance Value. The Datum Reference

contains the Datum Identifier and the Datum Material Condition.

In terms of the final AIM, the Simple Closed Area entity will be used to

carry the Frame Box that is defined by four coordinate pairs. The Line

entity will be used to carry the Frame Box Divider that is defined by two

coordinate pairs. The General Symbol entity will be used to carry the

associativity of the General Note, the Simple Closed Area, and the Line entities.

III.l General Symbol Entity

The Directory Entry section field value requirements for the General Symbol

entity are given in II. 2.1. Therefore, this section will not discuss the

Directory Entry section for the General Symbol entity.

The Parameter Data section field value requirements for the General Symbol

entity are outlined in II. 3.1. This section will specify the use of the

Parameter Data section fields for the General Symbol entity in terms of the

final AIM and IGES.

The General Symbol Entity will be used to carry the associativity for the

General Note, Simple Closed Area, and Line entities and to group these

entities together into a Feature Control Frame entity. In terms of IGES,

this means that the General Symbol entity will be used to carry the pointers

to the General Note, Simple Closed Area, and Line entities. The order and

meaning of the Parameter Data section fields for the General Symbol entity

are given below. The use of each entity that is pointed to by the General

Symbol entity will be described in subsequent sections.

The General Symbol entity can carry only one pointer to a General Note

entity. The General Symbol can carry multiple pointers to geometry

entities. These geometry entity pointers will point to Simple Closed Area

and Line entities. There must be one or more pointers to a Simple Closed

Area entity and one or more pointers to Line entities. The pointers to the

Simple Closed Area entity must be placed in the list before the pointers to

the Line entities. The General Symbol entity must contain no pointers to

Leader entities.

B - 29
Parameter Data Section Field Field Value Requirement

ENTITY TYPE NUMBER 228

DENOTE

N

GPNT1

Pointer to the general note entity that

contains the Geometric Characteristic,

the Tolerance Specification, the Maximum

Tolerance Value Specification, and the

Datum Reference information

Total number of pointers to Simple Closed

Area and Line entities defining Frame

Boxes and Frame Box Dividers; there

will be one or more pointers to Simple

Closed Area entities and one or more

pointers to Line entities

Pointer to a Simple Closed Area or Line

entity

GPNTN

L 0; No pointers to Leader entities

NA 0; No pointers to Associativity or General

Note entities

NP 0 ; No pointers to Property entities

III. 2 General Note Entity

The Directory Entry section field value requirements for the General Note

entity are given in II. 2. 2. Therefore, this section will not discuss the

Directory Entry section for the General Note entity.

The Parameter Data section field value requirements for the General Note

entity are outlined in II. 3. 2. This section will specify the use of the

Parameter Data section fields for the General Note entity in terms of the

final AIM and IGES

From the final AIM, the Feature Control Frame contains the Geometric

Characteristic, the Tolerance Specification, the Maximum Tolerance Value

Specification, and the Datum Reference. The Geometric Characteristic will be

represented by a Geometric Characteristic Symbol.

The Tolerance Specification is identified by a Tolerance Specification

Identifier. The Tolerance Specification will contain the Tolerance

Cylindrical Form, the Tolerance Value, the Tolerance Material Condition, the

B - 30
Tolerance Unit Length, and the Tolerance Unit Width. The Tolerance

Cylindrical form will be represented by a Diameter Symbol. The Tolerance

Value will be represented by a Tolerance Value String. The Tolerance

Material Condition will be represented by a Material Condition Symbol. The

Tolerance Unit Length will be represented by a Tolerance Unit Length String.

The Tolerance Unit Width will be represented by a Tolerance Unit Width String.

The Maximum Tolerance Value Specification is identified by a Maximum

Tolerance Specification Identifier. The Maximum Tolerance Value

Specification contains a Tolerance Cylindrical Form represented by a Diameter Symbol. The Maximum Tolerance Value Specification contains a Maximum Tolerance Value that is represented by Maximum Tolerance Value String.

The Datum Reference is identified by a Datum Reference Identifier. The

Datum Reference contains a Datum Identifier that is represented by a Datum

Identifier String. The Datum Reference contains a Datum Material Condition

that is represented by a Datum Material Condition Symbol.

Only one General Note entity can be included in a General Symbol entity.

However, the single General Note entity can have an unlimited number of

strings. The Feature Control Frame will have two or more "compartments"

that are represented by the Frame Box and the Frame Box Dividers. Each of

the compartments will contain either a Geometric Characteristic, a Tolerance

Specification, a Maximum Tolerance Value Specification, or a Datum

Reference. Therefore, this APFS will allocate one string in the General

Note entity to carry the contents of each compartment in the Feature Control

Frame. This means that the contents of each compartment must be contained

In a General Note string having a font characteristic such that the contents

can be correctly represented. The order of the text and symbol strings in the

General Note entity must be from left to right as per the order of the

compartments in the Feature Control Frame.

B 31
Parameter Data Section Field Field Value Requirement

ENTITY TYPE NUMBER 212

NS Number of compartments in the Feature

Control Frame; must be >= 2

NCI Number of symbols and/or text

characters in the first string; must

be > 0

WT1 Symbol and/or text character string

width; must be > 0.0

HT1 Symbol and/or text character string

height; must be > 0.0

FC1 Symbol and/or text character string

font characteristic; must be equal to

1, 1001

SL1 Symbol and/or text character slant

angle; must be equal to 1.5708

Al Rotation angle in radians; must be

equal to 0.0

Ml Mirror flag; must be equal to 0

VH1 Rotate internal text flag; must be

equal to 0

XS1 First symbol and/or text character

string start point X

YS1 First symbol and/or text character

string start point Y

ZS1 Z depth; must be equal to 0.0

TEXT1 First symbol and/or text character string

NC2 Number of symbols and/or text

characters in the second string; must

be > 0

TEXT 2 Second symbol and/or text character string

B - 32
NCNS Number of symbols and/or text

characters in the last string; must be

> 0

TEXTNS Last symbol and/or text character string

NA 0; No pointers to Associativity or General

Note entities

NP 0 ; No pointers to Property entities

There is no limit on the number of symbol and/or text character strings that

may be included in the General Note entity. The number of strings in the

General Note entity must be equal to the number of compartments in the

Feature Control Frame.

B - 33
III. 3 Simple Closed Area Entity

The Directory Entry section field value requirements for the Simple Closed

Area entity are given in II. 2. 3. Therefore, this section will not discuss

the Directory Entry section for the Simple Closed Area entity.

The Parameter Data section field value requirements for the Simple Closed

Area entity are outlined in II. 3. 3. This section will specify the use of

the Parameter Data section fields for the Simple Closed Area entity in terms

of the final AIM and IGES

From the final AIM, the Feature Control Frame is represented by a Frame Box.

The Frame Box is defined by four coordinate pairs that each consist of an X

Value and a Y Value. The Frame Box is identified by a Frame Box Identifier.

The Simple Closed Area entity will be used to carry the Frame Box for the

Feature Control Frame. Visually, the Frame Box is made up of four vertices

and four curve segments. The Simple Closed Area entity will contain four

coordinate pairs of data points that represent the vertices of the box and

the four curve segments that make up the box.

B - 34
Parameter Data Section Field Field Value Requirement

ENTITY TYPE NUMBER 106

IP Interpretation Flag; must be equal to

1

N1 Number of Coordinate Pairs for the Frame

Box; must be equal to 4

ZT Common Z displacement; must be equal

to 0.0

XI X Value for the first corner of the

Frame Box

Y1 Y Value for the first corner of the

Frame Box

X2 X Value for the second comer of the Frame

Box

Y2 Y Value for the second comer of the Frame

Box

X3 X Value for the third corner of the

Frame Box

Y3 Y Value for the third corner of the

Frame Box

X4 X Value for the fourth comer of the Frame

Box

Y4 Y Value for the fourth comer of the Frame

Box

NA 0; No pointers to Associativity or General

Note entities

NP 0; No pointers to Property entities

B - 35
III. 4 Line Entity

The Directory Entry section field value requirements for the Line entity are

given in II. 2. 4. Therefore, this section will not discuss the Directory

Entry section for the Line entity.

The Parameter Data section field value requirements for the Line entity are

outlined in II. 3.4. This section will specify the use of the Parameter Data

section fields for the Line entity in terms of the final AIM and IGES

From the final AIM, the Feature Control Frame is compartmentalized by the

Frame Box Divider that is defined by two coordinate pairs that each consist

of an X Value and a Y Value. The Frame Box Divider is identified by a Frame

Box Divider Identifier.

The Line entity will be used to carry the Frame Box Dividers for the

compartments of the Feature Control Frame. There must be two or more

compartments in the Feature Control Frame. The number of Frame Box Dividers

must be one less than the number of compartments in the Feature Control

Frame. Each Frame Box Divider must consist of two endpoints that define one

curve segment.

Parameter Data Section Field Field Value Requirement

ENTITY TYPE NUMBER 110

XI X Value for the start point of the Frame

Box Divider

Y1 Y Value for the start point of the Frame

Box Divider

Z1 Z coordinate of start point; must be equal

to 0.0

X2 X Value for the terminate point of the

Frame Box Divider

Y2 Y Value for the terminate point of the

Frame Box Divider

Z2 Z coordinate of terminate point; must

be equal to 0.0

NA 0; No pointers to Associativity or General

Note entities

NP 0; No pointers to Property entities

B - 36
Appendix B .

3

FEATURE CONTROL FRAMES - APPLICATION PROTOCOL FORMAT TEST CASES

This Appendix describes the set of test cases for the Feature Control Frame

example. The test cases for this example were prepared as per the technical

content requirements given in Section 3.1.

The set includes ten test cases, and the test cases are based on the Feature

Control Frames illustrated in Figure B5 . These test cases were taken from

examples given in the ANSI Standard for Dimensioning and Tolerancing, ANSI

Y14.5M, 1982. [6] In Figure B5 , the Feature Control Frames are identified by

FCF#1, FCF#2 , etc. These names identify the test cases and appear in the

test case listings.

Test case numbers 1-6, identified as FCF#1-FCF#6 in Figure B5 , contain

various mixes of Geometric Characteristic Symbols, Tolerance Cylindrical

Form-Diameter Symbols, Tolerance Value Strings, Material Condition Symbols,

Datum Identifiers, and Material Condition Symbols. Each of test cases 1-6

contain a Frame Box, and one or more Frame Box Dividers.

Test case number 7 contains many of the same information items as test cases

1-6, but also contains a Tolerance Unit Length String. Test case number 8

contains similar information items as the other test cases, but it also

contains a Tolerance Unit Width String. Test case number 9 contains an

additional information item, the Maximum Tolerance Value String. Finally,

test case number 10 is known as a Composite Feature Control Frame. [6] As

shown in Figure B5 , the Composite Feature Control Frame is made up of a "double" Frame Box with one Geometric Characteristic Symbol and two individual

Tolerance Specifications.

The test cases are handmade test cases and were prepared as per the Application

Protocol Format Specification given in Appendix B.2 and the IGES Test Case

Development Committee's Guide to Developing Entity Test Cases. [7]

Currently, test cases for application protocols are not required to conform

to the specifications of the test case development guide. The standard file

documentation header is used as an example of one file documentation method.

A listing of the AP format files for these ten test cases is given below.

These ten test cases have been thoroughly checked for correctness using both

manual methods and software methods. In addition, each test case has been

read with an IGES postprocessor into a CAD system, plotted, and visually

verified to correctly represent each of the Feature Control Frames

illustrated in Figure B5.

B - 37
B - 38

FEATURE

CONTROL

FRAME

TEST

CASES
0

0.005/0.1X0.1

FCF

#7

o

CO

< <

00

o

©

m

C\|

o

'a

-6>

O

==S=

Li_ O

Li_

B - 39

Figure

B5

(Cont.)
s F FCFTC01 S

DAT S

S

V IGES 3.0 s

S

I Application Protocol Test Case S

Application Protocol: Drafting S

Information: Feature Control Frames S

S

E ENTITY FORM COUNT S

228 0 IS

212 0 IS

106 63 IS

110 0 IS

S

B This is a test case for the Feature Control Frames Application S

Protocol example. This test case implements the Feature Control S

Frame shown in Figure B5 and labeled as FCF #1. S

S

P Not applicable S

S

R Not applicable S

S

C This test case was prepared as per the IGES Test Case Development S

Committee's "Guide to Developing Entity Test Cases", S

Draft Version 0.2, November 10, 1987. S

S

D IGES Specification, Version 3.0 S

Guidelines for the Specification and Validation of IGES Application S

Protocols, Draft Version 0.04 S

S

H 24-Feb~1988 A Created Test Case for AP Example - R.J. Harrison S

S

L This data was 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

1H ,

, 1H ; , 10H0000011111 , 11HFCFTC01 . DAT , 8HHANDMADE , 3H1 . 0 , 32 , 38 , 6 , 38 , 15 , G

10H0000011111, 1.0,1,4HINCH, 8,0. 08, 13H880224. 104500, 0.0001, 8. 7500, G

1.4HR . J. HARRISON, 24HD0E/Sandia National Labs, 4,0; G

1

2

3

4

5

6

7

8

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

1

2

3

B - 40
228 1 0 1 250 0 0 000000101D 1

228 0 0 1 0 FCF INFO ID 2

212 2 0 1 250 0 0 000010101D 3

212 0 0 3 0 FCF TEXT ID 4

106 5 0 1 250 0 0 000010101D 5

106 0 0 2 63 FCF BOX ID 6

110 7 0 1 250 0 0 000010101D 7

110 0 0 1 0 FCF SEP ID 8

228 .3.2. 5. 7.

0.

0.0; 212.2.1.0.

3332.0. 5000 . 1001 .1.5708.0. 0000 .0.0.5.2500.5.1500,

0. 0000, lHc, 4, 2. 0833, 0.5000, 1,1. 5708, 0.0000, 0,0, 6. 5000, 5. 1500,

0 . 0000 , 4H0 .08,0,0;

106.1.4.0.

0000 . 5 . 0000 . 5 . 8000 .8.7500.5. 8000 .8.7500.5. 0000

,

0.0000,5.0000,0,0;

110.6. 2500 . 5 . 8000 . 0

.

0000 .6.2500.5. 0000 . 0 . 0000 .0.0;

S 48G 3D 8P 7

IP

3P

3P

3P

5P

5P

7P

T

1

2

3

4

5

6

7

1

B - 41
s F FCFTC02 S

DAT S

S

V IGES 3.0 S

S

I Application Protocol Test Case S

Application Protocol: Drafting S

Information: Feature Control Frames S

S

E ENTITY FORM COUNT S

228 0 IS

212 0 IS

106 63 IS

110 0 IS

S

B This is a test case for the Feature Control Frames Application S

Protocol example. This test case implements the Feature Control S

Frame shown in Figure B5 and labeled as FCF #2. S

S

P Not applicable S

S

R Not applicable S

S

C This test case was prepared as per the IGES Test Case Development S

Committee's "Guide to Developing Entity Test Cases", S

Draft Version 0.2, November 10, 1987. S

S

D IGES Specification, Version 3.0 S

Guidelines for the Specification and Validation of IGES Application S

Protocols, Draft Version 0.04 S

S

H 24-Feb-1988 A Created Test Case for AP Example - R.J. Harrison S

S

L This data was 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

1H , , 1H ;, 10H0000022222 , 11HFCFTC02 . DAT , 8HHANDMADE , 3H1 . 0 , 32 , 38 , 6 , 38 , 15 , G

10H0000022222 ,1.0,1, 4HINCH ,8,0.08, 13H880224 . 134000 , 0 . 0001 , 10 . 5000 , G

14HR . J. HARRISON, 24HDOE/Sandia National Labs, 4,0; G

1

2

3

4

5

6

7

8

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

1

2

3

B - 42
228 1 0 1 250 0 0 000000101D 1

228 0 0 1 0 FCF INFO ID 2

212 2 0 1 250 0 0 000010101D 3

212 0 0 3 0 FCF TEXT ID 4

106 5 0 1 250 0 0 000010101D 5

106 0 0 2 63 FCF BOX ID 6

110 7 0 1 250 0 0 000010101D 7

110 0 0 1 0 FCF SEP ID 8

228 .3. 2. 5. 7.

0.

0.0;

212.2.1.1. 0000

.

0 . 5000 . 1001 . 1 . 5708 . 0 . 0000 .0.0.5.2500.5. 1500 , 0 . 0000 , 1H- , 6 , 3 . 5000 , 0 . 5000 , 1001 , 1 . 5708 , 0 . 0000 ,0,0,6. 7500

,

5.1500.0.

0000 . 6Hn0 . 14m , 0 , 0

;

106.1.4.0.

0000 . 5 . 0000 .5.8000.10.5000.5.8000.10.5000.5. 0000

,

5.0000.

5.0000.0.0;

110.6. 5000

.5.8000.0.

0000 . 6 . 5000 . 5 . 0000 . 0 . 0000 .0.0;

S 48G 3D 8P 7

IP

3P

3P

3P

5P

5P

7P

T

1

23

4

5

6

7

1

3 43
s F FCFTC03 S

DAT S

S

V IGES 3 . 0 S

S

I Application Protocol Test Case S

Application Protocol: Drafting S

Information: Feature Control Frames S

S

E ENTITY FORM COUNT S

228 0 IS

212 0 1 S

106 63 IS

110 0 2 S

S

B This is a test case for the Feature Control Frames Application S

Protocol example. This test case implements the Feature Control S

Frame shown in Figure B5 and labeled as FCF #3 . S

S

P Not applicable S

S

R Not applicable S

S

C This test case was prepared as per the IGES Test Case Development S

Committee's "Guide to Developing Entity Test Cases", S

Draft Version 0.2, November 10, 1987. S

S

D IGES Specification, Version 3.0 S

Guidelines for the Specification and Validation of IGES Application S

Protocols, Draft Version 0.04 S

S

H 24-Feb-1988 A Created Test Case for AP Example - R.J. Harrison S

S

L This data was 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

1H, , 1H ;

, 10H0000033333 , 11HFCFTC03 . DAT , 8HHANDMADE , 3H1 .0,32,38,6,38,15, G

10H0000033333 ,1.0,1, 4HINCH ,8,0.08, 13H880224 . 140500 , 0 . 0001 , 11 . 5000 , G

14HR . J. HARRISON, 24HDOE/Sandia National Labs, 4,0; G

1

2

3

4

5

6

7

8

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

1

2

3

B - 44
228 1 0 1 250 0 0 000000101D 1

228 0 0 1 0 FCF INFO ID 2

212 2 0 1 250 0 0 000010101D 3

212 0 0 4 0 FCF TEXT ID 4

106 6 0 1 250 0 0 000010101D 5

106 0 0 2 63 FCF BOX ID 6

110 8 0 1 250 0 0 000010101D 7

110 0 0 1 0 FCF SEP ID 8

110 9 0 1 250 0 0 000010101D 9

110 0 0 1 0 FCF_SEP 2D 10

228,3,3,5,7,9,0,0 ,0; IP 1

212,3,1,0.5547,0. 5000,1001,1.5708,0 0000,0,0,5. 2500,5 1500, 3P 2

5 . 0000 , 1H1 , 6 , 3 . 5000 , 0 . 5000 ,1001,1.5708,0. 0000 ,

0

,0,6.7500, 3P 3

5 . 1500 , 0 . 0000 , 6Hn0 . 05m, 1,0. 5000 , 0 . 5000 ,1,1.5708 ,0.0000,0,0, 3P 4

L0. 7500, 5. 1500,0. 0000, 1HC, 0,0; 3P 5

106,1,4,0.0000,5. 0000 , 5 . 8000 , 11 . 5000 , 5 . 8000 , 11

.

5000,5 0000, 5P 6

5.0000,5.0000,0,0 5P 7

110,6.5000,5.8000 , 0 . 0000 , 6 . 5000 , 5 . 0000 , 0 . 0000 ,0,0; 7P 8

110 , 10 . 5000 , 5 . 8000 , 0 . 0000 ,10.5000,5 0000,0.0000 ,0,0; 9P 9

3 48G 3D 10P 9 T 1

B - 45
s F FCFTC04 S

DAT S

S

V IGES 3.0 S

S

I Application Protocol Test Case S

Application Protocol: Drafting S

Information: Feature Control Frames S

S

E ENTITY FORM COUNT S

228 0 IS

212 0 IS

106 63 IS

110 0 2 S

S

B This is a test case for the Feature Control Frames Application S

Protocol example. This test case implements the Feature Control S

Frame shown in Figure B5 and labeled as FCF #4. S

S

P Not applicable S

S

R Not applicable S

S

C This test case was prepared as per the IGES Test Case Development S

Committee's "Guide to Developing Entity Test Cases", S

Draft Version 0.2, November 10, 1987. S

S

D IGES Specification, Version 3.0 S

Guidelines for the Specification and Validation of IGES Application S

Protocols, Draft Version 0.04 S

S

H 24-Feb-1988 A Created Test Case for AP Example - R.J. Harrison S

S

L This data was 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

1H ,, 1H ;, 10H0000044444 , 11HFCFTC04 . DAT , 8HHANDMADE , 3H1 . 0 , 32 , 38 , 6 , 38 , 15 , G

10H0000044444 ,1.0,1, 4HINCH ,8,0.08, 13H880224 . 144500 , 0 . 0001 ,10.7500, G

14HR . J. HARRISON, 24HD0E/Sandia National Labs, 4,0; G

228 1 0 1 250 0 0 000000101D

1

2

3

4

5

6

7

8

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

1

2

3

1

B - 46
228 0 0 1 0 FCF INFO ID

212 2 0 1 250 0 0 000010101D

212 0 0 4 0 FCF TEXT ID

106 • 6 0 1 250 0 0 000010101D

106 0 0 2 63 FCF BOX ID

110 8 0 1 250 0 0 000010101D

110 0 0 1 0 FCF SEP ID

110 9 0 1 250 0 0 000010101D

228.3.3.5.7.9.0. 110 0 0 1 0 FCF SEP 2D

0.0; IP 212.3.1.0.

5547.0.5000.1001.1.5708.0.0000.0.0.5.2500.5.1500, 3P

0 . 0000 , lHh , 4 , 2 . 0000 , 0 . 5000 ,1,1.5708,0. 0000 ,0,0,6. 5000 , 3P

5 . 1500 . 0

.

0000 . 4H0 . 05 , 3 , 1 . 5000 , 0 . 5000 ,1,1.5708,0. 0000 ,0,0, 3P

9 . 0000

.

5 . 1500 . 0 . 0000 . 3HA-B , 0,0; 3P

106.1.4.0.

0000 . 5 . 0000 . 5 . 8000 .10.7500.5. 8000 .10.7500.5. 0000 , 5P

5.0000.

5.0000.0.0; 5P

110.6. 2500 . 5 . 8000 . 0

.

0000 . 6 . 2500 . 5 . 0000 . 0 . 0000 .0.0; 7P

110.8. 7500 . 5 . 8000 . 0

.

0000 .8.7500.5. 0000 . 0 . 0000 .0.0; 9P

S 48G 3D 10P 9 T
s F FCFTC05 S

DAT S

S

V IGES 3.0 S

S

I Application Protocol Test Case S

Application Protocol: Drafting S

Information: Feature Control Frames S

S

E ENTITY FORM COUNT S

228 0 IS

212 0 IS

106 63 IS

110 0 3 S

S

B This is a test case for the Feature Control Frames Application S

Protocol example. This test case implements the Feature Control S

Frame shown in Figure B5 and labeled as FCF #5. S

S

P Not applicable S

S

R Not applicable S

S

C This test case was prepared as per the IGES Test Case Development S

Committee's "Guide to Developing Entity Test Cases", S

Draft Version 0.2, November 10, 1987. S

S

D IGES Specification, Version 3.0 S

Guidelines for the Specification and Validation of IGES Application S

Protocols, Draft Version 0.04 S

S

H 24-Feb-1988 A Created Test Case for AP Example - R.J. Harrison S

S

L This data was 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

1H ,, 1H ;, 10H0000055555 , 11HFCFTC05 . DAT , 8HHANDMADE , 3H1 . 0 , 32 , 38 , 6 , 38 , 15 , G

10H0000055555,1.0,1,4HINCH,8,0.08,13H880224. 150500, 0.0001, 12. 7 500, G

14HR . J. HARRISON, 24HDOE/Sandia National Labs ,4,0; G

228 101 250 0 0 000000101D

1

2

3

4

5

6

7

8

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

1

2

3

1

B - 48
228 0 0 1 0 FCF INFO ID 2

212 2 0 1 250 0 0 000010101D 3

212 0 0 5 0 FCF TEXT ID 4

106 7 0 1 250 0 0 000010101D 5

106 0 0 2 63 FCF BOX ID 6

110 9 0 1 250 0 0 000010101D 7

110 0 0 1 0 FCF SEP ID 8

110 10 0 1 250 0 0 000010101D 9

110 0 0 1 0 FCF SEP 2D 10

110 11 0 1 250 0 0 000010101D 11

110 0 0 1 0 FCF SEP 3D 12 228.3.4.5.7.9.11.0.

0;

212.4.1.0.

4167.0.5000. 1001 .1.5708.0. 0000 .0.0.5.2500.5.1500,

0.0000, lHj ,6,3.5000,0.5000,1001,1.5708,0.0000,0,0,6.2500,

5.

1500.0.

0000. 6Hn0. 25m, 1,0. 5000, 0.5000, 1,1. 5708, 0.0000, 0,0,

10. 2500. 5.

1500.0.

0000. 1HB, 2, 1.2500, 0.5000, 1001, 1.5708,

0 . 0000 ,0,0,11.2500,5. 1500 , 0 . 0000 , 2HCm ,0,0;

106.1.4.0.

0000.5.0000.5.8000.12.7500.5.8000.12.7500.5.0000,

5.0000.

5.0000.0.0;

110.6. 0000

.

5 . 8000 . 0 . 0000 . 6 . 0000 . 5 . 0000 . 0 . 0000 .0.0;

110 . 10 . 0000

.

5 . 8000 . 0 . 0000 . 10 . 0000 . 5 . 0000 . 0 . 0000 .0.0;

110 . 11 . 0000

.

5 . 8000 . 0 . 0000 . 11 . 0000 . 5 . 0000 . 0 . 0000 .0.0;

S 48G 3D 12P 11

IP

3P

3P

3P

3P

3P

5P

5P

7P

9P

IIP

T

1

2

3

4

5

6

7

8

9

10

11

1

B 49
s F FCFTC06 S

DAT S

S

V IGES 3.0 S

S

I Application Protocol Test Case S

Application Protocol: Drafting S

Information: Feature Control Frames S

S

E ENTITY FORM COUNT S

228 0 IS

212 0 IS

106 11 IS

110 0 4 S

S

B This is a test case for the Feature Control Frames Application S

Protocol example. This test case implements the Feature Control S

Frame shown in Figure B5 and labeled as FCF #6 . S

S

P Not applicable S

S

R Not applicable S

S

C This test case was prepared as per the IGES Test Case Development S

Committee's "Guide to Developing Entity Test Cases", S

Draft Version 0.2, November 10, 1987. S

S

D IGES Specification, Version 3.0 S

Guidelines for the Specification and Validation of IGES Application S

Protocols, Draft Version 0.04 S

S

H 24-Feb-1988 A Created Test Case for AP Example - R.J. Harrison S

S

L This data was 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

1H ,

, 1H ; , 10H0000066666 , 11HFCFTC06 . DAT , 8HHANDMADE , 3H1 . 0 , 32 , 38 , 6 , 38 , 15 , G

10H0000066666, 1 . 0 , 1 , 4HINCH , 8,0. 08, 13H880224. 153000, 0.0001, 12. 5000, G

14HR . J. HARRISON, 24HD0E/Sandia National Labs, 4,0; G

228 1 0 1 250 0 0 000000101D

1

2

3

4

5

6

7

8

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

1

2

3

1

B - 50
228 0 0 1 0 FCF INFO ID

212 2 0 1 250 0 0 000010101D

212 0 0 6 0 FCF TEXT ID

106 8 0 1 250 0 0 000010101D

106 0 0 2 63 FCF BOX ID

110 10 0 1 250 0 0 000010101D

110 0 0 1 0 FCF SEP ID

110 11 0 1 250 0 0 000010101D

110 0 0 1 0 FCF SEP 2D

110 12 0 1 250 0 0 000010101D

110 0 0 1 0 FCF SEP 3D

110 13 0 1 250 0 0 000010101D

110 0 0 1 0 FCF SEP 4D

228,3,5,5,7,9,11,13,0; IP

212.5.1.0.

4167.0. 5000 . 1001 .1.5708.0.0000.0.0.5.2500.5.1500, 3P

0 . 0000 , lHj , 5 , 3 . 0000 , 0 . 5000 , 1001 , 1 . 5708 , 0 . 0000 ,0,0,6.2500, 3P

5.

1500.0.

0000. 5HnO. 4m, 1,0. 5000, 0.5000, 1,1. 5708, 0.0000, 0,0, 3P

9 . 7500 . 5 . 1500 . 0

.

0000 . 1HF, 1,0. 5000 , 0 . 5000 ,1,1.5708,0. 0000 , 0 , 3P

0,10.7500,5. 1500 , 0 . 0000 , 1HE ,1,0. 5000 , 0 . 5000 ,1,1.5708,0. 0000 , 3P

0,0,11.7500,5. 1500 , 0 . 0000 , 1HD ,0,0; 3P

106.1.4.0.

0000.5.0000.5.8000.12.5000.5.8000.12.5000.5.0000, 5P

5.0000.

5.0000.0.0; 5P

110.6. 0000

.

5 . 8000 . 0 . 0000 . 6 . 0000 . 5 . 0000 . 0 . 0000 .0.0; 7P

110.9. 5000 . 5 . 8000 . 0

.

0000 . 9 . 5000 . 5 . 0000 . 0 . 0000 .0.0; 9P

110 . 10 . 5000 . 5 . 8000 . 0

.

0000 . 10 . 5000 . 5 . 0000 . 0 . 0000 .0.0; IIP

110 . 11 . 5000 . 5 . 8000 . 0

.

0000 . 11 . 5000 . 5 . 0000 . 0 . 0000 .0.0; 13P

S 48G 3D 14P 13 T
s F FCFTC07 S

DAT S

S

V IGES 3.0 sS

I Application Protocol Test Case S

Application Protocol: Drafting S

Information: Feature Control Frames S

S

E ENTITY FORM COUNT S

228 0 IS

212 0 IS

106 63 IS

110 0 3 S

S

B This is a test case for the Feature Control Frames Application S

Protocol example. This test case implements the Feature Control S

Frame shown in Figure B5 and labeled as FCF #7. S

S

P Not applicable S

S

R Not applicable S

S

C This test case was prepared as per the IGES Test Case Development S

Committee's "Guide to Developing Entity Test Cases", S

Draft Version 0.2, November 10, 1987. S

S

D IGES Specification, Version 3.0 S

Guidelines for the Specification and Validation of IGES Application S

Protocols, Draft Version 0.04 S

S

H 24-Feb-1988 A Created Test Case for AP Example - R.J. Harrison S

S

L This data was 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

1H ,

, 1H ; , 10H0000077777 , 11HFCFTC07 . DAT , 8HHANDMADE , 3H1 . 0 , 32 , 38 , 6 , 38 , 15 , G

10H0000077777, 1 . 0 , 1 , 4HINCH , 8,0. 08, 13H880224. 153000, 0.0001, 15. 7500, G

14HR . J. HARRISON, 2 4HD0E/Sand1 a National Labs, 4,0; G

228 1 0 1 250 0 0 000000101D

1

2

3

4

5

6

7

8

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

1

2

3

1

B - 52
228 0 0 1 0 FCF ;INFO ID

212 2 0 1 250 0 0 000010101D

212 0 0 5 0 FCF TEXT ID

106 7 0 1 250 0 0 000010101D

106 0 0 2 63 FCF_ BOX ID

110 9 0 1 250 0 0 000010101D

110 0 0 1 0 FCF_ SEP ID

110 10 0 1 250 0 0 000010101D

110 0 0 1 0 FCF_ SEP 2D

110 11 0 1 250 0 0 000010101D

110 0 0 1 0 FCF SEP 3D

228,3,4,5,7,9,11,0,0,0; 212.4.1.1.0000. IP

0.5000.1001.1.5708.0.0000.0.0.5.2500.5.1500, 3P

0 . 0000 , 1H- , 11 , 6 . 0000 , 0 . 5000 , 1001 ,1.5708,0. 0000 ,0,0,6. 7500 , 3P

5 . 1500 . 0

.

0000 . 11HnO .005/0.10,1,0. 5000 , 0 . 5000 ,1,1. 5708 , 0 . 0000 , 3P

0, 0, 13. 2500, 5. 1500,0. 0000, 1HA, 2, 1.2500, 0.5000, 1001, 1.5708, 3P

0 . 0000 ,0,0,14. 2500 , 5 . 1500 , 0 . 0000 , 2HBm, 0 , 0 ; 3P

106.1.4.0.

0000.5.0000.5.8000.15.7500.5.8000.15.7500.5.0000, 5P

5.0000.

5.0000.0.0; 5P

110.6. 5000 . 5 . 8000 . 0

.

0000 . 6 . 5000 . 5 . 0000 . 0 . 0000 .0.0; 7P

110 . 13 . 0000

.

5 . 8000 . 0 . 0000 . 13 . 0000 . 5 . 0000 . 0 . 0000 .0.0; 9P

110 . 14 . 0000

.

5 . 8000 . 0 . 0000 . 14 . 0000 . 5 . 0000 . 0 . 0000 .0.0; IIP

S 48G 3D 12P 11 T
s F FCFTC08 S

DAT S

S

V IGES 3.0 S

S

I Application Protocol Test Case S

Application Protocol: Drafting S

Information: Feature Control Frames S

S

E ENTITY FORM COUNT S

228 0 IS

212 0 IS

106 63 IS

110 0 2 S

S

B This is a test case for the Feature Control Frames Application S

Protocol example. This test case implements the Feature Control S

Frame shown in Figure B5 and labeled as FCF #8. S

S

P Not applicable S

S

R Not applicable S

S

C This test case was prepared as per the IGES Test Case Development S

Committee's "Guide to Developing Entity Test Cases", S

Draft Version 0.2, November 10, 1987. S

S

D IGES Specification, Version 3.0 S

Guidelines for the Specification and Validation of IGES Application S

Protocols, Draft Version 0.04 S

S

H 24-Feb=1988 A Created Test Case for AP Example - R.J. Harrison S

S

L This data was 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

1H ,

, 1H ;, 10H0000088888 , 11HFCFTC08 . DAT , 8HHANDMADE , 3H1 . 0 , 32 , 38 , 6 , 38 , 15 , G

10H0000088888, 1.0,1 ,4HINCH, 8, 0.08, 13H880224. 140500, 0.0001, 15. 0000, G

14HR . J. HARRISON, 24HD0E/Sandia National Labs, 4,0; G

228 1 0 1 250 0 0 000000101D

1

2

3

4

5

6

7

8

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

1

2

3

1

B - 54
228 0 0 1 0 FCF INFO ID 2

212 2 0 1 250 0 0 000010101D 3

212 0 0 4 0 FCF TEXT ID 4

106 6 0 1 250 0 0 000010101D 5

106 0 0 2 63 FCF BOX ID 6

110 8 0 1 250 0 0 000010101D 7

110 0 0 1 0 FCF SEP ID 8

110 9 0 1 250 0 0 000010101D 9

110 0 0 1 0 FCF_SEP 2D 10

228,3,3,5 ,7,9, 0,0,0; IP 1

212,3,1,0 .5547 ,0.5000,1001,1.5708,0 .0000,0,0,5.2500,5 1500, 3P 2

0 . 0000 , lHc ,13,7. 0000 , 0 . 5000 ,1,1. 5708 , 0 . 0000 ,0,0,6. 7500

,

3P 3

5.1500,0. 0000 , 13H0 . 005/0 . 1X0 . 1 , 1 , 0

.

5000,0.5000,1,1.5708, 3P 4

0.0000,0, 0,14. 2500,5 .1500,0.0000, 1HA, 0,0; 3P 5

106,1,4,0 .0000 , 5 . 0000 , 5 . 8000 , 15 . 0000 , 5 . 8000 , 15 . 0000 ,

5

0000, 5P 6

5.0000,5. 0000,0,0; 5P 7

110,6.5000,5.8000,0. 0000 , 6 . 5000 , 5 . 0000 , 0 . 0000 ,0,0; 7P 8

110,14.0000,5. 8000,0 .0000,14.0000,5 .0000,0.0000,0,0; 9P 9

S 48G 3D 10P 9 T 1

B - 55
s F FCFTC09 S

DAT S

S

V IGES 3.0 s

S

I Application Protocol Test Case S

Application Protocol: Drafting S

Information: Feature Control Frames S

S

E ENTITY FORM COUNT S

228 0 IS

212 0 IS

106 63 IS

110 0 3 S

S

B This is a test case for the Feature Control Frames Application S

Protocol example. This test case implements the Feature Control S

Frame shown in Figure B5 and labeled as FCF #9. S

S

P Not applicable S

S

R Not applicable S

S

C This test case was prepared as per the IGES Test Case Development S

Committee's "Guide to Developing Entity Test Cases", S

Draft Version 0.2, November 10, 1987. S

S

D IGES Specification, Version 3.0 S

Guidelines for the Specification and Validation of IGES Application S

Protocols, Draft Version 0.04 S

S

H 24-Feb-1988 A Created Test Case for AP Example - R.J. Harrison S

S

L This data was 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

1H ,, 1H ;, 10H0000099999 , 11HFCFTC09 . DAT , 8HHANDMADE , 3H1 . 0 , 32 , 38 , 6 , 38 , 15 , G

10H0000099999, 1 . 0 , 1 , 4HINCH , 8,0. 08, 13H880224. 153000, 0.0001, 14. 2500, G

14HR . J. HARRISON, 24HD0E/Sandia National Labs, 4,0; G

228 1 0 1 250 0 0 000000101D

1

2

3

4

5

6

7

8

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

1

2

3

1

B - 56
228 0 0 o

i

—

1

FCF INFO ID 2

212 2 0 1 250 0 0 000010101D 3

212 0 0 5 0 FCF TEXT ID 4

106 7 0 1 250 0 0 000010101D 5

106 0 0 2 63 FCF_ BOX ID 6

110 9 0 1 250 0 0 000010101D 7

110 0 0 1 0 FCF SEP ID 8

110 10 0 1 250 0 0 000010101D 9

110 0 0 1 0 FCF SEP 2D 10

110 11 0 1 250 0 0 000010101D 11

110 0 0 1 0 FCF_SEP 3D 12

228 ,3,4,5, 7,9,11,0,0 ,0; IP 1

212,4,1,0. 5547,0.5000,1001,1.5708,0.0000,0 0,5. 2500,5.1500, 3P 2

0.0000, 1H1 ,3, 1.5000, 0.5000 ,1001,1.5708,0.0000,0 ,0,6.7500, 3P 3

5. 1500,0. 0000, 3Hn0m, 7,3.7500,0.5000,1001,1 5708 ,0.0000, 3P 4

0,0,9.2500 ,5. 1500,0. 0000 , 7HnO . 1MAX, 1 , 0 . 5000 , 0 . 5000 ,1,1. 5708

,

3P 5

0.0000,0,0,13 .5000,5 . 1500,0. 0000, 1HA, 0,0; 3P 6

106,1,4,0. 0000 , 5 . 0000 , 5 . 8000 ,14.2500,5. 8000 , 14

.

2500,5.0000, 5P 7

5.0000,5.0000,0,0; 5P 8

110,6.5000 ,5. 8000,0. 0000,6 .5000,5.0000,0.0000,0 ,0; 7P 9

110,9.0000 ,5. 8000,0. 0000,9 .0000,5.0000,0.0000,0 ,0; 9P 10

110,13.2500,5 .8000,0 .0000, 13.2500,5.0000,0 0000 o o IIP 11

S 48G 3D 12P 11 T 1

B 57
s F FCFTC10 S

DAT S

S

V IGES 3.0 S

S

I Application Protocol Test Case S

Application Protocol: Drafting S

Information: Feature Control Frames S

S

E ENTITY FORM, COUNT S

228 0 IS

212 0 IS

106 63 3 S

110 0 4 S

S

B This is a test case for the Feature Control Frames Application S

Protocol example. This test case implements the Feature Control S

Frame shown in Figure B5 and labeled as FCF #10. S

S

P Not applicable S

S

R Not applicable S

S

C This test case was prepared as per the IGES Test Case Development S

Committee's "Guide to Developing Entity Test Cases", S

Draft Version 0.2, November 10, 1987. S

S

D IGES Specification, Version 3.0 S

Guidelines for the Specification and Validation of IGES Application S

Protocols, Draft Version 0.04 S

S

H 24-Feb-1988 A Created Test Case for AP Example - R.J. Harrison S

S

L This data was 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

1H ,, 1H ;

, 10H0000101010 , 11HFCFTC10 . DAT , 8HHANDMADE , 3H1 . 0 , 32 , 38 , 6 , 38 , 15 , G

10H0000101010, 1.0,1,4HINCH, 8,0. 08, 13H880224. 153000, 0.0001, 13. 0000, G

14HR . J. HARRISON, 24HD0E/Sandia National Labs, 4,0; G

228 1 0 1 250 0 0 000000101D

1

2

3

4

5

6

7

8

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

1

2

3

1

B - 58
228 0 0 1 0 FCF INFO ID

212 2 0 1 250 0 0 00001-0101D

212 0 0 8 0 FCF TEXT ID

106 10 0 1 250 0 0 000010101D

106 0 0 2 63 FCF BOX ID

106 12 0 1 250 0 0 000010101D

106 0 0 2 63 FCF BOX 2D

106 14 0 1 250 0 0 000010101D

106 0 0 2 63 FCF BOX 3D

110 16 0 1 250 0 0 000010101D

110 0 0 1 0 FCF SEP ID

110 17 0 1 250 0 0 000010101D

110 0 0 1 0 FCF SEP 2D

110 18 0 1 250 0 0 000010101D

110 0 0 1 0 FCF SEP 3D

110 19 0 1 250 0 0 000010101D

110 0 0 1 0 FCF SEP 4D

228,3,7,5,7,9,11,13,15,17,0,0,0; IP

212.7.1.0.

3332.0.5000.1001.1.5708.0.0000.0.0.5.4500.5.5500, 3P

0 . 0000

,

lHj , 5 , 3 . 0000 , 0 . 5000 , 1001 , 1 . 5708 , 0 . 0000 ,0,0,6.7500, 3P

5 . 9500 . 0

.

0000 . 5Hn0 . 8m , 1 , 0 . 5000 , 0 . 5000 ,1,1. 5708 , 0 . 0000 , 3P

0, 0, 10. 2500, 5. 9500,0. 0000, 1HA, 1,0. 5000, 0.5000, 1,1. 5708, 3P

0. 0000, 0, 0, 11. 2500, 5. 9500,0. 0000, 1HB, 1,0. 5000, 0.5000, 1,1. 5708, 3P

0 . 0000 ,0,0,12. 2500 ,5.9500,0. 0000 , 1HC , 6 , 3 . 5000 , 0 . 5000 , 1001 , 3P

1. 5708.

0.

0000. 0. 0.6. 7500. 5. 1500.0. 0000. 6Hn0 . 25m, 1,0. 5000, 3P

0. 5000, 1,1. 5708, 0.0000, 0,0, 10. 7500, 5. 1500,0. 0000, 1HA, 0,0; 3P

106.1.4.0.

0000 . 5 . 0000 . 6 . 6000 . 6 . 5000 . 6 . 6000 . 6 . 5000 . 5 . 0000 , 5P

5.0000.

5.0000.0.0; 5P

106.1.4.0.

0000 . 6 . 5000 .6.6000.13. 0000 . 6 . 6000 . 13 . 0000 . 5 . 8000 , 7P

6.5000.5.8000.0.

0; 7P

106.1.4.0.

0000 . 6 . 5000 . 5 . 8000 . 11 . 5000 . 5 . 8000 . 11 . 5000 . 5 . 0000 , 9P

6.5000.5.0000.

0.0; 9P

110 . 10 . 0000

.

6 . 6000 . 0 . 0000 . 10 . 0000 . 5 . 8000 . 0 . 0000 .0.0; IIP

110 . 11 . 0000

.

6 . 6000 . 0 . 0000 . 11 . 0000 . 5 . 8000 . 0 . 0000 .0.0; 13P

110 . 12 . 0000

.

6 . 6000 . 0 . 0000 . 12 . 0000 . 5 . 8000 . 0 . 0000 .0.0; 15P

110 . 10 . 5000 . 5 . 8000 . 0

.

0000 . 10 . 5000 . 5 . 0000 . 0 . 0000 .0.0; 17P

S 48G 3D 18P 19 ‘ T

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

1

B - 59
NBS-1 14A I REV. 2-80

U.S. DEPT. OR COMM.

BIBLIOGRAPHIC DATA

SHEET {See instruction s)

1. PUBLICATION OR

REPORT NO.

NISTIR 88-3846

2. Performing Organ. Report No. 3. Publ i cation D ate

I JANUARY 1989

4. TITLE AND SU BTITLE

Guidelines for the Specification and Validation of IGES Application Protocol.

5. AUTHOR(S)

Randy J. Harrison; Mark E. Palmer

6. PERFORMING ORGANIZATION (If joint or other than NBS, see in struction s)

national bureau of standards

DEPARTMENT OF COMMERCE

WASHINGTON, D.C. 20234

7. Contract/Grant No.

8 . T/pe of Report & Period C

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

10.

SUPPLEMENTARY NOTES

Document describes a computer program; SF-I8S, FlPS Software Summary, is attached.

11.

ABSTRACT (A 200~word or less factual summary of most significant information. I f document includes a significant

bi bl i o graph y or literature survey, mention it here)

This document provides a background discussion of product data, describes the conce

of IGES (Initial Graphics Exchange Specification) application protocols, specifies

technical content of an IGES application protocol, describes a validation methodolo

for these application protocols, and provides guidelines for the implementation of

IGES application protocol. A key conclusion of the background discussion of produc

data is that IGES application protocols must be developed in order to achieve consi

tent and reliable exchanges of product data within specified application areas.

The technical content of an IGES application protocol includes a conceptual informa

model for the application area with its supporting documentation, an application pr

col format specification with a protocol usage guide, and a set of application prot

format test cases. These test cases must be used in concert with a well-defined

testing methodology.

Since no complete IGES application protocols currently exist, this document describ

a current implementation of an application protocol process that is based on a part

complete application protocol. The document also includes a specific example of a simple application protocol that meets the technical content requirements.

12.

KEY WORDS (Six to twelve entries ; alph abeti cal order; capi ta 1 1 ze only proper names; and separate key words by semicolai

application validation; CAD data exchange; computer-aided design and drafting; data

exchange standards; data translation quality assurance; data translators; IGES; IGE!

application protocols; information management; validation of data translators

13. AVAILABILITY

NT U n 1 1 mi ted

For Official Distribution. Do Not Release to NTIS

_ Order F’-om Suoerin tendent of Documents, U.S. Government Printing Office, Washington, D.C.

20402.

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

14. NO. OF

PRINTED P At 110

15. Price

$18.95

j SCOMM-OC 804.