NATIONAL INSTITUTE OF STANDARDS &

TECHNOLOGY

Research Information Center

Gaithersburg, MD 20899

NBSIR 87-3

A11102 b7fl47'7

Final NBS Report for CALS, FY86

Sharon J. Kemmerer, Editor

U.S. DEPARTMENT OF COMMERCE

National Bureau of Standards

Center for Programming Science and Technology

Institute for Computer Sciences and Technology

Gaithersburg, MD 20899

May 1987

U.S. DEPARTMENT OF COMMERCE

100

.056

#87-3566

1987

C.2

7 O

QC

' OF STANDARDS

NBS^R 87-3566

FINAL NBS REPORT FOR CALS, FY86

Kesearcli i/sformation Center

i^ureau of Standards

Gaithersburg, Maryland 20899

Cluoo

Sharon J. Kemmerer, Editor

% U.S. DEPARTMENT OF COMMERCE

National Bureau of Standards

Center for Programming Science and Technology

Institute for Computer Sciences and Technology

Gaithersburg, MD 20899

May 1987

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

NATIONAL BUREAU OF STANDARDS, Ernest Ambler, Director
-r

‘,^i ' :.' — - y‘-;- -V' 4.,^ ./

^ ';.- -iits^itlaMy.

* '^" \y V'* %-^rU, ,-3MS20 ^ .-: A. >V -_

•

® 0'S sjCJLI Efia

iisw-’taKiAdqli^ -flX ' ,:m«muoob oj B’xosudl^:^^oo

^ a V^- iSHU

. =15

' ' ^ciSstsB »a^I-

^ ;|

• ft “i “ S

r.>3*.el5:»t. b'lViia

^ , x;v.

S ’ m^^^Ot. ' *ir

I s , -

’' -' j^=-

-•'«=•

rbxtpsS baoibisia

"f ^ r -' -^ i3 i q2 fiA •'1

..wT^

^1 .

mfmm' ' ^ _

- 'afasyp-.. •>' i^< v.^/i-V*WT

i‘^,5C';^'“> T" '

, ^

'" - !L .

»<|'r. .. w,.

.' ->>5i' ;. *

*1,' ,.

‘

V V

*

' (»T ’ ‘'’^i.v
FINAL NBS REPORT FOR CALS

FY86

Table of Contents

EXECUTIVE SUMMARY

PRODUCT DATA

Specific Tasks

Product Definition Data Standards, Final Report, March

September 1986

Appendix A,

Appendix B,

Appendix C,

Appendix D,

Appendix E,

Appendix F,

Appendix G,

Boeing/ Supplier CAD/CAM Interface

Standards (available from The Boeing

Company

)

GM/IGES Specification

Hughes/EDSG IGES Requirements

Specification, Version 5

Draft Proposal - Tool Development for

IGES Translator Verification

Plan for Research and Implementation

Testing in Product Data Exchange

Completeness of Product Data Exchange

Documentation for the Testing Methodology

of IGES Translators and IGES Formatted

Data Files

GRAPHICS INTERCHANGE

Specific Tasks

Graphics Standards, Final Report

1 . Introduction

Compatibility of Graphics and Product Data

Standards

Graphics Standards Validation Efforts

Assessment of DoD Needs for Computer Graphics

Standards

Plans and Recommendations

Appendix 1, Computer Graphics Standards

Appendix 2, Feature Comparisons Among Graphics

Standards

IGES Entities as Rendered by Graphics

Standards System

Correspondence Between PDES Entities and

Graphics Elements

Standards for Specific CALS Applications

Short and Long Term Solutions to Raster

vs Vector Problem in CALS

TOP/MAP Computer Graphics Metafile (CGM)

Application Profile (AP)

2 .

3.

4.

5.

Appendix 3

Appendix 4

Appendix

Appendix

Appendix 7
TEXT

Specific Tasks

Textual Standards

Paper, SGML Parser Conformance Testing Methodology

and Framework

DATABASE NAMAGENEMT

Specific Tasks

Database Management Support

Paper, Preliminary Report on Data Management

Standards

CONCEPT PAPER - CALS Representative Systems
EXECUTIVE SUMMARY

r, j L- .1

tht 6fi« 1 ;

ICLl. ^h/9 t^PCTZ tc

NATIONAL BUREAU OF STANDARDS

SUPPORT FOR

DoD COMPUTER AIDED LOGISTIC SUPPORT PROGRAM

FY-86 FINAL PROGRESS REPORT

EXECUTIVE SUMMARY

December 8, 1986

INTRODUCTION

The overall objective of the Department of Defense Computer

Aided Logistic Support (CALS) Program is to integrate the

design, manufacturing, and logistic functions through the

efficient application of computer and communications

technology. DoD requires functional and interface standards

and procedures that will enable the digital interchange of

data in weapon system and automated system contracts, that

will be common to all Services and DLA.

Under an interagency agreement ratified in March 1986, the

National Bureau of Standards (NBS) has provided assistance to

DoD/OSD in support of the CALS Program. NBS identified four

broad categories of standards required to support the

interchange of CALS digitized' technical information:

( 1 ) product data , ( 2 ) graphics , ( 3 ) text , and ( 4 ) database

management. During the year, NBS activities associated with

these four categories have been primarily aimed at:

1. Determining CALS requirements by familiarizing NBS

technical staff with key DoD logistic functions and

CALS demonstration projects:

a. a two day DoD Logistic Seminar, presented by DoD

organizations at NBS on 18 and 19 February 1986,

b. travel to the sites of major logistic activities

in Huntsville, Alabama; Dayton, Ohio; Los

Angeles, Port Hueneme, Long Beach, and San Diego,

California,

c. review of many CALS documents such as the Service

and DLA implementation plans, the CALS

demonstration project descriptions, the report to

Congress, etc., and

d. a two-day workshop on Automation of Technical

Publications & Engineering Data Repositories,

held at NBS, which included presentations on key

projects in DLA and the Services, along with NBS

1
staff presentations on current and emerging

standards for data interchange.

2. Providing direct technology transfer by briefing DoD

personnel, contractors, and other interested parties

on federal, national, and international

standardization efforts that are expected to support

CALS objectives.

3 . Identifying and recommending a preliminary set of

standards required for data interchange in support of

CALS.

4. Developing a plan for continuing support of the CALS

program by assisting DoD in the ‘ effective use of

relevant standards (enhancing, tailoring, determining

performance, etc.)

FINDINGS AND RECOMMENDATIONS

The following recommendations, grouped into four general

areas, identify actions that NBS believes will help to assure

the success of the CALS development strategy recently

published by DoD. Included are actions that lie within the

technical expertise of NBS, and actions that NBS believes

must be undertaken by DoD and industry cooperatively.

Building upon the foundation laid during the past year, the

CALS Program should during FY-87;

1. Extend the planning process to meet both near-term

and long-term implementation requirements.

2 . Document interactions among CALS functions and

information processes to support implementation

planning.

3. Develop core requirements, standards, and

specifications to meet CALS application needs.

4. Establish the environment and tools needed to

facilitate use of CALS standards and specifications,

and to ensure the effective implementation of core

requirements

.

Specific findings and recommendations in each area are;

1. Extend the planning process.

Findings

;

o The CALS development strategy provides an

implementation concept, but a detailed implementation

2
process must still be articulated.

o Industry and government actions to develop and

implement CALS technologies require close and

continuing coordination.

Recommend FY-87 actions:

o The DoD and Industry CALS Steering Groups should

clarify the organizational roles and relationships

cutiong industry, OSD, the Services, and DLA.

o A framework for development of CALS requirements

and for phased implementation of CALS capabilities

should be published.

o Industry should organize a consortium or other

cooperative mechanism to focus on the major system

integration and technology issues involved in

defining and implementing the industry portions of

Phase II of CALS.

o The NBS support program for FY-87 should focus on

tasks which meet the priority requirements of DoD and

industry for CALS Phase I core elements and which lay

the foundation for Phase II core requirements.

o DoD and industry projects to develop,

demonstrate, test, and prototype CALS capabilities

should be effectively coordinated and given

appropriate priorities in the DoD CALS Plan. DoD

should establish procedures to prevent unnecessary

duplication in CALS development efforts.

2. Document CALS function and process interactions.

Findings

o The integrated design, manufacturing, and

logistics environment of CALS requires rigorous

definition of functional and information process

interactions.

o Effective and efficient implementation of CALS

requires a structured approach for selecting areas of

development focus.

Recommend FY-87 actions:

o DoD and NBS should define a technology and

standards baseline for near-term (Phase I)

implementation of CALS capabilities.

3
o DoD should plan and implement a strategy to apply

cost/benefit analysis, both at a corporate level and

within each Service and DLA, to articulate the

benefits of the CALS approach of standardizing

interfaces between technical data systems, rather

than the systems per se.

o DoD and NBS should develop, analyze and maintain

a high level CALS data model as part of the overall

CALS framework.

3. Develop core requirements, standards, and specifications.

Findings

;

o Several industry standards (SGML, IGES, and CGM)

provide capabilities needed to support CALS

applications, but the potential role of many others

examined during the past year is not yet well

defined.

o The standards recommended for near term CALS use

need selective enhancements, commonly agreed to

implementations, and consistent application guidance.

o Interactions among standards, such as integration

of document text and graphics, must be addressed as

part of a comprehensive package designed to satisfy

specified functional and user requirements.

Recommend FY-87 actions:

o NBS should continue analysis of CALS

requirements , development of suitable standards , and

development of implementation and application

guidance to meet CALS needs.

o DoD should develop and validate near term (Phase

I) CALS core requirements for highest leverage

logistic application areas, incorporating recommended

industry standards for digital exchange of data. In

support of the Phase I core requirements, NBS should:

Develop DoD application guidance for SGML,

IGES, and CGM, and incorporate it into an

extended MIL-STD-1840

.

Resolve issues regarding nonstandard

implementation of digital exchange capability

(e.g. CCITT Group 4 raster scan implementation).

4
o The Services and DLA should extend and tailor the

initial Phase I core requirements and updates (Phase

I.O,, I.l, etc.), and undertake accelerated programs

to test, demonstrate, and prototype these

capabilities.

o DoD and industry should undertake a preliminary

definition of long term (Phase II) core requirements

to achieve the CALS functional and system integration

requirements of the 1990s.

4. Establish the environment and tools for effective

implementation

Findings;

o Development of validation approaches is crucial

to the successful implementation of the recommended

CALS standards.

o High quality and timely availability of CALS

capabilities, and good return on investment for

developers and users are essential for CALS to

succeed.

o Packaging, marketing, and two-way technology

transfer are essential for industry and government

acceptance of CALS technology and standards.

o Legal and contracting aspects of digital logistic

technical information access and delivery are not

fully defined.

Recommended FY-87 actions:

o DoD, NBS, and industry should jointly develop

validation procedures and testing programs for CALS

standards and for delivery of logistic technical

information. As a starting point, NBS should provide

a strategic plan for validation mechanisms for

implementations of IGES, SGML, CGM and other

recommended CALS standards.

o DoD and the CALS Industry Steering Group should

resolve legal and contracting issues associated with

the transition from paper-based to digital weapon

system support processes.

5
- - ' } J ^

H&d .

- r/ii *>.. A L ^ S T i .»S j* tr/p^i^-'vf x/^t m

et

' Vi . ' 1 JL

• a®J; 5iXi4attso

r>

i |. j

• «'v-i'«w % 9 ' I 'r ' ”“ ,T^7^- . -.r‘W^ 1^'^ iy s" ^ ”” ^

-TM' - •• —^ " '_ " — ^ ''*„ •:''!«o-i-x tic>^aj;^'.':

^^

iitr’jo.ligfu.'i avPlitOL a}

' ,{^»

bfi.^- irx^jftTiTso’iirvnd

1»; / •: a .aoits-jfiamsXqaU , 4

loliDiuri 4>v^‘irfOi: '^j

3tl^ I iE

r%, -;*-•>’ i." ^ i:; >;.

*

e

‘3 ' z

*1 '^>- .«fciAD06:fe *?J:Xd

I;c>.. J-CuH -P*> or,. .: jjmi

<9

,Ti«3rw

' • .. 4.-7 I9 ?.al?o»waTO f»rji X».p^ o >.|—

'" - • , ^ . .AIK _ L f — — • . -A kffilH <3T<:?! is?-js/ v'li -'iXW^ .^iii%

‘ <«»uj5 r?oi^|p5^n; 4«r:nno&d

0|p«4»r|T*i4>? < -jS

w *. -,*. 3 .-.“ t *» j- —'^.Artl* «»,i «» aiodnsi

jBpi*;: -’.5* . ‘-fe 'V o^'WSeeiOQ*.

!j 4 '-xJj -Si

'!^l0:i3a ii-iWip'!, ...’.sia’t” ’ ?^' >;,i'ift«u«ru'j :»’• ii:T'A.,

' '^iffiB ,

' ' ‘

. .•» -.£5

' •V.-A ii't, 5 '*J!^»^„' £•. " " * ^9 _ '-- '' -•itUfV

ei)l4iwi*?E ?«A0 b»lvi»:iinDp»i •>’1

..® v<:il£i’ tflie .V© J?tlJLT£CC,.|t^ . f-XMkr*Cld^ Ov

;,. dJ i

-' ^ i^Xa ood4> f i*ini - i MO jp -.^ - -*v 1 $ ’ ,r^;?^p:l» oJ

’ ,'¥ ROi'l 4r:>iJ* -:.-:c oA.^

J-. ’>

V KC

rm

a f

:

. t'r
(I,

l>.: f

ft C

1 . t. ^ fi) *

^

'

;: ,

' fei*

; a ,i ^ J i .b ^

, : It OuJ : 5 • . ^ 1.#.. PRODUCT DATA

c Cu |5^^f ^ i

* f *

'' <

, v*!r;oui tf/r.

'. »;uc^ 5C«.‘<i4'

p? o c V 0 : r ttut _ r-. . #• '

riu;t;.: . iv'. 4I1

I.l PRODUCT DEFINITION DATA INTERCHANGE

SPECIFIC TASKS

FT 86

1. Asaeaa DoD needa for Product Definition Data (PDD)

interchange atandarda;

a. Identify PDD requireaenta in terma of CALS applications

(e.g. aparea re procurement

)

b. Recommend a aet of PDD interchange standada for various

product classes and logistic applications. Assess

specific near and long term benefits, limitations and

impedimenta to adopting these PDD interchange standards

for DoD use.

c. Assess specific current, intermediate, and long term

capabilities to apply PDD interchange standards to

competitive re procurement of spare and repair .parts for

various product classes. Include an assessment of how

' such standards can be applied within legal ccmpetitive

procurement constraints (DAR, FAR, Congressional

direction , etc.).

d. Identify and prioritise critical R&D issues in the

development and application of PDD standards. Assess

technical risks and provide rationale for the assigned

priority. -

e. Develop a plan to expedite the development and

implementation of- PDD interchange standards for CALS

based on the above findings.

Deliverables

:

2 .

Report to CALS Steering Group on tasks a-d (preliminary

report 3 months after go-head, final report at 5 montns

Plan for PDD area (outline 3 months after go-ahead, dr a plan at 6 months, firm plan at 3 months)

In parallel with tas< 1.1.1 assess the f

issues, and develop an issue paper on ea

^ i e- i ^ 2

Potential advan

other graphics

CALS appl i ca t

i

0

ages and disadvantages of

n t e r 0 h a n g e s t a n d a r d s ( G K S , s other t h a n e n g i n e e r i n g d

G E S V e C G M , e

a w 1 n g s

s us
b. PDD standards for electronics.

»c.. Drawing scanning systems and standards.

d. Extent to which IGES technical issues (validation,

flavoring) can be expected in PDES and other PDD

interchange standards.

e. Approaches for supplementing near term and intermediate

PDD standards with DoD specifications to ensure that

product definition data contains, at a minimum, all the

needed information currently provided in hard copy

formats

.

Deli verables ; Separate issues papers ( i ncr ement all y delivered within 6

months after go-ahead).

3. Accelerate PDD standards development and validation efforts

where needed to meet CALS schedule objectives:

a. Publish a comparison of Indus try/ go vernment IGEs

procurement practices and entity capability target dates.

b. For IGES applications recommended based on task 1. 2. a,

develop defined subsets of IGES entity types (this mi ght

include subsets for mechanical engineering drawings,

electronic printed wiring assemblies, finite element mesh

models, technical publications, etc.).

0 . Assess priorities for future definition of ICES entity

subsets, and provide a supporting rationale.

d. Develop and publish a draft specification of data

elements for labeling and identifying ICES files

del i ver ed to DoD .

e. Develop and coordinate Version 4.0 of ICES to induce’

solids model data exchange capability. Develop

supporting documentation and represent DoD interests to

gain acceptance of ICES as an ANSI standard.

Deliverables:

Quarterly status ’'eports and final

months after go-aheac).

Assess ICES translators for interrelationships and

interactions between entities for various combinations of lAl

10
systems to reduce the need for manual intervention. or

"flavored" translators;

a. Assess, the extent of "flavoring" present in various

vendor implementations and identify^ with supporting

rationale, which are correctable and which are not.

b. Review government (e.g. Sandia labs) and industry (e.g.

General Motors) experience and assess the feasibility of

obtaining 100!S automated data transfer with IGES.

Identify critical areas of needed work.

c. Assess alternative approaches to conducting validation of

IGES translators. Recommend a DoD approach for an IGES

translator certification program. Estimate the scope of

such an effort.

*d. Develop and publish a set of guidelines for testing and

validating IGES translators.

•e. Prototype a utility program to check conformance to a published subset of IGES entity types. Recommend an

approach to develop a comprehensive ut.illty program to

check conformance of all approved entity types for

specific applications, and estimate the scope of such an

effort.

f. Evaluate existing prototype programs to translate one

specific vendor and version or level of IGES file to

another "flavor" of vendor implementation. Recommend an

approach for a comprehensive program to handle a greater

range of vendor equipment and translators.

g. Prototype a utility program to check conformance to a specified data organization method.

Deliverables : Quarterly status reports and a final technical report (8

months after go-ahead).

As DoD needs are determined, via the initial task, adjustments may ha

made to the remaining tasks. Tasks identified by an asterisk (*)

appear beyond the funding resources for FY36. These tasks will be

accomplished in FY36 if possible. If not they will be deferred to F

T enta t ive FY 37 and 8 3 T a

s

FY 87 and 88 tasks will be firmed up in the tactical plan

delivered six months 'after FY 86 go-ahead. Tentative tasks
include

:

1. Update of PDD standards plan.

2. Publish a specification on the use of layers for organizing

the data in an IGES file.

3. Develop a program for automatically correcting incorrectly

organized files and for generalized editing of data

organization method.

4. Publish PDES Version 1.0 document.

5. Publish a working draft of an international standard for

product data exchange (STEP).

6. Develop a utility program to convert IGES illustrations subse

data into the Computer Graphics Metafile Format and publish

an analysis of expected benefits.

7. Develop an Issue Paper on Configuration Control.

8. Publish Version 5.0 of IGES.

FY88

1. Publish analysis of error propagation after successive CAD

data exchanges through IGES translators.

Develop validation techniques for solids model data exchanges

and test cases to intentionally stress system limits.

2 .
000 COMPUTER AlOEO LOGISTICS PROGRAM

FINAL REPORT OF THE NATIONAL BUREAU OF STANDAROS

For Fiscal Year 1986 - March - September

PROOUCT OEFINITION OATA STANDAROS

The CALS program objective for digital product data Is to have

effective exchange of data throughout the life cycle of weapons

systems development and deployment; an exchange using computer

readable datasets describing the systems* their individual piece

parts* and their product support data. A central issue here is

the technology for digital representation of product data In its

many forms: illustrations* drawings* 30 wire frame models*

surfaced models* solids models* and complete product models.

Two terms will be used* product definition data and product data.

Product definition data (POO) denotes the totality of data

elements required to completely define the product. Product

definition data includes the geometry* topology* relationships*

tolerances* attributes* and features necessary to completely

define a component part or an assembly of parts for the purposes

of design* analysis* manufacture* test* or Inspection. Very

little If any process data Is included* with the exception being

conformance to a standard (MIL-STD) or reference to processes

I I Ice a heat treat specification. The product definition is

expected to be sufficiently complete as to enable the generation

of all downstream process data.

Product data is more inclusive than product definition data.

Product data includes ail of the product definition data plus a larger class of data elements necessary to fully support the

product for ail applications over Its expected life cycle.

Product data is sometimes referred to as product model data.

The NBS CALS Program for product data exchange addresses the

exchange* archiving* and future use by 000 of product model data.

Major thrusts of this program are the development of a comprehensive program of testing and evaluation* the

identification and solution of problems encountered in

intersystem data exchange* research into the unique requirements

for long term archiving* the development of software tools to

assist users In maicing routine production use of digital product

data* the continued development of new applications capability*

the validation of new applications areas* and the acceleration of

work directed toward maicing the use of complete product model

data poss i b I e

.

1
Throughout the DOD and Its partners in Industry, an Increasingly

larger number of computer aided design systems are being used In

all phases of design, analysis, manufacture and test of weapons

products. Over a hundred vendors offer these CAD systems. It Is

natural that different DOD activities or different companies

would choose different vendor systems to meet their varying

needs. Hence, there Is a requirement In the normal course of

business to be able to exchange the digital part models that are

developed on one system to be used on another system.

Estimated at $4.3 billion in gross sales for 1 986, the CAD

Industry Is expanding quickly, and the capabilities of CAD

systems are similarly changing. But the need for part model

exchange among these systems has not diminished. Rather, with

over 10,000 new CAD systems being sold each month, portability of

data Is even more Important to the DOD and Its contractors each

day. The exchange of digital product models Is expected to

become as commonplace In the 1990's as the exchange of

paper-based engineering drawings Is today.

Since the databases of different vendor CAD systems are

Incompatible with one another, a direct transfer of digital

product models Is not possible. While converters from one

database to another can be written, the only rational long-range

solution on a company, national, or global scale lies In the

development of neutral data exchange formats that are wel I documented, standardized, and Implemented. Thus, the solution to

these data exchange problems for both t*he DOD and the Industry

lies In the effective development of consensus approaches through

close collaboration with s t andar ds-mak I ng groups like ANSI, and

with Independent groups like the Initial Graphics Exchange

Specification (IGES) Organization, the Air Force Very High Speed

Integrated Circuit (VHSIC) program, and the Electronic Design

Interchange Format Organization.

It is essential for CALS to fully utilize the resources of these

organizations to develop, review, and endorse needed pieces of

the technology. Digital product data exchange cannot be

developed by any one party. Nor can any of the parties afford

the cost of a mistake In choosing the technical direction.

Work during FY86 In the area of product data exchange has

centered on quantifying the present and the future needs of the

DOD, Identifying the problems with the use of IGES In the DOD

environment, generating a series of technical Issue papers, and

developing a detailed plan of activities for FY87-88 that will

assure an acceptable level of quality In IGES translators and

diffuse the competence In data exchange technology throughout

DOD

.

2
The following sections represent woric done toward Task 1.1 of the

NBS statement of work in support of the DOD CALS initiative.

Deliverables for this period include those for Subtasks i.l.1.a b c d e, 1. 1.2. a d e, 1.1. 3. a b e, and 1. 1.4. a beg. Information

contained in these sections is the result of NBS research, CALS

workshops, formal IGES meetings, telephone Interviews, and site

visits to 000 installations at China Lake, Carderock, Huntsville,

Dayton, Los Angeles, and San Diego. included also is the

experience gained through numerous discussions with DOD

contractors on their successes and problems with digital product

data exchange.

Task i.1.1 Assess DOD Needs for Product Definition Data

The CALS team at NBS made several site visits to better

understand how 000 and its contractors do business. Much

Interest in digital product data was evident, but only a few

instances were noted of the exchange of digital product data:

DSREDS/EDCARS : A Joint military program to store engineering

drawings. System accepts CCiTT Group 4 or paper Input. Data Is

stored on optical disks in a compressed format. Plans include

the Input and output of IGES data, but do not include any

capability to convert the IGES data to a- form for reviewing or

revising.

Pershing: An active user of digital product data. 60% of its

engineering drawings are stored in IGES format. Drawings are

maintained by the prime contractor who uses a system called

MiNGEL to manage and defiavor the IGES files. There are

questions about access and control of the digital data. There is

also an effort to convert existing drawings into IGES format.

ATOS: An Important lead project for CALS. Tech Orders are entered

Into the system using SGML for the text and IGES for the

technical illustrations. A special subset of IGES entities is

defined for these illustrations and there is a parallel effort

to incorporate these entities into a formal IGES subset. There

is a critical need for a validation program to test vendor data

for compliance to the IGES and SGML standards.

PDDI: The Product Definition Data Interface is an R&D project of

the Air Force CiM Branch. Work has proceeded since late 1982 on

the specification, pilot implementation and use of complete

digital product data models. The work of the PDDi project is

being integrated into the PDES efforts.

3
RocIcwaM B1-B project: The enormous size of this program has

forced Rockwell and Its subcontractors to automate their systems

and integrate digital product data into them. Engineering

drawings can be directly placed Into Tech Orders and modified for

display. They believe that their ability to deliver digital data

packages significantly exceeds the government's abl I Ity to

receive and use them. (EDGARS and ATOS are significant

exceptions). One Interesting point was that their efforts to

automate caused criticism by a government inspection group

because they were not following accepted procedures which

presumably are established to deal with paper-based product data

(drawings) and not digital datasets.

Subtask 1.1.1a Identify POD requirements

This element of the work plan Is designed to Identify DOD's needs

for product data exchange and archiving. Applications areas are

enumerated and characterized by their Information content.

Logistics requires the ability to deal with digital product data

for four generic applications:

1. Internal transfer of product data models among DOD

component s

2. The acquisition of new- manufactured parts/systems

3. Data transfer to systems producing technical

illustrations In documents referring to manufactured

par t s/systems

4. Archival storage of parts/assembly Information

Requirement 1 - Internal Transfer

For many of the same reasons that engineering drawings are

exchanged today, digital product data models will become

prevalent In the near future. This use, however. Is not easy to

categorize since the range of applications Is extremely large.

Missile nose cone geometries, tank tread designs, footware sole

pattern, machining geometries, technical Illustrations and

architectural floor plans each have their own requirements for

data content and organization. Some applications, such as

drawings, make use of simple modeling techniques such as wire

frame geometry while more sophisticated applications such as tank

vulnerability analyses require a solids modeling approach.

The Impending Navy procurement of CAD workstations recognizes

that five separate applications of CAD systems exist and that any

one vendor system cannot effectively serve all applications.

4
Hence, the Navy strategy is to make multiple vendor awards and

require IGES for Internal transfer of product data among the

dissimilar CAD systems; through IGES at first and then through

POES as it proves Itself capable.

Numerous internal transfers of product models are found In R&O,

prototype design, overhaul, and retrofit planning. Here the

weapons system, assembly, or facilities design Is analyzed In an

"as built” configuration and modifications are devised and

tested. Occasionally, a physical model is built In a prototype

shop to test simulated performance. Designs, of course, must be

reviewed by ail levels of management. Frequently, small lot

manufacture is done In house; as with submarine propellers at

Philadelphia Naval Ship Yard or howitzers at Rock island Arsenal.

Every one of these transfers of product Information Is a candidate for digital exchange in the immediate future. Ail that

is necessary Is to thoroughly test the applicable links and

educate the appropriate personnel. While this Is not a trivial

task, it is finite, predictable, and easily Implemented.

Requirement 2 - Acquisition of Parts or Systems

The second area of concern is the purchase by OOD of manufactured

parts, assemblies, or whole systems. Recognizing that DOD

maintains life cycle control over these purchased items,’ digital

product data becomes an Important consideration In the

contractual relationship. Here the data follows the product from

concept through detail design, engineering, manufacture,

production, test. Inspection, and deployment. The data package

goes through repeated exchanges between primes, subs, government

project managers, test labs, and consultants.

This external transfer application of digital product data is

equally as large as Internal transfer from the viewpoint of

application areas and data content. But in dealing with dataset

transfers In a contract situation, the problem Is compounded with

questions of data rights, liability, and dual authority.

While there may be many issues raised as to data rights. It is

believed that the use of digital transfers introduces no change

over the traditional use of engineering drawings. But Invariably

there will be contractors that say, "You can have my drawings but

not my CAD data bases." As to liability, the Issue becomes more

cloudy. if the data exchange is perfect. It seems there is no

more of a liability problem than when a drawing is furnished.

5
However, the question of liability for wrongful or Incomplete

Information as a result of less than perfect software translators

Is difficult to prejudge.

Intriguing questions abound on the Issue of dual authority - does

the drawing or dataset take precedence? The formal engineering

drawing of today Is still the authority for product definition.

Steeped In tradition, codified by ANSI standard, tested in the

courts and cited by MIL-SPEC and MIL-STD, the drawing will remain

a useful tool so long as man wishes to interpret the geometry,

topology, tolerances, and features of a product design. Yet few

will argue that someday we will place far more importance on the

exchange of digital product descriptions than we do of paper.

Drawings will become a by-product serving only to aid human

understanding of the received dataset, not serving as a primary

method for Information exchange; however, no one is able to cite

exactly when this will happen.

The term "dual authority" alludes to the Interim period of time

when datasets and drawings are both In prevalent use for data

exchanges. Which dataset should take precedence If an

Inconsistency Is found between them? Experience Is that this

happens often enough to require serious consideration. One

Instance was reported In which digital Information In IGES format

was In typical use. A contract definition of the prime authority

was not provided. A last minute change to a critical dimension

was made to the text note of a linear dimension In the CAD

system, by the sender, rather than by modifying the part geometry

that was being represented by the dimensioned drawing. Since the

part was manufactured from the received geometry rather than from

geometry created from the received CAD generated drawing, the

part was wrong. Negotiations between sender and receiver In this

instance placed the liability with the sender.

Most contracts still cite the drawing as the prime authority;

however, the Boeing Commercial Airplane Company Is taking the

lead In citing the dataset as prime authority. While this Is

primarily done with families of parts of a non-critical nature,

the application will most certainly spread as experience Is

gained. A booklet describing Boeing's contractual ground rules

is reproduced In Appendix A.

Requirement 3 - Data Transfer for Technical Illustrations

Much work In this last year has addressed the resolution of

problems with the digital exchange of technical documentation.

The ATOS project In conjunction with the IGES Technical

Publications Committee has developed and tested the section of

MIL-STD 1840 which uses a subset of IGES for the exchange of the

Illustrations. This Is quite appropriate since many of these

Illustrations are derived directly from the 3-D CAD product

6
tnodei. The technique is recommended a i so by the Airilnes

industry Association - Air Transport Association Joint committee

on Technicai Pub i i cat i ons , for exchange of documentation from the

aircraft manufacturers to the commercial airline companies, e.g.

between Boeing and United.

Requirement 4 ^ Product Data Archiving

If there Is any one requirement unique to OOD, it is the need for

archiving, or long term storage of product data. Present use and

cumulative experience with digital product data has been in the

area of exchange. Yet, I lice most government agencies, DOO has

significant investments in data archives which are necessary to

support its deployed forces. An almost unimaginable tens of

millions of drawings are stored in data repositories dating bacic,

for Instance, to the recoil mechanism on the Civil War gun ship.

Monitor. The problem as we approach storage of digital product

datasets. Is not particularly with the digital media or with the

volume of information (although these do present challenges).

Rather, the problem lies in satisfying the objective of being

capable sometime [n the future to achieve complete transfer of

ail information possible to the receiving system. This is hard

enough to do presently when complete Information can be obtained

» about the sending system. Archiving presupposes that the only

information available is what is recorded on the retrieved file,

and nothing can be assumed about the nature of the receiving CAD

system of the future.

A ready solution is not at hand, and few companies have given

serious thought to this problem. In characterizing the

information content of a digital product file for archiving. It

would be safe to theorize that in addition to the entity content

of the exchange file in the application area specified,

additional data might also be included to record how the

application information was mapped into the IGES entitles. But

this is still an area of research.

Requirement 5 - Transition from Paper to Digital

There is also a need to allow vendors who do not have modern CAD

systems to be able to do business with DOO. Essentially this

means the government must continue to deal with blueprints and

aperture cards for the foreseeable future. At a minimum, the

government contracting process should maice provision for the use

of data centers where drawings could be converted Into digital

datasets or datasets into drawings. It Is expected that the need

for paper-based product data will steadily decrease as an

integrated digital environment becomes established.

7
Sub task I . 1 . 1 .

b

Recommend and Assess POD Standards

This element of the work plan is Intended to recommend a set of

PDO interchange standards for various product classes and

logistic applications, and to assess specific near and long term

benefits, limitations, and impediments to adopting these PDO

interchange standards for OOD use.

There are currently a number of national efforts to develop

product data standards. In the area of mechanical products there

are two; the IGES data exchange specification and the PDES

product data exchange specification. I’GES has also addressed the

area of printed circuit board products. Two efforts exist In

the area of Integrated circuit products; the Electronic Design

Interchange Format (EDIF) and the Air Force sponsored VHSIC

Hardware Definition Language (VHDL)

.

These evolving standards, IGES, PDES, EDIF, and VHDL should be

the only standards efforts adopted by DOD. Others such as APT,

iPC D350-2, and COMPACT are good standards for their area of

application, but are not product representation formats.

Primarily they address the process requirements to generate

control data for automation equipment. As such, they are can be

derived directly from the product data formats or with the help

of manufacturing engineers and part programmers. Their use

varies with the production shop.

Any meaningful evaluation of these product data standard efforts

must take Into account several facets of a successful work

effort ;

1. application area

2 . matur I t

y

3. standardization status

4. degree of Implementation

5. resource commitment

While most of these classifications are self-explanatory,

maturity and resource commitment will be elaborated upon.

Maturity means a measure of completeness and technical worth as

proven by time, and Industry consensus. Resource commitment has

to do with the number of people that stand In back of a specification to fix It If necessary, or to extend It to new

capabilities. Commitment also addresses whether the group has a long term pledge to stick with the area or will be disbanding as

soon as the paper Is published or the funding runs out.

8
Area of App i i cat I on

IGES and POES have primary application to mechanical, finite

element, electrical PCS, and AEG models. EDIF and VHOL refer to

iC products. Certain overlaps are noted in iC and PCS between

EDIF and IGES, but NBS is working toward a near-term resolution

of these problems.

Standardization Status

The only specification for product data exchange currently

accepted as a national standard is IGES.

IGES Version 3.0 is currently being reviewed by ASME Committee

Y14.26 as a new ANSI Standard with an expected approval In the

third quarter of 1987. A thorough discussion of IGES Is given

under Subtask 1. 1.2. a. PDES is expected to be available in preliminary review form by

the second quarter of 1987 and in a working draft by the fourth

quarter of 1987. After being passed by the technical committees,

it will be submitted to ASME Y14.26 for national standardization

and to ISO TC184/SC4 for International consideration. A thorough

discussion of POES is given under Subtask i.1.2.a.

Presently, the EDIF committee Is a i i gn i ng . i t se i f with the IEEE

Data Automation Standards Committee, the ASME Y14.26 and with the

Electronic Industries Association. No timetable is known for

achieving a national standard on EDIF 2.0.

Ma tur i t

y

IGES started In 1979. Version 1.0 was published In early 1980

with Version 2.0 available in 1 983. Version 3.0 came out in

April 1986 and Version 4.0 is scheduled in the second quarter of

1987. Version 1.0 was approved as an ANSI Standard in 1981 and

Version 2.0 was evaluated favorably under a $500K Air Force

contract in 1982-3. All improvements suggested in these reviews

have been coordinated into the specification and are reflected in

the present version. IGES Is production worthy and useful for

transferring part geometry and attributes between different CAD

systems. Though IGES has known problems, primarily with the

quality of vendor translators. It is being used in production at

a large number of companies.

PDES is still In the R&D stage, but offers the promise of being

able to describe the complete set of information needed to

manufacture a part. PDES is not meant as a replacement for IGES,

it is seen more as an advanced technology. it must be

recognized, however, that a workable implemented PDES capability

9
Is still a couple of years away from quality vendor

I mp I emen t a t I on

.

The EDIF activity began In November 1983 and Is finishing Version

2.0 which Is to be released In November 1986. The EDIF

organization, like IGES, numbers around 100 quite active

contributors, with a larger group (around 600) seml-active.

Degree of Implementation

IGES has been Implemented for at least two years on every major

CAD system marketed In the U.S. with over a 1% market share by

gross sales. EDIF Implementations are available on CADNETICS

and VALIDLOGIC.

Subtask 1.1. 1.C Assess Procurement Applications

This element of the work plan Is designed to assess specific

current, intermediate, and long-term capabilities to apply PDD

Interchange standards to competitive reprocurement of spare and

repair parts for various product classes.

To make use of digital product data In reprocurement actions, the

requirements for a neutral, archival quality dataset must first

be understood, and then the digital data Itself must be made

available. The first step, understanding the requirements of an

archival quality dataset, requires more experimentation and some

RStD addressing extent to which different flavorings presently

exist among CAD vendors, and developing mechanisms for minimizing

their Influence. The second step, making the data available for

reprocurement actions. Involves procuring the right data with

each new contract, generating the data at optimal cost on spares

contracts, or generating the data In-house during a redesign or

remanufacture activity.

What Is needed are specifications for each application area

subset of IGES so that datasets can be procured and reissued as

part of orders for spares procurement with the confidence that

the data can be successfully utilized. The problem of dual

authority and the need to establish the precedence of datasets

over drawings was discussed earlier. It Is recomended that the

furnishing of IGES data as part of contracts for spares

production should Initiate with the IGES datasets being provided

as Information only, until such time as digital data Is found to

be unquestionably reliable.

These application area subset specifications must be developed

specifically for the application being addressed In the data

exchange. Procurement specifications have been developed with

this principle In mind by the Navy Sea Systems Command, by

General Motors, and by Hughes EDSG. The procurement

10
specifications prepared by GM and Hughes are given in Appendices

B and C.

The question remains as to how the i generated. Two avenues are possible:

GES datasets wl 1 1 be

1 . An optional specifi cation can be attached to each

procurement of spare parts. Th is spec would say that

If the contractor uses CAD i n the contract, the

government offers to purchase the iGES flie for an

extra fee provided It passes certain acceptance tests.

2. The contract for spares could be processed In-house by

a government facility, provided they use CAO to model

the part and agree to furnish the IGES file along with

the finished parts. As above, the iGES file must pass

certain acceptance tests.

Both the procurement of product data as IGES f i les and the

testing of translators requires an appreciation of application

subsets. Each new application area in IGES will require a definition of information content through format modeling

techniques, a specification of how this Information is

unambiguously mapped into or represented by the IGES entities,

and a definition of the IGES entity subset for the application.

Also needed will be a series of test cases, a method for

organizing the data within the iGES file, and demonstrations of

intersystem exchange. Already several of these subsets are being

prepared by committees of the IGES organization or by private

companies. The Electrical Applications Guide is one example in

the PC board area and MIL-STD 1840 Is another In the technical

i i I ust r a t i ons ar ea

.

In February, the Navy circulated a draft Request for Procurement

on new CAD systems that reflects their intent to make frequent

use of digital product data. A detailed, mandatory IGES

requirement is included. NBS personnel have worked with the Navy

to refine these specifications and develop needed verification

procedures

.

Legal issues were investigated through a review of the 1985 CALS

panel report and through collaboration with the US Navy CAD

procurement effort, with the DOD MIL-STD Standard 1840 project

and with Hughes and General Motors on the development of uniform

CAD iGES procurement specifications.

Subtask 1.1. l.d identify and Assess Critical R&D issues

This element of the work plan is designed to Identify and assign

priorities to critical R&D issues in the development and
application of POD standards. It also assesses technical risks

and provides rationale for the assigned priority.

IGES Test ing

Several potential areas of R&D are associated with the

development of IGES testing methodology. The work would lead to

the development of a rigorous set of software utilities to assist

with the validation of translators and procured datasets.

Appendix 0 contains the details of one proposal to NBS for this

work. Work is also needed in the application of artificial

Intelligence techniques to Increase the degree to which the

results of formal testing activities are automatically

Interpreted. Current practices require the expenditure of

considerable time in the manual review and comparison of data

listings In order to accomplish the evaluation.

1 GES Data Archiving

The experience to date In using digital product data has been

reasonably successful. Yet this has'^oniy been the result of

careful planning and testing of the data paths used. The effort

has been slow because of the need for personnel Involved to

understand the I d I osyncr ac I es of the CAD systems and to develop

competence In using the translators. Success can be attributed

to the collaboration of sender and receiver. This is a reflection of present practice world -wide and underscores that

the present use of digital product data Is for exchange.

The term ''exchange'* denotes an activity characterized by the

following conditions:

The data transfer occurs at a single point In

t i me

Complete Information Is available on the two

computing systems Involved

Sender and receiver can communicate to solve any

problems that are encountered

However, the problems envisioned in the DOD CALS arena Include

not only "exchange" but also "archiving" of product data.

Archiving Is a much more demanding activity. Archiving Is

character I zed by

:

Data transfer to a receiving system at some

relatively unknown future point in time
Only limited information known about the CAO

system and the computing environment which

prepared the product data

Complete information available only on the

receiving system

- Receiver acting alone must resoive any problems

that are encountered

Generator of product data files has no real vested

interest in assuring that data is complete and

accurate (Future use of the data may not be the same

as when the data was prepared. For example, data

produced for human consumption as an engineering

drawing may be needed in the future for NC data

gener at ion.)

As can be seen, the archiving problem is more severe than the

immediate exchange of data. in order to make archiving

achievable, detailed guidelines and software tools are needed to

analyze ail datasets and assure their data integrity before they

are accepted and placed into archival storage.

Subtask 1.1. 1.e Develop Plan to Expedite Standards Development . This element of the statement of work is designed to develop a plan to expedite the development and implementation of PDD

interchange standards for CALS, based on the above findings.

A plan to expedite the development of product data standards is

outlined in figure 1 and more fully presented in Appendix E. The

plan is an expanded version of the plan developed by the ICES

Committee to guide the development of both IGES Version 4.0 and

PDES Version 1.0. That document constitutes a formal long-range

plan for the IGES Organization, approved by the IGES Steering

Committee on March 26, 1986. The plan presented here also

reflects an increased emphasis on testing of translators,

development of utility software for procurement, and an

acceleration of test case development; ail of which are critical

to the CALS plans for the successful implementation of digital

product data. Schedules and target dates cannot be forecast

until resources under the CALS program are finalized.

Task i.1.2 Technical issue Papers on Product Data

This element of the work plan is designed to develop several

technical issue papers having to do with IGES versus other

standards, exchange completeness, and translator testing.

13
IV

V

VI

V I I VIII

Develop Comprehensive Testing Methodologies

Develop Entity Test Cases

Develop Applications Area Subsets

Develop Production Worthy Translators

Perform Extensive Intersystem Testing

Implement a Translator Validation Program

Accelerate PDES Development

Pursue International Standards Approval and Liaison

Figure 1. A Plan to Expedite the Development and Implementation

of Product Data Definition Interface Standards.
Two tutorials are presented in the Appendices. The first, in

Appendix F, is on the completeness of product data exchange. it

examines the hierarchy of information flow from the application

on one CAO system through the iGES entity exchange and the media

or telecommunications system to the receiving CAO system. The

second. In Appendix G, has to do with testing methodology.

Developed by the IGES Testing Methodology Committee, the document

is in working form at the present time and is expected to be

approved and published in 1987.

Task 1.1.3 Accelerate Product Data Development & Validation

This element of the work plan is designed to accelerate the

development of standards for product data exchange as well as the

development of validation techniques as needed to meet CALS

schedule objectives.

The Product Data Exchange Specification is being developed as an

exchange mechanism for complete product models. The PDES

initiation Activities were designed to develop the concepts and

the methodologies to be used In PDES and to rigorously establish

PDES information content as a baseiin*‘e for Version 1.0

development. A report on the details of the presentations has

been prepared and distributed. Much additional work is needed to

bring the PDES effort to the point of a Version 1.0 specification

and then to validate the concepts and implement sample code. The

Air Force Advanced Tactical Fighter (ATF) program and the

Geometric Modeling Applications Program (GMAP) both have reviewed

the PDES material from the April 1986 Initiation Activities and

agree that the program should be accelerated. The NBS Automated

Manufacturing Research Facility could provide a responsive

testbed for such work.

The Plan in Appendix E addresses several avenues for accelerating

the work in product data standardization. It presently shows

tittle emphasis on PDES, as the CALS direction is perceived as

having heavy reliance only on IGES for the near future.

Task 1.1.4 tges Translator Capability improvement

The context of product data exchange in the DOD environment is so

broad that ensuring a good quality of exchange through the

neutral IGES format requires careful specification of the data

requirements for each application, complete testing of the

software involved in the exchange, development of software to

assess compliance at critical points In the exchange, and

extensive intersystem testing to identify and evaluate problem

areas, maintain area competence, and provide needed feedback to

CAD system developers.

15
f

itt'' icoaibneoQA srtJ n<" b^ineifcio 8(»iieJu» okT

* n "rtj •• xlbn*o«A

rf»r*i»f IO«» » 4 J !««'«%! wo» t not t© xrtjs tbi* > ri *«; t*nlNtx«

»lte»»**rt»'bn» •6»i*rt0** easi. 4*wo'«rt’ e;ot« 0« bfio no

*«T , .«t*r«X» OAO »* aflj?tfigainini«e>8«l*J io

* ,XOo|»bb«f*«T,5

ftl?ii»| rtJ !<» «!> Of •»« .9 »t>«t*aoA nt .mos#*

fni«»»ofc •rtJfl ,*#i« l«ii!00 xpoIcbartJwi* pnlj«*T t3’»l orfJ tb b*qoi«»«e

-b %j bn* •»> inb*ma •'<!» ii nto^ onMnnw ni *1

a n^ t-»«*neuo bn* bbvoagq*

floMAbltaV A jn*i!igoJ «WbC »tfc6 fb^b<nt *)».i#i»os'A t.f.) ;iii*T

» I

3 JAO oV® 1 rr-fc

fk«l# tMT

'Q not fOnitntJ* ta lrift«»aol •vab

to i rt»i=^u. I evbb

.••vila^ido »tjjbbr(aa

/« . i. L w s ^ ta ’ /

nojL* 1 1 i eonAnoxS ioiibon^ oilT jiiftol t i ?>ba2 aonAnoxS

bWonc at * I “Jia lnsdaap aortsilaxa

fLVf ilxMacii^# « a <• t nat nea_ no < J »» t o vn f ^ 83

let ”? 8 ' hW.^'ih .Tf?' a . xn««qoi*v*b

flir El

mJX 6 ft ».»» *w ^^ - - ~ --•

vaJ? 04bf -t £J3io- l,bb 5 fioull oatudi ntt i b bfis banACjond naad

vfOflT X bnb b^oocnon artt e?bbN«v oi nsni oo«

"bn* vq' M 3 b , >«T .b*^bA» .baa-y n .A

bVwbliV*! «v»d rt;od ('5AM31 o*%ov= eUbJUansflA onlt»boM »i j »*ao*»

bill •bmvlJ4>A ooll-mm «id»r IIIAA *At mo-^'i UlxeJAa 230<t oAS

iT»temotu4, ten *rtT .bpjuftlbbs* bd b<ii»4« nn'iscig *ii» ?*rt> . **.ic»

ylbnoalai • *tolvo-<d blMot> X»-HUs 4 i) 9 '-^**^« c" I ^w"«M

f — - IJ-. - . . _ „ . . ^ "jow It 9110 not Obdf * PtHi* to » i i»p 1 ationtat ion

rfioi«V^ M .no! 5 tJibtoboo;# fJnb lowbonq nl xl^o^ artJ

qnbd 'oi noilooTlb SJAO oftf oo bloBdatio oiJiu

v»ar»JJJu 1 •«> «SU»‘ "« < ' bbo*

I

I »•) »xv*brt Oflly,»»i

to#«®vond«it X!> * * ! 04I(£«D I t xt«*T nD?« ' F.*C iT

^ .. 'V fnomnonJvtio OOO *trtl no ^ad«*rtoji# tii^b t^abonq txotncov^dT

arti n»uonrtt eon^rtoia "to booig o

itftfo Od^l 1© |t<^1->5btt)&©0« tjittioo o»ntno9t Joftnot tSPI tsntixar

an J tii ^ n I ^ 00 r ©I ‘ d«©P A S9J ftoae not ©1 n » w 0 1 n oJ Anofliltoa^^o J fioaoo » iS#|Ti5©<^o«b'- ^ bd/t©¥ni anB^jiaa

lootttn© l6 •©r.otiq*oo 04jnne»

at Bbtsxatat^J av:i*nftx©

, tOftoloa«c9^ a© If nlfttnisB ,«§ani

J i n e

Q

0

1

a

V

0

4

* mat i

aqniin&sfa ®Ht I dbn fp ©t^bw t «vo bnt

• 1 Xt I tnob

I

;V;

©
Copies of Appendix A, Boeinq/Suppi ier CAD/CAM Interface Standards , April 1984, can be obtained from:

The Boeing Company

P.O. Box 3707

Seattle, WA 98124
h^OVCAO y.

; w<n T k. u a •«* ••kj ,^8CI fHc|A •

f i f ff

y. i

'(ns^i^roD p^t^9 f*5lT xoS i*a,^

AW

•

’>v • ".* ^ * '

i>%‘

P'7

' %y, >i'^«^,'^ - *

S' "

V- . ^ ^ • #.*!4. -i > o' ^ 1

'K

*

-a- ..'i •f v«^ -A .> ^

:

' r,- • J,'('Vt>*<<^^ - ^ ^ a —

\li
APPENDIX B

GM/IGES Specification

0«e«fflb€r 22, 1983

Computer Integrated Systems

General Motors Technical Center

Warren, MI 48090-9010

Document Number CSS lOl-F-01
GM/IGES Specification (CGS lOl-F-01)

First Edition published December 22, 1983.

Revisions distributed March 30, 1984.

\

Refer to memos kept at the bock of the manual for details on the the material

that was revised.

ii
ABSTRACT

2riJsr.s <i«> ..^."°sllsss^

that ars not required at this ^^^m^ jy, IdMtl^L/^'^rs?'*’ ^*^*^“*

tloa. GH's veadezs are ewec^ tT!

apeeiflcatUa doca««,t through theiTlGES zrlLu^ identified iu

CGS lOl-F-01 U1 °*°e«b.r 22. 1983
I

I

t

*

i

It - i

J

T.

S * tt, F-01

iv D^caaber 22, 1983
PREFACE

This «pttclfic4tlon will bm txpdat«d regularly until Q! achieves 100 percent

data^ exchange. Tliia document refines the IGES specification to meet Ql's * needs. It has been reviewed and approved by the Of Data Exchange Coanittee, * which is the Corporate team responsible for the implementation of data * exchange specifications within GM (see "Appendix A. Miners of the Q! Data * Exchange Coanittee" on page 5«1). This specification will evolve as tech*

nology and Gh requirements change. Future releases of this document will

incorporate adjustments due to the release of new versions of the NBS/IGSS

standard, as well as additional needs of GH for electrical, numerical conr

trol. finite element modeling and analysis (FEM/FEA). and solid modeling * applications. Ongoing maintenance of this specification is the responsi- * bility of the Q1 Data Exchange Coomittee and the Extensions and Repairs « Subcommittee (see "Appendix B. Members of the GM Extensions and Repairs Sob* * committee" on page 6.1). * The authors of this specification assume that the reader is familiar with

the technical aspects of computer graphics and NBS/IGES Version 2.0 . Unless

stated othervise, any reference to NBS/IGES within the document refers to

, NBS/IGES Version 2.0 . published in February. 1983.^

This document is organised to resemble the NBS/IGES Version 2.0 document.

Unless stated otherwise', the definition of terms in this specification is

identical to that used and defined in NBS/IGES Version 2.0 . The Directory

Data Entity Type Number of each entity described in this document refers to * the number listed in the NBS/IGES Version 2.0 document. To obtain a copy of * the NBS/IGES Version 2.0 . write to the following address. ' . * National Technical Information Service * S285 Port Royal Road ^ . * Springfield, Virginia 22161 PB 83»L37hh8

e For further information, phone (703) ^87-4650 * References to RFCs in this document identify approved and pending requests * for change submitted to the NBS/IGES Committee. To obtain a copy of the * documentation for an RFC. write to the following address. ** United States Department of Comoierce * National Bureau of Standards * Manufacturing Systems * * Bldg. 220, Room A*353 * Vashington, DC 20234

' U.S. Department of Commerce. Initial Graphics Exchange Specification

(IGES). Version 2.0 . Vashington, D.C., 1983.

CGS lOl-F-01 V March 30. 1984
* An asterisk (*) in the left oarsin of this document indicates changes s^de * to the specification in March, 1984. *

* Direct your questions and comments regarding this specification to Charles * Zones, Chairperson of the Extensions and Repairs Subcommittee of the Qi Data * Exchange Committee, at the follotfing address and phone number.

e

*

* Computer Integrated Systems

Advanced Product and Manufaeturihg Engineering Staff

General Motors Technical Center

Engineering Staff Building

NO-Tumkey/APMES

Varren, MI 48090-9010

Phone (313) 492-1604 * (GM Network) 8-562-1604

e

* Members of the GM Data Exchange Task Force and the GM/IGES Specification * Team contributed their time and effort to this specification document. * Elaine Lockhart (Multiple Technologies Corporation) edited the original * document, and Claris Henderson (also with MTC) provided production support * for the original document.

CGS lOl-F-01 Vi March 30, 1984
CONTENTS

Introduction I.l

Overview ' 1.1

Purpose of Specification 1.1

Required Entities 1.1

Required NBS/IGSS Geometry Entities 1.2

Required NBS/IGES Annotation Entities 1.4

Required NBS/IGES Structure Entities l.J

Required Refinements 1.6

NBS/IGES Entities to be Addressed in Future Releases • . • • l.S

Possible Future Requirements 1.10

Gordon Surface 1.10

^ Solid Modeling 1.10

Data Form 2.1

ASCII Format File Structure ' 2.1

Directory Entry Section 2.1

Level Number 2.1

Geometry ......... 3.1

Conic Arc 3.1

Copious Data 3.S

Carves end Surfaces . 3.5

Structure ...... 4.1

Associativity Definition 4.1

Trimmed Surface Definition 4.1

Associativity Instance 4.6

Trimmed Surface Instance 4.6

Property 4.12

Offset Curve ............ ..... 4.12

Offset Surface 4.16

Trimmed Curve 4.21

r Appendix A. Members of the GM Data Exchange Committee 5.1

f Appendix B. Members of the GM Extensions and Repairs Subcommittee 6.1

CGS lOl-F-01 vii March 30 » 1984
Ac

. .>C4

.. -^*1

Vgbrxotjerr:^: **• rtsQ*'^' * (m

IM

7i

. » >

4

4 i* -" f.

rftS »

!:x«t3 an

tS

y r l%zT)

r

.‘•u

O ,

CGS lOl-F-01

t

’. as

-t 7 (it

viii March 30, 1984
LIST OF ILLUSTRATIONS

Flyura !• Example of Mumerical Instability Using the Algebraic Representation

Figure 2. Graphs of Ellipse, Hyperbola, and Parabola in Standard

Fora

Figure 3. Classes of Trimmed Surfaces ...•!!!!!!**

Figure 4. The Moving Trihedron Associated with a Space Curve C Figure S. Offset Carve in a 2*D Plane

Figure 6. Parametric Representation of a Surface in 3-D Euclidean

Space

Figarm 7. Offset Surface in 3-D Euclidean Space !!!.*'***

Figure S, Trimmed Ciirve

ix

3.2

3.3

4.7

4.13

4.14

4.16

4.19

4.21

^ CGS lOl-F-01

INTRODUCTION

OVERVIEW

In 1980, thtt GM Engineering Coopnter Advisory Sttbcoomittee of the General

Technical Copnaittee aade e long-range eommitaent to develop a data exchange

standard based on the National Bureau of Standards Initial Graphic Exchange

Specification (NBS/IGES) standard. IGES is a data foraat that is being

developed by the NBS and by representatives of industry to provide a oechanisa whereby graphic systems with dissimilar data bases may exchange design

data. The General Motors Integrated CAD/CAM Plan that was adopted in May,

1983, committed resources to develop a GM data exchange standard. GM*s goal

* for data exchange is to ensure that 100 percent of its required CAD/CAM data * can be exchanged among systems from GM-approved vendors

.

PURPOSE OF SPECIFICATION

The purpose of this document is to provide an IGES specification that will

be attached to GM purchase orders for graphic systems. The purchase orders

will dictate compliance of a vendor's system to the standard. In this document, all GM-defined refinements to NBS/IGES are described in detail, and

implementation dates are provided.

REQUIRED ENTITIES

The NBS/IGES Specification defines a large percentage of the GM required

entities. The entities required by approved CAD/CAM systems to comply with

Of standards are listed in the following tables:

* **Required NBS/IGES Geometry Entities'* on page 1.2

* **Required NBS/IGES Annotation Entities'* on page 1.4

* **Required NBS/IGES Structure Entities'* on page 1.5

CGS lOl-F-01 1.1 March 30, 1984
Required N6S/IGES Geometry Entities

Entity Type Nnmber Fo3

Ifipiesentetion

Date

Circular Are 100 June 1934

Composite Curve 102 June 1985

Coxkic Arc 104 *

- General Conic 0 June 1984

Ellipse 1 Jxme 1984

Hyperbola 2 June 1984

Parabola 3 June 1984

Copious Data 106

Points 2-D 1 * . June 1984

Points 3-D 2

* June 1984

Linear Path 2-D . 11 * June 1984

Linear Path 3-D 12 * June 1984

Centerline through 20 * June 1984

2-D Points

Centerline through 21 * June 1984

2-D Circle

(Section 2-D, Forms 31-33, is no longer required)

Witness Line 2-D 40 ^ June 1984

Simple Closed Area 2-D 63 * June 1985

Plane 108

Bounded Plane is 1 June 1985

Positive

Boimded Plane is -1 June 1985

Negative (hole)

Line 110 June 1984

Parametric Spline Curve 112 * Linear Type 1 Dec. 1984

Quadratic T^e 2 Dec. 1984

Cubic Type 3 Dec. 1984

B-spline Type A Dec. 1984

^ Entity has been amended and is to be used according to the guidelines

defined in this document. * ^ This entity has been replaced by the Sectioned Area Entity (Number 230).

CGS lOl-F-01 1.2 March 30, 1984
Required NBS/IGES Geometry Entities (cont«)

I^leaentetion

Entity Type Humber Form Datr

Parametric Spline Surface XIA * Linear Type 1 Dec. 1984

Quadratic 2 Dec. 1984

Cubic Type 3 0«e. 1984

B-spline T^e 6 Dec. 1984

Point 116 June 1984

Ruled Surface 118

Equal Relative Arc 0 June 1985

Length

Equal Relative 1 June 1985

Parametric Values

Surface of Revolution 120 June 1985

Tabulated Cylinder 122 June 1985

Transformation Matrix 124 0 June 1984

Linear Path 106 * June 1984

(see Forms 11 and 12

of Copious Data) • Simple Closed Area 106 * June 1985

(see Form 63 of

Copious Data)

Rational B-spline Curve 126 * D«e. 1983

Rational B-spline Surface 128 * Dae. 1983

Finite Element 136 * June 1986

* Entity hes been amended and is to be used aecordin^ to tbe suidelines

defined in this document.

* This entity ves faihanced by tbe NBS/IGES Extensions and Repairs Subcoa*

aittee in February, 1984. For documentation of these enhancements,

refer to RFC Number 135 for Material Properties and RFC Number 164 for

Loads and Constants.

CGS lOl-F-01 1.3 March 30, 1984
Required NBS/IGES Annotation Entities

lapleoescatlon

Entity Type Number For» Date

Angnlsr Dimension 202 June 1984

Centerline

(see Forms 20 and

21 of Copious Data)

106 * June 1984

Diameter Dimension 206 June 1984

Flag Note 20S Dec. 1985

General Label 210 June 1984

General Note 212 June 1984

Leader (2-D)

Open Triangle

Triangle

Filled Triangle

No Arrowhead

Circle

Filled Circle

Rectangle

Filled Rectangle • Slash

Integral Sign

214

1

2

3

4

5

6

7

8

9

10

June 1984

June 1984

June 1984

June 1984

June 1984

June 1984

June 1984

June 1984

June 1984

June 1984

Linear Dimension 216 June 1984

Ordinate Dimension 218 Dec. 1985

Point Dimension 220 Dec. 1985

Radius Dimension 222 June 1984 * Sectioned Area 230 ^ Dec. 1985

Witness Line 106 * June 1984

(see Foxo 40 of

Copious Data)

Entity has been amended and Is to be used according to the guidelines

defined In this document.

Entity vas approved by the NBS/IGES Extensions and Repairs Subcommittee

in February, 1984. Refer to RFC Number 197 for documentation.

CGS lOl-F-01 1.4 March 30, 1984
JL.*

Required NBS/IGES Structure Entities

loplefflenratioa

Entity T^rpe

^ Nnaber Foxb Date

Associativity Definition * Eztexaal Reference File

Index

Trioned Surface

Associativity Instance

Group with Backpointers

Views Visible

Group without

Backpointers

Single Parent * External Reference File

Index

Trimmed Surface

Drawing

Line Font Definition

Pointer to Subfigure

Repeating Structure

Description

Property

* External Reference File

List

Offset Curve

Offset Surface

Trimmed Curve

Subfigure Definition

Singular Subfigure

Instance

View

i* External Reference

302

12 • Dec. 1985

6002 * Dec. 1985

402

1 June 1985

3 June 1984

7 June 1985

9 Dee. 1985

12 • Dec. 1985

6002 • Dec. 1985

404 June 1984

304

1 Dec. 1985

2 Dec. 1985

406

11 * Dec. 1985

6004 ‘ Dec. 1985

6005 ' Dec. 1985

6006 * Dec. 1985

308 Dec. 1984

408 Dec. 1984

410 June 1984

416 • Dec. 1985

* Entity has been amended and is to be used according to the guidelines

defined in this document.

* These entities were approved by the NBS/IGES Extensions and Repairs Subcommittee in April, 1983. Refer to IGES RFC Number 136 dated September

1, 1983, for documentation of these entities.

CGS lOl-F-01 1.5 March 30, 1984
REQUIRED REFINEMENTS

The refinements to IG£S which will be required by approved CAD/CAM systems

to satisfy GM's requirements are listed and described in this section.

These refinements, some of which Include user*defined entities and GM recom*

mended practices, are within the guidelines and provisions of the HBS/IGZS

standard. Gh's user*defined entities are being presented to the NBS/IGES

Extensions and Repairs Committee for incorporation into the NBS standard.

Vhen these entities are incorporated, the user-defined Form numbers will be

changed to the new standard NBS/IGES Form numbers. GM's required implementation dates for translator support of these entities and refinements are

given in this specification, (^'s vendors will be expected to support all

the required entities and refinements through their IG^ translators.

The following tables- list the required refinements, the reason they are

required, and -their implementation dates. Detailed explanations of the

refinements are included in subsequent sections of this document.

PARAMETERS

Refinement Reason Required

Implementation

Date

Level Number For transferring level

information between systems

without restricting the

number of levels.

June 1984

CGS lOl-F-01 1.6 March 30, 1984
Required Refinements (cent.)

Eimnss

' lopleaentation

Refineaent Reason Required Date

Conic Arc For transferring conic

arcs in a numerically

stable representation.

June 1984

Copious Data For clarifying usage of

various Foras.

June 1984

Curves and

Surfaces

For handling nontnifora knot

spacing.

Dec. 1984

Offset Curve For defining curves which are

offset froa an existing curve.

Dec. 1985

Offset Surface For defining surfaces which are

offset froa an existing surface.

Dec. 1985

Triaaed Curve For defining triaaed curves so

the pre-processor does not have

Dec. 1985

' to refit the curve or traasfer

data for an untrlanaed curve.

Triamed Surface For defining trinmed surfaces Dec« 1985

so the pre*processor does not

have to refit the surface or

tmsfer data for an untriaaed

surface.

When these entities are incorporated by KBS into IGES, the user*defined

Fora nuabers will be changed to the new standard KBS/IGES Fora nuabers.

CGS lOl-F-Ol 1.7 March 30, 1984
NBS/IGES ENTITIES TO BE ADDRESSED IN FUTURE RELEASES

Th« following table lists the entitles that GH will address in futnre

releases of the Ol/IGES Specification.

Entity T^rpe Number Fora.

Copious Data .106

Points 3-0 (sextuples)

Linear Path 3-D (sextuples)

Section 2-D

Parametric Spline Curve 112

Wilson-Fowler Type 4

Modified Vilson-Fowler

Type 5

Parametric Spline Surface 114

Vilson-Fowler Type 4

Modified Vilson-Fowler

Type S

Transformation Matrix 124

Cartesian Coordinates

Cylindrical Coordinates

Spherical Coordinates

Flash 125

Defined by attached entity

Circular

Rectangular

Donut

Canoe

Node 134

3

13

31-38

10

11

12

0

1

2

3

4

* (Finite Element Entity Number 136 is now a required geometry entity)

Associativity Instance 402

Views Visible, Pen, 4

Line Weight

Entity Label Display * 5

View List 6

Signal String 8

Text Node 10

Connect Node 11

CGS lOl-F-01 1.8 March 30, 1984
NBS/IGES Entities to be Addressed in Future Releases (cont.)

Entity T^e Number Form

Naero Definition 306

Naero Instance 600*699

Property 406

Definition Levels

Region Restriction

Level Function

Region Fill

Line Widening

Drilled Hole

Reference Indicator

Pin Number

Part Number

Hierarchy

Rectangular Subfigure Instance 412

Circular Subfigure Instance 414

Text Font Definition 310

1

2

3

4

5

6

7

8

9

10

CCS lOl-F-01 1.9 March 30. 1984
POSSIBLE FUTURE REQUIREMENTS

Gordon Surface

Gordon Snrfaca entity is not required at this tiae. It may be required

if GH's graphic system cannot satisfactorily approximate Gordon, surfaces

¥ith B-spline surfaces.

* Solid Modeling

e

e

An RFC will be presented by the NBS/IGES Advanced Geometry Subcommittee in * May, 1984, to extend IG£S to handle solid modeling data. I^e solid modeling * entities will undergo a year of testing and evaluation. During this time, * the RFC will be open to changes to acccoaodate the needs of the full * NBS/IGES community. This NBS Subcommittee will then prepare a Change Order * to incorporate formally these entities into the NBS/IGES standard. GM is * participating in these activities and will address the solid modeling enti* * ties in future releases of this document.

CGS lOl-F-01 1.10 March 30, 1984
DATA FORM

ASCII FORMAT FILE STRUCTURE

Refer to the ASCII Foxaat File Structure thet is described in NBS/IGES , pp. 9-22,

Directory Entry Section

The Directory Entry (D£) Section provides an index for the file and con*

tains attribute information for each entity. See NBS/IGES . p. 23, for

further information.

Level Number

The Level Number should be used in accordance with the following GN recom*

mended practice

.

Humber Field Name Meaning and Notes

*5 Level Number This entity is defined on this

graphic display level or levels.

There is no restriction on the

number of levels that may be

used. CAD/CAM systems must

develop methods for handling a number of levels greater than

their current system restrictions.

See NBS/IGES . p. 24, for further information.

CGS lOl-F-01 2.1 December 22, 1983
P^r ill? Uc.'igmE ' j9 .;rn^

3HUT0U«T* 3JI*» TAMB03 »I32A

'W^''

,

5-

'^roixaira al hodi^b *X **w»«3« »4^ «i*m« U3U •d3

Swf*M^«*tir)r 'l* I • —, it. uM-ttfak*.

ii C?J‘% grmiiA ««|^ ' fei »->:gfc

" vitfil

**

llil&fc' ^ _ ' 3ob^ \-iJn3 H.netD»tia

li* K

'

,T-.

. ..,?

;i» > *U^4s ?a» *>:*»» *• DDiUft

1 *7 7 ^jfdrw^

i» JOt wlil ba by tfe •» '^'^j

T ’•#»/.» IF 5»*« MW.JPUbMli*-, / , !M ^ Ii*|hjp '• f:^3 jtifecr> 5|Hiir -«.£:/» f»aa»i3i 4 y thtnzt , . .-. -.*»

' » i?r

' „ ^ ST

,s '

' fli

- \ir.* MmH

<i^ ®

O • niii » b.«XUb mi Tsi^* , ;; !_ ?

£(0V#l TO l#*V»X Aldt^'SS “ *

. . L ^ ^ iBMkJhJiCT

( .' to .»;;

•ij 0t> aoi^a^:ita‘: oe ei

ttipv*! ^aKtaaa*!'^ 99U9 . *«r ttiDSCiUJ

xft^aa'sqt

aiaoxyai^f'^W

7|f*!'1 Ji'

/''"

w.

. “r/»

f

»ii0|?furxo%iil 3 t3^ t^ST t^^£i4S

T,

,a*;;

P-. .*'*

K* 4i:. lao tC^iTiiii 30 . I ?|4

«£i t^t iO*^*X0l •JO

Pf2C
. GEOMETRY

CONIC ARC

This section describes d 6H recommended practice that is Intended to

remove the numerical Instability of the IGES algebraic representation of

conics without changing the current representation.

Algebraic Versus Geometric Representation

The Conic Are Entity (as defined in NBS/IGES . pp. 71<*75), treats all conic

ares collectively with the algebraic representation

2.- 2

Ax + Bxy + Cy + Dx + Ey + F « 0. (1)

For 6K purposes, the recommended practice is to avoid using the algebraic

representation because it has the following disadvantages when compared

with the geometric representation.

* The algebraic representation is numerically unstable in certain situations. See Figure 1 on page 3.2 for an example which supports this

point

.

* The determination of the type of the conic by means of the algebraic

representation (1) depends upon whether certain invariants are positive, zero, or negative. When you work with floating point arithmetic

to evaluate the invariant, you may not get the value zero. Thus, you

may risk losing the characterization of the type of the conic arc. In

the geometric representation, the conic arc type is easily obtainable

from the data.

* To rotate a conic in the algebraic representation, each point must be

rotated independently. In the geometric representation, only the

defining points and vectors are rotated.

* The graphic users, as a rule, specify geometric elements to define

conic arcs, so this must be the primary data to be stored. The algebraic data, that is, the six coefficients A, B, C, D, £, F, of (1), is

secondary data and can be derived when needed.

CGS lOl-F-01 3.1 December 22, 1983
f 1

Consider the two conics (circles):

-2 2 2 6

10 .xO.lllKX +Y ) - 0.9999X - 0.999Y + 10 x0.4040 0 (2)

-2 2 2 6

10 x0,1110(X +Y ) - 0.9999X - 0.999Y + 10 x0.4040 * 0 (3)

The Conics differ in the coefficients A end C only, see (1),

-6

by 10 , which is a very small quantity, but (2) is a circle

with center 0^(450,450) and radius R^31. 62277; however,

(3) is a circle with center C=(450. 40541, 450.40541) and

radius R=41. 59964, which is a very substantial difference.

I Figure 1. Example of Numerical Instability Using the Algebraic |

I Representation: Conic Arc |

I

• I Recommended Practice

To remove the numerical instability of the algebraic representation, use

the geometric representations described below.

For ellipses and hyperbolas, use the geometric representation

2 2

Ax + Cy + F - 0 (4)

in conjunction with' a matrix defining the transformation in 3*D. In this

representation

2 ' 2 2 2

B = D = E«0, A = b, C«ta, F«-ab, .(5)

where a and b are the lengths of the major and minor semi-axes. (See

Figure 2 on page 3.3.)

CCS lOl-F-01 3.2 December 22, 1963
Thtt. noraalized fora of (4) is

2 2

Ax + Cy + r * 0 (6)

2 2

and A « 1/a , C * + 1/b , F *

Tha minus sign for C is chosen vhen^the conic is a hyperbola.

For a parabola, use the geometric representation

2

Cy + Dx = 0 (7)

in conjunction with a transforaation matrix being called in by a pointer.

In this representation

A»B«E = F- 0, C*l, D = -4a,

and a is the distance of the vertex from the focus. (See Figure 2.)

Directory Data

Entity Type Number: 104

Parameter Data

See NBS/IGES . pp. 71-75, for parameter data.

CGS lOl-F-01 3.3 December 22 , 1983
COPIOUS DATA

Clarification notes on the use of Copious Data are described here to help

ensure consistent usage of various forms between different CAD/CAM systems. See NBS/IGES . pp. 76-78, for further ixiformation.

Clarification Note about Forms 1, 2^ IT,, and 12

Forms 1 and 2 of the Copious Data entity (106) pertain to sets of points

that are not necessarily ordered. Forms 11 and 12 pertain to ordered sets

of points connected consecutively by straight line segments.

Clarification Note about Form 12

GM's CGS translator maps multi-point lines into Copious Data Form 12

(3-D). This entity must be interpreted by post -processors as geometric

data. The geometric operators of the vendor systems must be able to

manipulate these multi-point lines geometrically. For example, the vendor systems must be able to smooth these lines with curves, generate surfaces, etc.

Clarification Note about Forms 20, 21, 40, and 63

To handle 3-0 planar Centerline, Witness Line, and Simple Closed Area

entities, IGES translators should nap the data into the 2-D entities of

Centerline (Forms 20 and 21), Witness Line (Form 40), and Simple Closed

Area (Form 63) in conjunction with the 3-D Transformation Matrix (124).

This practice is consistent with the way that IGES maps data from definition space to model space.

CURVES AND SURFACES

CAD/CAM systems and their IGES translators must support non-\miform knot

spacing for curves and surfaces involving splines. The non-uniform knot

spacing can be handled either directly or by approximating the non-uniform

spacing with uniform spacing.

The following entities are affected:

• Parametric Spline Curve (Types 1, 2, 3, and 6)

• Parametric Spline Surface (Types 1, 2, 3, and 6)

• Rational B-spline Curve

• Rational B-spline Surface

CGS lOl-F-01 n.r.«h.r 1983
This section provides information about the 'organization of the data. See

NBS/IGES . p. 194, for further information.

i ASSOCIATIVITY DEFINITION

The Associativity entities are desi^ied for use when several entities must

be logically related to one another. The Associativity Definition entity

specifies the structure of the logical relationships. See NBS/IGES . p.

195 • for further information.

Trimmed Surface Definition

The Trimmed Surface Definition is used to define a trimmed soirface so that

the pre-processor does not have to refit the surface or transfer data for

an untrimmed surface.

This entity is associated with the Trimmed Surface Associativity Instance

. entity type 402 , Form 6002

.

The Trimmed Surface uses a parameter value called opacity which is defined

as follows:

Opacity is a variable that is defined on surface boundary curves and/or

isolated points and takes on the values -1, 0, or ^1, as follows:

Opacity » 'fl on closed curves constituting the outer

boundary of a surface.

Opacity « -1 .on closed curves constituting the boundary

of a hole with non-empty interior on the

surface.

Opacity « 0 on any curve or isolated point on the

surface that delineates a hole of empty

interior.

CGS lOl-F-01 4,1 December 22, 1983
Thera are five classes- of data for the Trlomed Surface Definition entity.

Class I has one entry for the base surface. That entry has one item, which

is a pointer to the Base Surface entity.

Class 2 has one entry for the curve constituting the outer boundary of the

triaoed surface*. This entry has two items. One item is a pointer

to the curve entity; the other is the value of the opacity on the

outer boTindary of the trimmed surface. The opacity value equals

plus one (*^1) . Class 3 has as many entries as there are disjoint closed curves delineate

ing holes of non-empty interior on the trimmed surface. Each

entry has two items. One item is a pointer to the corresponding

closed curve; the other is the value of the opacity on this closed

curve. The opacity value equals minus 1 (-1).

Class 4 has as many entries as curves in the interior of the trimmed surface other than those delineating holes of non-empty interior. In

other words, the entries in this class are curves on the surface

which delineate holes of one dimension (that is, along the curve

Class 5

itself) on the surface, and consequently these holes have empty

interior. Each entry has two items. One item is a pointer to the

corresponding curve on the surface; the other is the opacity value

on the surface curve that delineates a hole with empty interior.

The opacity value equals zero.

has as many entries as isolated points in the interior of the

trimmed surface. Each such point delineates a dimensionless hole

on the surface. Each entry has two items. One item is a pointer

to the corresponding point entity on the surface; the other item

is. the opacity value on the surface point that represents a dimensionless hole. The opacity value equals zero. * The curves on the surface are to be given in terms of the parameter values of * the parameters U and V of the surface.

CGS lOl-F-01 4.2 March 30, 1984
’ Directory Dcta

Entity Type Nuoberr 302'

Form Number: 6002

Parameter Date

Parameter Value Format Coament

1 5 Integer Number of class

definitions

.

2

Class 1 1 Integer Backpointers required

for class 1.

3 2 Integer Unordered class.

Appearance of entries

in class 1 is not

significant.

4 1 Integer Number of items

in class l.„ That item

is a pointer to the

base surface to be

trimmed.

5 1 Integer Indicates that the item

consists of a pointer

to a directory entry

for the base surface.

6

Class 2

1 Integer Backpointers required

for class 2.

7 2 Integer Uhordered class.

CCS lOl-F-01 4.3 December 22 » 1983
Parameter Value Format Comment

a 2 Integer Number of items

in class 2. First item

is a pointer to the

geometric curve

constituting the outer

boundary of the trimmed

surface. Second item

is the opacity value

which is equal to 1.

9 1 - Integer Indicates that the item

consists of a pointer

to a directory entry

for a geometric curve.

10 2 Integer Indicates that the item

consists of the opacity

value.

11

Class 3

1 Integer Backpointers required

for class 3.

12 2

' Integer Unordered class.

13 *2 Integer Number of items per entry

in class 3. First item

is a pointer to the

closed curve entity that

delineates a hole in the

trimmed surface. Second

item is the value of

opacity associated with

this closed curve and

has the value -1.

14 1 Integer Indicates that the item

consists of a pointer

to a directory entry for

the closed curve.

15 2 Integer Indicates that the item

consists of the opacity

value.

16

Class 4

1 Integer Backpointers required

for class 4.

17 2 Integer Unordered class.

CGS lQl-7-01 11. 1983
Parameter Value Format Comment

18 2 Integer Number of items per entry

in class 4. First item

is a pointer to the curve

on the surface that

delineates a hole of

e^^ interior. Second

item is the value of

opacity associated with

the curve and has the

value 0.

19 1 Integer Indicates that the item

consists of a pointer

to a directory entry

for the curve.

20 2 Integer Indicates that the item

consists of the opacity

value.

21

Class 5

1 Integer Backpointers required

for class 5.

22 2 Integer Unorder^ class.

23 2 Integer Number of items per entry

in class 5. First item is

a pointer to the point on

the surface that is a dimensionless hole on the

surface. Second item is

the opacity value on such

a point on the surface and

has the value 0.

24

25

1

2

Integer Indicates that the item

consists of a pointer to a directory entry for the

' point on the surface.

Integer Indicates that the item

consists of the opacity

value.

CGS lOl-F-01 4.5 December 22, 1983
ASSOCIATIVITY INSTANCE

The Associativity Instance specifies the information involved in a par*

ticular occurrence of a logical relationship between entities. See

NBS/IGES . p. 197, for further information.

Trimmed Surface Instance

This entity is used to define a triomed surface so that the pre-processor

does not have to refit the sxirface or transfer data for an ontrimmed surface.

This entity is associated with Trimmed Surface Associativity Definition

entity type 302, Form 6002.

The operation producing a trimmed surface is called the trimming

operation. Consider a surface entity that is a simply connected region

(that is. It has an outer boundary but no inner boundary), and call it the

base surface. A trimmed surface is the product of an 'operation on the

base surface that alters the outer boundary or introduces inner boundaries

to the base surface.

Altering the outer boundary of the base surface precedes introducing inner

boxindaries when the trimming operation involves altering the outer boundary and introducing an inner boundary to the base surface.

If the trimming of a base surface involves altering the outer boundary,

then a closed curve is generated from the curve segments participating in

the outer boundary of the trimmed surface. The closed curve constitutes

the outer boundary of the trimmed surface.

The outer boundary of the trimmed surface might consist of only one closed

curve interior to the base surface (see class a in Figure 3 on page 4.7).

It might also consist of a closed curve part which is common with the outer boundary of the base surface, (see class b, c, and d in Figure 3 on page

4.7). The shaded areas in the Figure depict the trimmed surface.
r

Figure 3. Classes of Trlimned Surfaces

To ' determine the sense of direction in tracing the curve of the outer

botmdar7 of the trimmed surface, designate one vertex of the outer boundary polygon as first, and then stipulate a sense rotational direction

(clockwise or counterclockwise)

.

For uniformity, choose as first vertex the one with minimum u and minimum

V, and choose the counterclockwise rotational direction.

CCS lOl-F-01 4.7 December 22, 1983
If the trisming of a basa surface involves introduction of an inner boundary, then you have the following cases:

* The inner boundary consists of, or has as a part, a closed curve in

. the interior of the trinsned stirface that delineates a hole of

non-estpty interior.

* The inner boundary consists of, or has as a part, a curve in the interior of the trimmed surface that delineates a hole of one dimension

(that is, along the curve itself) and therefore such a hole has empty

interior.

* The inner boundary is, or contains as a part, a geometric point in the

interior of the trimmed surface that represents a dimensionless hole.

From each of the above three categories, there may be any finite number of

inner boundaries in the interior of the trimmed surface.
Directory Data

Entity Type Number: 402

Form Number: 6002

Parameter Data

Parameter Value Format

1 I Integer

2 1 Integer

3 N3 Integer

4 N4 Integer

5 NS Integer

Caoment

Number of entries

ia class 1. The only

entry in this class

is the base surface

that is to be trimmed.

Number of entries

In class 2. The only

entry in this class

is the geometric curve

constituting the outer

boundary of the trimmed

surface.

Number of entries in

class 3. The number of

disjoint closed curves

delineating holes (of

non-empty interior)

on the trimmed surface.

Default value is 0.

Number of entries in

class 4. The number of

carves in the interior

of the trimmed surface

which delineate holes of

one dimension (along the

curve itself) on the

surface, and consequently

those holes have empty

interior . Default value

is 0.

Number of entries in

class 5. The number

of isolated points

in the interior of the

trimmed surface, each

representing a dimensionless hole on the surface.

Default value is 0.

CGS lOl-F-01 4.9 December 22, 1983
Parameter Value Format Comment

6

Class 1 DBS Pointer Pointer to the base

surface that is to be

trimmed.

7

Class 2

DEC Pointer Pointer to the curve

constituting the outer

boundary of the trimmed

surface.

3 1 Integer Opacity value assigned

to the outer boundary of

the trimmed surface.

9

Class 3

DEI Pointer Pointer to the first

disjoint closed curve.

10

• -1

• Integer

• First opacity value.

•

• 7+2N3

•

• DEN3

•

• Pointer Pointer to the last

disjoint closed curve.

8+2N3- -1 Integer Last opacity value.

9+2N3

Class 4

DEI Pointer Pointer to the first

curve on the surface

that delineates a hole

of empty interior.

10+2N3

•

0

•

Integer

•

First opacity value.

•

• 7+2N3+2N4

«

• DEN4

•

• Pointer Pointer to the last

curve.

8+2N3+2N4 0 Integer Last opacity value.

CGS 101*F*01 L in December
Parameter Value Format

C!ass 5

9+2N3+2N4 DEI Pointer

l(H-2N3^2N4

•

6

0

e

•

Integer

e

e

• 7+2N3

+2N4+2NS

• DENSe Pointer

8+2N3

+2N4+2N5

0 Integer

9+2N3

+2N4+2N5

M Integer

10+2N3

+2N4+2N5

•

•

DE

•

•

Pointer

•

•

• 9+2N3+2N4

+2N5+M

• DEe Pointer

10+2N3+2N4

+2NS+M

N Integer

11+2N3+2N4

+2N5+M

e

c

DE

e•

Pointer

•

•

• 10+2N3+2N4

0 DE• Pointer

+2N5+M^^

Comment

Pointer to the first

point on the surface

that is a dimensionless hole on the

surface.

First opacity value.

Pointer to the last

* point on the surface.

Last opacity value.

Number of backpointers

to associativity entities

or text pointers to

general notes.

Pointers to associativities or general notes.

Number of properties.

Pointers to properties.

CGS lOl-F-01 4.11 December 22, 1983
PROPERTY

Properties allow non*geonetrlc numeric or textual information to be

related to any entity. See NBS/IGES . p. 256, for further information.

Offset Curve

The offset curve property entity contains the numerical data necessary to

determine the offset of a given curve. The offset curve is restricted

here to apply to curves according to the following definitions.

Definition: General 3-D Curve

Let C denote a curve in the 3-D Euclidean space being analytically represented by

0 < t < 1 , (1)

where r(t) is differentiable in 0<t<l, and regular in 0<t<l, that is,

dr(t)

is not equal to 0 in the interval 0<t<l. (2)

*dt

Let T, N and B denote the unit vectors along the positive tangent, the

principal normal (first normal), and the binormal (second normal), at a point P on the curve C (see Figure 4 on page 4.13). Also let V be a given

unit vector.

CGS lOl-F-01 4.12 December 22, 1983
Definition: Offset 3-D Curve

The offset curve entity, C , of a givtix differentiable regular curve C

with parametric representation (1) ia a variation of C along the lines

of the field of vectors (VxT) by distance d. That is. if you denote

the parametric representation of’ the offset curve C by

-1

X (t)

d

T (t) «

d

then

y (t)

d

z (t)

d

0 < t < 1, (3)

/ V X T(t) \

r (t) « r(t) + d 1

' — ). (4)

d \|VxT(t)|/

I Figure 4. The Moving Trihedron Associated with a Space Curve C i

CCS lOl-F-01 4.13 December 22, 1983
Offset PUnar Curves

* If the curve C is planar, then the offset curve is also planar although its

* plane, in general, is not the same as that of C, (see Figure 5a). If V is

* perpendicular to the plane of C, then VxT is a unit normal vector of C, and

* the plane of the offset curve coincides vith that. of C, (see Figure 5b).

it

itit

it

it

itit

it

it

it*

*-

it**

*

it- it

itit

it .Figure 5. Offset Curve in a 2-D Plane I

l 1 The IGES File for the Offset Curve Property Entity

A curve C in 3-D Euclidean space is given to be offset. This curve sust be

smooth and have continuous first derivatives. The data defining the curve C

must allow for generating every point on the curve as well as for the tangent T at every point. It is assumed that a right-hand Cartesian coordinate

system is being used. The order in which you cross multipy the unit vectors

V and T is specified as V first, and T second; that is, (VxT).

The directional cosines of the vector V that determine the direction of the

offset by means of the cross product (VxT) constitute numerical data

entries of the Property entity.

The distance d by which the curve is offset along the lines of the field of

vectors (VxT) is also a numerical data entry of the property entity.

This property is generated by an IGES pre-processor in order to process an

offset curve.

CGS lOl-F-01 4.14 March 30, 1984
Dixectoxy Data

Entity Type hhimber: 406

Form Nnmber: 6004

Parameter Data

Parameter Value

1 4

2 A

3 B

Format

Integer

Floating Point

Floating Point

Floating Point

Floating Point

Cooment

Number of parameters

for this property.

The direction cosine of V

with the x-azis.

The direction cosine of V

with the y*axis.

The direction cosine of V

with the 2- axis.

The distance by which the

curve is offset along the

lines of the field of

vectors (VxT). The

distance is. positive in

the direction of (VxT)

,

and is negative in the

opposite direction.

6 NA Integer Number of backpointers to

associativity entities

or the number of text

pointers to general note

entities

.

7 D£ Pointer Pointers to

• • • associativities

• • • or general notes.

• 6+NA DE

e Pointer

7+NA HA Integer Humber of properties.

8-fNA

e DE

9 Pointer Pointers to properties.

e

o 7+NA+MA

« DE

e

0 Pointer

CGS lOl-F-01 4.15 December
Offset Surface

The Offset Surface Property entity contains the numerical data necessary

to determine the offset of a given surface.

Mathematical Background

Let S be a subset of 3-D Euclidean space, and let S denote a surface being

analytically represented by

r(u,v) »

x(u,v)

y(u,v)

2(U,V)

0 < u,v < 1 ( 1 )

where S is regular in 0<u,v<l, compact, and orientable. (See Figure 6.)

V *

Figure 6. Parametric Representation of a Surface in 3*0 Euclidean

Space

The regularity of a surface is a concept whose meaning narrows or broadens

according to the objective pursued. For G.M. purposes where the objective

is offset surfaces, surface S must have a continuous unit normal vector at

each of its points (u,v), 0<u,v<l. Tne following definition of regularity

handles the offset surface.

CCS lOl-F-01 4.16 December 22, 1983
Definition of Regularity: The surface S, represented by (1), is said to be

regular if

* r(u,v) has continuous partial derivatives of the first order in the

domain: 0<u,v<l.

• The inverse mapping r (x,y,2) is continuous.

0 • . For each point (u,v) in: 0<u,v<l9 the differential dr evaluated at

(u,v) is one to one.

Definition of Compactness: A subset S of the 3*D geometric space is compact if it is bound and closed in the sense that it contains all its limit

points. A point p is said to be a limit point of A if every 3-D neighborhood of p contains a point of A other than p. A surface S being represented by (1) and regular is compact.

Definition of Orientability: A regular surface S is orientable if, and only

if, there exists a continuous field of unit normal vectors N on S.

A continuous field of unit normal vectors on an open set S means a continuous mapping N that associates to each point (u,v) of U a unit normal vector N(u,v) to S at the point (u,v).

Given the representation (1) for S, you have for the unit normal vector

N(u,v)

r X r u V

N(u,v) =

|r X r

where r and r are the partial derivatives of r(u,v)

u V

with respect to the parameters u and v.

( 2 )

CGS lOl-F-01 4.17 December 22, 1983
Definition of Offset Indicator: Define as positive than orientation of S • which contains the unit normal vector

r XT

n V

N(0+,0+) « " where lim N(u,v) » N(0+,0+) (3)

jr X r

I u»v—(()+, 0+)

I u v|

in its field of unit normal vectors to S. Call the unit normal vector

N((H,0-K) the offset indicator of the surface S.

The Parametric Representation of the Offset Surface

Let S be a regular, compact, and orientable surface with parametric

representation (1), which is offset normally by distance d. Let the

offset surface be denoted by S and its parametric representation be

d

X (u,v)

d

r Cu,v)

d

2 (U,V)

d

, 0 < u,v < 1. (4)

If N(u,v) denotes the unit normal vector to S at (u,v) and you set

d(u,v) » d * N(u,v),

then you have for the parametric representation of S

r = r + d ®

d

x(u,v) + d cos a(u,v)

y(u,v) + d cos b(u,v) , 2 (u,v) + d cos c(u,v)

d

(5)

( 6 )

where cos a(u,v), cos b(u,v), cos c(u,v) are the directional cosines of

N(u,v).

CGS lOl-F-01 4.18 December 22, 1983
• The IGES Rle for the Offset Surface Property Entity

The surface S in 3-D Euclidean space is given to be offset. This surface

must be regular in 0<u»v<l, compact, and orientable.

The distance d by which the surface is offset along the unit- normal vector

N((H,0-^) is a numerical data entry of the property entity. It is assumed

that a right-hand Cartesian coordinate system is being used.

The offset indicator of the surface is the unit normal vector at

the point (CH*,04>). The directional cosines of the offset indicator are

numerical data entries of the property entity. (See Figure 7.)

CGS lOl-F-01 4.19 December 22, 1983
Directory Date.

Entity Type Nuaber: 406

Form Nuaber: dOOS^

Parameter Data

Parameter Value Format Cooment

1 4 Integer Number of parameters

for this property.

2 A Floating Point The directional cosine of

the offset indicator

with the x*axis.

3 B Floating Point The directional cosine of

the offset indicator

with the y*axis.

4 C Floating Point The directional cosine of

the offset indicator

with the 2- axis.

5 d Floating Point The distance by which the

surface is normally offset

on the side of the offset

indicator if d>0; andon

the opposite side if d<0.

6 NA Integer Number of backpointers to

associativity entities

or the number of text

pointers to general note

entities.

7 DE Pointer Pointers to

# • • associativities

• • • or general notes.

• 6-^NA

• DE

• Pointer

7+NA HA Integer Number of properties.

8-^NA

• DE

• Pointer

• Pointers to properties.

e

0 7+NA+MA

• DE

• Pointer
Trimmed Curve

Given a curve in some analytical fora with its boundary points, the need

nay arise to trim it on either end by a certain amount. If the curve is

given analytically either by one polynomial expression throughout its

or by means of a set of points to be interpolated by some underly*

ing interpolation scheme then trimming would not require the introduction

of a separate entity. In this case, simply redefine the end-points of the

curve to produce the desired curve.

However, if the curve is given analytically by a spline function, trimming

a curve and discarding the trimmed-off end parts require refitting the

spline because the trimming may not occur on the knots.

To avoid refitting a spline curve, transfer the existing spline along with

the two points on it where the trimming is to occur. Those points are given by their corresponding parameter values which constitute the numerical

data contained in this property.

This property is generated by an IGES pre-processor in order to process a trimmed curve.

CGS lOl-F-01 4.21 December 22, 1983
scvozy uaca

Entity Type Niunber: 406

Fora Number: 6006

Parameter Data

Parameter Value Format

1 2 Integer

2 BT Floating Poinr

3 £T Floating Point

4 NA Integer

5

• DE

• Pointer

•

• 4+NA

• OE

• Pointer

S+NA MA Integer

6+NA

• OE

e Pointer

•

• 5+NA+MA

• DE

• Pointer

Comment

Number of parameters for this

property.

The value of the parameter of the

enrve to be trimmed at the

beginning point of the trimmed

curve (beginning in the direction

of increasing parameter values).

The default value would be the

beginning parameter value of

the- base ctirve. If the* range of

the parameter values is normalized

in the interval (0,1), then the

default value of BT is zero.

The value of the parameter of the

curve to be trimmed at the ending

point of the trimmed curve. The

default value would be the ending

parameter value of the base curve.

If the range of the parameter

values' is normalized in the interval

(0,1), then the default value of

ET is one.

Number of baciq^ointers to associativity entities or the number of

text pointers to general notes.

Pointers to associativities

or general notes.

Number of properties.

Pointers to properties.

CCS lOl-F-01 December 22, 1963 4.22
1 * APPENDIX A. MEMBERS OF THE CM DATA EXCHANGE COMMITTEE

. Atallah, Paul

1 Cadillac Motor Car Dlv. , Dept 4017 * Computer Systems * 2860 Clark Avenue

Detroit » HI 48232-COORI2S *

S-284'6601

1 * Bachelor, Paul ) Hydra-Matlc Division * Ecorse & Viard Eoads

,* Ypsllanti. HI 48197

F COtJRIER

***

8-335-6695

^ Bowen, Sandra

* N2 - CIS

i* APMES Engineering North

* GH Tech Center

* Varren, MI 48090 - 9010

8-535-1181

^ Cenowa, Ron

* Fisher Body

f Computer Systems 1S2-32

^ GM Tech Center

' Varren, Mi 48090 - 9010

t

(313) 575-8936

f

' Georges, Stacy

Central Foundry Div.

77 Vest Center St. /

Saginaw, MI 48605-C0URI2S

8-386-3495

Loewengruber Kontry, Karen

No«T^imkey

APMES - Engineering North

GM Tech Center

Varren, MI 48090 • 9010

8-563-1604

Meise, Konrad

APMES - MD 69

Adam Opel Contact

G1 Tech Center

Varren, MI 48090 - 9010

(313) 492»0433

CGS lOl-F-01 5^2 March 30, 1984
Murray, Lyle 8-3«7-5572

AC Spark Plug

1300 N, Dort Hwy.

Flint, MI 48556-COURIER *

* Nelson, Ron 8-356-3541 * 6MC-Inland Division ^ 2701 Home Avenue

* Dayton, OH 45401-COURIER *

* Norfleet, Larry (313) 492-1688 * APMBS - CIS * 6454 E. 12 Mile Road

* GM Tech Center * Warren, MI 48090 - 9010 *

e

Panzica, Connie (313) 492-1935 * GMAD

30009 Van Dyke

GM Tech Center

Warren, MI 48090 - 9010 *

*

Rank, Charles 8-386-5822

Saginaw Steering Gear^

Prod, Eng..-Plant #3

3900 Holland Rd.

Saginaw, MI 48605 -COURIER

* Senft, Erich (313) 456-2368 * Truck & Bus * 660 South Blvd. E. * Pontiac, MI 48053-COURIER

**

* Spewock, Nicholas (313) 575-1181 * Engrg Bldg. * N2-CIS * Tech Center * Warren, MI 48090 - 9010

CGS lOl-F-01 5.2 March 30, 1984
* VlAeminck, Leon (313) 857-1683 * Pontiec Motor Division * Inforoetion Systeas * Pontiac, MI 48053 *

* Villiaas, Dan (313) 575-3640 * Chevrolet Eng. , A-244 * GM Tech Center * Varren, MI 48090 - 9010

*

** Zon^, Charles (313) 492-1604

No-Turnkey

APMES Engineering North * Q1 Tech Center ^ Warren, MI 48090 - 9010

CGS lOl-F-01 5.3 March 30, 1984
0

t

r*7: * '-Tursr, tyU

*• A'J SpMk flag

‘ ucaX. tkiXT Vy f4I-;ci

•• 7’int, «r

f-

» B

- Tib

12 SU

11 ^v:>o irp Jtf: *' voa/* Of

^ . l/7 »* i * G£ ijr .,. ' •

ifi d JL'.. ,;

Ki i4A
APPENDIX B. MEMBERS OF THE GM EXTENSIONS AND REPAIRS SUBCOMMITTEE

it I* Boven* Sdndra 8-535*1181

N2 - CIS

APMES-Engineerlxig North

GM Tech Center

Verren, MI 48090 - 9010

* Dick, Arnold (313) 575-3595 or 8-535-3595 * Chevrolet Motor Division * CEC- Rm. A-239 * GM Tech Center * Warren, Mi 48090 - 9010 *

* Grabowski, Joseph (313) 554-6604 * Cadillac Motor Car Div. , Dept 4017 * 2860 Clark Avenue * Detroit, MI 48232 - COURIER *

*

* Greenevald, Paul 8-387-8334 * AC Spark Plug * 1300 North Dort Hwy * Flint, MI 48556 - COURIER **

* Hinton, Villiaffl * World Truck A Bus Div. * Eng. Operations * 660 South Blvd. E. * Pontiac, MI 48053-COURIER *

*

* Loewengruber Kontry, Karen

* NO-Tumkey

* APMES-Engineering North

* GM Tech Center

* Warren, MI 48090 • 9010

*>

It* Meise, Konrad

* APMES - MD 69 * Adas Opel Contact

* GM Tech Center * Warren, MI 48090 - 9010

(313) 456-4744

(313) 492-1604

(313) 492-0433

CGS lOl-F-01 6.1 March 30, 1984
* Nicholas, Judy * APMES - CIS * ZnvironaentAl Activities Bld^. ^ GM Tech Center

« Vsrren, Ml 46090 • 9010

*

*

* Trsfidlo, Heidi

* Pontisc ^tor Div.

* Pontisc, MI • C0t3RI£R

* Tsiais, Eaasnnel * Fisher Body

* Engineering 192*32 ^ Q1 Tech Center * Vsrren, Mi 48090 - 9010

*•*

* Vethington, Robert * N2 - CIS * Engineering North * GM Tech Center * Vsrren, Mi 46090 - 9010

*

Vitwer, Mel * Delco Products * Mail Stop 4-07 * P.O. Box 1042 * Dayton. OH 45401-COORIER

4 4r* Voelfel, Too

* APMES - CIS * Environaental Activities Bldg. * GM Tech Center

* Varren, MI 46090 - 9010

*

*

« Zones, Chsrles * NO-Ttxrnkey * APMES - Engineering North * GM Tech Center

* Vsrren, MI 46090 - 9010

(313) 575-0696

6-237-1500

(313) 575-4082 or 8-535-4082

(313) 575-1181

8-358-7707

(313) 575-2247

(313) 492-1604 or 8-562-1604

CSS lOl-F-01 6.2 March 30, 1984
inter-Organization

Advanced Product and

Manutactudng Engineering Staff

Holders of 6M/I6ES Spteiflcstlon

March 30 » 1984

Qtneril Motors Corooration

Qanerai Motors Tecnnicai Csntsr Wsrrsn, Micnigan 48090-9040

Hath Y. Heed

Revisions

Enclosed are revisions for the GM/IGES Specification (CGS I01-F*01) that was

first published In December, 1983.

R Title Page

R V - viii

R 1.1 - 1.10

R 4.1 - 4.2

R 4.13 - 4.14

R S.l - 5.2

A 5.3 - 5.4

R 6.1 • 6.2

An asterisk (*) In the left margin and the date March 30, 1984, denote

revised pages.

Please file this memo at the back of the manual for future reference.

Update your manual by adding (A) and replacing (R) these pages:

;

Ruth 7. Reed, Coordinator

Technical Documentation Group

Computer Integrated Systems

FB 192-32, Ext. 5-8729

RYR/eel

Enclosures
" *

^*“- -jrtriumtiwM

Attl ,0c iottH

SSSI'vW )« £^cl

urC .‘ " 1^00 " i3£X. ., axni«tv»l

> . ,'

, . . -„ DtJ) STS-40I2 or •-5^-*iMa

’*£S*^^.¥ ^y e-ryaailtassOSIiffi

#

'm

^. . ..

’1^ , 4 fr. _ r — --‘' •“‘“•“-fWl #Xft W*.4^ v

(S0’a|3ai:>JtXq»i bfiJ (A) Xmiibu;

rii—wwifiiiwirnr an m ^ ^

cvf

•ijiT X T

.

^ ^

^tammrixWmi

.

F • C’il TiX> C«n,t4jr n

i|u? ^

*-'V; 'ifil SnUa a^rcBdocti

If; F

IUt - r

01. 1 - i.x

J.* - I.*

*1.* - u.*

£.C ' l,t,

*.e • c.i

»,» - i.« ' .'^*

ij-s« B»tl $t--? --37

i'V «t»s*« *nh *4s boa Aol oai ol

J'^ -» ’-*ablilR^^ .(nf-ooMlei *xcmi to's ltdSmm «4|j^, o*M» «m* tt49 #UViwo*H

ci» ' " .r^;

tiilJSWly*- w*J ir»; f' 'c . . ,

k:" «- ' ., ,5»*a -If iJ***

" ^Jj*r^3 Jlo>* -j»lcl =M»'!e^5.3) 4n-:J0 at • J41-W04 . ,,*

’'.Tti'i? .isX .{c-SM IT..

3

lmrn\m

< - *1

'^j

K&rcSi 30« lia4 \j
APPENDIX C

irkieicie*************

Hughes/EDSG

IGES Requirements

Specification

Version 0^

Q Q

April 1, 1986

Hughes/EDSG IGES Requirements Specification Version 0^

Table of Contents

Preface

1.0 Introduction

Purpose

Scope

Document Conventions

2.0 User Options and Information Requirements

User Interface Requirements

Start Section Input

Global Section Input

User Options

Executing IGES Processors Outside of the

Graphics Environment

Multiple Re Processing

IGES Start and Global Section Options

Error Recovery

Processor Reporting Requirements

Error Reporting

Progress Reporting

Rnal Report Log

Vendor Documentation Requirements

Physical Re Transfer

Entity Mapping and Representations

3.0 IGES Data Requirements

Start Section Requiremerrts

Global Section Requirements

Directory Entry Attribute Requirements

Application Entity Sets

Solid Modeling

Rnite Element Modeling

M^hanical Design/Drafting

Printed Ciix^it Board Design/Drafting

Manufacturing Process Planning

NC Tool Path Gener^n

Data Accuracy and Form^ Requirements

Entity Mapping

Tolerance Restraints .

Data Accuracy

Data Compression

4.0 Processor Validation Procedures

Test Rationale

Test Plan

Test Procedure

IGES Read Processors

IGES Wrfte Processors

Test Record

Test Library Res

Evaluation and Reporting

Page11123334568889

11

19

21

21

21

24

25

25

III
Hughes/EDSQ IGES Requirements Specification Version 0^

Table of Contents - Continued Page

5.0 Document Revision and Maintenance Procedures 26

Future Extensions and Modifications 26

6.0 Appendicles 27

Requirements 27

Desired Features 29

Sample Summary Report Fbnnats 30
Hughes/EOSG IGES Requirements Specification Version

plotted Line weights have distinct meanings in design/drafting applications.

R3.3J Processors shall support the Line Weight Number for afl entities.

3^.6 Color Number. This value maintains eight color values for displayed entities. The color definition

entity may be used to more accurately represent the colors required. However, at this time the color

differentiation is more important than the visual accuracy of that color.

R3.3.6 Processors shall support the Color Number for all entities.

3.3.7 Parameter Record Count. Data integrity in the IGES file must be maintained. This field irxiicates

the number of Parameter Data records that are used to represent the entity. This record count must

accurately represent the parameter record counts to assure valid post-processing of the data.

R3.3.7 Processors shall support the Parameter Record Count for all entities.

3.3.8 Entity Label and Subscript. Some systems utilize a tag and subscnpt mechanism to reference

specific entitles in the native system. Where these mechanisms exist, the tag and/or subscnpt value shall be

passed into the appropriate Directory Entry field.

R3.3.8-1 Processors shall support the Entrtv Label field as it applies to the processing system.

R3.3.8-2 Processors shall suonorf the Entity Subscript field as rt applies to the orocessino system.

3.4 Application Entity Sets

lit is a requirement that all CAD/CAM systems used at Hughes/EDSG have the capabiPity to exchange design

data with other systems in the design cycle. To ensure that entitiy requirements are representative of the

lactual work flow at Hughes/EDSG, subsets of the IGES entities have been divided into Application Entity

|Sets. These Entity Sets are composed of entities which are required for each particular design function and

I which win be transferred to other design functions.

. R3.4-1 OAEZCIM Systems shall support the Application Entitv Setfs) defined below for each area

I la_which the system is intended to be used.

1

! B

ile application entity sets addressed are: Solid Modeling, Rnite Element Modeling, Mechanical

esign/Drafting, Printed Circuit Board Design/Drafting. Manufacturing Process Planning, and NC Tool Path

Generation. The IGES entities which are required for these entity sets are detailed below. Each application •as a set of entities which processors must be able to read and write, in some cases, a select set of entities

|re designated as read-only. This Insures that data may be captured by the appPtcatlon which is not required

to be transfer to another application or system. In addition to the entities required by the application sets

I

I

11
Hughes/EDSG IGES Requirements Specification Version 0^

listed later in this section, the following requirement shall apply:

R3.4-2 Afw entitv written out to IGgS format must be able to be read bv the same system’s IGRR

Read pmcessoL

This assures that data generated on a system can be read back into that system for data verification

purposes.

3.4.1 Solid Modeling. The Solid Modeling application is used for the conceptual design of mechanical

devices as well as some printed circuit board layout applications. The solid model allows the user to check for

clearance problems, generate shaded images and of the product. The data generated will be used as input

to the Finite Element Modeling application and other analysis packages. When the design has* been

captured and analyzed, the model definition will be passed to the design/drafting application and the

NC/Tooling application. The solid modeling system must then be capable of generating two types of IGES

output files - View dependent "picture files* for use by the design/drafting application, and surfaced 3>D

wireframe representations for the NC/Tooling application.

The data generated for the design/drafting application will contain wire-frame geometry with view dependent

characteristics. This will allow the creation of hidden line views within the solid modeler that can be

transferred to the design/drafting systems. The data generated for the NC/Tooling application however, will contain a fully surfaced three dimensional wire frame model.

3.4.1.1 Solid Modeling Entity Set.

R3.4.1.1 Solid Modeling systems shall support all entities defined

Processing Requirement: Read/Write

Type Form Description

100 0 Circular arc 102 0 Composite curve 104 0 Conic arc - general form

104 1 Conic

^- ellipse

104 2 Conic arc - hyperbola

104 3 Conic arc - parabola

108 -1 Planar hole - Bounded

108 0 Plane

108 1 Bounded Plane

110 0 Line

112 0 Parametric spline curve 114 0 Parametric spline surface

116 0 Point

118 0 Ruled surface (Arc length parametrization)

118 1 Ruled surface (Equiparametric parametrization)

12
Hughes/EOSQ IGES Requirements Specification Version 0^

120 0 Surface of Revolution

122 0 Tabulated cylinder

124 0 Transfonnation matrix

402 3 Views visible instance

402 4 Views visible, Color, Line weight instance

402 6 View nst instance

402 7 Group without back-pointers instance

402 9 Single parent instance

410 0 View - Orthographic Parallel

Processing Requirement:

Type Fomi

402 1

Read Only

Description

Group instance with back-pointers

13
Hughes/EDSG IGES Requirements Specification Version 03

3AJ2 Rnite Element Modeling.

3.4.2.1 Rnite Element Modeling Entity Set

Processing Requirement:

Type Form

To be addressed at a later date

Read/Write

Description

3.4.3 Mechanical Design/Orafting. The Mechanical Design/Drafting system must be able to produce

MIL Spec drawings in IGES format. This requirement includes the support of toleranced dimensions, views,

drawings, and the general symbol entity for support of feature control symbols. The data produced for such a drawing must be able to be read back into the pre-processing system for editing. For a 3-dimensionai

system, the data will be composed of a single representation of the model and annotated views of the model

which are referenced by the drawing entity.

3.4.3.1 Mechanical Deslgn/Draftlng Entity Set.

Processing Requirement: Read/Write

Type Form Description

100 0 Circular arc 102 0 Composite curve 106 20 Centerline

106 21 Centerline through circle centers

106 31 Section lines • General use, iron, brick, stone masonry

106 40 Witness line

110 0 Line

112 0 Parametric spline cun/e

116 0 Point

124 0 Transformation matrix

202 0 Angular dimension

206 0 Diameter dimension

210 0 General label

212 0 General note - Font Code 1 212 0 General note - Font Code 1001

212 0 General note - Font Code 1002

214 X Leader arrow - 2 pts.

214 X Leader arrow • 3 pts.

214 X Leader arrow - 4 pts.

214 1 Leader arrow - Wedge

214 2 Leader arrow - Triangle

214 4 Leader arrow • No arrowhead

Support of Cross-hatching as per IGES Version 3.0.

14
Hughes/EOSG IGES Requirements Specification Version 0.5

t.4.3.1 Mechanical Design/Drafting Entity Set (continued).

Processing Requirement: Read/Write (continued)

Type Rjrm Description

216 0 Linear dimension

218 0 Ordinate dimension

222 0 Radius dimension

228 0 General symbol

308 0 Subfigure Definition

402 7 Group without back-pointers instance

404 0 Drawing

408 0 Single subfigure instance

410 0 View - Orthographic parallel

Processing Requirement: Read Only

Type Fomi Description

104 0 Conic arc ° general form

104 1 Conic arc - ellipse

104 2 Conic arc - hyperbola

104 3 Conic arc - parabola

106 1 Copious data - coordinate pairs

106 2 Copious data •> coordinate triples

106 11 Copious data - Piecewise planar, linear string(20 linear path)

106 12 Copious data » Piecewise linear string(3D linear path)

108 -1 Planar hole • Bounded

108 0 Plane

108 1 Bounded Plane

212 0 General note • Font Code 0

402 1 Group instance with back-pointers

402 9 Single parent instance
Hughes/EOSG IGES Requirements Specification Version 0^

3.4.4 Printed Circuit Board Design/Drafting. The Printed Circuit Board Design/Drafting system

must be able to support schematic capture, the physical description of the board, and the annotated drawing^

of the board. The system must be able to read in any data it creates for the purpose of editing. Although it is not a requirement at this time, future extensions of this specification will require the use of external symbols

for the support of component libraries.

3.4.4.1 Printed Circuit Board Design/Drafting Entity Set.

Processing Requirement: Read/Write

Type Form Description

100 0 Cirajiararc

102 0 Composite curve 106 11 Copious data - Piecewise planar, linear string(20 linear path)

106 12 Copious data • Piecewise linear string(30 linear path)

106 13 Copious data • Piecewise linear string (sextupies)

106 63 Simple closed area 108 -1 Planar hole • Bounded

108 0 Plane

108 1 Bounded Plane

110 0 Line

116 0 Point

124 0 Transformation matrix

125 0 Flash - defined by attached entity

125 1 Flash -circular

125 2 Flash • rectangular

125 3 Rash • donut

125 4 Flash -canoe

132 0 Connect point

202 0 Angular dimension

206 0 Diameter dimension

210 0 General label

212 0 General note - Font Code 1 212 0 General note - Font Code 1001

212 0 General note - Font Code 1002

214 X Leader arrow - 2 pts.

214 X Leader arrow - 3 pts.

214 X Leader arrow -4 pts.

214 1 Leader arrow - Wedge

214 2 Leader arrow - Triangle

214 4 Leader arrow - No arrowhead

216 0 Linear dimension

218 0 Ordinate dimension

222 0 Radius dimension

16
Hughes/EDSQ IGES Requirements Specification Version 0.5

3.4.4.1 Printed Circuit Board Design/Drafting Entity Set (continued).

Processing Requirement: Read/Write (continued)

Type Form Description

228 0 General symbol

302 5xxx Associativity Definition

308 0 Subfigure definition

312 0 Text template > absolute coordinates

312 1 Text template • relative coordinates

320 0 Network subfigure definition

402 1 Group instance with back-pointers

402 7 Group without back-pointers instance

402 8 Signal string instance

402 10 Text node instance

402 11 Connect node instance

402 18 Flow instance

404 0 Drawing

406 2 Property - Region restriction

406 6 Property - Drilled hole

406 7 Property • Reference designator

406 8 Property - Pin number

406 9 Property - Part number

406 11 Property - Tabular data

406 12 Property - External reference file list 406 15 Property - Name

408 0 Single subfigure instance

410 0 View - Orthographic parallel

412 0 Rectangular subfigure instance

414 0 Circular subfigure instance

420 0 Network subfigure instance

Processing Requirement: Read Only

Type Form Description

104 0 Conic arc - general fomi

104 1 Conic arc - ellipse

104 2 Conic arc • hyperbola

104 3 Conic arc - parabola

106 1 Copious data - coordinate pairs

106 2 Copious data • coordinate triples

112 0 Parametric spline curve 212 0 General note • Font Code 0

402 9 Single parent instance

17
Hughes/EOSG IGES Requirements Specification Version

3.4^ Manufacturing Process Planning.

3.4.5.1 Manufacturing Process Planning Entity Set.

Processing Requirement: Read/Write

Type Fomn Description

To be addressed at a later date

3.4.6 NC Tool Path Generation.

3.4.6.1 NC Tool Path Generation Entity Set

Processing Requirement:

Type Form

To be addressed at a later date

Read/Write

Description

18
APPENDIX D

it-klsitrkicicieititiciticititiiieie

DRAFT PROPOSAL

TOOL DEVELOPMENT FOR IGES TRANSLATOR VERIFICATION

Computer-Aided Design Branch

Automation Systexm Laboratory

Cnporate Research & Development

General Electric Company

October 2, 1986

s
1

V^*''- <15 'T

;t!-.^.

*

i'-j-

"'

illri^^Jk

il'i^'*- .- Vi

r '«

r:-

> # * ‘‘Vi

TMV' b

•4111 . ,• . ‘^|^''f3il<' .

, ' -fS* •• - V -• <0 -4^

'iljMiikil'

f

*

,i‘

-iM

^ t.'*‘ *• '• Y

>4t r 'Ji,

'•'

l''\ SiCTXi f' :?i ‘ •.vjr.’

’^|ff^A.» ?[» ‘ '* 4'- ^ ix X f‘

i t» A*'-*r-.'. ‘ "\ *, ' \

.•. «

JACO^K*i 'C^AH<1

f.

W^Jl/DriCiCaV’ HOTaIiE^sXs^ 583D1 Hcyf TV3M^J2T/3Q

^

^ r

:;5 •

civ- ^ ^,*jUiKfdtoa^

. t4i‘' d>rjrH iQiiwO

arajMiX^ i»tft«aDli>A

iiiji^rW %'v'^

'>

,= '1 > « osii ,t I><Ma«»0

I '» 'S' h*'^'‘'T'.t'«'-i*''-'fMiy.t'.' '•' %f(i!p. ^U’ *',. ' '. i£^-s; ,i”' .?:

«A'

,Sr ?!*.»«

• 4

?'» i ‘-M

' v '7 *<”•
. om .

DRAFT PROPOSAL

TOOL DEVELOPMENT FOR IGES TRANSLATOR VERIHCATION

1. INTRODUCTION

The IGES translator verification is important to both CAD /CAM users and vendors. It is get>

ting strong attention by the IGES community and the National Bureau of Standards (NBS). The

IGES Testing Methodology Committee has prepared a working paper on Documentation for the

Testing Methodology of IGES Translators and IGES formatted Data Files.

The General Electric Corporate Research and Development (CRD) has been analyzing the

whole process of IGES translator verification to identify technical voids which need to be filled to achieve an effective verification. This draft proposal is a result of this analysis.

The target of this proposal is to develop software tools required for the IGES translator

verification process in order to increase its degree of accuracy, consistency, and automation.

The next section provides a definition and description of the verification process steps including an identification of needed tools. Section 3 includes description of these tools. Section 4 details

the proposed statement of work including deliverables, and schedules.

2. FUNCTIONAL DESCRIPTION OF THE VERIFICATION PROCESS

The IDEFO methodology is used to model the functions covered by the IGES translation

verification process. Figures I through 4 are IDEFO charts for different levels of that process.

Figure 1 represents the top level of the IGES translator verification process. The process consists of the following three functions:

2.1 Upgrade IGES Test Library to Current Version

The NBS possesses the beginning of an extensive library of IGES test cases. These consist of a partial entity library originally donated by Boeing, the Air Force PDDI test tapes,

the AUTOFACT demonstration tapes, and miscellaneous tapes donated by members of

the IGES community. None of these IGES files exist in a format identical to IGES Version 3.0. Many contain syntax errors. It is necessary to correct these errors and upgrade

the files to IGES Version 3.0. It will also be necessary in the future to be able to update

that library to the then-current version of IGES.

There is a need for a software tool which can be used to upgrade the library to the current

version. That tool is referred to as Tool #1 in Figure 1.

2.2 Test Vendor’s IGES Thmslators

This function includes all the steps for testing vendor’s IGES preprocessor and postprocessor. The inputs to this function are the current IGES version library files, and the ouU

puts are the test results for the vendor's processors. Four different tools have been

identified as required for this function and will be described below.

Figure 2 shows the function of testing vendor’s IGES translators. This function consists

of the following three sub-functions:

2.2.1 Generate Reference IGES FUe

This function generates the IGES file needed for testing the vendor’s translators.

* There is a need for a tool (Tool #2) which can generate reference IGES files from

the current version library files based on the IGES subset to be tested. The tool is expected to generate the file either by adding entity files from a library or by reducing the number of entities in a given file. An information model for the IGES subset

is assumed to be available and will be used in controlling the contents of the refer- ence file.

October 2, 1986
Current,

IGES

Subset

Version ^’ ^

Information

Changes \I

Vendor’s

Reference

Manuals

Model

Figure 1-

VERIFY

IGES

TRANSLATORS
3o

Figure 2-

TEST

VENDOR’S

IGES

TRANSLATORS
3-

2.2.2 Test Vendor's IGES Preprocessor

This fuDctioQ handles the testing of the preprocessor and generates the preprocessor

test results. It consists of the following six functions: ( as shown in Figure 3)

a) Generate Vendor's Script

This function generates the input script which is needed to create a model in the

vendor's system equivalent to the model represented by the reference IGES file. It

is extremely difficult to manually write a script which will be sufficiently precise as to allow the same functionality to be placed in the native database of any system to be

encountered. One must at least expect that different operators will interpret the file differently.

There is a need for a tool (Tool #3) which can translate a reference IGES file into a

specific vendor’s script Vendor’s reference manuals and the IGES subset information model will be needed to provide controlling input to that tooL

b) Generate Vendor's Model

This function creates a model in the vendor’s system based on the input script.

There are no new tools needed for the execution of this function. The vendor’s system and reference manuals are required.

c) Verify Vendor's Model

It is desirable that the model generated in the previous step is verified to ensure that

the entities claimed to be supported by the vendor’s preprocessor are created

correctly in the native database. It would be a waste of effort to continue with the

test if there are obvious problems with entities in the vendor’s database.

If the verification reveals reference file related errors, feedback is passed to the

reference IGES file generation function to create another file which consists of entities supported by the vendor’s system. Another script is generated and another

model is created. If the errors are related to the input script, feedback is passed to the vendor’s script generating function to create another script and another model is created. This loop continues until a positive model verification takes place.

The vendor’s system utilities are expected to be used for the verification. There are no special tools needed for this task.

d) Generate Vendor’s IGES File

The vendor’s IGES preprocessor is used to create an IGES file from the model

created in function (b) above. No other tools are needed.

e) Verify Vendor's IGEIS Pile

The vendor’s IGES file is verified to detect any syntax errors. The results of the

verification are generated in a standard format and passed to the next step.

There is a need for a tool (Tool #4) to carry out that verification.

f) Compare Two IGES Models

This function compares two models represented by two IGES files. The two models

should include identical information and any differences are included in the test

results generated by this function.

IGES files may be physically different but acceptable within the scope of the IGES

specification. That may be a result of differences in native databases or in interpreting the specification. An example of such a difference is the practice of some programmers in aligning the parameter data section values in columns while other

October 2, 1986
oMno %OOH%ooHo

tac

«> >S

(O

to Vaeo>«%o ,

Preprocessor

Figure 3-

TEST

VENDOR’S

IGES

PREPROCESSOR
- 4 -

programmers produce as compact a representation as possible. Another example is the different ways in which entities can be ordered within an IGES file. Such

differences would make a text file comparison between the files worthless, while

they may represent the same information.

This function compares the reference IGES file to the IGES file generated by the

vendor’s preprocessor.

There is a need for a tool (Tool #5) to load the contents of each file in a neutral

database then verify the database contents against the IGES subset information

model to arrive at what happened to each entity during the IGES preprocessing

function. Vendors are expected to provide information about the mapping of their

entities into IGES entities.

The test results classify the translation outcome for each entity; examples of these

classes are:

• Full functionality, entity same

- Full functionality, entity/entities different

- Partial functionality

- No functionality

- Entity not processed

Test results are generated in a report form and a file form. The file containing the

test results will be used for analyzing the data exchange between two systems as shown in 2.3 below.

2. 2.3 Test Vendor’s IGES Postprocessor

The postprocessor test will have to be done after the preprocessor test because the

the preprocessor, translator will be used in the test. The preprocessor test results are needed to figure out any postprocessor errors. The use of the preprocessor in this

test avoids having to access the vendor’s database directly.

The function of testing the postprocessor consists of the following five functions: (as

shown in Figure 4)

a) Generate Vendor’s Model

The vendor’s model is generated using the postprocessor which translates the refer* ence IGES file into the native database. There are no special tools needed for this

task.

b) Verify Vendor’s Model

The model generated in the previous step is verified to identify any obvious problems with the entities in the vendor’s database. The results of the model verification

may be used later in the comparison of IGES models described in (e) below. The

vendor’s system utilities are expected to be used for the verification. There are no

special tools needed for this task.

e) Generate Vendor’s IGES File

The vendor’s IGES preprocessor is used to create an IGES file from the model

created in function (b) above. No other tools are needed.

October 2, 1986
o

<A

<A

US

“o

o

I-

*o

o

I01o

T3C

o

>

(0 •wo

*o

c

09 >

«»

•i-o

•oc

>

Postprocessor

System

Preprocessor

Figure

4

-

TEST

VENDOR’S

IGES

POSTPROCESSOR
d) Verify Vendor's IGES File

The vendor's IGES file is verified to detect any syntax errors. The results of the

verification are passed to the next step (e).

There is a need for a tool (Tool #4) to carry out that verification.

e) Compare Two IGES Modria

This function compares two models represented by two IGES files. The two models

should include identical information and any differences are included in the test results s^nerated by this function.

Hiis function compares the reference IGES file to the IGES file generated by the

vendor’s preprocessor.

There is a need for a tool (Tool #5) to load the contents of each file in a neutral

database then verify the database contents against the IGES subset information

model to arrive at what happened to each entity during the IGES postprocessing and

preprocessing functions.

Since the preprocessor test results are already known from task (f) in Section 2.2.2

above, the tool will deduce what happened to the entities during the postprocessing

function alone and generate their test results. If the preprocessor was not used in this test, it would have been necessary to directly access the vendor’s database to compare its contents with those in the reference IGES file. That may mean the creation of a special preprocessor to access the database.

The test results classify the translation outcome for each entity; examples of these

classes are:

- Full functionality, entity same

- Full functionality, entity/entities different

• Partial functionality

- No functionality

- Entity not processed

Test results are generated in a report form and a file form. The file containing the

test results will be used for analyzing the data exchange between two systems as shown in Section 2.3 below.

2.3 Analyze Data Exchange between Systems A & B

The purpose of this function is to predict what would happen to entities belonging to a subset of IGES when they are exchanged between two systems A and B. The prediction

includes the exchange directions A to B and B to A.

A tool (Tool #6) is needed for this function. The tool will use the test results files for the

A and B preprocessors and postprocessors generated by the vendor’s IGES translator test functions (Figure 1).

October 2, 1986
3, DESCairaON OF REQUIRED TOOLS

This sectioa describes the functionality of each of the six required tools identified in Section 2.

3.1 Tool #1 ( To Upgrade IGES Library to Gbrrent Venloa ) This tool upgrades the IGES test library to the current IGES version. It can be used for

version 3.0 upgrades and for future versions of IGES. The upgrades are automatic.

3.2 Tool #2 ( To Generate Referenee ICES Files )

This tool generates reference IGES files by combining entity IGES files from a library into one file or deleting entities from IGES files to suit a given IGES subset

3.3 Tool #3 ( To Generate Vendor’s Script

)

This tool generates input script for a vendor’s system. The script can be used to create a model in the vendor’s database informationally equivalent to the model represented by

the reference IGES file.

3«4 Tool #4 ( To Verify I(S)S File Syntax ) This tool verifys the syntax of an IGES file and produces verification results in report and

file forms. This tool is not included in the proposed work to be done because there are commercial products which claim the ability to do such verification.

3.5 Tool #5 ( To Compare Two IGES Models ) This tool compares two models represented by two IGES files and detects their

differences. In the case of preprocessor testing, the comparison idendfys what happened to the entities during preprocessing. In the case of postprocessing testing, the comparison

results are used with the preprocessor results to identify what happened to the entities

during the postprocessing. The comparison results are generated in report and file forms.

Tool #5*has two levels; a basic level and an extended level. The basic level covers all entities except splines and surfaces which would require geometric computation to check

if entity deviation is within tolerances. The basic level will output results in report form

only. The deduction of postprocessor functionality results will be done through human

interpretation of both the preprocessor and postprocessor test reports.

The extended level covers ail current IGES entities and will output results in a form

which is computer comprehensible. The extended level will automatically produce the

postprocessor functionality results. Results from the extended level will be input to Tool

#6 for conducting the analysis function. The extended level represents the output IGES

information model in terms of the input IGES information model plus delta information

about the changes which took place during the translation. This type of representation

would make it easy to interpret by a computer program.

The IGES Model Comparison System (IMCOS) developed at the University of Karlsruhe,

Germany, is an attempt to do the functions covered by the basic level of Tool #5. However, IMCOS is not designed to be extensible to cover the extended level of Tool #5 and

the consequent support for Tool #6. If IMCOS is used as the basic level of Tool #5,

significant effort will be needed to do the extended level of Tool #3 using a different base

software.

3«S Tool #5 ( To Predict Data Exchange Results for Two Systems ) This tool analyzes the preprocessor and postprocessor test results for two vendor systems

A and B in order to predict what happens to entities when the data is exchanged from A

to B or from B to A. Tool #6 is dependent on the availability of the extended level of

Tool #5.

m

October 2, 1986
. 7-

4. PROPOSED STATEMENT OF WORK

CRD is proposing a two-project effort to cover the development of tools required for the IGES

translator verification process. A description of these tools is included in section 3. The first project is the primary project in which most of the testing tools will be developed. The

second project complements the first one and focuses on developing one of the toob aimed at automating the generation of test models in the vendor's system. Since the success of this tool

is dependent on the ability to run the vendor's system using a script file or equivalent, a proof

of concept is essential; accordingly, a separate project is proposed for achieving that objective.

Each of the development projects and phases is targeted to be a seif contained package serving a specific purpose. Any dependencies between projects or phases will be stated below.

Any software developed as part of this project will be placed in the public domain. Tools

developed in this project will require the use of internal CRD software developed outside the

project. CRD will place the source code of this internal software in the public domain. CRD will

not provide support for the code after the end of the proposed projects.

4.1 PROJECT (A): DEVELOPMENT &VALIDATION OF TESTING TOOLS

Project Objectives

The main objective of this project is to develop four testing tools and validate them within a basic testing system that includes the script generator tool, which is developed in Project

(B). Another objective is to prove the transportability of the developed code by porting it to IBM^ hardware.

"Project Scope

The scope covers the development of Tools #1, #2, #5, and #6. It also covers the

delivery of two versions of the code; one for the DEC* VAX^ hardware, and one for the

IBM 43XX or 3XXX hardware. This project consists of the following three phases:

PHASE I: DEVELOP TESTING TOOLS

Phase I Objective

The objective of this phase is to develop tools needed for the vendor’s IGES preprocessor and postprocessor testing.

Phase I Scope

This phase includes the development of Tool #1, #2, and the basic level of Tool

#5. Tool #4 is assumed to be commercially available.

Tool #1 is used for upgrading IGES test files from earlier versions to the current

version. Tool #2 is needed for both preprocessor and postprocessor testing since it generates the IGES reference files. Tool #5 is used in both tests to generate test

results.

It is assumed that an IGES subset information model exists. Tools #2 and #o use

that model to control their functions.

MBM is i trademark of Inteniatioaai Bnsiaesa Machiset

^DEC is a trademark of Disitai Eqaipmeat Corperatioa

^AX is a trademark of Digiui Eqaipmeat Corporatioa

October 2. 1986
- 8 -

Phas« I consists of the following four tasks:

Thsk A«1 Develop File Upsrade Tool #1

This task provides a tool for upgrading the IGES test library files to IGES version

3.0 and for future library upgrades.

CRD will upgrade some files in the current IGES test library to version 3.0 to demonstrate the functionality of the tool. It is assumed that the principal work

involves reformatting issues such as addition of the version number in the global

section. Two specific corrections are anticipated and will be performed. The first is the correction, where the error occurs, of the misunderstanding which caused the

subordinate entities to some annotation entities to point to the same transformation

matrix entity as their parent. The second is the determination and correction of the

subordinate entity fiag according to whether the entity is physically dependent, logi«

cally dependent, or independent.

Files are put into the General Electric Neutral Database (NDB) using the IGES version 2.0 translator and then processed to correct the two known abnormalities. Then

data is output to an IGES file using IGES version 3.0 translator.

The software used for the version 3.0 upgrade can be used for future upgrades. A

program will be needed to take care of differences introduced by the new version.

Task A-2 Develop Reference File Generator Tool #2

This task consists of developing a tool for generating reference IGES files conforming to a given subset of IGES defined by an IGES information model. This tool will

be able to generate the file usifig two modes. The first mode is merging existing

entity IGES files into one file. The second mode is deleting entities from existing

IGES files to generate the reference file. Both modes may be used to build, the file

• depending on the available IGES files. Current IGES test library files will be used to demonstrate this tool.

Thsk A-3 Develop Comparison Tool #5 (Basie Level)

The basic level of Tool #5 is developed in this task. The extended level is covered

by Task A-6 in Phase III. The basic level compares two models represented by two

IGES files and detects their differences. It covers all entities except splines and surfaces. The basic level will output results in report form only. The deduction of posU

processor functionality will be done through human interpretation of both the

preprocessor and postprocessor reports.

Task A-4 Validate Basie Testing System

This task consists of validating Tools #1, #2, and #5 (basic level) developed in this

Phase in addition to their use as part of a basic testing system that includes Tool #3

which is developed in project (B). A demonstration of all these tools working

together is the main outcome of this task.

October 2, 1986
. 9 .

PHASE II: PROVE CODE TRANSPORTABILITY

Phaae II Ol^eetlve

The objective of this Phase is to demonstrate that the code developed or used in

Phase I is operational on a machine that is different of the development machine.

Phase II Scope

The development of the code will be on DEC VAX hardware. To prove the code

transportability, an equivalent version of the code will be prepared and its functionality will be demonstrated on IBM 43XX or 3XXX hardware.

This Phase consists of the following task:

Thak A-5 Port Code to IBM Hardware

The DEC VAX version of the code will be analyzed and necessary modifications will

be made to make it run on IBM 43XX or 3XXX hardware. The modifications and

the reasons for doing them will be documented. The main output of this task is demonstrating that the IBM version is operational: This efTort can be used as a guide

for porting the code to any other type of hardware.

PHASE III: DEVELOP EXTENDED COMPA|USON &ANALYSIS TOOLS

Phase III Objeciave

The objective of this Phase is to develop an analysis tool for predicting the results of

data exchange between two systems. This phase will also extend the tool which

compares t^vo IGES models to cover ail the current IGES entities and produce computer comprehensible test results.

Phase III Scope

The analysis tool (Tool #6) is dependent on the completion of Tool #3. Accordingly, this phase covers first an extension of the basic level of Tool #5 to cover all current IGES entities and to be capable of generating test results in a file form

comprehensible by Tool #6. The analysis tool will provide the user with detailed

prediction of what happens to each entity passed between two systems via IGES.

This tool can be expanded in the future to analyze data exchange through a series of

systems.

This Phase consists of the following four tasks:

Thsk A-Q Develop Comparison Tool #S (Extended Level)

This task builds on the basic level of Tool #5 to produce an extended level. The

extended level of Tool #S covers all current IGES entities and will output results in a form which is computer comprehensible. This level will carry out geometric computation for spline and surface entities to check if entity deviation is within toler- ances. This level will automatically produce the postprocessor functionality results.

Results from Tool #5 will be the input to Tool #3 for conducting the analysis function.

The extended level represents the output IGES information model in terms of the

input IGES information model plus delta information about the changes that took

place during the translation. This type of representation would make it easy to interpret by a computer program.

October 2, 1986
- 10 -

Taflk A-7 Develop Analysie Tool #0

This task covers the development of Tool #6 which can be used for analyzing the

preprocessor and postprocessor test results for two vendor systems A and B in order

to predict what happens to entities when the data is exchanged from A to B or from

B to A. For Tool #6 to operate, Tool #5 (extended level) must be available.

Tksk A-8 Validate Extended Testing System

This task covers the validation of Tool #5 (extended level) and Tool #6 as part of

an extension of the basic system validated in Task A-4 in Phase L

Task A-0 Prove Code Transportability

This task consists of preparing a version of the code developed in tasks A-6 and A-7

which would operate ou the IBM 43XX or 3XXX hardware. The task includes

demonstrating that the code is operational on that IBM hardware.

Project Dellvembles

CRD will deliver the following;

- Source code for the NDB plus its updated IGES preprocessor and postprocessor.

- Source code for an enhanced version of the Common Database Interface Language

(CDIL) compiler and the runtime interface code necessary to run a CDIL-compiled

program against the NDB. There is a CDIL version placed in the public domain by

the U.S. Military Academy. The deliverable code mentioned above is an enhancement of that version.

- Source code for the CDIL programs developed for the Version 3.0 upgrade.

- At least five IGES test files upgraded to IGES Version „3.0 as a proof of Tool #l

capability.

- Tool#2 source code for generating IGES reference files from existing IGES files. For any given IGES subset, this code will generate a compatible IGES file. - Tool #5 (basic Level) source code for comparing two IGES models represented by

the reference IGES file and the vendor’s output IGES file. The program will generate vendor’s preprocessor and postprocessor test results in a report form. Splines

and surfaces are not included in this basic level.

- Source code extending Tool #5 (basic level) code to cover all current IGES entities

and to output test results in a computer comprehensible form.

- Tool #6 source code for predicting the results of exchanging data belonging to an IGES subset between two CAD /CAM systems. The predictions are based on the

preprocessor and postprocessor test results produced by the extended level of Tool

#5. - The above software will be delivered in two versions. One for the DEC VAX

hardware and the other for the IBM 43XX or 3XXX hardware.

- Documents describing the delivered code, its installation, and usage.

October 2, 1986
- 11 -

4.2 PROJECT (B) : SCRIPT GENERATOR DEVELOPMENT & PROOF

OF CONCEPT

Prqiect Objectives

The main objective of this project is to develop a script generator tool and proof its concept by applying it to two different vendor systems. Another objective is to demonstrate

that the code is operational on DEC and IBM hardware.

Prqject Scope

The scope covers the development of Tool #3, the CDIL code needed for its use with the

Calma DDM^ and CADAM^ systems, and proving that it works on DEC VAX and IBM

43XX or 3XXX hardware.

Task B-1 Develop Script Generator Tool #3

This task covers the development of a tool which can generate an input script file for a vendor's system based on a reference IGES file. The script file can be used to automatically create a model in the vendor's database equivalent to the model

represented by the reference IGES file. The code developed in this task is a module

common to all vendor's systems. In order to be able to use the tool, a CDIL program is needed for each vendor's system to take care of entity mapping.

Tank B-2 Develop Programs for Use of Tool #3 with Two GAD Systems

This task covers the development of CDIL programs needed for the use of Toot #3

with the Calma DDM and CAD AM systems. In the case of CAD AM, an equivalent

to a script file will be the program's outpuL

Task B>3 Validate Tool #3 and Compare Its Use with Manual Methods

In this task, Tool #3 and the two CDIL programs will be validated and the results

are compared with the case when the vendor's models are created manually. The

objective of the comparison is to prove the validity of the concept of Tool #3.

Task B-4 Prove Code TVansportability

This task consists of preparing and demonstrating a version of the code, developed

in tasks B-1 and B-2, which would operate on the IBM 43XX or 3XXX hardware.

Project Deliverables

CRD will deliver the following:

- Tool #3 source code suitable for generating a script file from a standard reference

IGES file. The software consists of a special output module from CDIL designed to write script files for a variety of CAD/CAM systems.

- CDIL source programs to generate script writing programs for two CAD /CAM systems using Tool #3. These two systems are the Calma DDM the CAD AM systems.

- The above software will be delivered in two versions. One for the DEC VAX

hardware and the other for the IBM 43XX or 3XXX hardware.

- Documents describing the delivered code, its installation, and usage.

^DOM is X tndcm&rk of the CsJm& Company

^AOAM is a trademark of CAOAM, Inc.

October 2, 1986
. 12 -

4.3 SCHEDULE

Placet (A)

The target start and completion dates for each of the project tasks are as follows:

TARGET DAT]ES IN MONTHS ARO

PHASE TASK START COMPLETE

I A-1 0 3

I A-2 0 10

I A-3 0 10

I A-4 10 12

U A-S* 11 14

111 A-6 10 18

III A-7 17.5 22

III A-8 22 23.5

III A-9 23 24

Prqieet (B)

The target start and completion dates for each of the project tasks are as follows:

TARGET DATES IN MONTHS ARO

TASK START COMPLETE

B-1 0 10

B-2« 7.5 10.5

B-3 10.5 12.5

B*4 13 14

« Preliminary estimate; may change when the IBM environment is analyzed

October 2« 1986
? I/?:*

. . .U. 1 rPA -*

ajUdlT-^^ c.>

t A,. r^*

r; j-s L iii 'W'Ji

* »!.-« Ul«

X Au ITfM ,

rr

IkMtTM

fj , rw Ui^l

oi l\t r/©p»»c®"“

r 5-4 tmm I —li(^

44M Uii eoftfv'i «i n^fA

Uctkt i*4 r**t, Wiw^

<1 ^ I

I'i r

I ti I

'

• i ' ,0 Vv C» iK'

V ^ .-fn ^

•*> 'i

• f :..i ' »

Dy\vw^4 tii

.1 Mi «o*m «9d* MUMi tm tfm

ICTS alt. nt

fllr %cHfi tk» Ur

ntf

- *z

. *4

’ ATfcf'

\ -ttrnmM.

sn yxx i

O' : ' : tcao6$ai
APPENDIX E

PLAN FOR

RESEARCH AND IMPLEMENTATION TESTING

I N

PRODUCT DATA EXCHANGE

21 October 1986

Bradford Smith

National Bureau of Standards

A3S3 Bldg 220

Gaithersburg, MD 20899

(301) 921-3691
'

' ' ‘-' -’ a^uTaaf M6iT^Tv«3i.ijJ'‘iMi owa.

I. : ‘ l^«r . - ,

'• ’">' „ > '"> -,' 4 J ^ ^

.?Wf|

V i • S» -li';

19 JiM

3CH/H0X3 ATAfl T5U00fV*» »

•*‘<1

?r.*

I

^ TT?

* f

]*

1 'IiAJ ! it?rii?*.;M

' ' i’ '» ,

„

''- ' ^ 4» -I - -Jb '

rtflfft biolbfi^S

osii Qtie cacA

QM , cfiudniirtJ I A© ?*

;v SB ( roc ) a frj ’f-'tyr

, ;-Vr S'i

i'sifnvJS* ‘-fi -via

r -rii
1 DEVELOP A COMPREHENSIVE TESTING METHODOLOGY

GOAL:

A rigorous methodology for testing Implementations of the IGES

Specification is the Icey to developing quality translators for

widespread production use of IGES. This tasic will develop the

technology and the tools to adequately test IGES file translation

software. it will also devise and document the criteria to be

used to evaluate the degree of success attained. In addition to

the formal methodology, actual testing requires an entity subset

specification and a suite of documented test cases. Application

subsets and test cases will be developed by other tasks of this

plan.

APPROACH:

The testing methodology must be based on definitive procedures

and a categorization of the problem Into workable segments. A

careful and complete Identification Is needed of all potential

error sources or barriers to an Intersystem data exchange.

Categories of IGES entity types needed for the exchange of

specified user data sets (i.e., 2D Drafting or 3D Wireframe

Models) must be developed. The methodology will Include both a comprehensive test plan for gathering data and mechanisms for

analysis of collected data.

Software tools must be specified and developed to complement the

methodology. The tools will be In the public domain and will be

constructed so as to be easily agumented as new IGES entities are

published. The software programs are needed for preparing,

editing and documenting both the IGES test files and the scripts

needed to direct CAD operators in creating the proper models.

Additional, programs are needed to analyze files for proper data

organization and content. Finally, software Is needed for the

analysis of test results to determine whether a CAD system's

translators have conformed to test objectives.

Policies must be established for the documentation of entity

mappings, application subsets and test cases. Finally, formats

and procedures are needed for feedback of Information to IGES

translator Implementors and for presentation of testing results

to the pub lie.

1
TARGET MILESTONES-.

A Publish a generic plan for gathering data, testing

translators, determining success, returning comments to

vendors, and communicating the results to the CAO/CAM

commun I t y

.

B Develop methods for analyzing the data collected. Including

mechanisms for comparison and presentation.

C Develop a methodology for presenting and using vendor

specific IGES entity mappings to predict degree of exchange

completeness among dissimilar CAD systems.

D Document entity subset concept and guidelines for developing

and using generic or applications subsets.

E Publish a users guide for testing and validation of IGES

t r ans I ator s .

F initiate the development of a rigorous method for

comprehensive testing of both pre- and p o s t - p r o c e s s o r translators. Identify software tools needed. % G Publish the criteria for an acceptable IGES translator

verification program.

H Document the applications area entity subset concept and

provide guidelines for users to perform end-to-end

certification testing.

I Develop documentation standards for test cases and

procedures for test case validation.

J Develop specific test methods for error checking, system

limit testing, and numerical error propagation.

K Develop a program to provide generalized plotting directly

f rom an I GES file.

L Develop a utility program to check conformance to a published subset of IGES entity types.

M Develop validation techniques for solids model data

exchanges

.

2
2 IMPLEMENT A TRANSLATOR VERIFICATION PROGRAM

GOAL:

Assuring a good quality of data exchange through the neutral IGES

format requires careful and complete testing of the Involved

translators. This can only be attained through a comprehensive

program of testing, the cost of which Is beyond all but the

largest of user companies. An Independent, self-sustaining,

centrally run verification program utilizing the testing

methodologies approved by the IGES Organization seems to offer

the only rational solution.

APPROACH:

This effort will Initiate a national translator verification

program by providing the resource material and the startup

consulting support. Criteria will also be developed for

measuring the effectiveness of the verification program.

The ve r I f I ca t I on program makes use of deliverables from ail the

other tasks of this plan. While the goal is to develop a centralized testing facility, it should be noted that the test

procedures are generic and can be performed by any individual at

any site. This task provides the startup resources and the

consulting needed by a national v^er I f I ca 1 1 on program until it can

become self-sustaining.

TARGET MILESTONES:

A Define the relationship between the testing program and the

I GES Organ I za t

I

on

.

B Develop the criteria for ranking, rating or accepting a candidate in the testing process.

C Document a format for presentation of results.

D Develop a policy and procedures guide for a national

verification program.

E Initiate a National IGES Translator Verification Program run

by a neutral third party.

F Provide consultation and startup resources.

G Review and audit program one year after Initiation.

3
3 DEVELOP ENTITY TEST CASES GOAL:

A Wide range of verified correct test cases must be developed as

a basis for Individual translator testing and for Intersystem

testing at user or vendor sites. The range should cover a wide

spectrum of entity types, user applications, model scales, file

sizes, and data organization methods. Test Library cases serve

the needs of software testing and provide examples of how

IGES-defIned entitles are to be used to express various part

model data.

APPROACH:

Version 1.3 of the Test Library provides test cases for IGES 1.0

entity types. Additional test files will be created to represent

current versions and various application areas of IGES, to

represent multiple entity relationships, or to show different

schemes for data organization within an IGES file. Finally, a series of test cases will be developed to intentionally stress

system limits and to check postprocessors for error detection

capab I I I ty

.

AM files generated will be suitably documented and thoroughly

checked for conformance with the applicable IGES version.

Documentation will include the purpose of the test, the entity

content, a script for generating the test case, the Information

to be carried by each entity and the evaluation criteria for

measuring the success of the test.

TARGET MILESTONES:

A Revise Version 1.3 test cases and develop new cases for ail

IGES entity types. Publish the document.

B Gather variety of benchmark test cases, analyze them for

conformance to the Specification and document them for use.

C From a single test case script, generate an IGES file on

each of a variety of CAD systems to form a suite of “flavor"

test cases.

D Develop test cases to stress system limits.

4
4 DEFINE APPLICATIONS AREA SUBSETS

GOAL:

Each new applications area in IGES will require a definition of

information content through formal modeling techniques, a specification of how this information is unambiguously mapped

into or represented by the IGES entities and a definition of the

IGES entity subset for the application. Also needed will be a series of test cases, a method for organizing the data within the

IGES file and demonstrations of intersystem exchange.

APPROACH

Much new technical work has been accomplished since the

publication of Version 2.0 and is included in the Version 3.0

document. A substantial portion of this new capability is aimed

at providing extensions for electrical, drafting, finite element,

and plant design applications. it is necessary for this work to

be implemented, tested, and, if necessary, modified or extended

to satisfy objectives for each application area.

For each new application capability in Version 3.0, vendors and

users should be identified for trial implementations. Entity

subsets, applications guidelines, information mappings and sample

test files should be made up of typical engineering uses of this

data. Errors, omissions, or extensions should be documented

where found and , subm I t t ed for consideration.

TARGET MILESTONES:

A Define Initial candidates for applications entity sets.

B Document current practice and procurement specifications on

applications entity sets.

C Gather, analyze and document existing applications test

cases

.

D Document any existing compliance specifications and

applications guidelines.

E Develop a defined subset of IGES entity types for

application to engineering drawings.

F Document and test a preliminary suite of IGES benchmark

files to demonstrate drafting applications.

5
G Develop a defined subset of IGES entity types for

application to 3D mechanical product models.

H Document and test a suite of IGES benchmark files to

demonstrate 3D mechanical applications.

1 Develop a defined subset of iGES entity types for

application to electronic printed wiring boards.

J Document and test a suite of iGES benchmark files to

demonstrate electronic product applications.

K Develop a defined subset of IGES entity types for

application to finite element mesh models and their

associated engineering properties.

L Document and test a suite of IGES benchmark files to

demonstrate finite element analysis applications.

M Develop a defined subset of IGES entity types for

application to ar che t ectur a I engineering and construction.

N Document and test a suite of IGES benchmark flies to

demonstrate AEG applications.

6
5 DEVELOP PRODUCTION WORTHY TRANSLATORS

GOAL:

An intersystem data exchange is basically limited by the matching

of functionality of the two systems and the quality of the preand post-processor translators available for use. A necessary

condition is that both translators be capable of processing ail

Information to be transferred. For a production-worthy exchange,

this processing must be complete and accurate. Where problems

are encountered, the translator software must effectively deal

with errors and supply sufficient information to the CAD operator

to detail the nature of the problem. Hence, the quality of data

exchange rests on the correctness and the completeness of

translator implementation.

it Is recognized that writing translators is a function usually

performed by each vendor's staff. Little material other than the

IGES Specification is available to assist the writer. This tasK

will develop necessary resource material, will generate the user

pressure for compliance and will feed back to the implementor the

results of analysis and intersystem testing on his translators.

APPROACH:

A first step in assessing whether a data exchange will be

successful Is a comparison of entity mappings between the

translators Involved and the anticipated content of the data

file. information must be made available on translator entity

capability and the way an internal entity is mapped in and out of

IGES. User guides are needed on how to plan for a successful and

complete data exchange and for the many considerations Involved

In writing an IGES translator. Finally, mechanisms will be

created for making the resource material freely available.

7
TARGET MILESTONES:

A Request and document vendor entity mappings.

B Develop a schedule of entitles to bo tested.

C Publish a User Guide to IGES Data Exchange.

0 Plan at least one major public demo each year.

E Publish sample specifications for procurement of JGES

translators and IGES data files.

F Develop a User Guido for writing IGES translators.

G Publish Recommended Practices for error checicing and

reporting by translator software.

H Provide error feedbacic from testing to vendors.

8
6 PERFORM EXTENSIVE INTERSYSTEM TESTING

GOAL:

Implementors typically develop their IGES translators based on

the printed specification and tend to work at arm's length from

each other with little opportunity for testing with other vendor

systems. This approach virtually assures that differing

Interpretations, or flavors, of the IGES Specification will be

promulgated. As this software Is released to users. Implementors

are warry of making changes, feeling an obligation to their

customer base to maintain the utility of any previously produced

datasets. Hence, an active and focused central program of

intersystem testing Is essential in order to develop smooth and

capable intersystem exchange capability across a broad range of

I mp I ement at I ons . APPROACH;

The Intersystem testing will provide close coupling between the

needs of users and the capabilities of vendor implementations in

a data exchange. The barriers to complete data exchange will be

analyzed and documented. Policies and software will be developed

to alleviate the problems where possible. This task requires the

active cooperation of Implementors and the outputs from other

tasks In this plan. Results of the frequent Intersystem testing

will be carefully evaluated to track the level of Implementation

and to refine the testing methodology, the test cases, the

software tools and the other testing materials.

A vendor's view of IGES tends to be limited to mapping his data

structure to and from a specified set of IGES entity types that

he has implemented. Users on the other hand are interested in

the more demanding task of an end-to-end exchange of the data

structure

.

This task is designed to develop competence in the full exchange

process, to understand the limits of the technology and to assess

the quality and completeness of the testing methodology, the

application area entity subsets, the software tools and the test

cases developed by the other tasks. Through extensive

Intersystem testing, guidelines can be developed for the user

community to maximize the Information content capable of being

exchanged or archived In IGES.

9
TARGET MILESTONES:

A Assess the completeness of the IGES Testing Methodology.

B Validate all test cases generated.

C Verify reported entity mappings.

0 Test developed software tools and refine if necessary.

E Develop database of Implementation capability.

F Document any inherent problems of CAD database exchange and

recommend solutions.

G Validate applications area entity subsets and the

information mappings.

10
7 DEFINE REQUIREMENTS FOR ARCHIVAL QUALITY DATA

GOAL:

The experience with IGES to date has been for exchange of

datasets. Success has been attained only through careful

planning and testing of the data paths used and the close

collaboration of sender and receiver. However, the need also

exists for the archiving of product data. This is a much more

demanding activity. The data is stored at one point In time and

transferred to a receiving system at a some relatively unknown

future point in time. The receiver acting alone must resolve any

problems that are encountered.

APPROACH:

This task will develop a full understanding of the "archive"

problem and will result in detailed guidelines and software tools

for ensuring the Integrity of datasets before they are accepted

Into archival storage.

TARGET MILESTONES:

A Host a workshop on the archiving problem.

B Develop documentation profile about the IGES file Including

the CAD system which generated the fiie, data organization

method and Information content.

C Determine if above information should be placed in START

Section or if additionai data eiements are needed in the

GLOBAL Sect i on

.

D Publish a report on fiie flavoring with emphasis on problems

for archiving and suggesting solution approaches.

E Document procedures for archiving 1 GES dat a .

F Develop software too is needed to check f 1 les before

archiving.
8 DEVELOP PDES VERSION 1.0

GOAL ; PDES Version 1.0 will provide entity capability for mechanical

piece parts, mechanical assemblies, electrical printed wiring

board products Including both schematic and physical designs, AEG

models, FEM models and drafting applications. Supporting

technical areas will also be provided In PDES for manufacturing,

solids modeling , curve and surface modeling and presentation

da t a

.

APPROACH

The development of Version 1.0 Is Intimately tied to the PDES

Initiation Activities described earlier. Major Inputs have come

from the Air Force PDDI contract, and much Is expected from, the

evolving GMAP contract. Details of approach are documented In a draft plan prepared by the PDES Project Manager.

TARGET MILESTONES:

A Develop a detailed project plan.

B Identify functional content of PDES Version 1.0 % C Prepare updated and enhanced project plan.

D Choose formal data modeling methodology for PDES.

E Prepare data models for each applications area.

F Develop conceptual schema for PDES Information.

G Specify a data specification language as the Interface

between the logical layer and the physical layer.

H Develop physical file structure.

I Embed the conceptual schema In the physical file structure.

J Publish Initial draft PDES Version 1.0

K Publish final draft PDES Version 1.0 for practical test and

va I I da t I on

L Develop algorithms to convert data In then current IGES

Version to PDES Version 1.0

M Release POES Version 1.0

N Release ANSI Standard for PDES
9 DEVELOP TOOLS FOR MAINTAINING THE INFORMATION MODELS

GOAL:

To be useful to the IGES community; a significant portion of the

standard, the conceptual schema and Its mappings, must exist In

computer readable form. The Information model will exist In

several forms during the life cycle of a particular change to the

standard. For example, the application committee interested in

the change Is Nicely to utilize IDEFIX to study and modify a proposed change. Later, the logical layer committee will use lA

to complete the analysis of the change and map It Into the

conceptual schema. The physical format committee will use DSL to

complete the mapping of the change into the physical format.

APPROACH:

Each of these forms of the Information model should be recorded

in a single format and language. Where automatic conversion

between different forms Js possible, software for accomplishing

the conversion should be developed and made available to

committee members. The software must read and write the standard

format for recording the model.

TARGET MILESTONES:

A Modeling methodology committee agree on set of tools

necessary to do the job.

B Modeling methodology and physical format committee define

standard format (probably an extension to DSL).

C -Software committee prepare specifications for any required

software modules.

D PubI Ish conceptual schema in standard format and males

available to Interested members.
JlaOALl

k'i

7ntt iti

m%s-' o>K

^ p jV*^ U HOIT^MWOHWI 3HT aWfillATHlAW ? JOOT S0J3V30

t . -V - . . ^ ^ . A j nrin#*4l «si;f >c$

ft«*r4 pro .let* Il'cluef ii B®|H # - - - _

!•-«/. -> cn.-.ul. un,...

• I '^*€ If ;jDa 4, 4

Jr in.f #4 « f

ird aiirflotl

pj jvntv ttd} DfJi-.wb ©‘10^ Ui*t*r

Xi ^M.rj.’." .•jf.r.r,’:, i;! ^.» »«•"•>;

iQt atruiM «; («»«»<

<)r.

^ HDA0J?*I^A Jl

h.i'l .* dL'iiv ''*. ,*-\ T(Mta^t ^‘•eaigwii. . i.bois floli»c'i-o'ni 'o *»iei •r*.it T® rts*3

M»v'e»«-' , . r,r,.» .o»i»on*t bnt »M)n',s • *'• ^PDif^iVivcs •te’ in.\*»^!e nn^ttC

no 1 t ttvaoi^ .ftrt J M,--i;« «d» rf'Mi >enc

snlbvo®*-! i<'; »*•«’

w cr*cj pfOib;? : ^ V _

'S'sr S fo*-^*;' t? *».! 1.^9 Gi«*inow*f>tOp|

J "sm

5 ^r#0 tf€ <?at§ f " iicfi, *wff * dr«,i* ^ ^

:f Otv#fM CD.* :*atUA I 3 Ct«%» f**r f^O!f$ ^n(ar^l^»>n• }

-.-V. YCO»0t>ofl?*O ^nll'ynoli A

y'tfiA'i V,-Vb*i‘T**Uffr . v«iJ»«a Vr x»i»**i^*'* .-, ,f)» Icr1‘:ll mil*'' VB« .t»v;,,j.t >.<*r.

Drtltfc&OM e

y®<

^.v -^C 1 * - t »yf*a DHft <Bo I 04/ gn Itt&oM 6

|;^t-‘M^^ li%?t;tl drift rs4a V«r«?ion ?.C,

iii I

» . •»ti*r ft# t I d 1*5, ^ Id^Mon^ ‘ • i sr. b

0^v^**;a *i^crrJth«» ti» co^tTAft Ott«

»'•.*- f4 to ?Uf# Vortlofs 1*P /

' \te^, CfiLfC4 »P

..T. 1

. V, i .*^«o ?0^$ v#r#l<m t o

II, 1l4|0#»OgAHti Sttr^dard for #OCS

n2

, i

.‘f-'i, TiT'- ^•'

^ S
APPENDIX F

Itiiit-ililiUtiiii'ititiiititiiiiit

COMPLETENESS OF PRODUCT DATA EXCHANGE

A conceptual model for product definition information exchange is presented

along with a discussion of the responsibilities of the system users in

effecting a successful exchange. Also presented is a discussion of the role

of the XGES Organization in supporting these users in their quest for accurate

and reliable information exchange on a routine basis.

Computer aided design and drafting (CAOO) systems are becoming quite

commonplace in many segments of our society. The proliferation of traditional

CAOO systems, and the introduction of low-cost, microcomputer-based CAOO

systems have given many people amd -organizations their first taste of the

creation aind ^ssemination of product definition information in electronic

form. This increase in the use of CAOO and other systems which generate

product definition data is causing more and more people to become concerned

with the exchange of information between systems which are incompatible. It

is the desire of these people to establish accurate and reliable exchauige of

product definition information between dissimilar systems on a regular and

frequent basis. In this paper, the author refers primarily to the kind of

data used on CAOO systems but the concepts are equally applicable to any of

the systems which deal with product definition data.

In the following discussion, it is important to distinguish between data and

information. Data is defined here as 'simply a collection of facts. In

contrast, information is made up of data as well as the relationships among

the data items and is, therefore, more meaningful emd valuable.

The conceptual model for product information exchange used here is a

hierarchical one consisting of four layers (Figtire 1). Starting at the

highest layer, these are (1) a common knowledge base with its definition of

information content, (2) representational models with their standards and

conventions, (3) data translation standards and conventions, and (4) data

transmission standards and conventions.

In any exchange of information, there needs to be a common understanding of

certain fundamental principles between the parties to the exchange. This

I common knowledge base is necessary so that the meanings of what is said can be

understood. An important part of this common knowledge base is an

understanding of the basic information which is required to communicate some

meaning from one party to another. As an example of this, consider the

exch2uige of drilled hole information between a designer and an N/C programmer.

Both need to understand certain basic concepts for drilling holes; they also

have to define what information is needed in order to specify the holes to be

drilled (e.g., location, depth, diameter, tolerances on each of these lengths.

< < < INTROOOCTION > > >

< < < A CONCEPTnAL MODEL FOR INFORMATION EXCHANGE > > >
etc. ) • The representational models concern themselves with how the information

content of the icnowledge base is to be represented in a particular CADO

database. Standards and convetions need to be developed so that consistent

representation will be found within a given system, but the representational

models may not be, and do not have to be, the same between systems, especially

if the systems are supporting different disciplines. For example, the

representation of a drilled hole on an engineering design system does not have

to be the same as its representation on an N/C programming system, so long as

the inforamtion content is present on both systems. In this example, the

engineering design system might represent a drilled hole by two circles

connected by three lines with yet a fourth line indicating the angle of the

drill at the bottom of the hole, while the N/C programming system might

represent it as two points (at the beginning and end of drill penetration) and

a circle.

Another example of representation conventions in a machining environment could

be that external cast features are to be found on layer 1, internal machined

features on layer 10, through holes on layer SO, etc. In an electrical

environment, the representation conventions could be that^ the outline of the

printed circuit board is to be found on layer 20, the physical details of each

of the n layers of the circuit are to be found on layers 30<»n, ax^ the

supporting design details (e.g., schematics and netlists) are to be found

elsewhere on specific layers.

Obviously, these sorts of conventions are highly dependent on the parties

involved in the information exchange. Bven with the attempts at

standardization of such industry groups as the Automotive Industry Action

Group (AIAG) and the Electronics Industry Association (BIAK , there is still

much room for establishing unique conventions between the parties at each end

of an information exchange.

Frequently, the term information modelling is used to mean the combination of

the information content and the associated representational model.

Data translation standards and conventions address how the data is transformed

from the native form of one system to the native form of another system.

There aire two fundamental approaches to this task; direct translation and

indirect translation. Direct translators take the data from the sending

system and transform it immediately into the equivalent form on the receiving

system. Direct translators have to know the internal data structures and data

definitions of both systems involved in the exchange. Indirect translators

transform data between the native form on one system and an intermediate,

standard form (usually referred to as a neutral form) . Indirect translation

is a two*step process: translating from the native form on the sending system

into the neutral form, and translating from the neutral form to the native

form on the receiving system. IGES (the Initial Graphics Exchange

Specification) is an example of an indirect translator.

Data transmission standards and conventions define the process of moving the

data from one system to another. This layer of the exchange model is

concerned with the physical media and the standards and conventions which

apply to writing data to a medium and reading the data from it. For example,

the most common means of transmitting data in IGES form is by way of magnetic

tape. By convention of the IGES community, the tapes are written at 16 00 bits
THF CADD INFORMATION

FXCHANGE ENVIRONMEM

PRODUCT INFORMATION

/\ /\

SENDER RECEIVER

TRANSMIT

NATIVE NATIVE

FORM TRANSLATE TRANSLATE FORM

1 COMMOI

(INFOf

1 ^ KNOWLEDGE

^MATION CON

BASE

TENT]

REPRESENTATION

CONVENTIONS

REPRESENTATION

CONVENTIONS

DA^

STANDAR!

1

'A TRAN SLAT

DS AND CON^

ON

MENTIONS

DATA TRANSMISSION

STANDARDS AND CONVENTIONS

FIGURE 2
To teat the information modelling levels, end-to-end teats must be run between

the systems which ait on each end of the information exchange* These are the

testa which will ultimately tell whether the exchange can worh. These teats

are entirely dependent on the users' environments and the underlying systems.

They cannot be run by any agency for the "general case."

< < < HOW THE IGES 0RCAN12ATI0M CAN SUPPORT THE USER > > > There is a desire on the part of the members of the IGES Organization to

assist users in successfully creating a reliable information exchange

environment. Unfortunately, no one can completely guarantee such an

environment except the useir himself. The IGES Organization can, however,

supply services and tools which can increase the likelihood of success.

The Organization can publish tutorials and case studies concerned with these

user tasks and how to accomplish them. There are many IGES members who have

already started to wrestle with these issues and can provide valuable insights

for those just beg^ning. There are actual examples, of both successful and

unsuccessful attempts, which can help users to progress through these tasks

smoothly while avoiding pitfalls.

The Technical Committees of the Organization can define modelling entity sets

for different application areas, and can provide IGES files which correctly

demonstrate how the application entity set is to bm used to create the models.

These entity sets can aid the users in establishing- their own modelling

conventions. Both users and translator implementers can look to the

demonstration files for examples of how to deal with the information content

and the representational conventions for that application area.

The Organization, through its testing agent, can provide reliable information*

on the general performance of IGES translators. This information will consist

of entity maps and performance designations. The entity maps define which

modelling entities on one side of the translation are transformed into which

entities on the other side. The performance designations indicate the degree

to which the information content of the modelling entity is preserved during

the transformation.

< < < CONCLUSION > > > A simple conceptual model for product definition information exchange has been

presented which can be used to orgamize the work required to create an

effective information exchange environment. This model consists of four sets

of standards and conventions: information content, representational modelling,

data translation, and data transmission. The responsibilities of the parties

to such an information exchange in establishing these standards and

conventions have been described. The underlying work must be done by the user

(or a consultant to that user) and cannot be done successfully by an

independent body for the general case; the details which affect the contents

of the specific conventions and the users' operating environments vary too

widely to be reasonably supported in the genereU. case. The functions of the

various types of testing which must be carried out have been described. Also

described has been the support role for an independent body such as the IGES

Organization. The type of assistance this organization can lend has been

outlined, and falls into the categories of providing user education in the

areas of modelling conventions, testing methods, and application entity sets;

and providing reliaible performance information aibout translators.
appendix g

Initial

Graphics

Exchange

Specificaticn

DOCUMENTATION

FOR THE

TESTING METHODOLOGY

OF

IGES TRANSLATORS

• AND

IGES FORMATTED DATA FILES

WORKING PAPER VERSION 0.03

19SEP86

PREPARED BY: TESTING METHODOLOGY COMMITTEE

IGES ORGANIZATION

APPROVED BY:

BRADFORD SMITH

CHAIRMAN

IGES STEERING COMMITTEE

0291X
* Preface to the Working Paper *

The enclosed material represents ideas and concepts to be considered

by the IGES Technical Committee members. Your comments and ideas

are solicited and should be addressed to the editor. As this

material is subject to major changes during the technical review, it

should not be taken as representing a consensus of any IGES

committee.

This working paper of the Testing Methodology document contains the

collection of the most recent thoughts of the members of the Testing

Methodology Committee. It is my intent to prepare a new version

shortly before each of the quarterly IGES meetings, then collect

changes and additions at the meetings to incorporate into the next

version. In some instances. I will add to or change the working

paper to reflect what I thought was the sense of the committee. It

is expected that anyone not agreeing with the changes will challenge

the new version.

Where items have changed substantially from the previous version, a change bar in the right margin will be found. The working paper

version number is made up of a major version number (equal to the

version number of the latest release of the document), a decimal

point, then the sequence number of the latest version since the last

release of the document. Hence. Version 1.07 is the seventh version

of the working paper after the first published document version.

J. M. Fleming

Editor

Cummins Engine Co., Inc.

Box 3005. M/C 50142

Columbus, IN 47202-3005

Testing Methodology Document Working Paper

i
1.0 ABSTRACT:

This document contains the descriptions and explanations of

the test methods and test data sets collected and developed by

the Testing Methodology Committee of the IGES Organization

which is sponsored by the United States National Bureau of

Standards. The document also describes the purpose and worlc of

the Committee. This information is intended to be used by

people interested in the verification and use of IGES

translators

.

The test procedures and data sets contained herein are aimed

at exercising many aspects of data translation performed as a part of the exchange process for product definition data.

Expected results of each test, along with guidelines for

evaluating a processor's performance, are also presented

.

Suggestions for additions to, and corrections of, this document should be sent to the Chairman of the Testing Methodology

Committee via Mr. Bradford Smith, Chairman, IGES Steering

Committee. National Bureau of Standards. Gaithersburg. MD 20899

1.1 Acknowledgements

This document is the product of many hours of work on the

part of the members of the Testing Methodology Committee.

In addition, the following companies contributed

employee's time and computer resources to help verify the

procedures and test data included.

Testing Methodology Document

1

Working Paper
2.0 introduction

2.1 The Charter of the Testing Methodology Committee

The Testing Methodology Committee has been established to

create and maintain a collection of test methods, along

with their supporting data sets and software tools, aimed

at verifying and diagnosing IGES processors and data

files. This charge includes coordinating the committee's

worh with that of other individuals and groups engaged in

similar efforts. Development and maintenance work consists

of producing at least the specifications which can be used

to create and modify the test methods, test specifications

(how to run a test), and evaluation criteria (how to judge

the results).

2.2 The Scope of IGES Testing

The Testing Methodology Committee should concentrate its

efforts on developing and maintaining test pxocedures which

deal with verification testing, validation of processors

for specific application subsets, and application-specific,

user-performed acceptance testing.

In this context, verification testing is aimed at ensuring

that the implementer * s claims for entity mapping and

functionality of translation are accurate, validation

testing is aimed at ensuring that application subsets of

IGES/PDES are treated in a manner consistent with the

application, and acceptance testing is aimed at ensuring

that particular IGES/PDES processors will work adequately

in a user's environment.

The immediate goal of the Testing Methodology Committee is

to establish a verification program for IGES translators.

An underlying concept to this testing is that of

functionality. Functionality of the results of a

translation is defined as the degree to which processed

part data have been treated as if they were generated on

the system being tested.

2.3 The Need for IGES Testing

There are several major reasons why testing IGES processors

is necessary. Both implementers and users of the

processors are interested in testing. Implementers need a

set of widely accepted test procedures and data in order to

ensure that their products conform to and adequately

support entity subsets for a specific application area of

the IGES standard (i.e.. verification and validation

testing) . Users and implementers need a set of widely

Testing Methodology Document

2

Working Paper
2.3 The Need foe IGES Testing (cont'd)

accepted test procedures to determine if the processors in

question will adequately support the user's data exchange

requirements (i.e., acceptance testing). In addition,

users frequently desire advice on how to construct test

data sets which will accurately reflect these data exchange.

requirements. Finally, since much data exchange, worth

millions of dollars, will be accomplished using IGES

translators, users are requiring more assurance that the

data is not being modified or lost during the exchange

process

.

2.4 The Fundamental Principles of Testing

A distinction is to be made between demonstrating and

testing a product. The objective of a demonstration is to

show that the product works (i.e., that the features and

capabilities function as advertised). As a result, a data

set for demonstration purposes will usually be well-formed

and will contain no errors. In contrast, the objective of

a test is to expose flaws in the product (i.e., to show

where the product does not work as it should). In this

regard, data sets for testing should contain purposely

malformed and incorrect data.

In his book. The Art of Software Testing {MYER79}, Glenford

Myers cites the following basic principles of tests:

. Testing is the process of executing a program with the

intent of finding errors.

. A good test case is one that has a high probability of

detecting an as-yet undiscovered error.

. A successful test case is one that detects an as-yet

undiscovered error.

In the context of generalized IGES processor testing, the

test cases developed will be aimed at exposing flaws in

important features of the processors. Since the test cases

will be known to most of the implementers of these

processors, the opportunity will be available to them to

construct the software so as to pass the tests. If the

contributers to the Test Data Library do their jobs well,

this should not be a drawback to the verification process,

but a positive influence on the construction of working

translators.

Testing Methodology Document

3

Working Paper
3.0 ACCEPTANCE TESTING - A TUTORIAL

This section is provided as an aid to end users who need to

determine the suitability of IGES translators for their

applications and operating environments. It is impossible for a single agency to provide the level of testing required to malce

this determination. Therefore, it is up to the end user to

examine his/her own environment and to devise appropriate tests

to ensure that the proposed translators will perform

adequately. A fundamental concept in this worlc is that of

entity mapping. The next section explains this concept. In the

sections which follow, then, are explanations of how the end

user's acceptance testing should be carried out.

The verification program described later in this, document will

provide a solid basis for acceptance testing by assuring that

the entity mapping claimed by the implementer accurately

reflects the processing carried out by the translator, and. in

the case of preprocessors, that the IGES entities are correctly

formed. Once the end user is aware of the capabilities and

limitations of the translators, a more controlled and effective

data exchange can talce place between dissimilar systems.

The report of the results of the verification testing for a

translator plays an important role in assessing how effective

the data exchange will be. both into and out of a particular

system. This report contains the translator's entity map along

with the findings of the verification testers concerning the

preservation of functionality and the correctness of the entity

formulations

.

3.1 Use of Entity Mapping in Data Exchange

In general, entity mapping can be described as the manner

in which the implementer of a translator has defined the

correspondence between native entity forms (i.e.. the

entity form maintained within a system) and the IGES entity

forms (i.e.. the entity form contained in the IGES

specification). For example, a string of curve and line

segments on a system may be translated into a Composite

Curve entity (Type 102) by a preprocessor. This

correspondence of a string in the native form to a Composite Curve, in the IGES form is the preprocessor’s

entity mapping for the native string entity. Similarly, a

postprocessor may translate a Copious Data entity (Type

106) into a 3D line entity on the receiving system under

some circumstances. Thus, the correspondence of the

Copious Data entity to the line entity is the

postprocessor's entity mapping for the IGES Copious Data

entity.

Testing Methodology Document

4

Wording Paper
The forms for the preprocessor entity map shall include

the names of the IGES entities and the names of their

corresponding native entities along with the letter

designation which identifies the degree to which the

functionality of the IGES entity is preserved in the

translation.

The entity maps can be used as a first step in determing

how well data can be exchanged between two systems.

Knowing the native entities which are to be used on the

sending (or initiating) system* the end user can follow

each entity through the entity maps for both the

preprocessor and the postprocessor to see what the

resulting entity will be on the receiving system. The end

user can also see from this how good the translation of

that entity will be by looking at the corresponding letter

designations

.

Depending on the end user's application of the data

exchanged* imperfections in the mapping and translations

may be acceptable. Acceptance tests should be performed to

determine the effects of imperfections on the overall data

exchange. Based on the results of the acceptance testing*

the end user can strive to improve the quality of the data

exchange by:

. making use. of options provided by the translator*

. adding to and deleting from the list of native entities

being used*

. developing intermediate processors to deal with < "flavoring" during translation.

Flavoring is a term that is used to describe particular

practices built into a translator in situations where* for

preprocessors* the underlying system supports entities or

relationships which are not directly supported by IGES*

and* for postprocessors* the underlying system does not

handle specific entities or relationships supported by

IGES. Since the manner in which these situations are

handled is not standardized* other knowledge than what is

available in the IGES document is needed. This additional

knowledge is frequently built into the translators.

3.2 Designing an Acceptance Test

To be added

3.3 Evaluating of Accpetance Tests

To be added

3.4 Application Entity Subsets

To be added

Testing Methodology Document

- 5 - Working Paper
f»TR FILES

^

.SrSiSSt .o t-.t.

•XA«io^ wH-l ,„ MM JU5^WM of-.-S

iiriiO‘f

I

'i>*

-Tffi:

Lirrri^

«, '-^susa&iui ki,

, i;:.-: .c.pco^;. ^., -c t.. ^S^

.

•ii^cilM.

mo^

m foc 4

'"m 13 » ijictwav^

3 fciV0 J: 9| ao3 .•lertMl,, „., .earn

100 •«<^.ftis/a<«f

»„ ,S A

'•dwinv- f-c

o^ce*oc*4 ioe •*»- <:e i.i)il tats * JO 1-la*

gij®|iglac5

^

-&•

{fSlpl:

"• • 4 ;«» tacit'

ru. llB*

fo» i tail

.

CMwm• *" ' iU i^r» *

,’. j •<•» 0 it(S..i;» Ma-' &9

j,, cipi«^,i>4ta .auv

soiAmt

poB<’ti'e'^«*®'J*^ ‘ * aippiaa tor

k'" 'i ' ‘'‘' -J

85 ob«Jw* ysiaoS oolJfcoIIq^^

Worlclno Pap0C

Testing Methodology Document^ ^

,

,9r-^ jj _^ , . •

^^4 8,8 - 6 - 3jD»ff *t>oO xpolohcriTn. T

l!>g6*5 VrI" t 4
5.0

VERIFICATION PROGRAM

5.1 Rationale

It is requited that the IGES organization provide a verification process for IGES translators. This

requirement is imposed by the ultimate users of these

translators - the people whose business requires the

exchange of product definition data in electronic form

between computer systems.

In devising such a verification# the first consideration is

that of deciding what aspects of the translation process

can be verified. From the end-users' point of view the

ideal verification would be that of a complete, end-to-end

data transfer. To do this, however, requires not only a

great deal of testing to cover all the necessary

combinations of vendors' products, but requires that these

combinations be tested for each different user's

application and environment. This is an impractical task

for a verifying agency.

The following approach to translator verification has been

devised to provide users with the greatest amount of

reliable information. Also provided is a discussion on how

a user is to employ the verification results to establish a reasonable data exchange environment (see Section 3.0).

It is proposed that the thrust of the verification of a

processor be the substantiation by an independent agency

(the Society of Automotive Engineers —the SAE) of an i implementor's claims for the entity mapping and other | processing carried out by a translator. The method

proposed here is to collect this information from an

implementor for each proceseor to be verified, and then to

j perform sufficient testing so as to verify that the claims

made are correct and that the entity mapping is correctly

described

.

5.2 Overview of the Verification Process

The verification process is initiated by an implementer I (called the Presenter) by filing a Verification Request • Package with the IGES Verification Panel of the SAE (give

specific citing & address). The Verification Request

Package will contain a cover sheet (Figure 5-1), a set of

entity mapping forms (Figures 5-2 and 5-3). and any

required system and application documentation.

The Verification Request Package sheet contains identifying

information about the Presenter and the processor to be

tested. It also contains a checklist for the information

required to support the verification testing. The

documents required to support the testing may vary from

system to system. All documents submitted should be listed

here

.

Testing Methodology Document

- 7

Working Paper
IGES

VERIFICATION

REQUEST • • op•<aS

oesu

LxJ (X o ^ p ® < W P P ^ S w

C£U

q: < F

a: o z z o CO o ex Cia CO CO p o

CO u Lu ex u o m ^ 2 o u o Cj CO o OS CO as

a. o w uo

CaJ CO LJA P o

OS o Q« OS ex Q. Q. CO o CL

CO

(jj

CL

CL O a CO 3Oo

q:oooex

0.

CJo u

cn ga u u ^ g a a a H O o

UJP cn 2 V3

LU

U

COu

C£

Q.

a:

C3o

•< 2OP<o

EZP ^ u < S 2 CO w < P LiJ CO -J >- CiJ CO c u

SS>-

ex cou

CO<

CjJ

-J

CxJ ex op

ffi o

cZ2OOu

ex<o

•< 2 o

CO u

CO z S

CQ

S2

CO

yP S CO <

CO < o

a.o • • 2 • • • • O o o P p • 4 p < •< < o u < o

cZ lZ cZ P P p • • O

CaJ X< us

cso

CO

COu 2uQ <o U CiJ o u CaJ CO CO o CO CO

<c o < X

CiJ CO CiJ Cij u u

CiJ C<J CO CiJ LiJ ex C3<o X LJo X X i

FIGURE

6-1:

COYER

SHEET

FOR

THE

VERIFICATION

REQUEST

PACKAGE
PREPROCESSOR

ENTITY

MAPPING

o

u

o

<

CL

!

REMARKS

(PRESENTER

AND

TESTER)

FNCTL FOUND

ncb

FNCTL CLAIM

ICES

ENTITY

NO.

100 CIRCULAR

ARC

NO.

102

COMPOSITE

CURVE

N0.104

FORM

0

CONIC

ARC

(GENERAU

N0.104

FORM

1

CONIC

ARC

(ELLIPSE)

N0.104

FORM

2

CONIC

ARC

(HYPERBOLA)

N0.104

FORM

a

CONIC

ARC

(PARABOLA!

NATIVE

ENTITY

FIGURE

6-2:

PREPROCESSOR

ENTITY

MAPPING

FORM
POSTPROCESSOR

ENTITY

MAPPING

o

cuo

ce

cn So

U

cnu

a:

QL

p22

CbU

p

u

u

p

F

UJ

cnLUO

O

crc

crc

o-j

2S6S

:zo

a:

o

CQ

(M o

O 2. c a

21 o

Qi

oS2“

oo^ ZO w

£a--

<CJ

Soi^ -J

6ojj ZOw

C4

G2

o

Q.

07

2

,, c o_j 50 <s: cs o

-<£23 •<o

cr ^ cn O Lk2 o<^-<

2i« o>:

i=i — £r

do 2 O C 20 w

FIGURE

6-3:

POSTPROCESSOR

ENTITY

MAPPING

FORM
5.2 overview of the Verification Process (Cont'd)

The Verification Request Entity Mapping Form contains

information about the entity mapping between native

entities and IGES entities that the translator purports to

implement. (Note that there are two sets of forms, one for

a preprocessor mapping, and the other for a postprocessor

mapping.) The third column on the form gives the

Presenter's claim of the functionality of the mapping for

each entity listed in the native entity column. See

Section 8.1 for an explanation of the functionality

designations. This information is necessary to enable the

verification testers to determine which test cases need to

be executed. The rightmost columns on the form will be

used by the testers to record the test results. Presenters

may also use the remarics column to identify unusual

situations

.

After reviewing the Verification Request for completeness,

the IGES Verification Panel will schedule the test and

assign a tester. Using the information on the request

form, the tester will identify the test cases needed from

the test library and any that need to be written. The

tester will also develop the specific evaluation criteria

for the test cases. Finally, the tester will execute the

test plan and record the results. These results will be

returned to the IGES Verification Panel for a decision on

whether the processing of the translator has been verified.

The IGES Verification Panel will notify the Presenter of

its findings prior to any public release of the

verification material. The Presenter will than have an

opportunity (30 days?) to respond to any problems

encountered or to appeal the decision of the Panel.

When a translator has been successfully verified, the

Verification Package (the request, test results, and

summary report) will be forwarded to the NBS for

distribution. The NBS will distribute copies of the

Summary Report and the Verification Package on request.

If in subsequent use of a verified translator, a user has

reason to believe that the translator is not working as

verified, the user should notify the Chairman of the IGES

Verification Panel (give address of SAE office). Such

notification should include sufficient information to

recreate the fault.

Testing Methodology Document

8 - Working Paper
5.2 overview of the Verification Process (Cont'd)

The Panel shall forward the notification to the Presenter

for response, and to the Test Agency(s) for review. If the

Presenter does not adequately resolve the problem, the

verification for the translator will be revoked.

5.3 Verification Program

The IGES verification program is being sponsored by the

Society of Automotive Engineers (SAE). It is one of

several verification programs administered by them. There

are four groups which participate in the verification

program: the SAE staff, the Technical Board, the IGES

Verification Panel, and the testing agency(s)

. Provide administrative services and support.

. Arrange logistics of meetings including meeting

facilities.

. Handle invoicing and collection of presentation

fees

.

. Maintain detailed financial information on- incomes

and expenditures of the IGES Verification Program.

Provide such information to the Technical Board

to assist it in establishing appropriate fee

structures

.

. Arrange for appropriate legal counsel and report

the findings and recommendations of legal counsel

to the IGES Verification Panel.

. Arrange for appropriate indemnification insurance

for the IGES Verification Panel.

. Assure compliance with all prescribed forms and

procedures involving the IGES Verification Program

. Hire a capable agency(s) to perform the testing

and provide contract administrative support.

. Maintain appropriate records.

. Establish and maintain procedures to ensure the

confidentiality of certain results as appropriate.

Testing Methodology Document

9

Working Paper
6.0 OVERVISW OF TSST METHODS

The testing of IGES pcocessocs can be classified in various

ways. As discussed in Section 2.2, the entities and parameters

to be tested are chosen based on whether the intent of the

testing is verification, application validation, or user

acceptance. Three levels of test are identified here. These

levels are referred to as the physical, logical and functional

levels

.

On the physical level, the testing is aimed at verifying the

ability of processors to handle the syntax of the specifications

(e.g., proper recognition of data types). On the logical level,

the testing is aimed at verifying the entity mappings defined by

the implementers (e.g., a particular entity is translated into | and out of the native form in conformance with the IGES

specification and in accordance with the implementer ' s claims),

j On the functional level, the testing is aimed at determining the * degree of equivalence between data models on both ends of a data

exchange.

Table 6-1 presents a summary of several key considerations for

the different test levels. Details are contained in the

following paragraphs.

6.1 Types of Tests

This section presents-an overview of a number of different

approaches to processor testing. Various combinations of

these test types may be usbd diiring the testing of an IGES

translator. The details of how the test results are

evaluated and how success of processing is determined

depend on the specific test being run and are to be

described in the appropriate testing documentation (see

Section 9)

.

One-way Preprocessor (Figure 6-1) - A test of a preprocessor which translates a known CAD model into a resulting IGES model. This IGES model is then examined to

determine the success of the processing.

One-way Postprocessor (Figure 6-2) - A test of a postprocessor which translates a known IGES model into a resulting CAD model. The CAD model is then examined to

determine the success of the processing.

Circle (Figure 6-3) - A test of both preprocessor and

postprocessor. A known CAD model is translated into an

IGES model which is then translated back into a CAD model.

The resulting CAD model is compared to the original CAD

model to determine the success of the processing. This is

sometimes called a Loop Test.

Testing Methodology Document

15

Working Paper
6.1 Types of Tests (Conf d)

Simple Intersystem (Figure 6-4) - A test of the

preprocessor of one system end the postprocessor of

another. A known CAD model from one system is translated

into an IGES model which is then translated into a CAD

model on the other system. The resulting CAD model is

compared with the original CAD model to determine the

success of the processing. Frequently, variations such as

reversing the direction of data flow are performed.

Jury System (Figure 6-5) - A test where a single system

under the test is used to run intersystem tests pairwise

with a number of other systems. This form of testing is

used to determine the suitability of the processors on the

system under test in a real-world environment.

Daisy Chain (Figure 6-6) - A test in which a known CAD

model is passed through several systems' preprocessors and

postprocessors in succession. The resulting CAD models are

.compared with the original to analyze any degradation of

the data caused by the multiple processing.

6.2 Combined Testing

The above methods are* combined to test end-to-end data

exchange for acceptance testing. Depending on the user's

requirements, the test method will be a choice or

combination of the simple intersystem test, the jury system

test, or the daisy chain test.

Where possible, software tools are being produced to assist

in the analysis of the Test Result Models (See Section 9.4)

Testing Methodology Document

16

Working Paper
Table 6-1 Summary of Testing Levels

TYPE OF

TEST

I

! Physical

!

I

I

Logical Functional

WHAT IS

TESTED

!

!

1 Syntax and

I structure

Entity Mapping

and

System Limits

End-to-End

Data Exchange

BASIS FOR

TEST DATA

!

I

t IGES

! Specification

I

!f

IGES

Specification

and

Implementer '

s

Entity Ma^

Application

Requirements and

Implementer '

s

Entity Map

TESTER

1

! Implementer

I

!

I

Verifying

Agency

End User

Preprocessors

Modeling script-to-IGES File

Postprocessors

IGES f ile-to-database

! ! I EVALUATION ! Preprocessors 1 Before and after

I Error Log ! IGES model I comparison with

. ! t comparisons ! respect to user

I ! criteria

! ! - Visual comparison

I Postprocessors ! - Operational and

I - Syntax t - CAD model 1 functional tests

! Checker ! comparisons I - Database content

! I - Operational !

! ! tests 1

I ! - Geometric !

f

1

I verification I

! PURPOSE OF

!

! Error I Formal

!

I Applicability in

TEST AND I Detection 1 Verification 1 specific appliesUSE OF ! ! tion environment

RESULTS !

I

I

!

TEST

METHOD

Testing Methodology Document

17 - Working Paper
c TEST ^

^YSTEIL^

NATIVE

FORM

»( compare)*

FIG. 6-1: ONE-WAY PREPROCESSOR TEST

IQES

P0S17R0CESS0R

r TEST ^

^YSTEM>

NATIVE

FORiyr

*( compare)*

FIG. 6-2: ONE-WAY POSTPROCESSOR TEST

HG. 6-3: CIRCLE OR LOOP- BACK TEST
FIG. 6-4: SIMPLE INTERSYSTEM TEST

rsY^^r r

r

SYSTEM UNDER TEST

system a”!

w test . NATIVE

TARGET SYSTEMS o

0

test , ^VsSYSTEM^

NATIVE

SYSTEM Z

TEST

'^SXSTEl^'

NATIVE

FORM

KCOMPARE

FIG. 6-5: JURY SYSTEM TEST
FIG.

6-6:

DAISY

CHAIN

SYSTEM

TEST
7.0 VERIFICATION TESTING

The following paragraphs describe how the verification tests are

to be run. Some variation on the test methods explained below

may be used for particular tests. Specific test procedures are

given in Section 9.

7.1 Preprocessor Testing

The procedure used in testing preprocessors at the physical

and logical levels (Table 6-1) is shown in Figure 7-1. The

following paragraphs provide more detail about the various

components of the test.

A script is provided in the test documentation describing

how to model the Standard Reference Model on the CAD system

under test. This script is functional in nature and

identifies the kinds of entities and groupings needed for

the test. The script is used by an experienced CAD user to

create the native form Standard Reference Model. Once

built, the model is verified to ensure that the proper

entitites and data are present in the CAD system's data

base.

The native form Standard Reference Model is then translated

into the IGSS form Test Result Model by the preprocessor

under test. The preprocessor error log is used to aid in

identifying problems with the translation.

Following the translation, ^the Test Result Model and the

IGES form Standard Reference Model are compared for

equivalence. The comparison must consider not the

record-by-record equivalence of the IGES files, but must

fully reduce the IGES data in order to establish the

functional equivalence of the° models. In this sense, not

only must geometry be transformed completely into model

space, but entity replications must be performed (e.g..

groupings of entitites must be maintained). Display of the

models may be used depending on the particular test being

run. The comparison also produces exception messages

describing any anomolies found.

During the comparision of the two models, some computerbased analysis may be required. These routines will be used

for such comparisons as determining whether two space curves

are equivalent by comparing their values at a prescribed

number of intermediate points.

As part of the evaluation of the results, various verification procedures are followed. These procedures cover such

items as syntax checking of the Test Result Model and collecting model statistics (e.g., entity counts, levels used,

fonts used, etc.). The verification procedures produce

exception messages describing any anomolies found.

Testing Methodology Document

- 18

Working Paper
SCRIPT FOR

STANDARD

REFERENCE

MODEL

STANDARD

REFERENCE,

MODEL |tnL?rA>rrn 'FORMATTED

ATA FILE

C test >

NATIVE

IGES

PREPROCESSOR FORM

DISPLAY

EXOEPTION

MESSAGES

STATISTIC

HG. 7-1: TEST SCHEME ADOPTED FOR

IGES PREPROCESSOR TESTING

.5
7.2 Postprocessor Testiag

The procedure used in testing postprocessors at the

physical and logical levels (Table 6-1) is shown in Figure

7-2. The following paragraphs provide more detail about

the various components of the test.

The IGES form Standard Reference Model provided in the test

documentation is translated into the native form Test

Result Model by the postprocessor under test. The

postprocessor error log is used to aid in identifying

problems with the translation.

The Test Result Model is verified for geometry,

functionality, and operational completeness. A

verification script is provided in the test documentation

which describes the procedures to be used in evaluating the

Test Results Model. This verification script identifies

steps to be taken by the tester in checking that data and

relationships have been preserved in the translation. The

script is used in conjunction with other verification

procedures and software. These procedures cover such items

as what inspection and querying should be done against the

Test Result Model, what further processing should be done

against the Test Result Model, what further processing

« should be attempted on the Test Result Model on the system

under test, and collection of model statistics (e.g.,

entity counts, levels used, fonts used, etc.). The

verification procedures produce exception messages

-describing any anomolies found.

Another script is provided in the test documentation in

some cases to describe how to model the Standard Reference

Model on the CAD system under test. This script is

functional in nature and identifies the kinds of entities

and groupings needed for the test. The script is used by

an experienced CAD user to create the native form Standard

Reference Model. Once built, the model is verified to

ensure that the proper entitites and data are present in

the CAD system's data base.

In addition to being subjected to the verification

procedures, the. Test Result Model may be compared with the

native form Standard Reference Model for functional

equivalence. For these purposes, functionality is defined

as "the degree to which the processed part data is treated

as though it was created on the system under test"

{DRAT84a}. Display of the models may be used depending on

the particular test being run. The comparison also

produces exception messages describing any anomolies found.

During the comparison of the two models, some

computer-based analysis may be required. These routines

will be used for such comparisons as determining whether

two space curves are equivalent by comparing their values

at a prescribed numoer of intermediate points.

resting Methodology Document

- 19

ifi. Working Paper
STANDARD

REFERENCE

FIG. 7-2: TEST SCHEME ADOPTED FOR

IGES POSTPROCESSOR TESTING
GRAPHICS INTERCHANGE
i^MOARD

IXOOEl

/' |Q€3

'^' #r |r<’- ' ^ORWAtTM

'?at4 nu^

,' •’ V

' 4- ' J

r itt£s

M POil^POCCttO^

rl»i' I- ?

.,f M’ *!-• A'S(. 1 SCRIPT I OR

TEBT I

i* \--r24.

I gtJ^HOARt)

’.i Rtf iRENCE

tiOOCl

HATl'/E

FORM

VERIFJ CATION!

ocmpT

HAT1V^'‘*

FCRi

VtRlFV

\i < i'

SHr •<!i-. ry.

'kilt'

OIBPtAY

*' m

'** 'I *-‘S

Iv •*'; it. .f-JSPkLXCF.<nC*i

* UF3?A«E5

^ r • - i

fill -- f!S. 'ira; TEST

IGES PCSIB ^ r

^ • •• • IB

*1

aoopted for

TESnK

. ^ ; iW

..3» J
1.2 COMPUTER GRAPHICS STANDARDS

SPECIFIC TASKS

FY 86

1. Assess DoO needs for Computer Graphics (CG) interchange

standards s

a. Identify graphics interchange requirements in terms of

CALS applications (e.g., engineering drawing repositoriesr spare parts procurement^ technical publications).

b. Assess the advantages and disadvantages of proposed and

existing graphics standards for specific CALS applications. Recommend a set of computer graphic standards

for DoD use. This should be done in conjunction with

tas)c I.1.2.a.

c. Assess the compatibility of various graphics standards

with proposed PDD standards (IGESr PDES, etc.).

d. Assess current/ intermediate and long term capabilities

to apply CG standards to specific CALS applications.

Identify and prioritize critical R&D issues.

e. Identify priorities for key planning elements/ including; testing for conformance to standards/ testing

for required performance/ use of microcomputer graphics,

and interface with database management systems.

f. Develop a plan to expedite the development and implementation of CG interchange standards for CALS based on

the above findings.

Deliverables ; — Report to CALS Steering Group on tasks a-e (preliminary report three months after yo-ahead, final report at

six months) — Plan for Computer Graphics area (outline three months

after go-ahead, draft plan at six months, firm plan at

eight months)

2 . Accelerate CG stancarcs development and validation efforts

where neecea to meet; CaLS schedule objectives:

a. Accelerate and complete the ongoing NBS evaluation of

the European validation suits. Use tnis as a oaseline

for recommencing a DoD validation approacn.

* b. Develop preliminary lunctional specifications for validation suites for each of the CG standards recommenced

by task I.2.1.b (this might include CGM, GKS-3D, and/or

PHIGS)

.

1
c. Evaluate the need for subsetting CG standards for CALS

use* If needed, recommend an approach.

* d. Filter CALS graphic item requirements into the registration process.

De 1 i verables

— Quarterly status reports and a final report (eight

months after go-ahead)

As DoD needs are determined, via the initial taslc, adjustments

may have to be made to the remaining tasks. Tasks identified by

an asterisk (*) appear to be low priority for FY 86. These tasks

will be accomplished in FY 86 if possible. If not, they will be

deferred to FY 87.

Tentative FY 87/88 Tasks

FY 87 and 88 tasks will be firmed up in the tactical plan delivered six months after FY 86 go-ahead. Tentative tasks include:

FY 87

1. 'Develop preliminary functional specifications for conversion’

of European validation suite to programming languages needed

by CALS ( e . g . , Ada )

.

2. Complete enhancements to validation suite.

3. Complete conversion of validation routines to additional

languages.

4. Produce report on microcomputer based graphics.

5. Begin development of CGM validation suite.

6. Begin development of GKS-3D validation suite.

7. Begin development of PHIGS validation suite.

FY 88

8. Complete CGM -validation routines.

9. Continue PHIGS validation routine development.

10. Complete GKS-3D validation routines.

11. Produce report on benchmarking methodology.

12.

‘ Demonstrate completed validation suites.

13. Demonstrate CGM transfer between CALS systems.
COMPUTER AIDED LOGISTICS SUPPORT (CALS)

FINAL REPORT

GRAPHICS STANDARDS
toif CALS

'-^ * S'® *: trnBJf.H'C'd Aft

;.^,. -..-’.pMc r*<ul«gwr.M l«V> tS-

¥ n ( Mit *N^ *

• •’ ’^* ^*‘ ’

' w* H"< ,' .

i- » ‘ ^ 1 ^

^ - r» ^ ^1 -' / r^

I# i(iM‘ t*«i?ort (.•I 5 tlt

_ 3

^‘ J»r '-‘.V

’- -Jii’ «(h '•>*! 1*

: A»|, 'x 9

'!-» s--? '-“SP

. '•!

y^Kfcrrf^o f)t kj,^

Ifit'.cy' "'a^ ti|

••.ii pM<A>‘

Hit-

' s

'*

lifc'8

1* -ji* .A’*#* - « - ?*•«'

QT *" *1 r — y •f ^ ^ DA J • ^ .»/f-M T PC^

Km^ ^ -ct. tft*y

^.1

, I

^

c-f / 5 » .r rft# dAfMC.Ai plAft,*^

t*»rA

•i wrui’* . - '^ •flff'raF .«’

ii». -'-.'li < 'j ..mftjMTP. i'-l

: n

Conv«“»i<fn

^/at* »anrs-<'

JN» #

"ii, ,j»ii ' - >.*.»f'-^ i--*i 'A

•?. .lifei'*'

‘IN

iw-'

• • ^ - "

'4 .

w«» -^ ,**^*' *st
TABLE OF CONTENTS

1. INTRODUCTION 1

2e COMPATIBILITY OF GRAPHICS AND PRODUCT DATA STANDARDS . . 4

2.1 CRITERIA FOR FUNCTIONAL COMPARISONS ....... 4

2.1.1 Representational Power ..... 4

2.1.2 Expressive Power 4

2.1.3 Extensibility 5

2.2 CRITERIA FOR SYNTACTICAL COMPARISONS . 5

2.2.1 Speed of Processing 5

2.2.2 Compactness 6

2.2.3 Human Understanding 6

2.2.4 Consistency with Existing Standards .... 6

2.3 FEATURE COMPARISONS AMONG GRAPHICS STANDARDS ... 7

2 . 4 TRANSLATION OF IGES ENTITIES INTO GRAPHICS

ELEMENTS 7

2.5 CORRESPONDENCE BETWEEN PDES ENTITIES AND GRAPHICS

ELEMbiNTS ........ ...... ....... S

2.6 DISCUSSION OF GLOBAL CONSIDERATIONS 8

2.6.1 Dimensionality and Coordinate Systems ... 8

2.6.2 Viewing Models 8

2.6.3 Text Model 9

2.6.4 Relationships Among Entities. ....... 9

2.6.5 Non-graphical Elements 10

2.6.6 Extensibility 10

2.6.7 Conformance Rules 11

2.7 TRANSLATABILITY . 11

2.7.1 Effect of Loss of Information ....... 11

2.7.2 Consistency of Semantic Level 12

2 . 8 SUMMARY ....... 12

3. GRAPHICS STANDARDS VALIDATION EFFORTS

3 . 1 INTRODUCTION

3.1.1 Statement of the Problem

3.1.2 Approach to the Problem .......

3.1.3 Installation and Execution of Tests . 3.1.4 Summary of Results

3.2 REQUIREMENTS TRACEABILITY ANALYSIS

3.3 CONCLUSIONS .......

3.3.1 Data Structure Tests

3.3.2 Error Tests . . . . 3.3.3 Operator Tests ...........

3.3.4 Summary . . .

14

14

14

15

16

16

17

18

18

19

19

19

4. ASSESSMENT OF DOD NEEDS FOR COMPUTER GRAPHICS STANDARDS 20

4.1 INTRODUCTION 20

4.2 ARCHITECTURES FOR CALS .............. 22

4.2.1

Overview 22

4 . 2 . 1 .

1

General CAD Functions 22

ii
4.2. 1.2 General Picture Processing 24

4. 2. 1.3 Kinds of Applications 24

4.2.2 Automated Data Repositories 29

4. 2. 2.1 Engineering Design and Drafting . . 29

4. 2. 2.

2

Procurement Support 29

4.2.3 Automated Technical Manual Systems .... 35

4. 2. 3.1 Publishing 35

4. 2. 3.

2

Interactive Delivery Systems .... 40

4.2.4 Intersystem Relationships 44

4.2.4.

1

Automated Data Repository Projects . 44

4 . 2 . 4 .

2

Automated Technical Manual Proj ects 44

4.3 CONCLUSIONS AND SUMMARY 48

4.3.1 CGM Strengths 48

4.3.2 Comparison of Levels of Presentation ... 48

4.3.3 Picking the Right Level of Exchange .... 49

4.3.4 CGM as a Raster Format '. 49

4.3.5 Impact of Standards on Software Life Cycle

Costs 50

4.3.6 Benefits of Different Kinds of Standards . 50

4.3.7 Synergism of CGI and CGM 50

4.3.8 Using ASCII Files 51

5. PLANS AND RECOMMENDATIONS 52

5.1 RECOMMENDATIONS FOR GREATER COMPATIBILITY AMONG

GRAPHICS AND PRODUCT DATA STANDARDS 52

5.1.1 NBS Recommendations . . . .* 52

5.1.2 Contractor Recommendations 52

5. 1.2.1 Within the Family of Graphics

Standards 52

5. 1.2.2 Within the Family of Product Data

Standards 57

5. 1.2.

3

Across Family Issues 57

5.2 RECOMMENDATIONS FOR GRAPHICS STANDARDS VALIDATION 60

5.3 POSSIBLE SHORT AND LONG TERM SOLUTIONS 61

5.4 RECOMMENDATIONS FOR USING COMPUTER GRAPHICS

STANDARDS 61

5.4.1 Accelerated Development Work 61

5.4.2 Urgent Requirements for Validation .... 63

5.4.3 Accelerated Implementation 64

5.4.4 Related Standards 65

5.5 PRIORITIES FOR KEY PLANNING ELEMENTS 66

5.6 FINAL CONCLUSION 68

REFERENCES 69

GLOSSARY 71

APPENDIX 1 74

1. PURPOSE OF VARIOUS GRAPHICS-RELATED STANDARDS ... 75

2. NBS ROLE IN COMPUTER GRAPHICS STANDARDS 91

3. STATUS OF GRAPHICS STANDARDS 94

iii
APPENDIX 2 97

APPENDIX 3 107

APPENDIX 4 ............. . . 114

5«Gceeeeeceeoccec*«eoe«e«e 1^7

6«oe«e«ceceo«eeoc«ee*«*oee 3=>3 ^ APPENDIX 7 141

iv
urmftUunQt

4 2 . ? . 2 v> ' icir«h»An‘C s\jpfag-t. ^ , ft. jtiovjsi

.4., >. j- *'rt;OTat«tt tftbbhlfc*! Itiirtu*! ,«y*t«n .... JV

4 .s.i.i pubU«sii»9 • • •>/ .- ,• / r ^ > 8 xiaim'8«

nx . . • »v ‘ 4.«.e.«' • inttertcV.Vo’ ... *J“

|.r.4 Int«r»y«t93 B«iatioa*Ulpft .. .. , , ,

1 j

»tJl ... * ’ jxtit -iti ^

r?»fL«««ai«*A.*!'_'*.JC:ffliftV !!..«. • • ’ * * *

; tj

4 ' * O I

i9

» • • ' •

*

» »

« • «

sc':rcurfSOW* . ... * 1.3.1, Cffi< ^T.ra.noidl* ....-,

1 - 3.8 ' c itt'i'.arl!''' 9 f .jf _pr<i ii..-i^el.QO

^ 3

-

^ **'T 1

». c5h !» . i TorMi’tl.' - »« ••--«, .u

i tn^. . it' 'itarAnrXt. ftR Cyaw , 1 “ fttfj . > . •- . « . . . ' • • • • • • • * ?.-* 1 cm.sitft ’:r rifr*c*nt Ot at4»J-»r<la . » 1 «yTi»rii'or. C6I *09 csar . • ., isci‘1 rii** 5^

#» waow '

- ..... .

. . . ; .

• fiB . ' f.i M:cc*9tsqfax5 o. i ..xam-. ibxi^tv . (aWuTHtofc x*f!) v^.:k $?*'•' .... • .^ 58

, i.l.X ‘RmwKMr.Uit\.<!a» 52

4 ,

3

8»S,.

•> % 5.1.2 ritttraetor B*cd|WMwiaa«owi • 53

5 ; -2.1 Wir2ii:t f^lir ari|>i *c«;

' 1 M .-.x^ r<Jn • • • • • • • • '• ' V;j3

^..,l.2v2 wiciin tmfill: oc

^x*:.;. .3 Aor«Mi ri«u#« • * » - a. i fOU 112A.I>iiIC5 5tA0t WUrATI '‘J ibl fOOTI5LB •THK .SCUT-. - ‘.^>^5 - • • *;|

;*.4 ••"oii *Ti?rK*i **^H-7rKK oa#PHiC3j^

5

. 4,1 A*riil#rawt r ^ » . . .« •

' 5/4.7 Ur/’tnt

57

57

SO

41

• • *

5

* " i.. K^a*ttod st4Ln5iirds ..•> • * t.s fou on? ctJfrrr'

5. 5

’ cx«?cLa:7ToiJ . . •

.i *

s;

51

S3

44

€6

sa

,3tam'K£*scK. • . • • • , t i*' -<fc^

' i* r 4

‘ ^Htne^AHY • a * • *

‘ * ^

-B

* % %t

• * « 4

65

71

1*V %r 9 » ...a • •• » *...• _»a_ * *T r I . £:miNS2’ "F 7xa|[t*a3 c»aAyHics-;\si4it52t. "rAif^ ^ , ^ . . *^ • 41# i. T<33 aotiK 3 cc^pi T^r. cjiftsjiies sTASt''.

sTX'. :.'-^ ..? 'uauBics :?^jTCAJ«aa « A.-

.-"ft

74

75

9]

44

:.I

.V/

:-8
COMPUTER AIDED LOGISTICS SUPPORT (CALS)

FINAL REPORT

GRAPHICS STANDARDS

1. INTRODUCTION

This section of the report is a final deliverable for Task 1.2,

Computer Graphics Standards for Logistics. It discusses two

specific task areas: 1.2.1) Assess DoD needs for Computer

Graphics interchange standards; and 1.2.2) Accelerate Computer

Graphics standards development and validation efforts where

needed to meet CALS schedule objectives.

The strategy in meeting the deliverables for CALS in FY86 was to

involve knowledgeable NBS personnel as well as key people from

the graphics standards community in the CALS effort. The

involvement of key graphics standards personnel in the CALS work

served a twofold purpose. First, it brought together the most

knowledgecible graphics standards experts focusing on solutions

for CALS. However, in order to recommend CALS solutions, these

graphics experts had to become knowledgeable concerning detailed

CALS requirements. Thus, the second hnd most important benefit

of involving key national and international standards people in

CALS is that these people now regularly represent CALS

requirements during discussions at both national and

international standards meetings. The end result is that CALS

has had a significant impact in the standards community in

determining priorities and future directions of graphics

standards

.

It is appropriate to draw attention to Appendix 1 of the report.

It is recommended reading before continuing with the rest of the

graphics section deliverables. A large part of NBS's job for

CALS in this first year has been to educate DOD in the area of

standards. As such, this appendix represents a substantial

effort toward meeting this educational requirement. Appendix 1

is divided into three distinct sections, each of which can stand

on its own as a separate reference. The first section describes

the family of computer graphics standards in a manner that is

understandable for anyone trying to gain some grasp of the what

and the why of computer graphics standards. The material for

this section has been obtained in part from Dr. Peter Bono's

first CALS contract report [BON186] , and should be read before

proceeding on since it lays a proper foundation for understanding

the discussions of and recommendations for the utilization of

computer graphics standards in CALS contained in subsequent

sections of the report. It has been deliberately separated out

of the main report so that it could provide a short, but complete

reference to graphics standards, especially since so many DOD

1
people involved in CALS have expressed the need for a single

source of information on graphics standards.

The second section of Appendix 1 provides the reader seeking

understanding of NBS ' s mission and efforts with regard to

computer graphics standardization; it also is a separate

reference which can, as the first section of the Appendix, stand

on its own.

Finally, the third section of Appendix 1 provides the reader an

up-to-the-minute overview on where in the standards process the

graphics standards are at the international (ISO) , national

(ANSI) , and federal (FIPS) levels. It becomes important to know

how standards important to the CALS effort are progressing in

relation to the schedule demands imposed by the CALS program.

Section 2 details the work accomplished on subtask 1.2. l.c to

"assess the compatibility of graphics standards, both among

themselves and with the product definition standards (IGES and

PDFS)." Appendices 2, 3, and 4 are integral parts of this

effort, and formally specify how graphics standards relate to

each other, how IGES entities could be rendered by graphics

standards, and how PDFS entities correspond to "elements” in the

graphics standards. Recommendations for making these standards

more compatible are discussed in Section 5.1. This work was also

accomplished in part through Dr. Bono's first contract report

[BON186].

Section 3 details the work* accomplished on subtask 1. 2. 2. a to

"accelerate and complete the ongoing NBS evaluation of the

European validation suite,” while Section 5.2 discusses the

second part of this subtask, namely "Use this as a baseline for

recommending a DOD validation approach." This work was primarily

accomplished through Dr. Steve Carson's CALS contract report

[CARS8 6] . If the reader is interested in the nuts and bolts

details of the validation testing, please read the contract

report, which accompanies this report.

Subtask I.2.2.C was to "evaluate the need for subsetting Computer

Graphics standards for CALS use.” Based on our initial

investigations of CALS requirements, it is premature to state

whether or not subsetting will be necessary. Since CGM has been

recommended as the standard of immediate use for CALS, closer

inspection of CALS requirements is necessary before determining

that, for example, only one CGM encoding should be used in all of

CALS.

Section 4 discusses areas of the work under subtask 1.2.1. a,

namely to "identify graphics interchange requirements in terms of

CALS applications.” Appendix 5 contains NBS's preliminary

thoughts on how particular CALS projects might utilize standards,

and has been added here for completeness. Section 5.3 references

2
Appendix 6 , which details (from the contract report [SPAR86]) a

possible short and long term solution to the raster vs. vector

problem for CALS. Section 5.4 then delineates the

recommendations for future work on computer graphics standards

for CALS. Appendix 7 is referenced here to show that NBS is

aware of the implications for CALS of the work going on to

incorporate CGM into the TOP industry standard , and that

unnecessary deviation from these kinds of efforts should be

avoided. Parts of this section of the report are attributable to

Dr. Bono*s second CALS contract report [BON286].

Finally, Section 5 collects all the recommendations that Sections

2, 3 and 4 generated, which serve as the end-products of the

contract reports, and represent the contractors' "wish lists" for

all the things that should be done in the area of graphics

standards for CALS-. NBS does not recommend that DOD fund all

activities identified here. However, contractor-recommended

lists are provided for completeness. The proposed FY87 Statement

of Work contains the prioritized list of NBS tasks in the area of

computer graphics standards. This, in effect, is the draft plan

called for in sxibtask I.2.1.f, "develop a plan to expedite the

development and implementation of Computer Graphics interchange

standards for CALS .

In addition. Section 5.5 provides a summary of the prioritization

for s\ibtask 1.2. l.e,^ to "identify priorities for key planning

elements, including testing for conformance to standards, testing

for required performance, use of microcomputer graphics, and

interfcice with database management systems." NBS/ICST has

incorporated priorities for graphics standards efforts in the

proposed Statement of Work.

3
2 . COMPATIBILITY OF GRAPHICS AND PRODUCT DATA STANDARDS

2.1

CRITERIA FOR FUNCTIONAL COMPARISONS

As has been documented, there are a number of graphics-based

exchange formats, which have been or are being standardized.

Comparing them is difficult, because they have been designed to

meet a variety of objectives. Nevertheless, there are some

criteria that are important across all such picture exchange

standards and are useful in assessing which standard to use, if

the application does not fall into the normal scope of just one

of the exchange standards. 2.1.1

Representational Power

One of the simplest measures of the utility of a standard is its

representational power. This means how rich is the standard in

its primitive elements for representing pictures. For example,

the Graphical Kernel System Metafile (GKSM) and Programmers

Hierarchical Interactive Graphics System (PHIGS) have only 5

basic output primitives, while the Computer Graphics Metafile

(CGM) has 18 different output forms. The product data base

standards have many more basic entities, because they are more

application oriented. Many specialty items for certain

application areas—mechanical design, electrical design,

etc. —are available for use.

Also to be considered is whether the standard can directly

represent views of three dimensional objects or whether the

application must first do the 3D-to-2D projection and viewing

before describing the object in terms of its 2D projection.

2.1.2

Expressive Power

Another measure of the power of an exchange standard is the

expressiveness of its semantics. Support for structures and

segments allow the representation of more complex entities and

relationships. The presence of a "macro” facility will also

facilitate representing these relationships. Finally, if the

semantics permit alternate representations, which depend upon the

settings of certain parameters (e.g., ABSOLUTE or SCALED

linewidths) , more kinds of pictures can be represented and

portrayed in a device-independent manner on a wider variety of

workstations

.

4
2.1.3 Extensibility

The process of developing a formal standard is a lengthy one: 4

to 7 years depending upon complexity. And the review cycle for

ANSI standards is 5 years. This means that a standard must

provide some mechanism for private extensions to meet needs that

were not considered during the development of the standard.

Without such extensibility, otherwise useful and valuable

standards may be ignored or neglected by applications which need,

say, just 10% more functionality than is provided by the

standard.

When mechanisms for registering these application-specific

extensions exist, the extensions achieve a semi-formal status and

are more likely to foster interchange. The graphics

standards—GKS, PHIGS, CGM, and Computer Graphics Interface

(CGI) —are all beneficiaries of a registration mechanism being

formalized by the International Standards Organization (ISO)

.

The NBS/ICST is the international Registration Authority for the

Register of Graphical Items, and thus can represent CALS needs

for extensions to the graphics standards.

2.2 CRITERIA FOR SYNTACTICAL COMPARISONS

Semantics determines what kind of information can be represented

in an exchange file; syntax determines how that information is

expressed in concrete terms. The same semantics can be

represented by different syntaxes; depending upon the purpose of

the exchange file, different criteria are important.

2.2.1 Speed of Processing

If the graphics information is stored in a format that is close

to the internal number representation of the host computer,

interpreting that file will take a lot less time on similar

machines. Of course, when transported to dissimilar computer

environments these so-called Binary Encoding formats may be very

slow to process, because of the need to convert all values from

one internal binary format to another.

Another factor that affects the speed of processing is how

complex are the rules used to encode and decode the data. Simple

rules lead to fast processing. Unfortunately, they are also

often associated with large files: only binary file formats are

both fast and reasonably compact.

5
2.2.2

Compactness

File size is often a very critical factor, especially on PCs and

in networks, where each workstation may not have a large amount

of secondary storage. File size is also crucial where the files

are sent via telephone networks, where character transmission

rates of 1200, 300, and even 110 baud are most commonly

encountered

.

Techniques developed by the CCITT and the Character Coding

committees of ISO (TC97/SC2) and ANSI (X3L2) are often used as

the basis of the most compact picture and text representation

formats. Typically based on the ISO 646 (ASCII) 7-bit and 8-bit

character codes, these techniques are present in the CGM Part 2

and many proprietary coding techniques used by a wide variety of

graphics peripheral devices.

2.2.3

Human Understanding

Sometimes it is more important that an exchange file be readable

by humans. The CGM Part 4, the so-called Clear Text Encoding,

and one version of IGES were specifically designed with human

comprehensibility in mind. Generally speaking, these formats

restrict themselves to the printing character set of ASCII and

use mnemonic abbreviations to represent the- basic elements of the

file.

Standard text editors can be used to create such exchange files.

This becomes useful for testing purposes. And being able to read

an exchange file makes debugging more convenient.

Because English text contains a lot of redundancy, these files

are not very compact nor are they necessarily fast to process,

because the words must be parsed and converted to numbers via

table-lookup before being processed.

2.2.4

Consistency with Existing Standards

Where new exchange standards are consistent with existing

standards, production efficiencies can be obtained by

manufacturers by designing algorithms and building firmware and

silicon to process these standardized formats. The common

encodings of the CGM and the CGI are expected (within the next

three to five years) to bring wide performance and manufacturing

efficiencies to graphics terminal and peripheral device

manufacturers

.

These efficiencies can accrue to the users of the standards

because of the semantic and syntactic match between the

applications using the standards and the hardware devices

6
implementing and supporting the standards. For example, the new

Office Document Architecture/Office Document Interchange Format

(ODA/ODIF) standard (ISO DIS 8613) will include a Geometric

Graphics Content Architecture, based on the CGM semantics and

syntax. Consequently, applications involving mixed text and

graphics—like technical documentation and diagrams for

logistical support—should benefit from devices and systems

supporting the CGM and CGI encoding formats.

2.3 FEATURE COMPARISONS AMONG GRAPHICS STANDARDS

Appendix 2 details the specific graphics-related functions and

how they relate among the graphics standards, in particular for

GKS, GKSM, CGI, CGM, PHIGS and the PHIGS Archive File (ARCH). It

provides a feature-by-feature look the functionality of the

graphics standards, giving the reader a feel for which functions

exist in which standards, as well as an easy reference for

identifying areas that are not well-related between them.

No attempt has been made as yet to determine a priority for how

to approach the many areas identified in Appendix 2 that need to

be worked on to make these standards more compatible. . At present

CALS is only concerned with the CGM, so it perhaps is still

premature to worry about the compatibility of all the graphics

standards in general. Thus, most inconsistencies that have been

identified will be items for the long term.

2.4 TRANSLATION OF IGES ENTITIES INTO GRAPHICS ELEMENTS

The IGES file format treats a product definition as a file of

entities, each entity being represented in an

application-independent format. The entity representations

available in IGES include forms common to current CAD/CAM systems

and forms that support the systems technologies currently

emerging.

Entities are categorized as geometric and non-geometric.

Geometric entities represent the definition of the physical shape

of the product. Non-geometric entities typically serve to enrich

the product definition model by providing a viewing perspective

in which a planar drawing may be composed and by providing

annotation and dimensioning appropriate to the drawing.

Non-geometric entities further serve to provide specific

attributes or characteristics for individual entities or groups

of entities and to provide definitions and instances for

groupings of entities.

The entity set of IGES allows the description of wire-frame

models. Issues of compatibility with graphics standards must,

therefore, involve whether the graphics standards have a rich

7
enough vocabulary of primitives and attributes to produce views

of these wire-frame models in an efficient and accurate manner.

Appendix 3 describes each of the IGES entities in turn, noting

how well these entities could be rendered by a system based upon

the graphics standards. It does not attempt to make any

decisions on which particular IGES entities should be added (in

some fashion) to the graphics standards. This is a subject for

future efforts.

2.5 CORRESPONDENCE BETWEEN PDES ENTITIES AND GRAPHICS ELEMENTS

Appendix 4 details the specific areas of the PDES specification

which discuss the PDES viewing pipeline, pictures, text model,

color model, line attributes and surface attributes, and how they

correspond to graphics elements within the graphics standards.

The PDES presentation entities were deliberately borrowed from

the graphics standards. With a few exceptions, it would be

trivially easy to use an application program written using one of

the graphics programming standards—PHIGS, GKS, or CGI—to

interpret the PDES presentation entities and render the image

correctly on a graphical output device.

•2.6 DISCUSSION OF GLOBAL CONSIDERATIONS

It must be emphasized that IGES and PDES are not directly

comparable with the graphics standards—GKS, PHIGS, and CGI/CGM.

The product definition standards have quite different objectives

than the graphics standards. Nevertheless, it is useful to

examine the standards for comoatib i 1 itv one to another, because

one would expect to both read and write IGES/PDES data bases from

application programs written using GKS, CGI, and especially

PHIGS. Furthermore, one would expect to extract drawings from

IGES/PDES data bases and represent them as CGM files, before

incorporating them in manuals, reports, and logistical support

systems

.

2.6.1 Dimensionality and Coordinate Systems

IGES and PDES deal with 3D wireframe objects; so do PHIGS and

GKS -3D. At present, neither CGI nor CGM accommodate 3D objects.

In all the 3D standards the coordinate systems are right-handed.

2.6.2 Viewing Models

The viewing models of PHIGS, GKS-3D, and PDES are much richer

than that for IGES, since only one type of projection—an

orthographic parallel projection--appears to be supported by

IGES.

8
In recognition of this fact, PDES has deliberately borrowed most

of the PHIGS viewing model (which is also shared with GKS-3D)

.

However, in its current draft, PDES restricts the transformation

matrix to 4x3 , rather than the fully general 4x4

.

PDES includes the workstation transformation—a device dependent

transformation—in the definition of a view, unlike PHIGS, which

does not allow the workstation transformation to be changed

during structure traversal.

The 2D standards—GKS, CGI, and CGM—can be looked at as

trivially embedded in the more complex viewing model of the 3D

standards

.

2.6.3 Text Model

The IGES text model superficially resembles the text models of

the other standards, but there are many differences. For

example, in IGES—as in GKS and PHIGS, but unlike CGI and CGM«*a

single font number or index applies to the whole note and

combines the separate concepts of type face and character set.

In IGES, only 7-bit character codes are supported.

Unlike any of the other standards, IGES uses a single index, the

form number, to represent many independent aspects of texts

single or multiple strings, justification of the strings within a

text rectangle, the presence of subscripts, superscripts,

fractions, and font changes. Special cases have to be added

continually to handle new layouts.

PDES has taken its text model from CGI/CGM. The GKS and PHIGS

text models are subsets of the CGI model.

2.6.4 Relationships Among Entities

IGES/PDES supports very complex relationships among product

entities. Not only can entities refer to one another, but a macro

facility is provided to allow the creation of

application-specific entities and relationships. Furthermore,

many entities are specifically present to represent special

relationships (e.g., OFFSET CURVE, OFFSET SURFACE, and CONNECT

POINT) . At a higher degree of interrelationship, there are

several entities to support finite element modelling and the

representation of drawings. Finally, there are numerous

structure entities, like ASSOCIATIVITY DEFINITION and

ASSOCIATIVITY INSTANCE, that permit the representation of

arbitrarily complex networks of blocks of simpler IGES entities,

including wireframe and surface definitions, annotation, and

9
properties. SUBFIGUREs are available to allow instances of

objects—defined once--to be included in several places.

PHIGS includes a hierarchical geometric structuring facility for

modelling graphical objects. Although nowhere as rich as

IGES/PDES, PHIGS structures are more flexible and more powerful

than the segmentation features of GKS and CGI.

At present, CGM has no capability to express relationships among

the graphical primitives that comprise a metafile picture. Thus,

modifications of groups of entities in graphical pictures are

more difficult to accomplish. An addition to the CGM may

incorporate the capability to provide these kinds of

relationships. Since this capability would be desirable to have

in CALS, ICST will work within the standards community toward

this addition.

2.6.5 Non-graphical Elements

Non-graphical elements are useful for extending the standard and

for storing information closely related to a standard product,

but not properly a part of the standard representation.

All the graphics standards contain an APPLICATION DATA element to

permit the communication and storage of non-graphical

information. Furthermore, they include a MESSAGE element to

allow for the transmission of information to an operator of the

graphics equipment.

In IGES/PDES, the PROPERTY entity plays a similar role. Many

engineering-specific properties are defined in the IGES

specification. A few of them do correspond to graphics elements

and would be used in rendering a picture; e.g., drawing size,

drawing units, and region restriction.

2.6.6 Extensibility

In IGES/PDES, the MACRO capability allows the standard to be

extended far beyond the common entity subset, utilizing a formal

mechanism which is a part of the IGES- specification. Implementing

an interpreter for the MACRO facility is a major investment and

may not be available on many systems. In the graphics standards,

two elements, ESCAPE and GDP (Generalized Drawing Primitive) , are

available for implementors to extend the standard beyond the

original specification. GDP is used to provide new graphics

primitives and attributes, while ESCAPE is reserved for elements

that do not directly create output on the view surface.

In IGES/PDES, there is no formal mechanism to exchange

information about useful extensions. However, for the graphics

10
standards, a set of formal procedures have been written (subject

to ISO approval) to establish and maintain a Register of

Graphical Items. The register will record extensions to the

graphics standards of the following sorts: new GDPs and ESCAPES;

new line types, marker symbols, and hatch styles; associations

between font indices and the appearance of characters making up

the font; and errors. As previously stated, NBS/ICST is the

Registration Authority for these standards.

2.6.7 Conformance Rules

All the standards that relate to product or picture

exchange—IGES/PDES and CGM—have very weak conformance

requirements. The specifications describe the file structure and

syntax^ but no requirements are placed on the generators or

interpreters of IGES, PDES, and CGM files. The result is that

conformance to the standard is trivial to verify, but doesn't

assure you that two people receiving the same file will

eventually see the same picture. In the case of CGM, CALS needs

assurance that CGM implementations fully transfer the graphical

picture from one device to another. ICST will work toward

enhancing the conformance requirements of CGM.

«) On the other hand, the programming standards—GKS, PHIGS, and

CGI—have rather strict conformance rules built into the

standards. The rules serve two principal purposes: to assure

that all implementations of the standard provide some m'inumum

functionality and to guarantee that the behavior of all

implementations is similar with respect to graphical input and

output. Without the guarantees represented by the conformance

clauses, application developers using a graphics standard would

have no confidence in using any particular set of features from

the standard. Instead, they would have to limit themselves to

the most primitive elements to assure the widest support for

their prograuns.

2 . 7 TRANSLATABILITY

2.7.1 Effect of Loss of Information

Much of the discussion above outlined how the content of

IGES/PDES files could be expressed or interpreted by programs

based on the X3H3 graphics standards. In many cases, it was

noted in Appendix 3 how information is lost when going from a

product definition file to a graphics representation. A few

examples include:

-connectivity of points and lines

11
-directionality of lines

-offset relationships between curves and surfaces

-purpose of text: annotation vs. part of the model.

In many cases, it is advantageous that this selective information

be lost! This is because the files become much smaller, are

easier to interpret, and are much faster to process if a picture

is the final object. This is precisely the case for Automated

Technical Manual systems within CALS, which will be explained in

greater detail in another section of this report.

If too much information would be lost, but most of the IGES/PDES

product data is not needed, the CGM APPLICATION DATA element can

be used to supplement the CGM elements to provide the needed

relationships

.

2.7.2 Consistency of Semantic Level

As one would expect, there is an unevenness of semantic

consistency across the product definition and graphics standards,

due to their differing objectives. However, when geometry is

involved, it is desirable that both the product definition

standards and the graphics standards be at the same semantic

level

.

% The IGES standard is lacking in its viewing and text models. PDES

is attempting to remedy this. The graphics standards lack

richness in the area of output primitives: full conics, including

hyperbolas and parabolas, should be available at a minimum.

Extensions to support simple surface definitions are also

lacking.

Among the graphics standards, the CGI lacks support for 3D, while

the CGM lacks support for both 3D and any kind of structures

including, but not necessarily limited to, GKS and CGI segments

and PHIGS structures.

2 . 8 SUMMARY

Because there are a number of graphics-based exchange formats

(each designed to meet different objectives) , comparing them is

difficult. However, this section has attempted to help the

reader in the complex task of selecting the right exchange

format. First, one must find a standard whose objectives are

consistent with one's applications needs (functional

comparisons) . Then, one must hope that the selected standard has

specified a syntax whose size and performance characteristics

also meet one's needs (syntactical comparisons) . Sometimes, it

12
may be necessary to select a standard based on its syntactic and

representational qualities, rather than on its intended scope.

In these situations, one will use the extensibility facilities to

create an exchange file that meets all one*s needs.

Appendix 2 provides the specific comparisons of features among

all the graphics standards. Although acting on all these points

of comparison is premature as far as CALS is concerned, it is

important to lay a proper foundation that accurately specifies

the areas of compatibility (and incompatibility) among graphics

standards

.

In a like manner. Appendices 3 and 4 provide comparisons of IGES

and PDES entities with elements of the graphics standards,

respectively. These comparisons are based on discussions of

global considerations and transalatibility problems, and provide

the necessary groundwork for future efforts aimed at making the

graphics and product definition standards more compatible.

f

13
3. GRAPHICS STANDARDS VALIDATION EFFORTS

3 . 1 INTRODUCTION

This section provides a siiminary of results and a description of

the approach taJcen in evaluating the European validation tests.

Subsequent sections summarize the conclusions reached for each

major category of test, namely data structure tests, error tests,

and operator interface tests. For a more complete discussion of

the validation tests run for the European Validation Suite,

please read the attached CALS contract report [CARS86]. In

Section 5.2, contractor recommendations are made regarding future

work and the utility of the tests for DOD graphics validation

purposes

.

3.1.1 Statement of the Problem

The great diversity of graphics packages with different

philosophies has inhibited the development of graphical

applications software. Graphics standards, such as the Graphical

Kernel System (GKS) and the Computer Graphics Metafile (CGM)

,

have been developed to help eliminate this problem and to

encourage portability between different environments.. A

validation procedure is necessary to insure that implementations

of standards, such as GKS, are consistent with the standards.

Without this consistency, the advantages of portability are lost.

Recognizing this, the European Community sponsored a series of

workshops during 1981 and 1982 to develop a methodology for

testing GKS implementations. The development of a suite of

tests, based on the methodology developed at these workshops, was

siibsequently funded. The actual development work was done at the

Technical University of Darmstadt in the Federal Republic of

Germany, ‘ and the University of Leicester in England. The

development work was supervised for the European Commission by

the GMD (Gesellschaft fur Mathematik und Datenverarbeitung) in

the Federal Republic of Germany.

The European test suite is supposed to subject a completed GKS

implementation to a thorough test of its consistency with the GKS

standards with hopes of discovering errors. The less errors a

particular implementation generates, the greater degree of

standardization it contains, yet the lack of errors generated

does not guarantee correctness. As the test suites are developed

further, the degree of confidence in the correctness of the

implementation will increase. Basically, the GKS implementation

is tested by calling GKS functions, sometimes in conjunction with

input devices, which generate a response. The responses from

these calls are then evaluated and corresponding error messages

reported if the responses are not as those designated by the GKS

14
standard. The operator interface tests are evaluated a little

differently since they require human visual evaluation of the

graphical output from the device chosen for test.

The GKS validation test suite developed under the sponsorship of

the European Community consists of three sets of tests. One set

tests the data structures internal to GKS; a second set tests the

errors that occur when executing GKS functions; and the third set

tests the general functionality of GKS at the operator interface

level. All of these tests are at the level of what would

commonly be referred to as "system acceptance tests" in DOD

terminology.

The data structure tests consist primarily of a dialog between

the certification program and the GKS implementation. GKS

routines are correctly called under valid states of GKS in order

to determine the viability of the implementation. The responses

of the GKS implementation are then written to a report file.

The error tests check the response of the GKS implementation to

deliberately induce error situations. Specifically, the error

messages returned by the implementation are compared with a list

of correct responses, and reports of these comparisons are

written to a report file.

The Operator Interface Tests consist of an "Operator Script" and

output to the screen of a workstation. The Operator Script tells

the operator what the screen should be displaying, and provides a

form for noting the agreement or discrepancies between the

scripted version and the actual content of the screen display.

The purpose of this effort was to ascertain the suitability of

basing a DOD validation procedure for GKS implementations on the

European GKS validation suite. If these tests are of sufficient

quality, their use can save the substantial development effort

needed to implement alternative tests. Section 5.2 details the

recommendations made as a result of this study.

3.1.2 Approach to the Problem

To evaluate these tests, a three part strategy was devised. The

first part of the strategy involved installing and executing the

tests in a typical environment in the United States. The second

part of the strategy involved analyzing the structure of the

1 tests themselves to determine the quality of their construction

I and their modularity and ease of use in testing GKS

! implementations, especially on smaller computers or in embedded

processors. The third part of the strategy involved a detailed

i investigation of the extent to which the routines test the

i requirements in the GKS specification.

15
3.1.3 Installation and Execution of Tests

The Validation Tests were developed in a European academic

computing environment and have not seen extensive use within

commercial production software development environments in the

United States. By installing and executing the tests, it was

determined that, in general, the quality of the installation

instructions was disappointing, as was the ease of customization

of the routines to a new environment, and the quality of

programming practice used in their construction.

3.1.4 Summary of Results

The test suites were successfully installed on a Digital

Equipment Corporation VAX 8600 computer running the VMS operating

system. The graphics capabilities available on this computer

include the ISSCO and the Digital Equipment Corporation (DEC)

implementations of GKS. Graphics output devices included a

Tektronix 4128 terminal and DEC VT240 terminals. A moderate

amount of difficulty was encountered in installing the tests due

to the poor quality of the documentation furnished with the test

suite. For example, instructions detailing how to customize

certain subroutines for a particular GKS * implementation were

contained in the written docximentation accompanying the test

suite and others in comments contained in the source code to the

subroutines themselves; For several routines, both sets of

instruction had to be followed.

The error tests and data structure tests were both completely

executed using the ISSCO GKS implementation and with the VT240

terminal. A large number of error messages were generated as a

result of the execution of these tests. For the data structures

tests, some of the errors were programming errors in the GKS test

programs and some were errors in the ISSCO GKS implementation

which were discovered by the tests. Problems encountered

executing the error handling tests were due mostly to programming

errors in the GKS test routines. The operator interface tests

were also completely executed with more favorable results. A

moderate number of errors were encountered executing these tests

with both the DEC VT240 terminals and the Tektronix 4128 terminal

and most were due to errors in the ISSCO GKS implementation.

A determination of the structure and organization of the test

programs was completed. During inspection of source code for the

routines, numerous problems with programming practices used in

their construction, the quality of their internal documentation

and FORTRAN language coding errors were encountered. These

problems are documented in the contract report [CARS86] in great

detail. The overall impression is that the data structure and

error tests are of very low quality. The operator interface test

16
source code is better, but still contains a number of errors and

examples of poor programming practices.

The degree to which the validation tests determine conformance to

GKS requirements was evaluated. This was done by taking a

representative set of requirements, some of those associated

with the POLYLINE output primitive of GKS, and determining if

these requirements are tested in the validation routines. The

more obvious requirements were usually well covered by tests at

an appropriate level for an acceptance test procedure. Less

obvious requirements were poorly tested or not tested at all.

Some requirements were identified that could not be tested

through the GKS sxibroutine call interface. Other forms of

requirements verification, such as analysis or ” internal

unit-level'* tests, must be used to verify these requirements.

3.2 REQUIREMENTS TRACEABILITY ANALYSIS

The quality of any validation test is determined by how well it

tests requirements of the system being evaluated. This is

especially difficult to determine in the GKS environment since

the GKS specification itself is not as well organized as a

traditional DOD System Requirement Specification. Nonetheless,

evaluation of the test routines was undertaken by picking one

area of GKS —the processing associated with producing the

Polyline output primitive— for extensive evaluation of

requirements traceability. A partial list of GKS requirements

relating to Polyline was developed and is contained in Appendix 2

of the contract report [CARS86]. Due to the extremely large

number of Polyline requirements that were found, only a subset of

them was able to be tested and evaluated.

Once these requirements were extracted from the GKS

Specification, they were used to derive a minimal, testable set

of requirements to validate that a GKS implementation conforms to

the requirements for processing Polylines. The three sets of GKS

tests were evaluated to determine how well they test each of the

derived requirements. From this exercise, one can infer the

degree of care used to construct GKS tests programs, the

percentage of coverage of GKS requirements which they are likely

to provide in an acceptance test situation, and the general

quality of the tests.

The detailed results of the evaluation are presented in Appendix

2 of the contract report [CARS86]. In this Appendix, a

representative set of requirements is listed, together with a

description of how the requirement should be tested, an

identification of one or more places in the validation suite

where it is tested, and a determination of how well it is tested.

17
The degree of requirements coverage in the European validation

suite is reasonable for an acceptance test situation, especially

considering the lack of organization of the GKS standard and the

difficulty of extracting testable requirements from it. All key

features of GKS were tested in more than one way. However,

meaningful requirements which were not adequately tested were

easily uncovered, and requirements that could not be tested at

the GKS language binding interface were found.

If additional confidence in the correctness of a GKS

implementation is needed, then additional requirements

verification must be performed. This could be done by analysis

of the source code of the implementation or by demonstrating the

correct performance of a set of "internal unit-level” tests

designed to check the correct implementation of key features —

such as transformations and certain approximations— that are not

visible enough through the subroutine call interface to be

adequately testable in a validation test suite.

3 . 3 CONCLUSIONS

3.3.1 Data Structure Tests

The internal documentation for the data structure test describes

the overall effect of the test. The programming style and degree

of commenting does not permit a quick reading of how the effect

is achieved. This is a definite deficiency from a maintenance

point of view.

The whole philosophy behind the data structure tests is flawed.

Since no graphical output is produced during the tests, an

implementation could pass by correctly implementing the update of

certain internal data items in response to the invocation of GKS

functions. Unfortunately, updating the data structures alone is

not sufficient. An implementation must modify its future

behavior —especially the graphical output it produces— based on

these values. This is not tested! The only valid way to test

the GKS data structures is to interleave such tests with the

production of graphical output. Demonstrating that a value in a

state list can be set is of little value if the implementation

makes improper use of that value.

Execution of the tests provides only a very minimal amount of

information regarding the correctness of a GKS implementation.

Many of the test routines perform functions other than those

expected and many contain nearly identical code. The diagnostic

messages provided are cryptic and nearly useless in locating and

correcting defects in an implementation. The quality of their

source code and dociimentation is extremely low.

18
3.3.2

Error Tests

The error handling test programs have a well defined structure of

subroutine calls and the internal documentation is a bit better

than the data structures tests. The simplicity of the error

routines makes the code almost self-documenting without extensive

commenting. Many errors are reported when they are executed.

Most of these are due to errors in the test programs themselves

rather than in the implementation being tested. Several

fundamental design flaws in the tests prevent them from providing

much useful information or from being properly evaluated. If

time had been available to recode routines ESEXER and ECHEKR so

that they worked correctly, a better evaluation of the error test

could have been accomplished.

3.3.3

Operator Tests

The internal documentation in these tests is very thorough. A

number of relatively minor coding errors were found in the test

programs. others probably exist that were not detected. The

tests were much more effective than the data structure and error

tests at uncovering problems in the GKS implementation being

tested. These tests appear to be of some utility in validating

GKS implementations

.

3.3.4

Summary

ConsideraUsle effort will be required to bring the European

validation suites up to an acceptable level for either DOD

purposes or for use in "commercial” testing in the U.S. Effort

will be required to properly document the internal structure of

most of the tests, rewrite portions of them consistent with good

programming practices, correct coding errors, and add additional

tests to increase the degree of requirements validation. A

detailed list of recommendations is given in Section 5.2.

19
4. ASSESSMENT OF DOD NEEDS FOR COMPUTER GRAPHICS STANDARDS

4 . 1 INTRODUCTION

Section 4.2 details work accomplished on subtask 1.2.1. a,

"identify graphics interchange requirements in terms of CALS

applications (e.g., engineering drawing repositories, spare parts

procurement, technical publications).'* For a long time, this

statement was interpreted to mean that for every CALS application

identified and studied, NBS should make recommendations on their

particular graphics standards interface requirements. However,

this has proved to be too ambitious a task in the time provided,

and has tended to fragment, rather than pull together, work on

CALS overall standards needs. The services and DLA have

identified more than 82 prograims in their draft CALS

implementation plans. It has been possible for NBS to visit or

hear about (in sufficient detail) only a handful of CALS

programs; and then these have been constrained to just two of the

major CALS application areas, namely drawing repositories and

^technical publications. Therefore, NBS really does not have the

total picture of CALS yet in any great detail. In addition, at

the CALS Architecture meeting of October 7, 1986, it was decided

to limit CALS projects to a few application areas for Phase I

purposes

.

However, quite a lot of NBS and contractor effort has gone into

trying to satisfy this subtask based on providing recommendations

for each CALS program. Efforts along this line include:

1) One of the contract reports [SDC 86], developed by

Madeleine Sparks of the System Development Corporation,

which attempts to describe each of the CALS programs

(those for which information was provided to her) in

terms of possible graphics standards usage (a copy of

this report accompanies this deliverable) ; and

2) Appendix 5, which is a compilation of NBS efforts from

all the standards areas in identifying those standards

that could be applied to each of the CALS applications

which NBS has studied. These represent are preliminary

thoughts, and have not been refined. They are pointed

out here for completeness.

Those efforts will not be reiterated here. Rather, in order to

put this fragmented information into an overall perspective, this

section describes the accomplishments on this subtask referred to

above by documenting, using architectural diagrams, a framework

for how the CALS program should use the computer graphics

standards

.

20
Although all the applications referred to in the following

architectures for graphics data flow do not conform precisely to

the same CALS programs identified as the 'representative'

programs in the NBS Point Paper, CALS Representative Systems , most are the same. Any difference is due mainly to the fact that

this section is confining itself to the flow of graphics data

• only. As a result, the architectures in this section do not

address all of the CALS application areas.

Section 4 . 3 then tries to draw some conclusions from this

discussion on the overall importance and impact of graphics

standards on attaining the stated goals of the CALS program,

while Sections 5.3 and 5.4 detail contractor recommendations that

result from this discussion.

21
4.2 ARCHITECTURES FOR CALS

4.2.1 Overview

Most of the program elements needed for CALS either are

themselves Computer-Aided Design (CAD) applications or share many

characteristics with classical CAD applications. Before

proposing specific architectures for the various applications

important to CALS, it is useful to look at CAD in general.

4 . 2 . 1 . 1 General CAD Functions

When examining any system at a conceptual level, it is beneficial

to think in terms of Inputs, Processes, and Outputs. For the

typical CAD system, the inputs are drawn from the following

information:

- specifications—WP files, OCR output, operator selections;

- drawings--output from raster scanners and automatic

digitizers;

- external repositories—archived digitized drawings, CAD

databases, component and symbol libraries;

- algorithms-rfinite element models, interference checkers,

routing heuristics

;

- practices—simulations, professional and legal stpmdards,

' design rules.

Generally this information is read in and organized into two

logically distinct, but often physically unified databases: the

geometry model and the product database. Figure 4-1 illustrates

this situation schematically.

Typical processing associated with a CAD system includes:

- Design and Drafting

- Revision

- Analysis

- Simulation

- Testing

- Scheduling

- Documentation

22
Specifications Drawings External DBs

23
CAD system outputs fall into a number of categories, illustrated

in Figure 4-2 and described in the following:

- Drawings—detailed views, assemblies, and schematics;

- Analytical Results—FEM outputs, loads and weights,

performance characteristics, test results;

- Manufacturing Instructions—N/C tapes, robotics commands,

processing drawings, materials lists;

- Purchasing Instructions—Cost estimates, bills of

material, parts lists, drawing lists, standards compliance

requirements

;

- Logistical Instructions—Documentation, parts lists,

diagrams and schematics, cost data, re-ordering data.

4. 2. 1.2 General Picture Processing

A top-level architecture focussing on processing pictures, rather

than on the specific components of certain applications is shown

in Figure 4-3. The roles played by the API (application

programer interface) standards (GKS, PHIGS, and CGI) and the data

exchange standards (IGES, CGM, and SGML) is highlighted.

Note the importance of the CGI in providing device-independence

for all devices—both input and output. New changes to the CGI

specification have been tentatively accepted to accomodate raster

and area input technologies. Note also that the CGM is expected

to be able to store all picture descriptions generated through

the CGI.

4.2. 1.3 Kinds of Applications

Many of the inputs and outputs of a typical CAD system are mixed

text and graphics documents, although some are purely graphical,

e.g., drawings. All CALS elements that share characteristics

with this general model can be addressed by studying the general

model for opportunities and requirements for graphics standards.

CALS programs studied thus far fall into two major areas, each of

which can be subdivided again into two areas. Automated data

repositories store product and geometry models in a central

database for shared use by a diverse set of people. The two

principal application areas for CALS projects are Engineering

Design and Procurement Support. Automated technical manual

systems emphasize rapid access to current documentation,

training, and maintenance information. Traditional printing and

publishing applications fall into this category as do the more

ambitious plans for paperless presentation systems and

interactive delivery and maintenance systems. Table 4-1 lists

some of the DOD projects that could contribute to the CALS

objectives and the application areas that they fit into.
Purchasing Instructions Logistical Instructions

Cost estimates

Bills of material

drawings and parts lists

Standards compliance docs

Documentatioa

Parts List

Diagrams & schematics

Cost Data

Figure 4-2. CAD Process Outputs

25
QMWiiaKAII

CAO

(«C3MUft

AWTHtiiriC

ir]

utGtmxtsam

iwm TftAHSm S10K

MANMUn

mxmk

MAMPUUn

0<«4

>

cmKm

CW/CIH

PHIOS

QKS-30

nMfMfiafTt

Ak04A4rtC

SUPfQMT

GKt

fUlUtNIM#

c«x

UINOOU f WWCCB

(•tf 1^

HU

K

S9m,

•irfMfCTMt MOOl

Acess*

CJV/OVI

PM I OS

OKt-30

4L0SiSTtC

suppqwT

GKS

PtMLIfUlM#

C4X

C

uiroou nMQCM

IK

(X/TPVT

(\OTTfBS

. ,ir=^

^TTHIK

pPMriRs ^

-r-»

CAMIM STSTfMS

li

Figure 4 -3. Picture Processing.

26
Table 4-1. CALS Application Areas

AUTOMATED DATA REPOSITORIES

ENGINEERING DESIGN

DSREDS IDS

EDGARS IISS

PDDI/GMAP

PROCUREMENT SUPPORT

MASTER

UDB

AUTOMATED TECHNICAL MANUAL SYSTEMS

PRINTING & PUBLISHING

APPS

ATOS

PAPERLESS PRESENTATION / INTERACTIVE DELIVERY

AND MAINTENANCE AIDS

EMPS

CMAS/IMIS

27
In the following sections, an architecture stressing the

graphical aspects of each application area is presented. The

specific inputs, processes, and outputs are listed. Finally,

overall architectures for each of the two main application areas

is portrayed. The architectures show how the various individual

projects could exchange information using IGES, CGM, and pure

image (raster) files.

28
4.2.2 Automated Data Repositories

4. 2. 2.1 Engineering Design and Drafting

Databases required to support CAD/CIM applications are very

complex. Table 4-2 lists the principal tasks associated with

managing an engineering database. Acquisition, storage, and

retrieval of the drawing data and associated product infomation

is a major undertaking—and costly too. All data must be kept in

revisable form so that the database can track changes made in the

design as the product moves from the early conceptual design

stages through detail design, validation, and final

manufacturing. Once in production, revisions will be needed;

either to fix errors or to make improvements.

Figure 4-4 illustrates the principal interfaces surrounding an

engineering database. Both IGES databases and CGM picture files

should be used for importing and exporting infonnation, but the

database itself is likely to have a structure and content much

richer than that currently supported by either IGES or CGM. The

PDES (and ISO STEP) efforts are more likely to eventually be

useful in standardizing this environment. The output of the

drawing digitization process could be expressed as a CGM file.

The application running on the CAD workstation used to create

original drawings and modify existing drawings could be built

upon -GKS or PHIGS—themselves, perhaps layered, on top of CGI —to

provide device-independence and code portability.

On very large projects, or where there are many thousands of

drawings to be managed, a distributed database, using networks of

design workstations to manipulate the information, could be

established.

4 . 2 . 2 .

2

Procurement Support

Repositories for supporting procurement actions may be as large

and as complex as engineering design databases, but they differ

in several other regards.

First, as Figure 4-5 shows the principal output of the

procurement process is a collection of "paper" (that is, the

documents that form the RFP/RFQ package) rather than the product

design. Second, as can be deduced from the processes outlined in

Table 4-3, the database changes much more slowly over time than

an engineering database. Third, the operator generally does not

revise, to any great extent, the information in the database.

Rather, the operator browses through the information, perhaps

analyzing contractor- and government-supplied statistics about

29
Figure 4-4. Architecture for

Engineering Design Data

30
Table 4-2. Engineering Design Data Repository.

Input

Engineering Drawings

Technical Drawings

Geometry

Product & material

characteristics

CAD/CAM WS for

revision

Process

Scan & digitize

Transmit to remote

sites

.

Store in

digital form.

Retrieve

Generate hardcopy.

Revise drawings

(EDCARS)

Allow for feedback

loops

(Digital) Product

Definition Data

Process Management

Output

Engineering Drawings

Technical Drawings

Technical Documents

NC & robotic program

codes

Reports, PERT charts,

project management

information

31
Figure 4-5. Architecture for

Procurement Support

32
Table 4-3. Procurement Support.

Input

Technical Data/

Conf. Mgmt. System

Operator

Part number data from

contractors

DS/REDS

Logistics data

(e.g., MTBF, MTTR,

cost, availability,

etc.

)

Process

Relate status of data

to type of

procurement

.

Retrieval

Output

Specification Lists

Drawing lists

Packaging data

sheets

Documentation

update

LSA reports

Query outputs,

including graphics

Engineering change

proposals

Budget Stratification Statistical Analysis

System

33
the perfonnance of the parts stored in the database and

ultimately making a series of selections that results in lists

being generated. From time to time, documentation updates may be

produced for incorporation into manuals and for wide

dissemination to field activities and contractors.

Where picture storage and retrieval is required, the CGM and

raster image files should be more than adequate for the needs of

these kinds of applications. IGES, or any such product

databases, are not needed and, indeed, would be quite inefficient

for most applications. The related text standards—ODA/ODIF and

SGML—could be used for storing and transmitting the documents

themselves. Both standards could use the CGM to incorporate

images into the running text of the documents.

In these applications, there is no particular need for API

standards based implementations. However, where previewing of

drawings is required, applications may want to build upon the API

graphics standards to get the usual benefits of program

portability, maintenance cost savings, and device-independence.

34
4.2.3 Automated Technical Manual Systems

4. 2. 3.1 Publishing

Figure 4-6 and Table 4-4 summarize the automated publishing

environment. Typically, a manual, report, or other document will

be prepared by the author on another, local word processing

system. If diagrams are required, the pictures will also be

prepared locally. When there is a need for this document to be

published in volume and maintained as an official publication,

the source text and pictures need to be transmitted to the

automated publishing facility. Clearly, standards like SGML and

ODA, along with CGM for the pictures, should be used to acquire

these source documents from the variety of DOD and contractor

sites that would be expected to produce such documents. Both

magnetic media and file exchanges over networks would be used to

accomplish the transfer of information.

Once received in source form, personnel at the publishing

facility would be expected to make changes to the supplied

information for some of the following purposes:

-To put the document into a prescribed format;

-To make uniform the style of writing where a single

document is being produced from several contributions;

-To correct spelling, grammatical, and word usage errors;

-To improve the readability and organization of the

document

;

-To modify or update existing documentation; and

-To modify the supplied pictures to conform to publication

conventions regarding line weights, text fonts, and other

such graphics arts considerations.

The result of such editing is, again, SGML or ODA logical

document files, with their associated CGM picture files, which

they themselves may have been modified during the editing

process. Where the publishing agency is not the maintenance

agency for the document, these revised files should be returned

to the maintenance agency as new master files for the document.

In all cases, the publishing personnel should not need to change

the substance (that is, the technical meaning) of the documents

or pictures. Furthermore, they should not perform any major

updates to the publication. Instead, the maintenance agency for

the document should make the changes to the master source

35
Contractor

Networks

{ remote sites }

Logical

EDIT Document

COMPOSE (ODA or

ENHANCE SGML)

PAGE

LAYOUT

PROCESS

Layout

Document

Technical Pubj

RPSTL Pages

Change Pages

for TO’s

Physical

Document

PAGE

IMAGING

PROCESS

Softcopy

Preview

{remote sites} COMMAND

FILES (e.g.,

POSTSCRIPT)

Hardcopy

^

Composite PhotoPreview Video for Typesetter

Disk Storage

Figure 4-6. Architecture for Publishing

36
Table 4-4. Publishing.

Input . WP-text

OCR-text

Pictures—Raster —Vector

Data tapes

CAD Workstation

-Vector

Process Output

Info. Retrieval Priblications of all sorts

( laserprinter

)

Exchange with Typset quality

remote sites mixed text & graphics

(e.g., Technology (phototypesetter)

Repair Centers

for ATOS)

Graphics Editing/ Repair parts & special

Enhancement tools lists (RPSTL)

pages [APPS]

Change pages for Technical

Orders [ATOS]

37
material and send new versions of the source files to the

publishing agency for republication.

Once the logical document exists in a satisfactory form, a second

process —the page layout process—is carried out. Here,

publishing personnel make decisions about how the information is

presented on the printed page. Such aspects as selection of type

face and point size are made at this time. Likewise, formatting

decisions concerning paragraph indentation, number of lines

between paragraphs, and margin settings are also made at this

time. The resulting layout document is no longer considered

processable because the location and appearance of every letter

and figure on every page has been decided.

The final step—the page imaging process —produces a stream of

commands to drive an output device. If, instead of targeting a

specific device like an HP LaserJet Plus, the imaging process

produces a device-independent command file, such as a PostScript

file or a CGI data stream encoding, the command file can be used

to produce the final images in a variety of ways:

-The document could be previewed on a CRT workstation to

check for errors before typesetting.

-The document could be printed on a lower resolution and

less expensive hardcopy terminal to check for errors before

typesetting.

-The document could be stored on disk in composite video

format for use in an interactive delivery system

application (see section 4. 3. 3.

2

below).

-The document could be sent to a phototypesetter or other

suitable hardcopy device for production of "camera ready"

masters

.

-The document could be sent to a remote site for any of the

above listed purposes.

At any of the stages in the process, the publishing facility

needs to be able to accept from remote sites (other government

agencies or contractors) a document of the appropriate format.

This implies that each representation of the document should be

standardized and that the standards used at each stage should be

fully capable of representing all information available at the

prior stage. The ODA and SGML standards are being designed to

meet these objectives for text; the CGM and CGI standards

likewise meet this criteria for pictures. Commercial page

imaging "de facto" standards like PostScript and Interpress, too,

seem to be sufficiently powerful to meet the needs for a page

imaging publication standard, whether generated at the back end

of either an ODA or SGML pipeline.

38
The only role for an API standard—either GKS or PHIGS-—in this

scheme is during the graphics editing/graphics enhancement stage.

Applications written to GKS or PHIGS will be able to easily read

in CGM metafiles, modify their contents, and write them out

again. Furthermore, the portcibility and device- independence

obtained for the application convey the usual benefits as

described in section 4.2 of this report.

39
4 ,2. 3.

2

Interactive Delivery Systems

With on-line, interactive delivery systems there are two phases

in their development and use. First, special operators (who

typically would be writers and designers with TV or movie

production experience) develop a script. Then, they

interactively merge a variety of visual and text information,

usually available as raster images, to produce a module. Each

module consists of a sequence of frames and has a very specific

purpose—say, to teach a maintenance engineer to replace a power

supply on an on-board computer. Each module will be indexed, so

that the module can be easily located by a maintenance engineer

when he is trouble shooting on site.

As shown by Table 4-5 and Figure 4-7, once the image database has

been created, there are many operations to be supported by the

interactive delivery system—each requiring an associated output

format consisting of images, forms, and instructions. Voice

input and output could also be integrated into such a system.

The performance requirements of such a system are demanding:

-The operator must be able to browse quickly through the

database.

-Modules must be found quickly and their initial frames

shown within a few seconds after they have been requested.

-The system must support two modes of operation—where the

operator has control and where the system has control.

-The system must be able to provide training upon demand and

nearly instantaneous help, when needed or requested.

-The operator must be able to initiate work requests and

actions.

-The system must be linked to a network to permit access to

centralized information, to initiate actions, and to

receive status information about work in progress or

completed.

-The system must be able to directly monitor, via probes or

channel interfaces, the equipment being maintained and

tested. Analysis programs must be available to calculate

the behavior of the system.

-Display programs must be available to provide test results

to the operator in easily understood graphical or tabular

formats.

40
Photographs

Tables

{network}

messages

IMAGE

DATA

BASE

Commands I

ACTION

REPORT

LOG

INTERACTIVE

Sketches

Drawings

Manual

Pages

CREATION

PROCESS

PROCESS probes

WORK

ORDERS

text k

iaeges

Video

Display

EQUIPMENT

qu< Ties

adyice

training

instrjuctions

actions test fresults

Maintenance Operator Workstation

Figure 4 -7. Architecture for

Interactive Delivery Systems

41
Table 4-5. Interactive ("Paperless") Delivery Systems

Input

Raster images

Operator commands

[Operators' are

writers/designers

with TV

experience.

]

Report on actions

taken.

Orders for parts

Process

Build & maintain an

interactive data base

of technical

information on disk . Retrieve/search for

specific information.

Browse thru DB.

Damage Assessment.

Analyze Data.

Test Components.

File/Organize Reports.

Dispatch Orders for

Parts

.

Training.

Send messages.

Interface with networks

on-board systems.

Output

Video images (TV vs.

digital frame buffer)

Instructions

Diagnostic Advice

Work Orders

Training Lessons

Messages to peers

42
In such a system, these requirements imply that, ideally, all

information must be stored and be accessible in formatted form;

that is, in the final form to be presented to the operator.

Otherwise, unacceptable delays may be introduced. Practically

speaking, however, such an approach has its own costs.

First, storage requirements for the images can become enormous,

especially if coupled to very high resolution displays. Optical

disk and TV technology, of course, apply here; indeed, without

the existence of such technologies, such application systems as

described above would not be feasible. Second, completely

formatted images are not revisable and are tied very closely with

current hardware. Revisions, corrections, and enhancements to

the curriculum are costly snd time-consuming. Upgrading to new

and more cost-effective harvare is difficult, without making

obsolete one*s investment in software and images.

From a standards point of view, given the performance

requirements, it seems reasonable to adopt the following

strategy:

1. During the creation process, keep as much of the input

information (drawings, images, text, tables of numbers) in

revisable, editable form.

2. Furthermore, the creation process itself should create

modules that themselves are stored in a device- and machineindependent format and structure.

3. Only after a module is complete should it be transformed, by

an irreversible process applied only once in its lifetime, to a

sequence of images. Even then, for infrequently accessed

information or for low density images (e.g., forms), the image

database should store this information in a device- independent,

non-raster-image format.

4. During the display of the information, the stored images will

be presented on the video terminal using TV standards for image

representation, while the stored text and simpler pictures could

use such standards as X3 . 64 and X3.122 (CGM) to present

instructions, forms, graphs, and tables on the operator’s

terminal

.

In this environment, there is little need for the graphics API

standards^—GKS and PHIGS, except during the creation process.

CGI, providing device-independence, would probably be useful

during interactive delivery as the interface to the operator’s

graphics terminal, but not to his TV video display.

43
4.2.4 Intersystem Relationships

4 . 2 . 4 . 1 Automated Data Repository Proj ects

Figure 4-8 shows how Automated Data Repository projects might

share information and communicate. This architecture diagram is

hypothetical in the sense that not all projects shown are planned

to communicate information at present. However, the purpose of

the figure is to show how information collected, maintained, and

output for one project might be used to provide input to another.

Figure 4-8 highlights the data formats that might be used in

interchanging pictures. In the figure, the terms "FAX’*, "GROUP

IV", and "Raster" are approximate synonyms, but with the

following more subtle distinctions:

-GROUP IV refers to the CCITT standard for facsimile. Only

two tone pictures can be represented.

-FAX refers to any facsimile format, whether or not it is in

exact conformance with the CCITT standard.

-Raster refers to some future standard for raster images,

which should include all the capabilities of FAX but be

capable of handling color and gray scale images as well.

This standard might be based on an extended CGM, limited to

the CGI pixel array element as its only output primitive

element.

The CGM and IGES play the central roles in exchanging information

between projects—the CGM for diagrams and engineering drawings

and IGES for product definitions.

4 . 2 . 4 .

2

Automated Technical Manual Proj ects

Figure 4-9 shows how the Automated Technical Manual projects

might share information and communicate. Like Figure 4-8, this

diagram is hypothetical in nature, showing the potential for

interchange among such systems.

In this environment, the CGM and Raster formats continue to play

an important role, but IGES is no longer needed because none of

these projects need to deal with product databases. Rather, they

deal with the representations (textual and pictorial) of

products. If the product definition needs to be changed, one

must go back to the engineering disciplines to make the change.

The maintenance, publishing, and training components should not

make changes to the product definition without the participation

of the engineering function.

44
Also in this environment, specialized formats like NTSC video and

page imaging languages like PostScript and Interpress have a role

to play. The formats—sometimes formal standards (CGM, SGML, and

ODA/ODIF) and other times de facto standards (PostScript and

Interpress) —are needed to provide extremely fast display of

frames of information. However, one does sacrifice the device

independence that comes from using the fornnal ANSI standards

relating to alphanumeric and graphics standards.

The Text and Office System standards like SGML and ODA/ODIF will

play a significant role in the interchange of information among

such publishing systems. At present, ODA/ODIF relies on CGM for

the incorporation of pictures into documents, while SGML does not

yet have any standardized procedure for drawings.

45
Publishing

ic

Maintenance

Figure 4-8. Possible Graphics Data Flow

Among CALS Data Repository k

Procurement Support Projects

46
From

DSREOS— CGM

Raster

Aperture

Card

Database

CGI data stream

ATOS/APPS —Ccci

EMPS/IMIS

PostScript^ et al.|

Hardcopy devices

(printers, plotters,

typesetters, film)

Smt Softcopy

Cameras & Video Capture Boards Terminals

Figure 4 -9. Possible Data Flow Among

CALS Publishing & Interactive

Delivery Projects

47
4.3 CONCLUSIONS AND SUMMARY

4.3.1 CGM Strengths

The CGM contains device-independent, digitally-encoded vector

graphics data. CGM files are easily transferred and displayed on

a wide variety of hardcopy devices (dot-matrix, ink-jet,

electrostatic, and laser printers, pen plotters, and film

cameras) ; furthermore, they can be easily previewed on an

extensive range of softcopy terminals.

The same cannot be said about facsimile and most

videotext/teletext formats. Most expect a certain, narrow range

of resolutions (sometimes only one!) and either cannot encode

color and gray-scale information or require the presence of a

certain range of color or gray-scale functionality. Page

description languages like Postscript and Interpress, although

theoretically device-independent, in practice require generally

medium to high-resolution devices in order to produce acceptable

results. Furthermore, the performance of these languages is

unacceptable in many display situations.

4.3.2 Comparison of Levels of Presentation

Three general levels of representation are available for storing

and transmitting pictures: Raster (for example, NTSC video

formats or CCITT group IV facsimile) , CGM picture descriptions,

and IGES/PDES/STEP product definitions. There are several

critical qualities by which they can be compared.

Speed of Interpretations. Generally speaking, raster formats are

the fastest to interpret, with IGES files being the slowest by

many orders of magnitude. CGM files are in between, with the

absolute speed affected principally by the speed of the vector to

raster conversion. When assisted by hardware, CGM interpretation

can be accomplished nearly as rapidly as interpretation of raster

files.

Device Independence. Both CGM and IGES files are much more

device independent than raster formatted files. Raster files are

often tied to one resolution and often do not encode color

information.

Size. CGM files are usually more compact than either raster or

IGES files. CGM allows geometry to be encoded more efficiently

than a full raster representation, as in facsimile, while CGM

also need not carry non-visual information as is often present in

IGES files.

48
4.3.3 Picking the Right Level of Exchange

Selecting the proper level of data storage and exchange —raster,

CGM, or IGES— depends upon what one wants to do with the data

after one gets it!

Raster. Raster formats are appropriate and adequate if one plans

on viewing the image on a limited set of similar devices, whose

characteristics (e.g., resolution, color capability) are known in

advance and suitable for raster display. Video (e.g., NTSC),

facsimile (CCITT Group IV), or videotext/teletext (e.g., NAPLES)

standards are all candidate storage and interchange formats.

CGM. CGM is appropriate for any combination of the following

three general situations:

-One wants to view the image on a wide variety of devices,

with different color and resolution capabilities. The set

of devices may not even be known at the time the metafile

is generated.

-One wants to be able to enhance picture qualities (e.g.,

colors, line weights and styles, font styles and text

position) before viewing the final image.

-One wants to be able to compose or overlay several drawings

into a single picture for viewing.

IGES. Product data definition files should be used when any of

the following conditions occur:

-One needs to exchange product designs, not just drawings or

images

-One needs to use the relationships between entities that

comprise the picture for such operations as analysis,

simulation, and design rule checking.

-One needs to transfer instructions for viewing the model,

not just the views themselves.

4.3.4 CGM as a Raster Format

The CGM can be used to exchange pure raster images using the CELL

ARRAY primitive. The standard encodings allow for compression of

the image data. Private encodings that follow the same rules as

the standard encodings may also be invented if the three standard

encodings are inadequate. This method provides a mechanism for

getting raster scanned images into, say SGML documents, using the

same techniques as for vector-oriented CGMs.

49
If the image must be scaled to fit the available space, the SGML

document processor can be programmed to provide this capability,

operating on the CELL ARRAY information contained in the CGM.

4.3.5

Impact of Standards on Software Life Cycle Costs

Four factors result in a lower overall software life cycle cost

for programs written to graphics standards. Machine independence

means that development costs can be shared across many program

elements. Device independence allows expensive graphics hardware

devices to be shared by many application programs and users,

reducing the overall pre-workstation cost. Performance

improvements mean that the same host computing environment,

augmented with evermore cost-effective graphics display hardware,

can have a longer life, thus delaying or even avoiding the need

for costly upgrades to more expensive CPUs as the workload

increases. Finally, the widespread training in graphics

standards concepts means that increases in overall maintenance

costs can be held in check. No longer will extensive,

specialized, and expensive training be required in order t® write

and maintain graphics application programs that are written to

the ANSI standards.

4.3.6

Benefits of Different Kinds of Standards

The benefits of process-related standards (that is, those for

program development—the API standards) are completely

independent of whether they are coupled to CGM. The converse is

also true: that is, CGM is valuable as a picture storage and

exchange standard regardless of whether the metafiles are

generated from applications written using GKS, PHIGS, or CGI.

However, due to the strong overlap between functions in the CGM

and those contained within the higher-level API standards, it is

slightly easier to generate CGM from such applications rather

than from non-standard programming environments. Stated more

formally, the '* semantic match” between the CGI and the other

standards is much higher than with most non-standard graphics

libraries

.

4.3.7

Synergism of CGI and CGM

Because of the deliberate and explicit alignment of CGI and CGM

concepts, primitives, attributes, and viewing models, CGM files

will be very fast to interpret on new hardware because the CGI

functions are going into microcode and even onto silicon.

Consequently, in the future, the speed advantage of purely raster

formatted images over the CGM will be greatly reduced.

50
4.3.8 Using ASCII Files

Seven-bit ASCII formatted files are the most transportable of any

of the coded formats for picture files, but the IGES ASCII file

format is very inefficient compared to the Character-Coded format

of CGM. The IGES and CGM binary files are also compact, but are

not very suitable for interchange across networks and among

heterogeneous computing environments.

51
5. PLANS AND RECOMMENDATIONS 5.1

RECOMMENDATIONS FOR GREATER COMPATIBILITY AMONG GRAPHICS

AND PRODUCT DATA STANDARDS

5.1.1

NBS Recommendations

The principal recommendations concerning compatibilty that NBS

endorses are as follows: —NBS suggests that implementation and user experience be gained

before incorporating technical changes to increase compatibility

in future versions of the standards. —A mechanism called "Registration of Graphical Items" is

available for the graphics standards; perhaps a similar mechanism

would be useful in the product database arena. —PDES should continue to look to the graphics standards for its

presentation entities. These features should be merged with most

of the existing IGES entities to form the international standard

for the exchange of product data. IGES entities that differ

greatly. from current graphics practice should be deprecated. —The exchange standards—IGES, PDES, and CGM—need to tighten up^

their conformance clauses so that users of the standard are

guaranteed a minimum level of service.

5.1.2

Contractor Recommendations

The rest of Section 5.1 contain the contractor's [BON136] own

wish list for all that could be done to make graphics standards

more compatible with one another and with the product data

definition standards. They specify a great many avenues for

arriving at more compatible standards. NBS has not had enough

time to completely evaluate this list, nor does NBS endorse

everything that the contractor states. This list is provided for

completeness. The Proposed '87 NBS Statement of Work for CALS

prioritizes which areas of this wish list NBS deems feasible for

CALS in the next couple of years.

5. 1.2.1 Within the Family of Graphics Standards

Not all the differences among the various graphics standards

imply that the standards are incompatible and, consequently,

would need changing 1 On the contrary, for example, the CGI was

designed to support the requirements of several kinds of graphics

systems that might be built on top of it. So elements are

52
defined very carefully, both to support GKS directly, but also to

permit other languages, both device-independent and

device-dependent, to use the CGI. Similarly, certain concepts

appropriate for PHIGS are missing from GKS-3DExamples of differences that are deliberate and don't imply a

need for changes to the standards are listed here.

-Background color is set explicitly in CGI/CGM, but is set

implicitly in the API standards.

-The absence of window, viewport, and normalization

transformations from CGI/CGM.

-The absence of modelling transformation capabilities from

GKS/GKS-3D.

-The differences between the segments of GKS and the

structures of PHIGS.

-The fact that the segment attributes of GKS are structure

elements in PHIGS.

"Near-Term Changes"

The following paragraphs recommend changes to PHIGS, GKS-3D, and

CGI that should be studied for inclusion in these draft standards

before they are finalized.

For PHIGS:

-Some reasonable meaning should be attributed to the GKS

functions ACTIVATE WORKSTATION and DEACTIVATE WORKSTATION in

a PHIGS environment. This issue is currently being studied

by ASC X3H3 and ISO/TC97/SC21/WG2 as part of the need to

resolve PHIGS-GKS compatibility.

-The utility of an explicit, standardized metafile

read/write/ interpret facility should be studied further.

This facility would be provided in addition to the current

PHIGS archiving facility. With the present facilities it is

awkward to write individual items to metafiles or interpret

individual items from metafiles.

-There is a strong effort to harmonize GKS and PHIGS,

especially in the area of modelling transformations and the

viewing pipeline. These efforts should be encouraged.

For GKS-3D:

-Only those changes that keep GKS-3D consistent with

53
PHIGS should be made in the near-term. It is vital that

GKS-3D be technically frozen, so that products can appear in

the marketplace. Future changes should keep GKS-3D current

with any changes made to GKS.

For CGI;

-On the output side, only those changes that keep the CGI

able to directly support GKS efficiently should be added.

-On the input side, support for new functionality is

appropriate. These include AREA and COMPOUND input devices,

dynamic association of triggers, and input extent. Other

new features for input like user-defined cursors should be

heavily driven by requirements generated by Task • Group

X3H3.6, Display Management.

"Future Changes'*

Some of the following paragraphs recommend changes to GKS and CGM

that should be incorporated in the next version of the standard.

In the meantime, some of these changes should be put forward for

registration so that they can be incorporated in implementations

in a standardized manner, prior to formal inclusion in the

standard. ‘ Other changes derive from the current CGI draft and

should be incorporated in the API standards if CGI implementation

experience shows that these elements are useful and accepted by

the user community.

For GKS, GKS-3D, and PHIGS:

-In CGI, one can reset the workstation to its default

settings without reinitializing the view surface. This kind

of facility would also be useful at the API level.

-The CGI closed figure facility.

-The CGI ability to declare the "maximum color index."

-The CGI ability to specify the "character coding announcer."

This permits the program to indicate how the character codes

contained in string variables should be interpreted by text

processing system within the graphics environment. At

present, the API standards combine the concept of character

set with the concept of font.

-The CGI output elements—DISJOINT POLYLINE, CIRCULAR ARC,

ELLIPTICAL ARC, CIRCLE, ELLIPSE, and RECTANGLE—should be

registered, then added.

54
-The use of the CGI text elements—RESTRICTED TEXT and APPEND

TEXT—should be studied, then added in some form to the API

standards

.

-The CGI permits line width and marker size to be specified

in absolute terms as well as with a scale factor

Specification of these elements in World Coordinates in

PHIGS and GKS might be useful in certain applications.

-Some portion of the CGI raster functionality—bitmaps,

drawing mode, auxiliary color, and transparency—needs to be

available to GKS and PHIGS application programmers. The new

bitmap interior style would be especially useful, when

coupled with the ability to create and modify offscreen

bitmaps.

-The CGI ability to specify a contiguous block of color

indices, and not just one index at a time, should be added

to the API standards.

For PHIGS:

-Support for Hidden Line and Hidden Surface Removal.

This enhancement should probably be coupled to a general

upgrade of PHIGS to handle surfaces and solid definitions.

For GKS:

-Addition of an explicit, standardized mechanism to save

and restore segments from GKS Workstation Independent

Segment Storage (WISS) should be considered. The mechanism

should operate similar to the PHIGS Archive Facility. This

facility would allow GKS segments to be used as symbols

drawn from a shared "symbol librairy.”

-The PHIGS ability to turn error handling on and off.

-The new GKS-3D function POLYGON SET should be registered and

then added to GKS.

-CGI unbundles the concepts of text font and precision to

allow independent specification of these aspects. GKS needs

to examine application use of font and precision to

determine whether changes should be made in future versions

of GKS.

-CGI unbundles the concepts of hatch index and pattern index

to allow independent specification of these aspects, while

in GKS there is just one index that is inteirpreted depending

on the value of interior style. GKS needs to examine

application use of hatch index and pattern index to

55
determine whether changes should be made in future versions

of GKS.

-The CGI allows, via the Pattern Size element, patterns

to be skewed (’’slanted**) . This feature is not directly

available in GKS and PHIGS; it can occur only as a result

of segment or structure transformations.

-The CGI/CGM, GKS-3D, and PHIGS edge attributes—type, width,

color, and visibility—need to be registered and then

migrated to GKS in the next version. Along with this

change, the ASF and ASF3 functions —controlling 13 and 4

elements respectively—in the current GKS should be merged

to a single ASF function controlling 17 elements, as is

currently specified in PHIGS.

-If application experience is favorable, the PHIGS ability to

set the color model (HLS or RGB) should be added to GKS.

-GKS and GKS-3D should be upgraded to support full 3x3 and

4x4 transformation matrices, so as to become consistent with

PHIGS and with current practice.

For CGI:

-If application experience is favorable, the PHIGS ability to

set the color model (HLS or RGB) should be added to CGI.

-CGI needs to be upgraded to support 3D objects and viewing.

The CGM is a picture exchange specification, while the GKSM has

different objectives. ISO/TC97/SC21/WG2 has recognized the

desirability of a single collection of metafile elements, coded

according to the same principles, that could serve as a basis for

different kinds of metafiles. An ad hoc group of experts has

recommended that the CGM elements and principles serve as that

basis and that extended metafiles be defined to meet the needs

currently served by the GKSM. Furthermore, they recommended that

the metafiles also be extended to support 3D objects,

segmentation, and viewing. PHIGS structures may be accommodated

in later versions of the extended metafile. (This very important

project is not staffed, as yet, by any US experts and the total

manpower available to WG2 is not large. If progress is to be

made, additional manpower, preferably from the US, needs to be

found.

)

In the following paragraphs, a few GKSM anomalies with CGM are

highlighted. These would be expected to disappear as the

extended metafile project makes progress.

-The specification of precisions of element data types is

limited to field length.

56
-There is no ability to distinguish between the precision of

real coordinates and other real numbers.

-There is no ability to distinguish between the precision of

indices and other integers.

-There is nothing similar to the CGM*s "local color

precision” to reduce the storage requirements for CELL

ARRAY.

The GKSM permits line, marker, text, and fill representations to

be placed in a metafile. In an extended metafile, one would

expect to see these elements added to the CGM base set.

5. 1.2. 2 Within the Family of Product Data Standards

"Near-Term Changes”

No near-term changes are suggested for IGES, because the IGES

committee is committed to using the PDES/STEP effort as the test

bed for evaluating the utility of new entities. These entities

will be migrated to IGES in an orderly fashion, after they have

been accepted into PDES.

All near-term suggestions for PDES arise from consideration of

the graphics standards and, consequently, are documented in

section 5. 1.2. 3 below.

"Future Changes”

The migration method from PDES to IGES adopted by the IGES

Committee is a sound idea. Consequently, no other

recommendations need be made in this category.

5. 1.2. 3 Across Family Issues

"Changes to Product Data Draft Standards"

The following paragraphs document changes needed in PDES and IGES

to increase the compatibility of these standards and the graphics

standards. As stated at the beginning of this section, these

changes are the conclusions of the contractor, and do not

necessarily reflect official NBS position.

-PDES should continue to look to the graphics standards

for its basic viewing, modelling, and text models. PDES

57
should continue to avoid all deliberate inconsistencies,

especially where matters of taste, rather than technical

issues are involved.

-The TEXT FONT definition facility of IGES should be

deprecated. This simplistic, STROKE-text facility is nearly

useless and is better served by upgrading the whole text

model to be consistent with the graphic standards, and by

including support for raster and outline character fonts.

In general, it is inappropriate for a product definition

data base to be specifying the detailed appearance of the

text fonts used in rendering a view or a drawing. These

matters are best left to the graphics support system,

'including the graphics device itself.

-Some of the IGES entities (e.g., SECTION) allow for the

specification of the details of the interior hatch pattern

to be used to fill the section area. Where standard

practice exists (that is, where special fill styles, say

narrowly-spaced cross-hatched lines at 45 degrees and 135

degrees, by convention mean, certain things, say an insulated

interior wall) , the use of the standard fill pattern should

be provided bv reference to the other standard practice

rather than bv specification of the details of the pattern

in the product definition file.

-IGES and PDES should adopt conformance rules for translators

(or interpreters) . All translators should be required to

process a minimum set of entities. Furthermore, for each

entity type—required or optional —some minimum standards

for fidelity of processing should be specified in the

standard

.

-IGES and PDES should adopt a 4x4 matrix, allowing for the

specification of arbitrary modelling and viewing

transformations. Existing IGES data bases need not use all

the matrix elements to specify their current views.

"Changes to Graphics Draft Standards'*

The addition of several facilities to the graphics standards

would greatly improve the ability of these standards to

efficiently represent the drawings and views implicit in IGES and

PDES files. These additions are described in the following

paragraphs

.

-Support for full conics including hyperbolas and parabolas.

-Support for splines, including at least one of the

parametric spline and rational B-spline representations.

58
-Support for surface definitions, including surfaces of

revolution and cylinders.

-Support for a ROUNDED RECTANGLE output primitive.

-Support for many new line types, including some or all of

the 11 forms of "arrows'* defined in IGES through

registration and subsequent standardization.

-Support for the CENTERLINE symbol as a new standardized

marker type.

-Addition of facilities to more directly control and specify

such features of text strings as subscripts, superscripts,

and fractions. At present, these features can be generated

only by using the more primitive APPEND TEXT and by changing

associated text attributes like CHARACTER HEIGHT, CHARACTER

SPACING, and TEXT ALIGNMENT.

-In IGES/PDES the slant of the text is independently

specified from the type face (e.g., Helvetica Italic Bold).

The CGI allows, via the Character Orientation element, text

characters to be skewed ("slanted”) . This feature is not

directly availaUsle in GKS and PHIGS; it can occur only as a

result of segment or structure transformations.

-In PDES, continuous text alignment is used to align multiple

text strings. This feature is also available in CGI/CGM.

It should be added tor GKS, GKS-3D and PHIGS.

-The six predefined IGES SECTION entity patterns not

corresponding to standardized CGI/CGM patterns should be

registered.

-Support for user-defined line types.

-Support for multiple color tables.

-The CGM should adopt conformance rules for translators (or

interpreters) . All translators should be required to

process a minimiim set of elements. Furthermore, for each

element—required or optional—some minimum standards for

fidelity of processing should be specified in the standard.

That is, the current guidelines in Appendix D of the CGM

standard need to be improved and promoted to official parts

of the standard.

59
5.2 RECOMMENDATIONS FOR GRAPHICS STANDARDS VALIDATION

Based on the extensive analysis of the European graphics

validation suite and experience installing and executing the

tests in a typical US graphics environment, NBS makes the

following recommendations to CALS:

1.

The data structure tests are of too low quality to be

useful for validating GKS implementations for DOD

purposes. Rather than expending the resources necessary

to correct deficiencies in the tests, and due to the

fundamental flaws described in [CARS86], it is

recommended that the operator interface tests be expanded

to include testing of the most important data structures.

2. The error tests are of higher quality than the data

structure tests. If fundamental flaws are corrected, the

tests could be used to provide a useful validation of the

error handling of GKS implementations. A moderate effort

would be required to upgrade the routines. The error

tests should remain a separate set of tests since they

are difficult to integrate with the operator interface

tests

.

3 . The operator interface tests are of definite value' in

validating GKS implementations, for DOD use- A moderate

effort would be required to correct programming errors in,

the tests and to make them more device-independent. As

stated in (1) above, the test could be expanded to

include tests of the most important GKS data structure

with little impact on their run-time efficiency.

4. The test programs are available only in FORTRAN. Since

DOD environments are likely to use Ada, consideration

should be given to converting the tests to that language.

This would be fairly straightforward due to the simple

structure of most of the’ test programs and subroutines,

but a time-consuming process.

5. Consideration should be given to restricting some of the

options available in GKS when it is used in a DOD

environment. Additional constraints should also be

placed on the "correct'* interpretation of many of the

effects which GKS defines to be ''device- or

implementation-dependent.'* If such constraints are

defined and promulgated, the test suite should be

expanded to test for them.

6. The test suites do not test the Computer Graphics

Metafile (CGM) and only test the GKS Metafile (GKSM) in a

cursory way. Due to the importance of graphical

60
metafiles for the CALS program, work should start at once

to develop a test suite for the CGM.

5.3 POSSIBLE SHORT AND LONG TERM SOLUTIONS

The contract report [SPARS 6] detailed a proposed short and long

term solution for the use of graphics within the CALS

environment. It is reprinted in Appendix 6 to give DOD a

perspective of how an expert in graphics standards foresees a

solution to the raster vs. vector problem in CALS. NBS does not

endorse this scenario, but rather specifies the need within the

draft plan to assess current raster to vector technology to get a

better handle on this CALS problem.

5.4 RECOMMENDATIONS FOR USING COMPUTER GRAPHICS STANDARDS

This section is devoted to Dr. Bono*s recommendations from his

second CALS contract report [BON286]. Again, these

recommendations are Dr. Bono's, and represent his view of CALS

priorities as it regards incorporating graphics standards into

the CALS environment. Since *he does not have to limit his

priorities based on available NBS personnel and resources, his is

a rather ambitious view of what should be done. As previously

stated, they are all reprinted here for completeness, and to give

DOD CALS a perspective on all the choices that NBS had to weigh

in coming up with the priority list contained in the FY87

Statement of Work, or CALS Draft Plan.

5.4.1 Accelerated Development Work

Work on the Computer Graphics Extended Metafile (CGEM) should be

given a high priority.

There is a wide gap between the relatively simple

representational capabilities of CGM and the very rich

capabilities of product data definition standards like IGES.

Conversely, there is also a wide gap between the compact size and

straightforward processing of CGM files and the enormous size and

convoluted processing of IGES files. The CGEM is a proposed ISO

project to add functionality to CGM in a staged, upwardlycompatible manner. The stages would include, at a minimum,

adding segments and 3D viewing. Facilities for more extensive

hierarchical support, new output primitives and attributes, and

symbol libraries could also be considered.

61
A mechanism for registering special CGM ESCAPES and APPLICATION

DATA elements should be built into MIL-STD-1840.

NBS will need to determine if DOD-specific ESCAPES and

APPLICATION DATA elements are needed to augment the CGM for its

use with MIL-STD-1840. The registraion procedures could be

modelled after those being developed within ISO for the

Registration of Graphical Items.

For MIL-STD-1840, NBS needs to determine what encoding (s) is

(are) suitable for CGM.

All three encoding formats—character-coded, binary, and cleartext—have their uses, but were designed for different purposes.

Depending on the purpose of MIL-STD-1840, some or all of the

standard encodings of CGM should be included by reference.

NBS should form a joint IGES/CGM team to identify needed CGM

ESCAPES

.

There are many situations in which IGES is being used but for

which IGES was not designed. The current CGM may not be able to

be used either, due to the absence of just a few items.

Identification and specification of these needed, missing

elements by the NBS team would permit the CGM to assume more

roles where its compactness and simple processing would allow

more efficient and less costly use of computer and human

resources. Generally useful new elements could be proposed for

registration, either within the more limited scope of MIL-STD1840 or in the wider ANSI and ISO arenas.

Work on the Programmers Hierarchical Interactive Graphics System

(PHIGS) Standard should proceed according to the current

published schedule.

A recent survey of attendees (43 responses out of 150 attendees)

at the PHIGS Tutorial course given at the SIGGRAPH ’86 Conference

provided the following insights:

-about one-half the respondents supported aerospace,

engineering, science, government, or military applications.

-over 80% of the respondents need PHIGS within one year.

-nearly 70% said that PHIGS was the best suited API standard

for their purpose.

-of the users, 24 of 32 (75%) stated that they needed exact

or almost exact PHIGS conformance.

Although these results are based on a small and biased sample.

Dr. Bono believes they correctly reflect DOD's need for a PHIGS

62
API standard. Because of the oveirwhelming life cycle cost

benefits that accrue from API standards, PHIGS should be

developed as soon as is practical, according to the published ISO

schedule.

5.4.2 Urgent Requirements for Validation

Validation of API-level Staindards Should Continue.

The beneficial impact of using API-level graphics standards to

keep software life cycle costs under control is so great that NBS

should accelerate its efforts to validate GKS implementations for

CALS use (see section 5.4 above) . Planning should commence for

the validation of GKS-3D, PHIGS, and CGI implementations, when

these draft standards are approved. Furthermore, as shown by

[CARS86], the DOD cannot rely on test suites developed abroad,

although these efforts may be used as a starting point for US

validation work.

Validation of CGM Interpreters is Urgently Required.

The CGM standard places conformance requirements on CGM files

themselves. In brief, there are rules about what elements may

appear in a CGM, in what order these elements jaay be placed, and

the relationship' of pictures one to another. Furthermore, fully

conforming CGMs must be coded with one of three standardized

encoding formats.

Although stated in terms of the CGM file itself, these

conformance requirements may be viewed as placing implied

requirements upon the metafile generator. Consequently,

validation procedures developed for the CGM standard will in fact

also serve to validate CGM generators.

However, there are no conformance requirements on CGM

interpreters. The appearance of the pictures produced by

interpreting a conforming CGM is not specified by the standard.

(The standard does offer guidelines, but these are not mandatory

and, consequently, will not be tested by any CGM validation

effort.

)

For CGM to serve the CALS program well, there is a need for a

validation suite for CGM interpreters. The validation suite

would consist of three major parts: (1) conforming CGM files in

each of the three standardized encodings; (2) expected pictures,

rendered on a variety of output media, illustrating the range of

allowable differences; and (3) a written description of the

expected output, detailing exhaustively the range of allowable

differences in the resulting image.

63
The value of this effort would be greatly enhanced and the

difficulty greatly reduced, if recommendation R34 were also

adopted concurrently with this recommendation.

5.4.3 Accelerated Implementation

Automatic digitizers should output CGM files.

The output from automatic digitizing equipment takes the form of

primitives and attributes that correspond closely to those of

CGM. The DOD should encourage vendors to, in fact, adopt CGM

perhaps with a few needed extensions registered as ESCAPES or

APPLICATION DATA elements—as their principal, non-proprietary

data format.

Conversion to digitized drawing databases should occur as quickly

as funding allows.

The urgent problem of converting massive quantities of drawings

from their raster (image) form (e.g., on aperture cards) to a

vector format (e.g., CGM) needs to be solved only for the

existing database. It is equally urgent that CALS not increase

the volume of non-digitized drawings. Consequently, building new

systems based on digitized, vector geometry now will pay

dividends in the future, to the degree that CALS can slow down

the increase in volume of non-digitized drawings and data.

The CGM should be targetted for accelerated implementation.

Given the important contribution that the CGM can make to

achieving the CALS goals, the DOD should focus resources on

encouraging commercial implementations and DOD use of the CGM.

Availability of fully validated CGM interpreters from a variety

of suppliers would stimulate wide usage of the CGM.

The DOD should promulgate CGM Implementors Guidelines for CALS.

Not all CGM interpreters will produce the same picture, even when

given the same CGM file and the same target output device. (See

recommendation R22 above.) For CALS, CGM interpreters should be

required to meet guidelines that specify at least the following:

-a list of required elements;

-minimum sets of functions and features;

-requires simulation for all unsupported elements;

-specific behavior for some (or perhaps all) of the aspects

of the CGM standard that are currently left implementation

dependent.

These guidelines (sometimes called Application Profiles) could be

64
developed at a series of CGM implementers workshops and

technology demonstrations, perhaps organized by NBS. Appendix 7

contains an initial draft of a CGM Application Profile being

recommended for inclusion into the TOP industry standard. TOP

requirements may not exactly overlap CALS requirements, so CALS

needs to do its own assessment of needs. Nevertheless,

unnecessary deviation from the TOP and other Application Profiles

that may emerge (such as from ISO TC97/SC18 for incorporating

pictures into office documents) should be avoided.

5.4.4 Related Standards

SGML needs to be eible to import CGM files to create mixed text

cind graphics documents.

Hooks are needed in SGML to permit the importing of CGM pictures

via external references to files and with "presentation

attributes'* like those being recommended for the Geometric

Graphics Content Architecture of the ODA/ODIF standard (ISO

8613/8) . The presentation attributes control position,

mirroring, and orientation of the picture; presence and

appearance of any border; and size and aspect ratio of the

displayed image within the block allocated for the picture.

DOD should continue to insist upon the complete separation of

function (semauitics) from format (syntaoc) . The graphics standards have been carefully crafted to allow

multiple, alternate syntaxes (either encodings—as in CGM—or

language bindings—as in PHIGS and GKS) for a single functional

specification. This permits a syntax to be selected according to

criteria important to a given application area, without

sacrificing the benefits of standardizing the functions.

Other standards groups have not been so careful with their

specifications. As a result, alternative standards—with

different semantics, but solving the same problem—often get

invented and promulgated because of dissatisfaction with syntax.

For example, the French alternative—and threat to IGES—arose to

a significant degree because the initial format of IGES files

specified in the standard was so inefficient and represented

obsolete technology. By the time IGES remedied the problem, a

competitor had been invented. Naturally, this competitor also

has many functional ''improvements'* over—and incompatibilities

with—the original IGES specification.

65
5.5 PRIORITIES FOR KEY PLANNING ELEMENTS

As a result of NBS/ICST studies of CALS requirements over the

past few months, and the schedule that has been developed for

CALS, CGM has been identified as the Computer Graphics

interchange standard of most immediate utility to CALS. Thus,

all priorities are based on getting CGM to the level of

completeness that CALS requires. NBS/ICST studies of CALS

requirements have revealed that CALS applications currently have

made, little or no use of microcomputer graphics, so this has been

given no priority for near term CALS. There is currently so much

work to be done on developing and implementing database

management standards and capabilities within the CALS

environment, that interfacing graphics standards with them has

been deemed premature for the near term. In addition, no work

has been formally started in the standards communities to tackle

this problem.

The Proposed FY87 NBS Statement of Work in support of the DOD

CALS program represents the Draft Plan for CALS work over the

next two years. Contained within it are the recommendations and

priorities for the incorporation of graphics standards into CALS.

Since the CALS Architecture work is likely to drive any changes

to this plan, NBS is not going to draft a plan separate from this

proposed Statement of Work in the area of Computer Graphics

Standards

.

To briefly restate those plans and priorities here, they include:

1. Develop a link between IGES/PDES data files and CGM/GKS/PHIGS

picture files. CAD/ CAM packages, which produce IGES files,

provide input to both automated technical manual and engineering

data repository systems. To minimize storage and processing

overhead and maintain required system performance, CGM should be

used to transfer graphical pictures within and across these

systems. A mechanism must be developed which supports the

transfer of data in IGES format to CGM.

2. Extend CGM conformance definitions to include "generators"

and "interpreters" of metafiles. Currently, conformance

requirements in the CGM refer to the syntax of the metafile, not

to programs which generate metafiles and read metafiles.

Conformance criteria are needed for these programs to ensure that

the complete graphical image is ported between devices.

3. Update Air Force MIL-STD 1840 to incorporate full CGM

implementation for the transfer of graphics pictures. To support

CALS requirements, this MIL-STD must provide for the use of CGM

in the transfer of graphics pictures.

4. Inject CALS requirements for extended CGM. Work is just

beginning to develop a more powerful and consolidated metafile

66
for graphics picture transfer. This metafile would allow much

more substantial modifications to be made on pictures being

transferred and would be more compatible with existing graphics

standards (GKS, GKS-3D, and PHIGS) . It is imperative that CALS

requirements with respect to picture modification be defined and

input to this effort in its early stages of development.

5. Identify CALS requirements for CGM registration. A

registration mechanism is being put in place by ISO to allow

extensions to existing graphics standards. As has been stated,

NBS/ICST has been chosen as the Registration Authority for this

task. Through registration, various primitives (geometric

shapes) can be added to CGM. A discussion of areas where

registration could be helpful appears in Section 5.1 of this

report. This mechanism should be utilized to ensure that all

geometric objects which are displayed graphically in CALS can be

represented by the CGM.

6. Accelerate development of CGM validation routines which are

underway in Europe. Validation routines must be in place for

CALS to accurately know if vendor implementations really conform

to the CGM standard.

7. With the extended CGM definitions of priority (2) above

delineated, develop a plan for additional CGM conformance tests

needed to validate generators and interpreters of CGM metafiles.

These validation tests must also be in place for CALS to

accurately know if vendor implementations really conform to the

extended CGM definitions for generators and interpreters as a

result of priority 2 above.

8. Conduct an in-depth study of raster-to-vector conversion

technology to include a technical assessment, a comparison of the

vector output of this technology with the vector outputs of CGM

and IGES, and recommendations for CALS. All of the graphics

standards, including IGES, require vector format to be utilized

effectively. The availability of this technology must be

assessed and alternative strategies developed if raster-to-vector

conversion is not available in a timely manner.

In addition, work in the graphics standards area for CALS is

incorporated in a number of other tasks in the Proposed FY87

Statement of Work, in such areas as defining the core CALS

standards package, holding DOD/NBS/ industry workshops for the

presentation and development of core CALS standards

specifications, and in developing the CALS Architecture.

67
5 • 6 FINAL CONCLUSION

This section of the NBS final report has detailed all the work

done in the graphics standards area, both by NBS and by the

contractors hired to help NBS in identifying CALS needs in terms

of graphics standards. It has also explored areas where the

graphics standards could or should interact with other standards

which have been identified as requisite for CALS, such as IGES,

PDES, and SGML, and how such interaction could take place. This

section of the report has also specified some ’’architectures" for

describing CALS application areas in terms of the use of

standards, in particular graphics standards. This work may be of

help in the planned architecture work for FY87.

The overall final result of this section of the report is that

CGM has been identified as the graphics standard of most

immediate benefit to DOD CALS. It is currently an ANSI approved

standard, and is shortly to become a FIPS standard. The areas of

work in the Proposed Statement of Work are, therefore, geared to

making CGM a complete reality for the CALS core specification,

including CGM’s inclusion into Air Force MIL-STD 1840, work on

conformance tests for CGM implementations, and identification of

CALS requirements for CGM registration.

68
REFERENCES

The official standards documents used as source material for this

report include:

Computer Graphics Interfacing Techniques for Dialogues with

Graphical Devices (CGI), ISO TC97/SC21 N1179, First Working

Draft, May 9, 1986.

Computer Graphics Metafile for the Storage and Transfer of

Picture Description Information (CGM) , ISO DIS 8632 Parts 1

through 4, 1 November 1985; also, dpANS X3. 122-1986 (to be

published in the fall of 1986)

.

Graphical Kernel System (GKS) , ISO 7942, 15 August 1985; also,

ANSI X3. 124-1985, June 24, 1985.

Graphical Kernel System for Three Dimensions (GKS-3D) , ISO 2ND DP

8805 (ISO TC97/SC21 N853), 1 October 1985.

GKS Metafile (GKSM) , Annex E of ISO 7942, 15 August 1985; also.

Appendix E of ANSI X3. 124-1985, June 24, 1985.

Initial Graphics Exchcmge Specification (IGES) , Version 3.0,

National Bureau of Standards Report NBSIR 86-3359/ April 1986.

Presentation Entities for the Product Definition Exchange

Specification (PDES) , ISO TC184/SC4/WG1 N53, November 4, 1985.

The STEP File Structure, ISO TC184/SC4/WG1 document 4.2.2

(working paper) , February 7, 1986.

Programmer's Hierarchical Interactive Graphics System (PHIGS)

,

ISO/TC97/WC21 N819, 4 November 1985; also, dpANS

X3. 144-1985, November 1985.

These documents are available from a variety of sources:

The published ANSI standards (viz., GKS) and the ISO

documents (CGI, CGM, GKS, GKS-3D, PHIGS) can be

obtained from ANSI, 1430 Broadway, New York, NY 10018.

The draft ANSI standards (CGI, CGM, GKS-3D, PHIGS) can

be obtained from the X3 Secretariat, CBEMA, 311 First

Street, Suite 500, Washington, DC 20001.

The IGES and PDES documents can be obtained from the

IGES Committee Chairman, Mr. Bradford Smith, National

Bureau of Standards, Gaithersburg, MD.

69
In addition to the official standards documents, the contract

reports referenced include:

[BON186] Bono, Dr. Peter R. , ”A Comparison of Standards Relating

to Graphics Picture Exchange - A Technical Analysis of

the Compatibility of Product Data Definition Standards

and Graphics Standards,'* June 1986,

[BON286] Bono, Dr. Peter R. , '*A Framework for How the CALS

Program Should Utilize Computer Graphics Standards,'*

October 1986.

[CARS86] Carson, Dr. Steve, GSC Associates Inc. , '*Evaluation of

European Graphics Validation Suite,'* July 198 6.

[SPAR86] Sparks, Madeleine, System Development Corporation,

'* Interchange and Graphics Standards for CALS

Applications - Review and Analysis of CALS-Related

Requirements for Graphics Standards,'* July 198 6.

70
GLOSSARY

blind interchcmge

chairacrter set:

device~dependent

device-independenb

device coordinates

escape fiinctions

A mode of interaction between a service and

its client in which the client requests

services without recourse to interactive

negotiation before use or acceptance of

response during use. This mode of interchange

may result from the service's inability to

respond, the client's lack of interest in

listening, or limitations in the

communications path between client and

service.

The set of displayable symbols mapped to

individual character codes in a text string.

A character set is independent of the font or

typeface.

A system or portion of a system that contains

logic, algorithms, or data that are consistent

with the behavior of a specific graphical

device.

A system or portion of a system that contains

logic, algorithms, or data that do not require

nor represent knowledge about the behavior of

any particular graphical device.

The coordinates native to a device;

device-dependent coordinates; physical device

coordinates

.

Graphical functions that describe

device-dependent or system-dependent elements

used to construct a picture, but that are

otherwise not standardized.

71
external functions

Functions present in some graphics standards

that communicate information not directly

related to the generation of a graphical

image

.

metafile

A mechanism for retaining and transporting

graphical data and control information. This

information contains a device-independent

description of one or more pictures.

metafile generator

The process or equipment that produces a

metafile.

metafile interpreter

The process or equipment that reads a metafile

and interprets the contents to produce again

the picture represented in the metafile.

modelling coordinates

Local world coordinates tied to some object

' being modelled by the client and viewed by the

graphical system.

negotiation

The interchange of inquiry and response by

which a client of a set of services determines

which capabilities are provided by the service

and what the characteristics of the service

are.

normalized device coordinates (NDC)

Coordinates specified in a device-independent

coordinate system, normalized to some range

(typically 0 to 1)

.

prior agreement

A process whereby the generator of a metafile

and the recipient of the metafile come to some

understanding regarding the content or format

of the metafile, that understanding not being

recorded in the metafile itself. In a blind

interchange environment, prior agreement can

be used to overcome limitations of exchange

standards

.

72
segmen't

A collection of graphical functions that can

be manipulated as a unit. Once functions are

grouped into segments, they are referred to as

segment elements.

world coordinates

Coordinates specified in a device- independent

coordinate system, whose units are selected by

and are meaningful to the client.

73
V.

i

.V , • • ^4p-.

I

yc! b«39*XM'

,

* . - s<9 yr> b^' .

. .'T -

• <*. r: ® 3 -in ^ b r -

L* - liAt*. !• .

» *

^

,* c

-** •

;:i ‘

1 .nd

J * "i .

‘f

r

4

I
APPENDIX 1

COMPUTER GRAPHICS STANDARDS

APPENDIX 1

COMPUTER GRAPHICS STANDARDS

1. PURPOSE OF VARIOUS GRAPHICS-RELATED STANDARDS

1.1 Position Within a Reference Model

Standards codify the exchange of information across an interface

between two functional units and specify what is to be exchanged,

but not how the functional units should carry out their

operations. Figure 1 depicts a reference model showing the

various interfaces in a graphics application process. This

process may receive information from an external product

definition database over the product definition interface. This

application process interacts with physical graphics devices and

operators via a computer graphics environment, which in Figure 1

has been partitioned into a support package level and a

workstation level. The interfaces significant for graphics

standards are depicted.

Figure 2 shows the current standards under development,

positioned at their appropriate levels. This figure highlights

the two interfaces that are central to graphics standardization:

the application programmer interface, or API, and the virtual

device interface, or VDI. Standards at both interfaces provide

device independence for the user of the standard. That is, the

user can deal with one or more abstract ("virtual”) graphics

devices with a full range of input and output capabilities. The

"messy details” of the particular hardware capabilities of any

particular graphics device are hidden from the user. Instead,

implementations of the standards must emulate any required

facilities not directly supported by the hardware. Furthermore,

the implementations mask the peculiarities of the particular

command sets used to communicate specific orders to the graphics

devices.

1.2 The Application Programmer Interface

To exchange pictures among diverse applications and across

separate programming environments, information can be captured at

an interface and placed in a graphical metafile , a formatted disk

or magnetic tape file containing graphical commands and data.

These files can be transmitted over telephone lines and computer

networks to be stored and processed by the recipient.

75
PRODUCT

DATA BASE

1

I

APPLICATION

PROCESS

APPLICATION

ENVIRONMENT

PHYSICAL ; GRAPHICS^-

DEVICES ;

COMPUTER GRAPHICS

ENVIRONMENT

COMPUTER

GRAPHICS

SUPPORT

PACKAGE

Figure 1.

OPERATOR

(optional)

76
IGES Product | PDES Data Boio|

GKS/GKS-3D

PHIGS

1

i

$ —

Operating System

CGM

Graphics Devices

Figure 2.

77
The API is represented by three major graphics standards

projects; GKS, GKS-3D, and PHIGS. These API standards are

typically implemented as a collection of external procedures or

subroutines that a programmer can link with his application code

to obtain graphical input and cause pictures to be displayed on

graphical output devices.

The API standards are not directly suitable for picture exchange.

However, each standard has an associated storage mechanism (an

archive file or graphical metafile) that can be used to exchange

graphical information among systems using the same standard. The

API standards are briefly described in the following paragraphs.

Their associated metafiles are described in later sections.

GKS. GKS consists of nearly 200 user interface routines that

give a programmer the ability to create graphical output and

accept graphical input from a wide variety of graphical devices.

These include black-and-white and color displays, printers,

plotters, and camera systems of varying resolutions, as well as

mice, data tablets, keyboards, joysticks, and digitizers. Only

2D primitives are used to describe pictures, although 3D

renderings can be created by the application by first performing

the 3D to 2D mapping itself before calling the GKS functions. A

GKS implementation typically provides programming access to GKS

from several higher-level programming languages such as Fortran,

Pascal, Ada, and C.

GKS ' s purpose is to allow the creation of views of objects. Each

view is described to GKS by a succession of primitives and

attributes that may be grouped into segments for later viewing,

without the client having to respecify the primitives and

attributes in the segment. As a whole, segments may be made

invisible and highlighted, translated, rotated, and scaled, but

the individual contents of segments may not be modified.

Consequently, GKS is a pure viewing system; GKS does not keep

anygraphical model or graphical database for the application

program.

GKS-3D. The project to specify extensions to GKS for defining

and viewing three-dimensional wire-frame objects is well

underway. Like GKS, GKS-3D is restricted to viewing objects;

nomodelling is performed by a GKS-3D implementation. This

limitation in GKS and GKS-3D keeps the size, complexity, and cost

of the implementation down and meets the needs of at least 8 0%

ofthe graphics applications today, including much of the needs of

business graphics, statistical and engineering graphics, project

management, and mapping.

PHIGS. The Programmer's Hierarchical Interactive Graphics System

is an emerging standard specifying an application programmer's

interface to a rich, device-independent graphics environment.

78
PHIGS is designed to support such important applications as

CAD/CAE/CAM, command and control, molecular modelling,

simulation, amd process control. PHIGS emphasizes thesupport of

applications needing a highly dynamic, highly interactive

operator interface and expects rapid screen update ofthe complex

images to be performed by the display system.

PHIGS provides all the viewing capabilities of GKS-3D in a

compatible manner, but, in addition, PHIGS supports the

creation, modification, and viewing of a geometric model, which is

maintained by the PHIGS implementation. Called the Central

Structure Store, PHIGS elements are structured into hierarchies,

with structures calling other structures and with offspring

structures inheriting attributes from parent structures. Once

created, or while being created, PHIGS structures can be marked

for displaying on one or more workstations.

The current state of technology dictates that the initial

implementations of PHIGS will be designed to run on nothing less

powerful than a superminicomputer, using a high-performance

display. Until fast, floating-point hardware is commonly and

inexpensively available, until processor cycle tines improve

substantially, and until internal word sizes and data path widths

increase to 32 bits or more, PHIGS is unlikely to be implemented,

in toto . on personal computers.

The principal purpose of the API standards is to provide

portability for the application program across a wide range of

operating systems, programming languages, and interactive

graphics devices. Consequently, programs written to an API

standard at one facility can be exchanged with another facility

and used with only minor modifications needed to tailor the

software to the implementation differences allowed by the

standard

.

Furthermore, as hardware CPUs and peripherals are upgraded and

replaced, software written to an API standard will survive and

need not be rewritten. Indeed, the software performance should

improve, assuming that the new hardware is more capable than the

old hardware.

1.3 The Virtual Device Interface

The VDI is internal to the graphics system and concerns system

programmers, independent software vendors, peripheral device

manufacturers, and graphics controller board and graphics chip

makers. These clients require device independence without

sacrificing performance.

The CGI (Computer Graphics Interface) standard is designed to

specify the exchange of information at the VDI, while the related

i 79

I j
CGM (Computer Graphics Metafile) standard serves to capture the

descriptions of pictures at the level of the CGI. These two

standards are described more fully in this and the next section.

CGI. The Computer Graphics Interface is a standard functional

and syntactic specification for the exchange of device

independent data and associated control information between

systems with graphical functional capabilities. These systems

may be peer graphics systems or may be device dependent graphics

device drivers

.

The CGI defines an idealized abstract graphics device capable of

accepting input and generating, storing, and manipulating

pictures. It contains elements for generating graphical

primitives; controlling the appearance of graphical primitives;

inquiring graphics device capabilities, characteristics, and

states; controlling graphics devices; generating and controlling

groups of primitives called segments; and obtaining graphical

input. At -present, the CGI supports only 2D output primitives

and controls only one device. The CGI has been designed to

directly support GKS viewing operations.

The purpose of the CGI is to serve as a standardized, device

independent interface for graphics package implementers to write

to. When supported in hardware by peripheral device

manufacturers, the burden of writing device drivers will be

greatly eased. Furthermore,, just as with applications written to

GKS, implementations written to the CGI will be able to take

advantage of new hardware without having to be rewritten and

extensively modified. Thus, the developer's investment is

protected, and any application layered on top of the CGI shares

this same benefit. With hardware products having a lifespan of

barely one year (new, less costly, faster, and higher-resolution

devices usually appear within a year of the initial product

offering) , writing to the CGI instead of to the hardware pays

enormous dividends to the developer and end-user (consumer)

alike.

1.4 Metafiles

There are two phases to the use of metafiles. To create the

metafile, a metafile "device driver," or metafile writer or

generator, must be available with a graphics package. To read

and redisplay metafiles generated on other computers, a metafile

reader, or interpreter, must be available on the system where the

picture is to be used.

Two principal kinds of graphical metafiles are being

standardized. The GKS metafile (GKSM) is an audit trail of the

GKS commands that were used to generate a particular picture on a

GKS workstation. Although GKS metafiles may be interpreted

80
outside the GKS environinent , most users will use GKS to both

generate and interpret these files. GKS metafiles are not very

compact and, if the picture stored in the metafile were designed

by the user in an incremental and iterative manner, the metafile

may contain a large quantity of superfluous information.

CGM. The Computer Graphics Metafile represents a snapshot of the

final image that a prograua has created. Unlike the GKS metafile,

no intermediate pictures are represented in the CGM.

Consequently, the files are more compact.

The CGM provides a file format suitable for the storage and

retrieval of picture description information. The fils format

consists of an ordered set of elements that can be used to

describe pictures in a completely device-independent way. One or

more pictures can be stored in a single metafile, and the

metafile is defined in such a way that, in addition to sequential

access to the whole metafile, random access to individual

pictures is well defined. That is, the pictures are completely

independent, one from another: their appearance does not depend

upon the order in which they are accessed or displayed.

In addition to a functional specification, the CGM standard

documents three standard encodings of the metafile -semantics.

The Character encoding requires minimum metafile size and is

suitable for transmission across networics of heterogeneous

systems but is expensive to encode and decode. The Binary

encoding requires minimum effort to generate and interpret but is

not well suited for exchange between computers of different

arithmetic data types. It is nearly as efficiently coded as the

Character encoding. The Clear-text encoding provides maximum

readaibility and editability for ease of use by humans (e.g., for

debugging purposes) but, generally, pays a heavy penalty in size

and performance. The size is much larger because English and

other natural languages contain a lot of redundancy. The

performance is worse because parsing and recognizing text strings

and converting text strings to internal numbers for use by a

graphics subsystem is expensive in its use of CPU cycles.

The standardized CGM elements by type can be found in Table 1.

The ESCAPE and APPLICATION DATA elements have been provided to

support uses of the CGM in ways that go beyond the exchange of

pictures. Nongraphical data and graphical elements not yet

stcuidardized cem be incorporated into CGMs in a regular way.

When these extended metafiles are exchanged by coopeirating

processes, standard commercial products can be used to handle the

standard metafile elements, and new code need be written only for

the special, non-standardized elements. Large groups of users of

extended metafiles can get together and agree upon a set of

extensions—just like MAP and TOP users have agreed upon

guidelines to the implementation of the OSI standards. For

81
example, the elements of a business chart—like legend entries,

tick marks, and axis labels—or the elements of a project

schedule—like PERT chart symbols, milestone markers, or

title—could be marked in the metafile. An editing program could

be written to read such metafiles and allow modifications to them

before rendering the chart on a hardcopy device or including it

in a report or manual.

82
TABLE 1. CGM ELEMENTS

Element Type

Delimeter

Metafile

Descriptor

Picture

Descriptor

Control

Graphical

Primitive

Elements

BEGIN METAFILE

BEGIN PICTURE

BEGIN PICTURE BODY

END METAFILE

END PICTURE

METAFILE VERSION

VDC TYPE

INTEGER/REAL PRECISION

COLOUR INDEX PRECISION

METAFILE ELEMENT LIST

FONT LIST

CHARACTER CODING ANNOUNCER

METAFILE DESCRIPTION

MAXIMUM COLOUR INDEX

INDEX PRECISION

COLOUR PRECISION

DEFAULTS REPLACEMENT

CHARACTER SET LIST

COLOUR SELECTION MODE SCALING MODE

LINE WIDTH SPECIFICATION MODE

MARKER SIZE SPECIFICATION MODE

PERIMETER WIDTH SPECIFICATION. MODE

VDC EXTENT

VDC INTEGER/REAL PRECISION AUXILIARY COLOUR

CLIP RECTANGLE CLIP INDICATOR

POLYLINE

POLYMARKER

RESTRICTED TEXT

POLYGON

CELL ARRAY

CIRCLE

CIRCULAR ARC CLOSE

ELLIPTICAL ARC

DISJOINT POLYLINE

TEXT

APPEND TEXT

POLYGON SET

GDP

CIRCULAR ARC

ELLIPSE

ELLIPTICAL ARC CLOSE

83
TABLE 1. CGM ELEMENTS (Continued)

Element Type

Attribute

Escape

External

Elements

LINE BUNDLE INDEX

LINE WIDTH

MARKER BUNDLE INDEX

MARKER SIZE

TEXT BUNDLE INDEX

TEXT PRECISION

CHARACTER EXPANSION FACTOR

CHARACTER HEIGHT

TEXT PATH

ALTERNATE CHARACTER SET INDEX

INTERIOR STYLE

HATCH INDEX

PERIMETER TYPE

PERIMETER COLOUR

FILL REFERENCE POINT

PATTERN TABLE

ASPECT SOURCE FLAGS

ESCAPE

APPLICATION DATA

LINE TYPE

LINE COLOUR

MARKER TYPE

MARKER COLOUR

TEXT FONT INDEX

TEXT COLOUR

CHARACTER SPACING

CHARACTER ORIENTATION

CHARACTER SET INDEX

FILL BUNDLE INDEX

FILL COLOUR

PATTERN INDEX

PERIMETER WIDTH

PERIMETER VISIBILITY

PATTERN SIZE

COLOUR TABLE

MESSAGE

84
1.5 Purposes of Metafiles

Figure 3 shows three levels of data interchange. At the lowest

level, simple files can be exchanged between systems (path 0) . The file transfer, access, and management (FTAM) standard—part

of the OSI level 7 facilities—is designed to handle this

activity, but Icnows nothing about the semantics of the contents

of the files it transfers. In its full generality, it will

automatically convert the format (i.e., syntax) of files as part

of the transfer process if the file types have been registered.

Indeed, the three encodings of the metafile are being registered

for use with FTAM. Although FTAM knows nothing about graphics,

FTAM can be used to transfer graphical metafiles from system to

system (paths I and J)

.

At the next level of exchange, graphical metafiles are used to

transfer pictures, drawings, or images between graphical

processes (path G) . In this case, not only is the syntax known

to the cooperating processes, but also the semantics; that is,

both processes know about color tables, bundled attributes,

filled areas, and pixel arrays. However, they don't know about

any application-specific information like surfaces and centers of

mass, nor relationships between entities like the association

between two connected objects. Only extended metafiles that use

APPLICATION DATA elements are able to communicate information

that goes beyond the elementary picture representation

.information. CGM is the principal graphics standard at this

level. Picture files may be sent directly to print spooler tasks

(path K) and thence to hardcopy devices (path N) , or they may

first be manipulated by application-specific programs like

desktop publishing applications (path H) . Such programs, perhaps

written using GKS,will manipulate the pictures, merge the images

with other, non-graphical information such as text and document

layout commands from a word processing program, and then route

the layed-out pages to a print spooler (path L) or directly to a

hardcopy device like a laser printer (path M) . The spooler and

other application programs are likely to use CGI to talk to the

graphics hardcopy devices. These application programs may also

produce structured, editable output like full drawings that may

again be treated as product databases (path F)

.

At the highest level of exchange, one needs to transfer product

databases . In the CAD/CAM/CIM environment, the product

definitions often have a high degree of geometric information;

indeed, if the product is a drawing, it may consist principally

of information that is pictorial. However, the purpose of a

product database is to support such functions as design,

analysis, manufacturing and testing. Furthermore, it is

sometimes desirable that cooperating processes not only share a

product database, but also that they share views of the same

objects so that, for example, engineers may see the same view and

consult with each other concerning the object's design and

85
Figure 3.

86
manufacture. The two principal standards at this level (path A)

are the Initial Graphics Exchange Specification (IGES) and the

Product Definition Exchange Specification (PDES) . Of particular

interest are the PDES Presentation Entities. These two standards

are described in more detail in section 1.7 below.

CGM pictures can be derived directly from IGES or PDES formatted

databases (paths C and D) for archiving and for inclusion in

technical manuals and reports. Typical CAD/CAM programs, again

perhaps written using PHIGS to obtain device independence, will

build internal geometric models and data structures by loading

data from an external product definition database (path B) . During the processing, CGM picture files may be produced (path E)

for later use in such applications as desktop publishingand

picture previewing.

1.6 Picture File Transfer and Storage

A graphical metafile, which is used to transfer and store

pictures, has great value in a networked environment. For

example, PCs are being connected to large mainframe hosts for

number-crunching and access to the corporate or engineering

databases. Because the users are trying to exchange information

(and not just data) and because pictures convey information much

more efficiently than words and numbers, graphical metafiles,

especially those extended to handle text and graphics, will play

an important role in integrated environments. Because graphical

metafiles store pictures in a resolution independent manner,

these pictures can be previewed on low-cost displays like those

found on today’s PCs and still be printed on high-resolution

printers, plotters, and camera systems. Metafiles can also be

stored for later use—in fact, can be stored for years and then

be retrieved for plotting on devices with new capabilities and

resolutions not imagined when the metafile was created.

In the text and office systems arena, at this level of

interchange, the Office DocTiment Architecture/Office Document

Interchange Format (ODA/ODIF) standard (ISO DIS 3613) is also

found. It is used to exchange so-called ’’compound documents”

that may contain a mixture of pure text, graphics pictures, and

facsimile images. The current draft proposal for a Computer

Graphics Content Architecture contains the CGM as its base

technology. Thus, the CGM is a very important standard for such

applications as technical dociimentation, maintenance manuals, and

project plans.

1.7 Product Definition Database Transfer and Storage

The term product data denotes the totality of data elements that

completely define the product for all applications over its

87
I

expected life cycle. Product 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.

IGES. The Initial Graphics Exchange Specification is a mature

mechanism for the digital exchange of database information among

present-day CAD systems. Now in its third version, engineering

drawings, 3D wireframe and surfaced part models, printed wiring

product descriptions, finite element mesh descriptions, and

process instrumentation diagrams are addressed by IGES . IGES

information, including drawings and 3D wireframe product models,

is intended for human interpretation at the receiving site.

PDES. Whereas IGES has addressed the need for data exchange

where the received product model is interpreted by a human either

as a display or as a generated plot, the Product Data Exchange

Specification (PDES) project is focussed on exchanging product

models with sufficient information content as to be interpretable

directly by advanced CAD/ CAM application programs. In addition

to geometry, PDES will suppori: a wide range of non-geometry data

such as manufacturing features, tolerance specifications,

material properties, and surface finish specifications.

It must be recognized that IGES and PDES have different

technological objectives and are in vastly different ^ stages of

development. IGES is mature and in production; PDES is in its

early stages of development and will not be ready for use before

the late 1980 's. IGES is a US standard, while PDES represents

the US contribution to the international effort in product data

exchange (ISO TC184) . Until PDES has been proven, IGES will

continue to evolve with upward compatible versions to support the

commitments already made by industry. Much of the development

work on PDES is expected to benefit this continuing IGES work.

Although much of PDES version 1.0 will have little to do directly

with graphics, the early work on PDES includes a task to develop

a conceptual schema to support the mechanical design of flat

plates with circular holes. Wireframe geometry will be used. The

schema will support some user-view presentation (viewing)

scenarios pertinent to this area of mechanical design. Wireframe

geometry entities and the presentation entities have been

developed as part of this task. These entities use concepts

drawn from the ASC X3H3 graphics standards.

1.8 Transaction Recording

Sometimes there is a need to record everything that is passed

across an interface. Such transaction files are called audit

trails. Audit trails can be used for a variety of purposes.

88
Audit trails provide a simple graphical metafile for the exchange

of pictures. The GKS metafile (GKSM) is an example of such a

metafile. The GKSM stores all the output transactions at the GKS

workstation interface. Consequently, segment contents and

segment manipulations are recorded, as well as the usual output

primitive and attribute information similar to that recorded in

the CGM. Audit trails like the GKSM typically are useful only

within a homogeneous graphics system environment, because they

are expensive to interpret unless the underlying graphics system

is also GKS. Audit trails are also not very compact, because

superfluous data may be placed into the metafile—data that

records intermediate pictures between those pictures of value to

the program.

Audit trails are particularly well suited as graphical

restart/recovery mechanisms. The GKSM can be activated

concurrently with, say, the graphics display screen. As commands

are issued to the GKS workstations to cause picture elements to

appear to the operator, they are also captured in the GKSM. If

the program were to be aborted unexpectedly, the GKSM could be

interpreted at the beginning of the next session to cause the

previous picture to be recreated and tjhe GKS system to be placed

into the same state that it was in when the program terminated

abnormally.

1.9 Symbol Library

Many graphical applications, especially in the CAD/CAM area, need

to start with a collection of graphical symbols that can be used

by the operator to build up more complex pictures and drawings.

Rather than have the application create these standard symbols

from scratch each time a new session starts, it is faster and

more convenient to be able to read in the symbol definitions from

some external source. Depending upon how these symbols are to be

used by the application, a variety of metafiles can be used for

this purpose.

In general, the metafile used is a function of the kind of

graphical manipulations needed by the application or allowed by

the underlying graphics support system. If the system is GKS, a

CGM or a GKSM can be used to store symbol instances used to load

a symbol library. Each CGM picture or each GKSM segment can

correspond to a symbol that can be stored in the Workstation

Independent Segment Storage of GKS.

If the underlying system is PHIGS, the application is probably

using the PHIGS centralized Structure Store for both viewing and

modelling of the graphical elements. The PHIGS Archive File

mechanism has been designed to allow the saving and restoring of

complete structure networks from the Structure Store. PHIGS

89
defines a complex set of rales for resolving what happens if

structures are saved into Archive Files when the networks are not

completely defined, and what happens if structures are retrieved

from Archive Files when the Structure Store already contains a

structure of the same name.

If the application is dealing with product databases, it may be

necessary to load an entire database prior to allowing the

operator to start interacting with the application. But IGES and

PDFS files can be very large, with complex interrelationships

specified within the file; consequently, they are often

unsuitable as symbol libraries which would be loaded each time

the program is run. Instead, non-standardized, proprietary

product databases may be linked into the application when it is

initialized.

In sum, any product or graphical picture file format can serve as

a symbol library. The appropriate file format to use depends on

the application and the underlying graphical system on which the

application is built. For portability of symbol libraries, the

PHIGS Archive File and CGM offer the best solution, while

maintaining good performance and size characteristics.

90
2. NBS ROLE IN COMPUTER GRAPHICS STANDARDS

NBS*s role in graphics standards encompasses the following areas:

o Active participation in voluntary standards committees

o Promulgation of FIPSs (Federal Information Processing

Standards)

o Development of test methods for graphics standards

o Registration authority for the ISO

2 . 1 Participation in Voluntary Standards Groups

NBS has been a member of the Accredited Standards Committee X3H3-

which is responsible for computer graphics standards-since X3H3's

inception. Since the federal government is the largest single

user of computer software, NBS's objective is to represent the

interests of federal agencies to the committee. Since X3H3’s

membership is primarily computer graphics vendors, this

representation also serves to help balance the representation

between vendors and users.

In the past, NBS*s technical contributions to X3H3 were primarily

in language binding. An NBS representative chaired the X3K3

Language Binding Task. Group, and initiated the bindings of the

Graphical Kernel System to Fortran, Ada, C, Basic, and Pascal.

An NBS representative currently serves on the Formal Description,

Validation and Testing Task Group within X3H3 and its counterpart

within ISO TC97/SC21/WG2 to pursue interests in graphics

standards validation. An alternate X3H3 member from NBS

participates in the PHIGS Task Group. PHIGS is of great interest

to NBS because it is intended for use with CAD/ CAM applications,

and is thus of great importance to DOD, NASA, and many other

federal agencies.

2.2 Promulgation of FIPS

As needed standards emerge from committees, the process of

adopting them as FIPSs begins. GKS was adopted as a FIPS in

April 1986. Before a standard becomes a FIPS, its effect on

federal agencies is thoroughly analyzed. Furthermore, because of

its limited staff, ICST must concentrate on computer standards

that have the largest impact. Thus, only the most beneficial

voluntary computer standards actually become FIPSs. FIPS GKS is

the first FIPS for computer graphics and reinforces the key role

computer graphics has in federal operations.

Proposed FIPS have a public review period similar to the ANSI

public review period, in which state and federal government

agencies comment on the proposed FIPS. Currently, CGM has just

91
completed this pxiblic review cycle in the FIPS process, and is

expected to become a FIPS in late 1986.

2.3 Test Suite Evaluation

In 1982 the European Economic Community (now called Commission of

the European Communities, or EC) sponsored a workshop in

Rixensart, Belgium, to bring together all parties interested in

contributing to the development of routines to test for

conformance to ISO GKS. The design and coding for some of these

routines began shortly thereafter. Most of the actual

programming was done at Leicester University in the UK and the

Technical University in Darmstadt, West Germany. The US, France,

and other countries attended subsequent workshops to review these

efforts.

The test suite developed in Europe contains several limitations.

Tests have been developed only at the application and operator

interfaces. Only selected levels of the standard have been

tested, and the tests that exist are written in Fortran and test

only for Fortran bindings to the standard. Additionally, no test

plan was developed to evaluate the accuracy of the suite.

At present NBS has acquired the European GKS test suite from

Gesellschaft fur ’ Mathematik und Datenverarbeitung MBH (GMD) , a

research institute in West Germany that is distributing the suite

within Europe. An agreement between NBS and GMD authorizes NBS

to distribute the test suite to companies in the US and Canada.

Participating companies provide feedback to NBS concerning the

quality and utility of the tests. Currently, 30 companies have

signed agreements with ICST to participate in evaluating the test

suite.

At the international level, the EC is funding an effort to

develop a harmonized graphics standards test suite and testing

service throughout Europe. Organizations in the UK, West

Germany, and France are the siibcontractors for the EC in this

effort. The US is participating in this effort through the ISO

TC97/SC21/WG2 Validation and Testing Rapporteur Group, and will

forward the US companies* evaluation of the test suite to the EC.

2 . 4 Registration

All proposed and anticpated standards emerging from ANSI X3H3 and

its international counterpart ISO TC97/SC21/WG2 share certain

classes of graphical items that are allowed to vary across

implementations of the standard. Line type is an example of such

a class. Four mandatory line types are required in GKS and CGM,

and the values 1,2,3, and 4 are reserved for them; line-type

values 5 or greater are implementation defined and are reserved

92
for registration. The other classes of graphical items to be

registered are marker type, hatch style, text font usage, prompt

echo type, error message, escape, and GDP (graphics drawing

primitive) . The purpose of registering these implementationdefined graphical items is to encourage implementors using the

same graphical items to reference them in the same way. The

purpose of the register is to inform all concerned of items

already registered, and of the specific identifiers assigned to

them.

NBS was selected by ISO as the registration authority for

graphical items. NBS’s responsibility is to maintain a register

of the names and meanings assigned to these graphical items. NBS

will receive proposals from various sponsoring bodies for

meanings to be assigned to graphical items. It will coordinate

the acceptance or rejection of these proposals with ISO TC97/SC21

and assign identifiers to the proposals accepted. NBS will then

make the information in this register available to all interested

parties.

93
3. STATUS OF GRAPHICS STANDARDS

3.1 At the International Level

NBS participated in the meeting of the ISO TC97/SC21/WG2 Formal

Description Validation and Testing Rapporteur Group (FDVT Rap

Group) held March 8-16, 1986 in the U.K. The European Community

has subcontracted efforts to convert GKS Level 2B tests to the

programming language C (effort to take 12 months) ; development of

CGM tests (effort to take 18 months) ; and development of GKS-3D

tests (effort to take 24 months) . The progress of this work will

be monitored closely. In addition, there are missing pieces in

this work which are not funded at the present time. In

particular, test routines for PHIGS and CGI, and the conversion

of GKS tests to Pascal and Ada are not being pursued.

NBS is trying to ensure that one coordinated set of graphics test

routines is developed for all graphics standards. As part of

this effort, NBS is currently distributing the test routines for

GKS received from West Germany to companies in North America,

asking for feedback concerning the quality and utility of the

tests from the implementations.

Members of this International committee have initiated a plan for

a series of international workshops on ‘Applications of Graphics

Standards. ' The plan calls 'for these workshops to be cosponsored by NBS and Eurographics (and perhaps other* European

organizations) . The first workshop is tentatively planned to be

held at NBS in September 1987. Future workshops are planned at

yearly intervals, concentrating on CGM and GKS -3D, rotated among

the U.S.,the U.K., and West Germany. These conferences will

concentrate on scrutinizing implementations of the graphics

standards

.

The current status of the graphics standards in the international

arena is as follows:

Standard Status Document

GKS International Standard ISO 7942

GKS-FORTRAN DIS Text produced DIS 8651/1

GKS-PASCAL DIS Text almost produced DIS 8651/2

GKS -Ada 2nd DP ballot closes Apr 16 DP 8651/3

GKS-C Circulate 2nd WD soon WD

Register as DP in Sept 86 (SC21/N669)

GKS-3D DIS Text produced by July 86

GKS-3D-F0RTRAN Circulate now for DP ballot WD

Register as DP in Sept 86 (SC21/N620)

GKS-3D-PASCAL Not started yet

PHIGS ISO WD

PHIGS-FORTRAN Circulate 2nd WD soon WD

Register as DP in Sept 86 (SC21/N667)

94
standard

PHIGS-Ada

Status Document

CGM

CGI

Circulate as DP soon

Register as DP in Sept 86

Published mid 87

ISO WD

WD

(SC21/N668)

DIS 8632/1-4

Note: There are four formal development stages within ISO:

WD = Working Draft (1st)

DP = Draft Proposed Int '

1

Standard (2nd)

DIS = Draft Int'l Standard (3rd)

IS = Int*l Standard (4th)

3.2 At the National Level

The current status of the national graphics standards efforts is

as follows:

Standard Status Document

GKS

GKS-FORTRAN

GKS-PASCAL

GKS-Ada

GKS-C

GXS-3D

GKS-3D-F0RTRAN

PHIGS

PHIGS-FORTRAN

PHIGS-Ada

PHIGS -C

CGM

CGI

National standard «ANSIX3.124

1985

National standard ANSIX3 .124.1

1985

dpANSIX3.124.2

dpANSIX3.124.3

Begin processing as dpANS

June 86

2nd Public review Fall 86 dpANSIX3.144

Recommended as dp by X3H3 X3H3/85-63

1st public review this summer

X3H3/86-43

Working draft X3H34/85-82

Published as ANS this summer dpANSIX3.122

X3H3 Letter Ballot on ISO WD

95
3.3 At the Federal Level

The status of graphics standards in the FIPS (Federal Information

Processing Standards) arena is as follows:

Standard Status Document

GKS

CGM

FIPS FIPS 120

Public Review over

Secretary package

in Preparation

96
APPENDIX 2

FEATDKE COMPARISONS AMONG GRAPHICS STANDARDS
>; -i A,::.'^f-^'!A4{^

%-4iivJer4» io xJ^m FIPS (F«ti#ral Inforaatiqit

^diilair :>tindU8i,'-'«3) ^r«n4' i* XoXiw«; f

SI,

'1

4

(:,'l'..'i t H'.s'

; "fBPtr'V '

' ^ PlOSliC over,

r P*«par»tt03

Docmiiri:

' V? *^3S ^ FXPa lao

V -jfT, Kjirir r 1-^ -

. Ti- ;*% * 4?’

t XiaU2H^

mk .., 4^:f--.r1? ii'..'"'

'

' ,. ^'

,p(KP i ^ I

BoJuaiiATE zsxsWD sw:*"'* E»c«ixA5?K» ajitrtAn

.n

I-

' t< a;

>J.'* >'i.l^V?

i,. |7

-

-a-

'.*.% /!**'*

i t*. . . 1

... *, .. ! ± \

• AtflE.j,.'.. V'’ iOr..:’ jflPHNPWi^ : 'liS^ - ’ . : .*

tf

fr.

: k . i

' ii' JuJ . 41^,.^

. V ><
APPENDIX 2

FEATURE COMPARISONS AMONG GRAPHICS STANDARDS

Generic Functions

Graphics System Management Functions

Open

Close

Activate Workstation

Deactivate Workstation

Virtual Device Management Functions

Initialize

Reset to Defaults

Terminate

Make Picture Current

Set Deferral Mode

Clear View Surface

Background Colour

File Delimiter and Descriptor Elements

Begin File

End File

Begin Picture

Begin Picture Body

End Picture

File Version

CGI CGM GKS GKSM PHIGS ARCH

k

it

it

* *

k ^

k

k k k

k

Q . k

O *

* k k

k k

1 i I

* k k

k k k

k k

k

k k

k * - *

93
Generic Functions CGI CGM GKS GKSM PHIGS ARCH

File Description

File Elements List

File Defaults Replacement

Metafile/Archive File Functions

Open Archive File

Close Archive File

Write Item to Metafile

Archive Structure Networks

Archive All Structures

Set Conflict Resolution

Get Item from Metafile

Retrieve Structure Networks

Retrieve All Structures

Read Item from Metafile

Interpret Item

Delete Structures from Archive

Delete Structure Networks from Archive

Delete All Structures from Archive

Coordinate Space Control Functions

Window

Viewport

Normalization Transformation

VDC Type o

VDC Precision for Integer Points

VDC Precision for Real Points o

•k

•k

k

•k

O

*

*

*

99
Generic Functions CGI CGM GKS GKSM PHTGS ARCH

VDC Extent * Device Viewport * * Device Viewport Specification Units Q

Device Viewport Specification Mapping Q

Clip Rectangle * * * * Clip Indicator * * * 1 Error Functions

Pop Error Stack o - - - Empty Error Stack o - - « Emergency Close System k - * - Error Handling * - Error Logging - * -> * Error Handling Mode - k

• Miscellaneous Control Functions

Integer Precision o k 1 Real Precision o k 1 Index Precision o k 1 Colour Precision 0 k ? Colour Index Precision o k ?

•

Maximum Colour Index * k

Character Coding Announcer o k

Message o k * * Application Data o k * * * Escape it k * * * Output Functions

100
Generic Functions

Polyline

Disjoint Polyline

Circular Arc 3 Point

Circular Arc Center

Elliptical Arc

Polymarker

Text

Restricted Text

Append Text

Polygon

Polygon Set

Rectangle

Circle

Circular Arc 3 Point Close

Circular Arc Center Close

Ellipse

Elliptical Arc Close

Cell Array

GDP

Attribute Functions

Line Bundle Index

Line Type

Line Width

CGI CGM GKS GKSM PHIGS ARCH

O

*

o

*

*

o

k

O

Line Colour

Line Representation

101

o
Generic Functions

Marker Bundle Index

Marker Type

Marker Size

Marker Colour

Marker Representation

Text Bundle Index

Text Font Index

Text Precision

Character Expansion Factor

x:haracter Spacing

Text Colour

Character Height

' Character Orientation

Text Path

Text Alignment

Character Set Index

Alternate Character Set Index

Text Representation

Fill Bundle Index

Interior Style

Fill Colour

Hatch Index

Pattern Index

Fill Reference Point

Pattern Plane

CGI CGM GKS GKSM PHIGS AR<

•k k * * * *

•k k * * *

O k f e * *

k k * * *

O * * *

k k * k k

O k 1 1 k *

* k 1#

1• k k

o k k * k k

o k k k k k

k k k k k k

k k k k k k

Q 1•

1e k k

O * * k k

1 k ' k k

o *

o

o k k k

k k k k

o k k k k

o k k k k

o 1 f« k k

o * 1 1• k k

o k * k k

* * k k

102
Generic Functions CGI CGM GKS GKSM PHIGS ARCH

Pattern Table o k k

Pattern Size o * 1 * * Fill Representation o k * k

Edge Bundle Index k 3 3 k

Edge Type * 3 3 * k

Edge Width o * 3! 31 k k

Edge Colour * 3 3 k

Edge Visibility o k 3 3 k k

Edge Representation o 3 3 k

Add Names to Set k k

Remove Names from Set k k

Output and Attribute Control Functions

Scaling Mode • k

\ Colour Selection Mode o k

Colour Value Extent o k

Auxiliary Colour o k

Transparency k

Colour Table o k 1 1 1 Line Width Specification Mode o k

Edge Width Specification Mode o k

Marker Size Specification Mode o k

Aspect Source Flags * k 1 k

Font List o k

Character Set List o k

Begin Figure o

103
Generic Functions

End Figure

Close Pari:ial Figure

Implicit Edge Visibility

Set Colour Model

Modelling Transformations

Local Transformation

Global Transformation

Translate

Scale

Rotate X, Y, or Z

Rotate

Define Coordinate System

Compose Matrix

Transform Point

Viewing Functions

View Index

View Representation

View Matrix

View Mapping

View Reference Point

View Plane Normal

View Up

HLHSR Identifier

HLHSR Mode

Evaluate View Matrix

CGI CGM GKS GKSM PHIGS ARCH

o

o

o

*

*

*

3

3

3

3

•k

*

*

*

*

*

k

I

*

*

k

k

k

k

3 3

3 3

3 - *

104
Generic Func-tions CGI CGM GKS GKSM PHIGS ARCH

Evaluate Transformation Matrix

Accumulate Transformation Matrix

Segment/Structure Manipulation Functions

Request Segment Identifier o

Open Segment * Close Segment * Copy Segment o

Delete Element/Range/Between Labels

Delete Segment * Delete All Segments o

Empty Structure

Execute Structure

Label

Set/Offset Element Pointer (at Label)

Rename Segment * Change Structure (Identifier and) References

Redraw Segment (Post Root) * Redraw All Segments * Update o

Implicit Segment Regeneration Mode * Copy Segment to Workstation

Associate Segment with Workstation

Insert Segment

Segment Attribute Functions

Segment Transform *

*

•k

k

I

*

k

k

I

k

k

k

k

k

k

k 1 * • 1k

k

k k

k

k

k k

k

k

k

k

I

* *

I

I

I

I

t

* I

105
Generic Func-tions CGI CGM GKS GKSM PHIGS ARCH

Segment Visibility * Segment Highlighting •k Segment Display Priority

Raster Functions

•k

* Pixel Array * Mapped Bitmap Foreground Colour O

Create Bitmap * Delete Bitmap

Select Drawing Bitmap * Display Bitmap * Two Operand Bitblt . * Tile Two Operand Bitblt k

Tile Three Operand Bitblt O

Drawing Mode

* * Ie * * i *

KEY TO ABBREVIATIONS AND SYMBOLS

COLUMN HEADINGS: GKS = Graphical Kernel System

GKSM = GKS Metafile

CGI =s Computer Graphics Interface

CGM = Computer Graphics Metafile

PHIGS = Programmers' Hierarchical

Interactive Graphics System

ARCH = PHIGS Archive File

SYMBOLS; * » required in the standard

0 = optional in the standard

1 = not exactly the same as in CGI (if GKS)

or as in GKS (if PHIGS)

- =s inappropriate function for that standard

3 = in GKS-3D only (not in GKS)

106
'jM KSSi s&H i22

/ # ' i

-j

. u 'i ^ rrjcriisfonMitlcr. utnr

j • •

V*’r'^«i;,..ut« ton t if

\^i-^rt functlena

z^iim

isi

; pniJdplitfpiH in<^np*a

\tfiiol'3‘J v*lq»fb ^nMtpea |

r^'^u c Xd4mt4^i««

Q{}«n M#iiiin"

CIodM S4»^«nt

mnol^nJJ\ ZL^uk^

XfiTtX 1«)£ASQ

- W w I atioXoD l)fix/OTp«ol qcisztlS bmqqsH ^

* • qetsSia ^

y^; . - .

,• •

' '’ ^

«s«nt /Rtnq9/ c« ti#«or. t-*

I >

q6£Jl8

«

q«jL:?lfl palvB-jQ lo#X#8

’ « • *

Sipty aLTMCtm

.) » ^

' st.;-L'ct:ur«

#

*

qms^XB yBlq^XQ

^r<±ti8 bnJrrfiK|0 >vT ^

Ir"' *»i ileWia bofft^qO enrtj #JxT , » *-‘5 axdaia-'bnMasja a»^irf!P »-i !:?

A i

%' 'ii'

'

„ T'^ ‘ •itfOM p(^w«:xO

E9kt^0tt^mt: Kl«ont PoiT;£«r f:it:

"ta

' char^q* JitfTactujr* (Id«ntlfi«r Antf) Jrtiricii*

a«9itt«nt (Post Rood &JWX3fS SWOTi TAI VSfifla^'

s*ount4W4cY& loifaoX looirtqxnr' • ;8J5^aa3H

• iiSe^sM exo - K8»i>

. aOii'afOr.T ’ssii3qt.-l» aojaqo*^ “ loa * oilSs^eM aoxrfqxisO is^jqooO • KM,

-—-- '^vrimaaunpo^ " 30IMq ..*{ ^ > —' ' 1 * ‘AT^i^nNK " KW ‘ — — ' " ^ n. ^ Barova eoiilqMD •vlto^'SOJnl

CO|^ .1»1}»•I:^• ' .-ly^X-ri? avXxfcixA BOIIPI • **^**'-

'-i^i

4U«o<;t *t<s t

*’ ^ at iBZiiupn

*‘ b'X6bfte:Js •fU ni Ir^toXc?qa • o

It.s«rt XDD ni «» »»« bsUJ-

on

.

'

, ii> oi e* «

^ noi:torm:t ««i-xqMqq*iti - -

, i .^ji9 lii ;fo(t ) \ iiio C t rti • • 9«- :a*»oxt T-TJifL'^fom ^ # i ^ ,

-f A
APPENDIX 3

IGES ENTITIES AS RENDERED BY GRAPHICS STANDARDS SYSTEM

APPENDIX 3

IGES ENTITIES AS RENDERED BY GRAPHICS STANDARDS SYSTEM

This Appendix describes each of the IGES entities in turn, noting

how well these entities could be rendered by a system based upon

the graphics standards.

1 . Geometric Entities

CIRCULAR ARC. Not available in GKS/PHIGS. Present as CIRCLE and

3 -POINT ARC in CGI/CGM.

COMPOSITE CURVE. Rendered by POLYLINE in GKS/PHIGS; by POLYLINE,

ARC, and ELLIPTICAL ARC in CGI/CGM. The full conics and splines

of IGES are not directly supported, but would have to be

approximated by POLYLINE.

CONIC ARC. Not available in GKS/PHIGS. Present as CIRCLE,

ELLIPSE, 3-POINT ARC, and ELLIPTICAL ARC in CGI/CGM. Parabolas

and hyperbolas are not directly supported.

COPIUS DATA. Directly available as POLYLINE with different line

types

.

PLANE. Unbounded planes need no direct visualization. Bounded

planes correspond to POLYGON SET in GKS/PHIGS/CGM and are

supplemented by CLOSED FIGURE in CGI.

LINE. Available as a two-point POLYLINE.

PARAMETRIC SPLINE. Can be visualized by lines, arcs, etc.

However, information adDout the shape is lost.

PARAMETRIC SPLINE SURFACE. Can be visualized by rectangles,

lines, arcs, etc. However, information about the shape is lost.

POINT. Available as POLYMARKERS for pre-defined symbols and

positioned SEGMENTS (GKS/CGI but not CGM) or STRUCTURES (PHIGS)

for user-defined symbols.

RULED SURFACE. Can be visualized by lines, etc. However,

information about the shape is lost.

SURFACE OF REVOLUTION. Can be visualized by lines, arcs, etc.

However, information about the shape is lost.

108
TABULATED CYLINDER. Can be visualized by lines, arcs, etc.

However, information about the shape is lost.

TRANSFORMATION MATRIX. Really used like an attribute in IGES.

Also special form numbers are used with certain contructs for

Finite Element Analysis and viewing. Closely related to SEGMENT

TRANSFORMATIONS of GKS and PHIGS transformation matrix structure

elements used for modelling and viewing. No direct parallel in

CGI or CGM.

FLASH ENTITY. In GKS, only have POLYMARKER or segments to

realize the forms. In CGI/CGM, you also have CIRCLE and

RECTANGLE. IGES flash entity form 4, rounded rectangle, is not

directly available in any of the graphics standards.

RATIONAL B-SPLINE CURVE. Can be visualized by lines, arcs, etc.

However, information about the shape is lost. Parabolas and

hyperbolas not directly supported by the graphics standards.

RATIONAL B-SPLINE SURFACE. Can be visualized by lines, arcs,

etc. However, information - about the shape is lost. Parabolas

and hyperbolas not directly supported by the graphics standards.

OFFSET CURVE. Can be visualized by lines, arcs, etc. However,

information about’ the relationship between the two entities is

lost.

CONNECT POINT. Can be visualized by lines. However, information

about the relationship between the entities is lost.

NODE. Not directly visualized, so no need for support from the

graphics standards. However, not unlike a PHIGS structure label.

FINITE ELEMENT. Thirty-three topologies are currently defined by

IGES version 3 . All can be visualized using the graphics

primitives of line, arc, ellipse, etc. , with loss of information

concerning the relationships between the lines and curves making

up the wire-frame model. Furthermore, the IGES specification is

much more compact.

NODAL DISPLACEMENT AND ROTATION. These are attributes that are

used to communicate finite element post processing data.

OFFSET SURFACE. Can be visualized by lines, arcs, etc.

However, information about the relationship between the two

entities is lost.

CURVE ON PARAMETRIC SURFACE. Can be visualized by lines, arcs,

etc. However, information about the relationship between the

curve and the surface is lost.

109
TRIMMED (PARAMETRIC) SURFACE. Can be visualized by lines, arcs,

etc. However, information about the relationships among the

boundary lines and other curved lines used to represent the

surface is lost.

ANGULAR DIMENSION. Visualize using text, lines, arrows, and

arcs. Only arrows not directly supported in the graphics

standards. See discussion under LEADER entity below.

CENTERLINE. Use graphics circles (in CGI/CGM) only and special

line types. Could be made available in GKS/PHIGS through special

marker types.

DIAMETER. Visualize using text, lines, arrows, and arcs.

FLAG NOTE. Visualize using text and fill area (polygon)

primitives

.

GENERAL LABEL. Visualize using text, lines, and arrows.

GENERAL NOTE. A general note entity consists of one or more text

strings. Each text string contains text, a starting point, text

size, and angle of rotation of the text. A single font number

applies to the whole note and incorporates the separate concepts

of type face (appearance of the characters; e.g., bold Helvetica,

italic Futura) amd character set (shape of the characters; e.g.,

ASCII, German National Set, Math, Greek) . Only 7-bit character

codes are supported. In addition, a form number is used to

designate the layout of the (possibly multiple) text strings, .the

justification of the strings within a text rectangle, and whether

there are sxibscripts, superscripts, fractions, and embedded font

changes. The GKS/PHIGS TEXT and CGI/CGM TEXT, APPEND TEXT, and

RESTRICTED TEXT primitives with their numerous text attributes

are capable of visualizing any general note entity. With

RESTRICTED TEXT and APPEND TEXT, CGI/CGM are a bit more capable

than GKS/PHIGS.

LEADER. Eleven arrow head types are specified in IGES version 3.

Although all can easily be rendered using more primitive lines

and polgons, the information that the arrowhead belongs with the

leader line is lost when described using graphics standards

primitives

.

LINEAR DIMENSION. Visualized using text, lines, and arrows.

ORDINATE DIMENSION. Visualized using text, lines, and arrows.

POINT DIMENSION. Visualized using text, lines, arrows, circles,

and polylines/polygons (hexagons)

.

110
RADIUS DIMENSION. Visualized using text, lines, arrows, and

arcs.

SECTION. Visualized using FILL AREA with HATCH patterns. Of the

eight pre-defined IGES patterns, two correspond to CGI/CGM hatch

patterns; namely, IGES form 31 is CGM hatch style 3 and IGES form

37 is CGM hatch style 6.

GENERAL SYMBOL. Visualized using text, lines, arrows, etc., and

possibly grouped in SEGMENTS (GKS or CGI but not CGM) or

' STRUCTURES (PHIGS)

.

SECTIONED AREA. Visualized with POLYLINE and FILL AREA in

GKS/PHIGS/CGM and also using CLOSED FIGURE with fill in CGI.

However, the IGES representation is generally more compact,

because there is control over the angle and spacing of the lines

that make up the cross-hatched fill pattern. In these cases, the

DISJOINT POLYLINE element of CGI/CGM may help. In its default

state, IGES line pattern code 1 corresponds to CGM hatch style 3,

line pattern code 16 to CGM hatch style 6, and line pattern code

18 to CGM hatch style 5.

WITNESS LINE. Visualized using POLYLINES, although the DISJOINT

POLYLINE of CGI/CGM may be useful in certain special cases.

ASSOCIATIVITY DEFINITION. Defines the relationship among

entities. These relationships are lost in CGM, occasionally can

be represented by GKS/CGI segments, and with somewhat greater

likelihood can be represented by PHIGS structures.

ASSOCIATIVITY INSTANCE. Many predefined associativity

relationships exist in IGES. These include simple and ordered

GROUPS (both doubly linked and forward-only linked entities)

,

external references and external reference files, labels, and

parent-child structures. These have some parallels in PHIGS

structures, but in general need not be directly handled by a

graphics viewing system like CGI/GKS. Likewise, the PLANAR and

FLOW instance types do not require direct support from the

graphics system. The VIEWS VISIBLE and VIEWS VISIBLE, COLOR,

LINE WEIGHT instance type have an effect on the visualization of

the IGES model. The necessary controls for proper visualization

are available in the graphics standards, using viewports, color

tables, and line width specification mode. Finally, the

DIMENSIONED GEOMETRY instance type has already been discussed in

Section 1 above, under the separate elements for ANGULAR

DIMENSION, LINEAR DIMENSION, POINT DIMENSION, DIAMETER DIMENSION,

RADIUS DIMENSION, and ORDINATE DIMENSION.

Ill
DRAWING. A drawing is a collection of annotation entities and

views. Multiple drawings can be included in a single file.

Drawings have names and size; units may be specified for the

drawing. A drawing closely corresponds to a CGM or to any image

displayed on a graphics view surface by any of the programmer

interface standards: GKS, CGI, or PHIGS.

LINE FONT DEFINITION. Two types of line fonts may be defined.

One type considers a line font as a repetition of a basic pattern

of visible-blanked segments superimposed upon a straight line or

a curve. The other type considers a line font as a repetition of

a template figure that is displayed at regularly spaced locations

along a planar anchoring curve. None of the graphics standards,

at present, support user-defined line types; the type 1

capability would have to be visualized by POLYLINE (in GKS/PHIGS)

and DISJOINT POLYLINE (in CGI/ CGM) ; the type two capability by

using segments or structures in PHIGS/GKS/CGI and only lines,

rectangles, etc. in CGM.

MACRO CapcdDility. This facility allows the IGES specification to

be extended beyond the common entity subset, utilizing a formal

mechanism which is a part of the IGES Specification. This

facility is available in an extremely limited fashion in the

graphics standards as ESCAPE and GENERALIZED DRAWING PRIMITIVE

(GDP)

.

PROPERTY. This facility is available in the graphics standards

as APPLICATION DATA and MESSAGE. Many engineering specific

properties are defined in the IGES specification. A few of them

correspond to graphics elements, generally useful for rendering a

picture. These are Region Restriction, Hierarchy (partial)

,

Name, Drawing Size and Drawing Units.

SUBFIGURE Definition. All such relationships can be visualized

fairly straightforwardly using PHIGS structures, somewhat more

difficultly using GKS and CGI segments, and much more difficultly

in CGM.

TEXT FONT Definition. This IGES facility provides for the

exchange of font definitions, which are limited to a model of

the motion of an imaginary pen moving between the points of an

integer Cartesian "font coordinate system." None of the graphics

standards provide support for "user-defined" fonts. However,

such a stroke-precision text capcibility can easily be built on

top of all the graphics standards. Compactness of

representation is lost, but speed of picture generation should

not be much worse.

112
VIEW ENTITY. This IGES entity defines a framework for specifying

a viewing orientation of an object in three dimensional model

space. The framework is also used to support the projection of

all or part of model space onto a view plane. One type of

projection, an orthographic parallel projection, can be

specified. Clipping to a view volume is supported.

The 3-D graphics standards, GKS-3D and PHIGS, have a much richer

viewing model. They allow a full 4x4 transformation matrix to be

used., thus obtaining perspective projections and various oblique

parallel projections as well.

EXTERNAL REFERENCE ENTITY. PHIGS Archive Files would directly

support this element. The other standards (GKS/CGI/CGM) would

have to do a lot more processing to directly support this

feature.

NODAL LOAD/CONSTRAINT ENTITY. A special element to support

Finite Element Modelling.

COLOR DEFINITION ENTITY. Not directly available in GKS/PHIGS,

but is present in CGI/CGM as the MAXIMUM COLOR EXTENT element.

In GKS/PHIGS, the application would query the workstation

description tables to gather sufficient information to adjust for

this entity before rendering the picture with a graphics system..

TEXT DISPLAY ENTITY. See the earlier discussion under the IGES

GENERAL NOTE ENTITY. The attributes of text include height and

width, font index, slant angle, rotation angle, mirror flag, and

horizontal/vertical text path. All such entities can be

correctly displayed by a proper setting of the graphics standards

text attributes, which are common to PHIGS/GKS/CGI/CGM.

113
APPENDIX 4

CORRESPONDENCE BETWEEN PDES ENTITIES

AND GRAPHICS ELEMENTS
T - r 

t-

,^n

aSiF .4DPnf/C?trT •

.*:

*«'«

iP^Udlirv'-

tKS t fr*»«.w*-0*flc ' for- jipftClltT»:<^

f.i;ft*‘.io;^ cf in t:lasi‘'-'« -itoa* ifc)«s«X'^' -

: ir^ttworH ^iJi W4N1 to tniqayp.y<» on tT -f ,oT:;,,t^o^i« ’ o?{t‘ a typ# or jIjb or^ ..jrtphlo pigr. lo- -tion, cm &«

f^cifiiod* clipping tr ^ |j[^ > pnortiid.

c"

^*'

'

. .

. '- ^-: Ttnif^cv •t44>i*‘ r'15 - ..if^ WXCM,. tmv^ a m>ch ricft^d?

vHvi .,o ^ fixil 'X4 »Atr4^

firritflv cbt’^i PbtJiiniiJVr f».. ;:r^;Ji;c"i^T5 v ^.-.Vgufe <

'^

p3'4'iiUil«iii- p;roj#6t.ioi%- os.*^ ^

'

' ' ' '

’ •_: mTrjrr'rT mfWnx

r WnWWt. ')tbva “t.o i1':l procaouv/vj ra •dlfACt.l'f ' osiippcr^ tjj

- ' •,'..7 7

* '

. ‘

’ . itteUiX. •'TTITT. A «p*clAl tS^ t.U-;;,-»ct

oit*n- >*c-» . .esr.

^'iA.w i»^,'*a<»*&c -!nt "fcxmia caifl* tXTiy:

’ts an’ 5!»*iiS, aW’g^' -TXX'Wi8ftqag*'«y <wfca»t*tion •;

j#«c»,^M-o,i tiiliCHi. to aarxici -:>'r i..tara*r4ion to Ciotbu •.-‘tipy ^ «M- ^awtaqiwa«BWpap»^ s ss 5T««»ojj

tr t

' STJkY japrtrf unci'!! tls*! t 'ES’i

C^TTTUlfc 'IWS !{»*";T/. tj>« I !!ri*»n’»» of . PMTt Vr^ludu A:-d

wlatn, f Vht ia<S»JC, »lMt.i*-.r:,n ^C» .^tiO« Uttgilo. Slrccx iHKft

'i*ontal/v«rt:ic«l triff p«"::3- All . . tia-* oaq o« c,^k

pprr.«kctlT *-spiAy^:i -

' aUMdasdii X

C4. . t ^tt:ri.2siitli<f

,

m'. till fil^A vc^iiAr 4|^x-7tiy,, ,v' (G^/CXrX'CW] ^ilXc^'X.

{froc>iouv/vq ra 4lt*ct.iy •J»ppcr^ ‘thtI

Ifot 111 <’tlQ5/OTl3tef^^

-s/ciiX/coH.

.

v^i^j

-^*- {l. -J-'•’*)’:

> '#1

if

>. k

f , : ..

.»f*-^ l‘ .-'•!.

• •»

- ‘"'Vf'-

. • i. - ..:j»;’,>-,ir5Jl..; '•. 'T-'t '',^.^*Wiii^'

•• ?/a , it'iv.

''X'Tli

,iS
APPENDIX 4

CORRESPONDENCE BETWEEN PDES ENTITIES

AND GRAPHICS ELEMENTS

1.

The PDES Viewing Pipeline

By design, the PDES viewing pipeline is modelled after that of

PHIGS. All coordinate systems—Local (i.e.. Modelling), World,

UVN, Normalized Polar Coordinates (NPC) , and Device—are

three-dimensional, right-handed

Cartesian systems. The PHIGS Composite Modelling Transformation

is provided by existing IGES entities. The Viewing

Transformation is defined by a 4x3 view matrix, whose components

may be specified by a view reference point, a view plane normal,

and a view up vector. The full view mapping is defined by

projection type (PARALLEL or PERSPECTIVE) , view plane distance,

view plane window, front and back clipping planes and indicators,

projection reference point, and NPC viewport. The final

Workstation transformation is specified using a Workstation

window and a device viewport.

2.

‘PDES Pictures

A PDES picture consists of a viewing operation, a workstation

transformation, line, text, and surface attributes, and a

so-called presentation list. The presentation list is a linked

list of blocks of PDES entities, each block of which can have its

own viewing operation, workstation transformation, and line,

text, and surface attributes. PDES pictures are analogous to

PHIGS structures

.

3.

PDES Text Model

The PDES Text Model is patterned after the CGI. The three

CGI/CGM text entities—TEXT, RESTRICTED_TEXT, and

APPEND_TEXT—and the nine text attributes—FONT, PRECISION,

EXPANSION_FACTOR, SPACING, COLOR, HEIGHT, ORIENTATION, PATH, and

ALIGNMENT—have been included in PDES. Unlike GKS and PHIGS, but

like CGI and CGM, the continuous text alignment values are

available.

4.

PDES Color Model

Unlike any of the graphics standards, the PDES color model

permits multiple color tables to be referenced by entities in a

single PDES Picture. There is a single, distinguished

115
BACKGROUND_COLOR associated with each color table. The color

table consists of indices associated with RGB triples. Th^

default colors for indices 1 through 8 are black, red, green

J

blue, yellow, magenta, cyan, and white.

5. PDES Line Attributes

The PDES line attributes—line width scale factor, line type, and!

color—are nearly identical to those of all the graphic3

standards. However, in PDES, the line type index is called

LINE__FONT and points to a LINE_TABLE where a repeating pattern ofi

bits indicates the desired line type. The default line types for|

indices 1 through 4 are solid, dashed, dotted, and dash-dotted.

6. PDES Surface Attributes

The PDES surface attributes consist of edge attributes andl

interior attributes. The edge attributes—edge visibility flag,|

color, edge type, and edge width scale factor—are taken directly

from CGI/CGM with the same generalization to repeating bit.

patterns as for line type. The interior styles available includel

HOLLOW, SOLID, PATTERN, HATCH, and EMPTY—exactly those available"

in CGI/CGM. There is a pattern table and a hatch table. The

pattern table includes pointers to the pattern attributes ofl

pattern size, pattern reference point, pattern plane vector, andl

pattern up vector—attributes equivalent to those in GKS-3D and

PHIGS. The hatch attributes are as yet unspecified, but ar^

likely to be such that the default hatch patterns are those

CGI/CGI, with an extension like that of line type to allow the

generator of a PDES file to specify exactly the hatch pattern. ,
APPENDIX 5

STANDARDS FOR SPECIFIC CALS APPLICATIONS
(

•

• %

*. .Jl,, eAC9i&l^t7KD_COOOR *.'« ^Ch ^olor

jonCtsts ct ihdlo«a vi*th aOB zrt^pl

Cwlorai for AjpwUjcm i>U:rtuga a blacv. *^6^4#

y<iliov, xaziqmhtJLr *a*4 vhit«.

VO'^S XJjcie^ kttriliXitmm

Th« POEa lin® ^ -:ltout€«—‘llfi# vl4tUi tfietoir. t

r^jl^^ndArda# Ho4«>v#rr In PQii. lin^i type ir^«x, la

«%• t*:^^»C)l<T #T>il polAt^ .? a %: rp, J^TAJX:: a ri^peatlixg pa.!j

li5<Ucat«® t.tia i«ilr#d i;z>5i Tb« dafault lina

4»^ioaa^l t^srWvTh ^Mtm rioIifl» djiatoiki, dotrad^ and 4asi!^'

d. ^PO£$ S'lrfa^ \ttrlriut,aa

>* . jito i'?jr

ku

rhja ’ POES aurfiurai sktxxV^tMw cmimimt ot ' mz^rn atrtxlXna^

inrarior arfcributea. TJia attjriJPataa«*<*«dd# ^l-ribliX'i

4,ojp, »^dga aadi.4^t2^ ald^A acala fiM?ror—*r« t;C<5n

• ' *' m, -m- ai

f

'

. -f .'. :raa leor/caff Vitt>.^^.« 7«n«7*H8i>‘ci(>n r£i><MC

<".S

ravtama as for Ilha zypm^ i:.t.arl'wr atyXaa araiX^la

n'XJU>«r, SOLID, PArraWf, KATt^f, Li5^tV--4xacrIy Uloae 51 in Thara tahia and a bated tabta<

pat''-*m tncIul4*I"JS3u4ra t<? tba m anrri

PHVrS, Tn« bat4iii attrlbutaa a« yat ur-xpaci04 d^

to ba SUCH r^jitr, Ui« ^.afault bacce. pattama ard

C02/CGX, an aarttf-naion ;ik.a that of lina typa to vM^--

gexiarator or PDB3 fKa to iroaolfy nxaetXy tbe hatch pattAj

fi*'

.'If I- - ^ m

1 :

»,'| /v .

i i

T. irf

: A'

rj

‘*^»'

Lr

? ir us
APPENDIX 5

STANDARDS FOR SPECIFIC CALS APPLICATIONS

Project: Title: Automated Technical Order System

Goals and Objectives: ATOS is • being implemented to improve

generation, storage, and distribution time associated with AF

TO's. A major goal is to significantly reduce the cost of AF

Technical Order acquisition and management.

Contact: Major Edd Higbee

Contact Telephone: (513) 257-3054 AV 787-3054

Contractor ( s) : Syscon Corp. ; San Diego, CA

Roc3cwell; El Segundo, CA

Acronym: ATOS

Technical Approach: ATOS is an automated publications system for

the storage, distribution, revision, and updating of Technical

Orders, documents that describe how to operate, maintain and’ use

equipment through narrative text and illustrations. The Phase I

Pilot Program installed at the Ogden Air Logistics Center (ALC)

consists of central processing units, micro- computer text entry

and editing workstations, CAD workstations for creation of

illustrations and diagrams, a document image composer and

phototypesetter. The system is used to develop change pages to

the TO*s managed by the Ogden ALC. This pilot system is

currently in operation at the Ogden ALC. Final steps have been

taken to upgrade the Phase I configuration and replicate the

configuration at each ALC and at the Aerospace Guidance and

Metrology Center (AEMC)

.

Phase II introduces contractor interface capability, further

enhancement to the individual configurations, and real time

electronic distribution of TO's to Technology Repair Centers

(TRC's)

.

Phase III implements electronic distribution to intermediate and

organizational maintenance shops at base level and provides the

overall system support to meet user needs.

Graphics Standards: CGM can be utilized for changes to pictures

within the technical orders. Presently, these changes are made

118
through the CAD/CAM systems and IGES could then be used to port

changes to different hardware (if heterogeneous hardware is

used) . However, some changes may be cosmetic, and personnel

making the changes will probably be graphics artists and not

engineers. Thus, it would not be cost effective or efficient to

use the CAD/CAM systens for these changes.

IRDS, SQL & NDL: There probably will be a need for an index to

the ATOS data. IRDS and/or SQL would be appropriate. Additional

information and analysis is needed to determine the extent to

which Technical Order and Change Order data is "structured” (vs.

lengthy text) . NDL or SQL may or may not be appropriate.

119
Project Title: Engineering Data Computer Assisted

Retrieval System

Goals and Objectives: The purpose of EDGARS is to make significant improvements in the quality, retrievability, and cost of

Engineering Data.

Contact: Capt. Cauldwell

Contractor: AT&T

Contact Telephone: (513) 257-3054 AV 785-3054

Acronym: EDGARS

Technical Approach: EDGARS is an automated system, similar in

concept to ATOS, for capturing, storing, distributing, revising

and updating the engineering drawing information currently stored

in manual and aperture card form. It is being developed jointly

with the Army’s Digital Storage and Retrieval Engineering Data

System (DSREDS) . A phased effort deals with the digitization of

selected existing engineering drawings as a prototype system to

provide drawing information to selected users. This will then be

extended to accept contractor’s, CAD/CAM data and new drawings

and eventually to provide CAD capability for revision of

engineering drawings and specifications. Two-dimensional drawings

only.

Graphics Standards: DSREDS/EDCARS is a homogeneous hardware

environment. Thus, graphics standards would only be applicable

for integration of DSREDS with other systems.

IRDS, SQL & NDL: IBM’s IMS database management system is

being used to develop a ’’central index” or directory to the 1.5

million drawings stored on optical disk storage. For

compatibility across the services, IRDS (or SQL/NDL) should be

planned for future implementations.
Project Title: Integrated Design Support System

Goals and Objectives: The IDS objective is to apply advanced

information management technology to integrate engineering data

into what will appear to the user to be a "single” data base.

IDS, therefore, will mesh with the Integrated Computer Aided

Manufacturing (ICAM) program, ATOS, EDGARS, UDB, IMIS and LIMSS.

Contact: T. N. Bernstein

Contractor: Roclcwell

Contact Telephone: (513) 255-6992 AV 785-6992

Acronym: IDS

Technical Approach: The IDS program is developing a prototype

system to allow the automated storage, retrieval, and transfer of

engineering data from design engineering through manufacturing to

maintenance and sustaining engineering. The IDS will develop a

computer software architecture to manage technical information

across the entire life cycle of a weapon systems including data

on "lessons learned" which can be fed back to the design function

for application to future weapon systems. (See demonstration

description in Section D.4.)

Graphics Standards: We haven't been briefed on this system yet.

Thus, no information concerning graphics standards is available.

IRDS, SQL & NDL: We haven't been briefed on this system yet.

Thus, no information concerning management standards is

available. IDS will use some of the IISS technology.

121
Project Title: Integrated Maintenance Information

System Program

Goals cuid Objectives: To promote effective aircraft maintenance

by enhancing capabilities of base level maintenance technicians

through tailoring information to support specific needs. IMIS

will provide a single interface to all required information and

will supplement on-aircraft diagnostics to provide full-fault

isolation capabilities.

Contact: Capt. John Von Holle

Contact Telephone: (513) 255-2606 AV 785-2606

Acronym: IMIS

Technical Approach: The IMIS was conceived to integrate the

information contained in Air Force ATI systems and to provide

access to it at the base level so that maintenance personnel can

effectively use it in the performance of their daily activities.

An extremely portable, ruggedized computer will provide the

technician with a single information source for all of the data

he needs to perform his job. The system will display graphic

technical instructions, provide intelligent diagnostic advice,

provide aircraft battle damage assessment aids, analyze in-flight

parauneter data, analyze aircraft historical data, and interrogate

airborne systems. It will also provide the technician with easy,

efficient methods to receive work orders, report maintenance

actions, order parts from supply, complete computer-aided

training lessons, and transmit messages throughout the

maintenance complex. The system will interface with larger

computer networks on the base, interface with on-board aircraft

systems, or operate independently for dispersed deployments.

The IMIS system will consist of four major subsystems: (1) A

technician’s portable computer, (2) An aircraft maintenance panel

connected to airborne computer/ sensors, (3) A maintenance workstation connected to ground-based computer systems, and (4)

Integration software which will combine information from the

multiple sources and present the data in a consistent way to the

technician.

Graphics Standards: Schematics are difficult on a small screen.

Concepts inherent in graphics standards , such as windows and

viewports would be very useful here.

IRDS, SQL & NDL: The AF is reviewing the content and

NDL & SQLformat of the Technical Orders. They plan to have

"automatic” cross- referencing/ indexing. IRDS or SQL may be

appropriate to store the results. Need more information on

Technical Order and maintenance data to determine if IRDS or SQL

are appropriate.

122
Project Title: Geometric Modeling Applications Interface

Goals and Objectives: The GMAP program will enable the digital

communication of product definition data describing air-cooled

jet engine turbine blades and disks throughout the entire product

life cycle including engineering analyses, manufacturing,

logistics, and depot support. GMAP objectives include: to

create a definition and model of engine blade and disk product

data; to survey the state-of-the-art geometric modeling systems

and application; to define the minimum requirements of a

geometric modeling system; and, to demonstrate the integration of

a prime contractor with its vendors and Air Force Logistics

depots

.

Contact: Lt. Robert A. Carringer

Contact Telephone: (513) 255-6976 AV 785-6976

Contractor: Pratt & Whitney

Acronym: GMAP

Technical Approach: To identify blade and disk definitions,

Pratt and Whitney will use the walk through technique. At every

activity or function in the life cycle of blades and disks, all

product description information will be collected. These data

will be organized and modeled into information classes of

entities. The entities will be installed in the PDDI system.

For data exchange, GMAP will expand the PDDI technology. The

PDDI system (exchange format, translator, access software, and

conceptual schema) will be updated to incorporate the results of

the blade and disk walk throughs. This new version of PDDI will

also be upgraded to enable the use of geometric modelers

throughout aerospace design, manufacturing, and logistics.

The implementation of GMAP will enable the defense industrial

base to eliminate the large quantity of paper drawings that are

created by computer aided design (CAD) systems. Air Force

acquisition offices and Logistics depots will be able to use the

digital data for their automated engineering manufacturing and

logistics systems.

Graphics Standards: The emphasis within GMAP and PDDI is on

product data vs. graphics data, or CAD/CAM, which emphasizes

geometry (line, arcs, circles) vs. CIM which emphasizes features

(hole, notch, bend) . This seems to eliminate the use of the CGM

for GMAP and PDDI unless a product definition database resides

behind the CGM. IGES and PDES are what's needed here. However a

way of getting graphical info from GKS to PDES would be useful in

"feeding" these systems.

123
IRDS, SQL & NDL: The IRDS is probably appropriate for the

Conceptual Schema. Need more information about the "information

classes” of entities/ features to determine if IRDS, SQL, or NDL

are appropriate. (Will use IDEFl* ER model and will need index

or catalog database.)

124
Project Title: Unified Data Base for Acquisition Logistics

Goals and Objectives: The objective of the UDB is to develop,

demonstrate, and evaluate a logistics information data base

system which will assist weapon system designers and logisticians

in incorporating logistics considerations into the early design

of weapon systems. The UDB will provide logisticians with a

flexible, efficient data base application system designed to ease

the burden of documenting iterative LSA tasks.

Contact: Ms. Janet L. Peasant

Contact Telephone: (513) 255-6718 AV 785-3871/6718

Acronym: UDB

Technical Approach: The requirements for an efficient logistics

support analysis data base application which also conforms to

MIL- STD-1388-2A will be analyzed. A data base management

software system will be selected and procured for installation on

a government computer. The data base management software will

then be installed on an Aeronautical Systems Division (ASD)

computer. A data base application will be designed, coded, and

tested. Demonstrations using actual and simulated weapon systems

logistics data will be conducted to test the quality and efficacy

of the software. The demonstrations will be conducted at

contractor computer facilities and at government computer sites.

The use of dedicated communication lines will be demonstrated.

Dial-up communication access will also be demonstrated. Both

government and industry logisticians and software engineers will

evaluate the initial data base to identify design flaws. The

identified faults will be corrected and enhancements such as

model interfaces will be identified and implemented. Prior to

technology transition, the operational organization will be

trained in the use of the system.

System outputs will include all LSA reports in compliance with

MIL-STD-1388- 2A including master files required for DoD

validations; LSA Control Number Master files. Task Narrative

Master file and Parts Master file; Interface to Logistics

Analysis models; Work Unit Code List; Support Materials list;

Reliability Maintainability Tracking Report and automated output

of Contract Data Requirements List (CDRL) items.

The UDB will improve the ability of the logistics engineer to

influence the weapon system design; create an acquisition

logistics data base management system which can be used by

government personnel and contractor personnel ; demonstrate the

benefits of linking logistics data bases with engineering design

data bases, specifically CAD and system test data bases;

eliminate the need for paper- intensive logistics documentation

125
systems; and improve data availability for interfacing with the

Air Training Command.

Graphics StcUideirds: There is a general need and a specific one

in UDB for graphical output of queries. This means that new

applications would have to be written to handle this if the dbms

can*t. If the dbms can handle graphics there must be a standard

interface between dbms and graphics. If the dbms can't handle

graphics, the new applications would have to use GKS, etc. to

ensure device- independence within UDB and also for interface to

other programs.

TRDS, SQL & NDL: They are currently using IDMS and IDD.

NDL & SQLTherefore IRDS and NDL or SQL would be appropriate to

enhance compatibility and exchange of data with other systems.

There is a need for a graphics interface to IRDS and the

appropriate database standard.

126
(

Project Title: Product Definition Data Interface

Goals and Objectives: The PDDI program will establish a digital I interface between engineering and manufacturing which replaces

the engineering part drawing. PDDI objectives are: to evaluate \ the Initial Graphics Exchange Specification (IGES) ; to specify | manufacturing informations needs from engineering; to create

prototype interface to exchange product definition data between i dissimilar systems in a factory and to demonstrate the program in

a production environment with in-house manufacturing systems and

commercial CAD/CAM Systems. PDDI seeks to lower the costs of

creating, managing and communicating part descriptions for

aircraft systems by allowing the data to be transmitted in a

standard, public domain format.

Contact: Lt. Robert A. Carringer

Contact Telephone: (513) 255-6976 AV 785-6976

Contractor: McDonnell/Douglas ^

Acronym: PDDI

Technical Approach: PDDI addressed the engineering to manufacturing interface for four (4) classes of airframe parts:

machined, composite, sheet metal, and turned. ' The product

definition data for these parts will encompass an estimated 90%

of the data types describing a typical airframe. The product

definition data was identified in a walk through process whereby

each manufacturing step required to produce the part was

evaluated to identify all product description information used.

The information was organized into a data model and file

^ specification. Software for manipulating the information was ‘ designed and built.

PDDI successfully demonstrated the transfer of complete product j definition data, the portability of the PDDI software, and the

use of product definition data in manufacturing. Demonstrations

of group technology classification and coding, computer aided

process planning, robotic programming, NC programming, composite

nesting, and interfacing to commercial CAD/ CAM systems were

presented to industry in September 1985.

PDDI is being modified to demonstrate the system for exchanging

composite and machined part models to Sacramento ALC*s composite

center and NC shop. Additional demonstrations will occur at

Vought*s Flexible Machining Cell.

Graphics Stcmdards: Same as for GMAP.

IRDS, SQL & NDL: Same as for GMAP.

127
Project Title: Integrated Information Support System

Goals and Objectives: To establish and operate a test bed to

validate the concept of Integrated Applications supported by an

Integrated Information Support System (IISS) in a heterogenous

computer and data base environment. In addition, the project is

using a set of interim standards and procedures to guide the

enhanced design of the IISS. The set of requirements established

from 1984 prototype and 1986 production implementation designs

will be the basis for enhancements to the IISS. The test bed

will serve as a technology transfer vehicle, training facility

and a central development site. The test bed realizing the full

benefits will also serve as a facility to assist the DoD

Community in achieving these benefits faster and with less risk.

Contact: David Judson

Contact Telephone: (513) 255-6976 AV 785-6976

Contractor: Boeing

Acronym: IISS

Technical Approach: It has been estimated that in large U.S.

corporations, most of the existing computer applications will be

redesigned over the next 10 to 20 years. It is further expected

that, because of the rapidly changing computer technology, the

construction techniques and operation modes of new application

will bear little resemblance to those of existing systems.

The Prime Contractors and coalitions to date have provided a set

of five principles as guides in formulating the IISS solution

which is extendible for the long-term trends. Individually, each

of these principles reflects state-of-the- art technology and has

been implemented in the integrated prototype IISS to yield a

functionally integrated system. These principles are stated as

follows.

1. The IISS is a key mechanism for integration of computerized

manufacturing. It defines, controls, and executes actions

affecting information among various functionally independent

subsystems, based on the use of common data.

2 . The IISS employs a coordinated data base approach to

support information resource msmagement of various application

systems in a closed loop environment within the manufacturing

enterprise.

3 . The IISS implementation strategy employs several stages of

date and application control.

128
4 . The IISS operates as a transaction oriented system

responding interactively to user commands.

5. The IISS is a distributed set of heterogenous computer

hardware and software systems accessible from geographically

dispersed locations.

These principles were inputs to establish a set of requirements

and specifications, which resulted in an overall system design

developed with capability of both short- and long-term migration.

To focus attention on the long-range needs and requirements for

IISS, projections beyond 1995 concerning computer systems

architectures were researched and established as the baseline.

The IISS development has participated in advancing standards in

fifteen (15) ANSI and ISO committees and has worked with industry

and NBS on communications, a major IISS subsystem, implementing

OSI protocols (MAP/TOP)

.

Over ten (10) major releases of software including methodologies,

languages, and compilers have been released since early 1983.

The Boeing effort continues the baseline established by four

years of General Electric coalition effort ending in 1986. The

transition to Boeing will see the system hardened and implemented

in production at Boeing and McDonnell Aircraft Co. in 1986 thru

1989. Technology Transfer has been initialized to the computer

handware and software vendors.

Graphics Standards: Since IISS provides the integration within a

completely homogeneous environment, graphics standards should be

used to provide machine, and especially device-independence.

GKS, PHIGS, CGM and CGI would all fit in well here.

IRDS, SQL & NDL: IRDS, SQL, and probably NDL are all applicable.

(General Dynamics currently using 300 IMS databases on shop

floor.) Currently using a "sophisticated” DDS with (IDEFl*)

model sitting on top. Neutral DML is SQL based.

129
Project Title: Engineering Drawing Automated Storage and

Retrieval Equipment

Goals and Objectives: The DLA Engineering Drawing Automated

Storage and Retrieval Equipment (EDASRE) project is directed

toward automating four technical data repositories to support

information requests and reprocurement actions. The

respositories include the Defense Electronics Supply Center

(DESC) , Defense General Supply Center (DGSC) , Defense Industrial

Supply Center (DISC) , and Defense Construction Supply Center

(DCSC) . Repository functions of each of the Supply Centers are

estadslished under DoDI 5010.12, Technical Data Management

Program. The DLA EDASRE program is comprised of two phases. The

first phase provides the Agency with an interim capability to

fully automate processing of aperture card files at the four

technical data repositories, thus eliminating the need to

manually store and retrieve aperture cards in response to

customer requests for technical information.

Phase 2 of the EDASRE program will incorporate Agency planning to

transition from our Phase 1 interim automated aperture card

systems into DSREDS/EDCARS digital storage and retrieval

environment for the processing of engineering drawings and

reprocurement bidset packages. It is the Agency *s intent that

upon completion of the EDASRE Phase 2 planning that we will

acquire digital capability through any existing DoD contract that

may be used as a means for acquisition. Otherwise, we will look

toward the DSRED/EDCARS experience in defining digital processing

requirements and acquisition criteria before taking any

competitive procurement action.

Contact:

Contact Telephone:

Acronym: EDASRE

Technical Approach:

13 0
Project Title: Modernized Parts Control Automated

Support System

Goals and Objectives: The Defense Logistics Agency Parts Control

Automated Support System (PCASS) currently has many manual

functions involved in the administration and performance of the

DoD Parts Control Program, DoDI 4120.19, MIL-STD 965. This

program supports Military Parts Control Advisory Group (MPCAG)

operations. The MPCAGs are located at four different Defense

Supply Centers (DSCs) , which evaluate and make recommendations on

parts proposed for use in systems being developed by the DoD and

other Federal agencies. The MPCAG' s responsibilities are to

promote standardization through the use of military specification

parts.

Obj ectives

1. Provide an on-line database to replace PCASS sequential tape

files, allowing near-real-time processing and ad hoc query

capability for the military services and industry.

2. Provide for almost 100% growth to 1,000 contracts supported

per year, with improved response time.

3. Automate the remaining manual/paper reference files,

including status of Mil/Spec standard preparation (over 1,200 per

year) and Qualified Products Lists (over 200 lists)

.

4. Provide telecommunications for system input/output , and for

interface with reference files in other DoD. and industry ADP

systems

.

Contact:

Contact Telephone:

Acronym: MPCAS

S

Technical Approach:

131
Project Title: Personal Electronic Aid for Maintenance

Goals and Objectives: This is a joint effort with the Army to

develop test and evaluate an authoring and electronic portable

field maintenance system. The Navy project is focused on the

extensive use of graphics displays as troubleshooting aides for

use by the maintenance technician. The system is being designed

to provide the technician with a checklist of maintenance actions

and step-by-step procedures in combined text and graphics format.

Contact:

Contact Telephone:

Acronym: PEAM

Technical Approach:%

132
t

Project Title: Computer-Based Aide for Troubleshooting

Goals €uid Objectives: The increasing sophistication of modem

Navy weapon systems has resulted in an exponential growth in the

technical information required for support. This phenomenal

growth often does not include the additional documentation

required to support maintenance of the advanced electronic

circuitry beyond the point where the automatic test equipment

(ATE) and built-in-test (BIT) leave off. Complete reliance on

ATE and BIT forces the technician, when ATE and BIT fail, to

fault isolate without any additional technical information.

While the amount of data is, in itself, a problem, complexity in

the presentation of information aggravates it. Specifically, it

is the user's access to an interaction with the technical

information that is formidable.

The objective of this project is to define, describe, and

evaluate the technical information variables that contribute to

effective maintenance performance by: (1) development of a

technology base for technical information design and delivery,

and (2) design, development, test, and implementation of an

intelligent user defined technical information system.

Contiact:

Contact Telephone:

Acronym: CBAT

Technical Approach:

133
Project Title: Navy Integrated CAD-CAM

Goals cind Objectives: This project will establish hardware and

software system specifications, develop program dociimentation and

execute consolidated acquisition and integrated installation of

CAD-CAM systems at principal engineering and industrial

activities performing design/maintenance of ships, systems and

facilities.

Contact:

Contact Telephone:

Acronym:

Technical Approach:

134
Project Title: Computer-Aided Integrated Logistic Life Cycle

Support (Computer Aided Logistical Support Analysis)

Goals and Objectives: Apply RAM across the spectrum of logistic

support analysis and the logistical support analysis record over

the life cycle of the acquisition. To provide front end and

supportability inputs and considerations to the design and

engineering process for the acquisition process.

Using the government owned CALSA (with the MK 50 Lightweight

Torpedo Program as a testbed) , the first steps have been to

record with current primary emphasis on the timely spare

provisioning process, reviews and audits.

Follow-on efforts will integrate RAM/CAD on an interactive basis

utilizing existent databases for corporate memory to provide

front end inputs to the design and engineering process.

Contact:

Contact Telephone:

Acronym: CALSA

Technical Approach:

135
APPENDIX 6

SHORT AND LONG TERM SOLUTIONS

TO RASTER VS VECTOR PROBLEM IN CALS
.' 4.

' ..V! T; t. i V r i 'l

Prr»}Hr^;. Tlcbtf g, Int^<yrAt#<| X^ite Cyci<

j Sapporo (Ccttpttt^r hXd0d hc^mticml Suj^rt kxtnl^Bim}

0 '-'*' ' i' .-. * -

* •

- if ’ - f

- <3o«1ji ar>d cb^«iGt4yw5 ^Ppi/ lUtH ^crc#t 55^i5*^ «p«ctroji of lec si:^

:»n^« l^i*ticAX,, ^uppctit t«corc

. T . l,Xjr«» cVm1« .Pt tnn acqulsiti'on, “ To p;y3ryi4A fr^mt

'• ' AappOTi^»illt^^ (ssputif :ron»id«rati.ot«j tix •sl-jn ' id.

,‘' for tti« ^•;<r'^iilt4U;;ek

.

' ^

jj^' ' tiia”' <7c.viirTm<ir>t ^wj«k4 CAt5A th#. ''?ix

. " torpidp Xmmth-X4'lf the fijrat Jitup* tiave teita: tpii

^:

• * r -y:arct .^'urreat primary a»p^^aai* , on the

-' otoceae# ravk«^rf« ajid , audita.

ft*

' - ‘ToXXokf^tai f^<3rt:3''C5riil' integrate IUIvX^-rcJ5' interactive

utiXJ,ricg ditahaiMia tor oot|N»rttA '^as&oxy to prwvi*.e

frxat fimd i-^pute fo the deeigr end i^rugt^fterii^

d

,• -* *“ *

J!»'-» .V

n

‘U V

,«3pfcBP^ S rt08S^<ZA '•

• ;

*

' #" '

. -f ' •- ' ^ ’•I.wr- v, '

• •

* ^ ' ^ ^

,\i7rt3oyei -A ^;a anoiTOioe KS2T rmoj oka tbosz - T^c*l >pp«Si5?

« ”

--4
APPENDIX 6

SHORT AND LONG TERM SOLUTIONS

TO RASTER VS VECTOR PROBLEM IN CALS

From the resources investigated (in the contract report

[SPAR86]), two major graphics-related opinions emerged, in very

clear and consistent statements throughout each project:

1. There is a tremendous backlog of data that must be

accessed, manipulated, and outputted, currently in raster

format* Much of this data is archived on aperture cards

that must be digitally scanned. Data in this format will

be a part of the CALS database for a very long time.

2. Many of the current and future graphics data inputs will

be originated at a CAD or CAE terminal that has

capabilities for manipulating and storing 3D solid

product models and/or an image in vector format. The'

database capabilities and engineering facilities provided

by such systems, as well as the current trend towards

lower cost, make their use highly desirable for

production of the original drawings.

These two facts negate any attempt to determine a single,

inclusive format for all CALS graphics data. Any solution must

be able to handle both raster and vector types of images.

Vector images can be translated into raster format. In fact, in

most cases, during display of the image on a graphics device,

they are converted to a raster representation so that the

hardware graphics engine can display the image. However, the

reverse is not true, given the current state of the art.

Although the command-and-parameter format of a vector image, such

as "draw a line from point one to point two,” can be fairly

easily turned into a series of on-off values for a raster display

memory, it is much more difficult to recognize that same series

of on-off points as a contiguous line. A major problem exists in

simply checking the resulting output for validity and

completeness. There are several industries that are attempting

to resolve this problem, while raster to vector conversion is

cost effective for drawing modification in some cases, currently

there is no cost effective solution for document archival.

137
1. Shori: Term Solution

The least common denominator in terms of technical difficulty is

the raster format of documents. The existence of raster-scanned

dociiments does not preclude the capture of hand-drawn images,

CAD-generated documents or alphanumeric databases. Therefore,

until standards are available to handle vector- formatted data,

it is recommended that a raster based CALS system be

standardi z ed

.

In such a system, CALS would store a raster facsimile of all DOD

dociiments. Any document could then be located and transmitted

anywhere in the world in seconds for display or printing. . As

standards for more complex data elements become available, CALS

can be modified to store, retrieve, and integrate them. CALS

could also store and retrieve binary files that do not conform to

a standard, although it must be recognized that such files will

be of limited value after a time, due to inevitable modification

of the systems that created them.

Raster image databases should be easier to manage than text,

graphic, or inventory databases, since raster images contain

fewer internal structures. This means that raster databases will

not require distributed database management systems, enhancing

the possibility of fast implementation.

Although much discussion of the surveyed projects has revolved

around the problems of perceived slowness of display, and cost

and amount of storage required by using only raster as the

database format, current technological trends are towards

cheaper storage and faster decompression and raster display

devices

.

This short-term solution allows for the accomodation of current

archival images as well as providing for the gradual development

of the long-term solution described in the following section,

without impacting the day by day performance of the projects.

2 . Long Term Solution

CALS should support both raster and vector formatted data. The

proposed long term solution is, while continuing to keep raster

scanned docximents in raster format, to migrate all incoming data

to vector format. This means to encourage originals to be

prepared on CAD systems, with a standard format for transferring

and storing the vector version of each image. This format is

already defined: it is the CGM standard format for the graphics

operations, with a backup of IGES/PDES for the product definition

data requirements.

138
In addition to using the established CGM and IGES/PDES standards

for data storage, there is a need for standard interfaces to the

target display devices. Many situations, from the soldier in the

field attempting to upgrade or maintain some equipment and the

logistician in the office updating some information in a

document, to management personnel briefing DOD Chiefs, require

diverse devices for display and input to the data management

programs that provide these capabilities. The emerging CGI

standard, in addition to the GKS and PHIGS application-level

standards, can be used optimally to provide the required

device- independence. Another benefit of using these standards is

programmer portability for application software development or

modification, and the cost benefits of increased availability of

Off-The-Shelf hardware and software.

There will be, then, a standard storage base of images, in

vector format if possible, that may be indexed, retrieved, and

modified if necessary. The primary representation of the image,

however, will remain the raster formatted version. The last step

of every retrieval will be a rasterization step.

This solution provides both a quick, global access to docximents

and images, from the raster version of the image, and flexible

storage of the same image in a format that is accepted from

contractors in a standard way. The perceived configuration

management problems with a dual representation method have

actually been dealt with over the years as multiple versions* of

documents were created and maintained. Older versions of a

document can be controlled in raster format while newer versions,

rewritten or amended in alphanumeric or vector format, can be

controlled in their new format. Controlling these multiple

.versions of documents is a capability that CALS must have whether

the versions are in the same format or different formats. As

described above, reformatting such as raster to vector

conversion, requires human input while the reverse vector to

raster conversion can be done automatically. Reformatting

requiring human input should be controlled as a new revision

while automatic reformatting should be considered part of the

output process. Because the output process can have several

conversions with intermediate buffers, CALS must be designed to

accomodate multiple automatically reformatted versions of a

document. If automatic reformatting requires extensive

computing, the intermediate results may be retained until the

source document is changed.

CALS must also accomodate multiple identical copies of each

document to provide spatial diversity for survivability of the

combat readiness document-base. CALS must have an integrated,

on-line backup capability.

139
3 . Conclusion

CALS must support raster images because almost all documentation

either lacks an alphanumeric/vector form, or, if one is used, it

is nonstandard. CALS must support standard alphanumeric and

vector storage formats to facilitate full text searches and CAD

input/modification. Choosing to remain with one or the other

format exclusively either would, result in losing the capability

to access archived raster images or would result in losing the

design and solid model information and the ability to search for

text strings.

The raster-only short term solution is suggested, since it can be

applied early and easily and cheaply. In addition, a successful

raster CALS system would almost certainly be able to inspire a

budget for additional vector capabilities.

For the long term, however, CALS must also provide portability of

software tools and ease of transfer of images and product data

from one system to another. For this reason, CALS must accept

documents in vector and alphanumeric formats as soon as standards

for these formats are established.

140
APPENDIX 7

TOP/MAP COMPUTER GRAPHICS METAFILE (CGM)

APPLICATION PROFILE (AP)
^ -

LfiL.

"

f>i ‘Sm/‘l!^ ti* r -m

a

|!--5 CliXif a4^«^ ii)dt|iport' ra«t^ .=JE^ idlL^osz hXI docujn«nt«t

«n *^lpa*^wntori<Vvmctor tow. or. if onii U iifttt*

"

’ <^SLJ itnutt f.apport n-cv^rd 2.ivnanu««PiO‘:^a?t4'

^^'?i©tor ,^t:or'<.g[« fowat^« tb t*clUtuit<i" fuXl .•mrrcn#« ««d' aCI

- l?tip«t/»odifiCation. “.CSlacolng tx c«Min wltH or# gar rij# otJlf

forMt: would rtt4^ul^ in io*in^ tti#

to «vro^iv#«2 .niRtot ,^;jv4gos o^ voulJ r«#ult in letting, -t;!

• ' ^ • .• ,. V afcl' . ,

‘ ~J^-, - .t;”^"*' rxrlmjo. ‘ ' ’ '

Tii« ^ttiRtRrunly abort '".•r« 1« i”. »plU4 a#rX/ An4 «#»Uy ind ca^^ipiy. w addition, a *0^

rafitor ayatUBu v-ald lajwjst cart&ial*/ b# abU .to -inaplra^ a

pudcot for ada^tiomal v#ct r ’ 'Xi

• r' • . ' - . - . yifl

?or fc,*^ Votvg -t%rai, rtov^v^r, Ott^-nuii'x t-iao. pJPO'rtats portabiii^

sodtnttdTo tools and araa of traruif^f i»agas‘ md {irodoet' d^

rt:^..Sroa <rro fystaffi to arotbor. for tJiis xaoaon, CALS oust
Graphics Docoaent 86-39

Title; TOP/MAP Computer Graphics Metafile (CGM)

Application Profile (AF)

CoBtrlbtttor; Fremh R. Dawson (Editor)

McDonnell Douglas Corporation

Text of an Application Profile defining the

TOP/KAP Graphics Technical SuJbcomalttee ' s Recommendation for support of the CGM as the

interchange format for computer graphics

picture description information in am CSX

environment

.

7 August 1986

Draft Version - 7 Angnst 1963 Page 142
Graplilcs DOCT*ent 86-39 R1 TOP/XAP CGM Application Profile

0 Introduction 3

1 Scope 3

2 References 3

3 Definitions 4

4 Architectural Concepts 5

5 Encoding 7

6 Metafile Constraints ,8

7 Environment€kl Constraints 23

3 Registered Elements 26

Page 143 Draft Version - 7 Anfnst 1986
tOP/XAP GGX Application Profile Graplilos Docuent 86-39 RI

0

Introduction

Tlie purpose of this document is to define the TOP/MAP

Application Profile for support of the ISO 8632, Information

Processing Systems Computer Graphics Metafile for the Storage and

Transfer of Picture Description Information, the CGK. An application

profile defines the conformance characteristics or permissible

combinations for all possible data streams that conxorm to that

profile. In addition, an application profile may define additional

requirements for transmitting, receiving, interpreting and handling

vailid CGM data streams. The definition of such implementation

constraints is usually outside the scope of an ISO standard.

However, such application profiles are required and necessary to

insure uniform implementation of such standards, especiailly where

interchainge in an open system environment is concerned.

The application profile specifies the conformance to the CGM in

terms of PERMISSIBZiB, BASIC, BOHBASIC, and DEFAULT values.

Permissible values are the range of values for CGM elements as

specified in ISO 8632. Basic values are the range of permissible

values that are mandatory for conformance to this application

profile. Nonbasio values are the remainder of permissible values for

CGM elements. The defatilt values for CGM elements are the implicit

initial values that are assumed for each pairameter. Default values

are ezplioitly overridden by the Metafile Description Elements,

Picture Description Elements, Control Elements, and Attribute

Elements.

This TOP/MAP Application Profile is the basis of the TOP

Specification for interchange of computer graphics picture

description information. This application profile can, in the

future, be supplemented by additional TOP/MAP CGM Application

Profiles.

1

Scope

This TOP/MAP CGM Application Profile defines the CGM

implementation that is recommended by TOP /MAP for interchanging

computer graphics picture information. CGM implementations that

conform to this application profile will be able to be integrated

into other TOP/MAP Application Processes (i.e., TOP/MAP Compound

Document Interchange Format).

2

References

These references are applicable to this document.

NBS Special Publication 424 - April 1978, Hershey Fonts.

ISO 646, Information Processing - 7-bit Coded Character Set for

Information Interchange.

ISO 2022. Information Processing - 7-bit and 8-bit Coded

Characters Set Code Extension Techniques.

Draft Version - 7 August 1966 Fagem
Grapliics Doouent 86-39 R1 TOP/ICAP CGX AppUoatlon Profile

|

ISO 7942, Information Processing Systems - Computer Granhics

Functional Specification of the Graphical Kernel System (GKS)

.

ISO 8613, Information Processing - Text and Office Systems - Office Document Architecture (ODA) and Interchange Format.

ISO 8632, Information Processing Systems - Computer Graphics

Metafile (CGM) for the Storage aind Transfer of Picture Description

Information.

3 Definitions

|

APPLICATION PROPILB - A specification that defines the use of an

International Standard, with a definition of aJ.1 possible data ] streajns that conform to that profile. An application profile insures I interoperability of implementations of an International Standard.

BASIC VALUB - The subset of permissible values for parameters of ] a CGM element that are mandatory for conformance to this application

profile.

CGH MI - A CGM metafile input vorMstation.

CGM MO - A CGM metafile output vorhstation.

| COMPOUND DOCUMENT - A digital analog of a document containing

more than one component objepts, such as character, computer

graphics, image or facsimile data.

COMPOUND DOCUMENT INTERCHANGE FORMAT - The specification for a

' mechanism for storing and transferring a compound document. Refer to]

ISO 8613.

COMPUTER GRAPHICS INTERFACE (CGI) - The specification for | interface techniques with graphical devices.

COMPUTER GRAPHICS METAFILE (CGM) - The specification for a

mechanism for storing and transferring picture description ’ information. Refer to ISO 8632.

DATA INTERFACE - An interface between software modules or

devices comprising one or more operation codes eind data; as

contrasted with a subroutine call interface.

DEFAULT VALUE - The implicit value for a parameter of a CGM

element (e.g., default Metafile Name in Begin Metafile is the null

string)

.

DEVICE DRIVER - The device dependent part of a graphics system

which supports a physical device. The device driver generates device

class specific output.

GRAPHICAL KERNEL SYSTEM - A standardized application

programmer's interface to graphics systems. Refer to ISO 7942.

Page 145
TOP/ICAF CQf Application Profile GraplLlos Docnnent 86-39 R1

METAFILE - Used synonymons with. CGM. A mechanism for retaining

and transporting graphical data and control information. This

information contains a device independent description of one or more

pictures

.

metafile generator - Used S3rnon3nnous with CGM Generator. The

software or hardware that creates a picture or conveys information in

the CGM representation.

METAFILE INTERPRETER - Used synonymous with CGM Interpreter.

The software or hardwaire that reads the CGM and interprets the

contents.

NONBASIC VALUE - The set Of permissible values for a parameter

of a CGM element other than the basic values.

PERMISSIBLE VALUE - The range Of valid values for a parameter of

a CGM element as specified in ISO 8632.

VIRTUAL DEVICE - An idealized computer graphics device that

presents a set of graphics capabilities to graphics software or

systems via the CGI.

NOTE; Refer to clause 3 of ISO 8632 and ISO 7942 for further

definitions of computer graphics terms.

4 Architectural Concepts

The CGM is designed to be usable emd useful to a wide range of

applications, graphics systems, and devices or workstations. The CGM

is graphics system independent, as well as device independent. The

CGM is created by a CGM Generator. The CGM Generator resides at the

level of the device driver and is invoked by the application callable

layer. The CGM Generator can be used to record device independent

picture descriptions, conceptueilly in parallel with the presentation

of images on actual devices. Figure 4.1 illustrates the reference

model for creation of the CGM.

m
Graplilcs Doouent 86-39 R1 TOP/ICAP CGM Application Profile

Figure A. 1: QGM Generator Reference Model

AppKoetiofi

•vice Independent

Qraphiot Syttem

CQM MO CQI

COM Qeneretor FeoUity

CQM

S

I

I

I

I

1

Tlie CGM is designed to be interpreted either by a special

application program, that in turn invokes a device independent

graphics system to render the CGM. As veil, it may be interpreted by

an application callable, device independent graphics system through

the use of CGM metafile input CGI. Figure 4.2 illustrates the

reference model for interpretation of the CGM.

Figure 4,2; PGM Interpreter Reference Modal

Application

CQM Device

Interpreter Independent

Feoility Graphics

Syttem

oij CGM

1 CQI

Page 147 Draft Version - 7 Angnst 1966
TOP/MAP CGM Application Profile Graplilcs Docuent 66-39 Rl

Fltfnra 4.S: Altaraata CCai Interpreter RaforencQ Model

Appltoation

O«vio« ifid«p«nd«nt

Qraphfot System

/ \

CGM

Ml cot

Ttrminal

CQt

» * CQM

Interpretei

FaoHity iiib

f

« O

0

Figure 4.3 illustrates the alternative reference model for

interpretation of the CGM.

The GSS may be the application callable, device independent

graphics system that is used in these reference models. The GSS

standard, however, does not specifically refer to the CGM einy more

that it does to any other specific class of graphics device.

Sections 9 and 10 define the mapping between GSS flind CGM as supported

by this application profile. The definition of the conformance for

this mapping will permit a specific GSS based application to create

the same CGM representation on any vendor's implementation of the

GSS.

5 Sncodlng

The CGM staindard defines the form (syntaz) and the functional

behavior (semantics) of the ordered set of metafile elements. There

are three different encodings of the CGM that have been standardized.

These include the Clear Text Encoding, Character Encoding, and Binary

Encoding. This application profile specifies that the CGH will be

encoded according to the Binary Encoding defined in ISO 6632/3.

The basic form for the command header and string parameter

header is the long form. The nonbasic form for the command header

and string parameter header is either the short or long form. The

long form of the command header is detailed in ISO 8632/3, subclause

4.4, pages 7-9. The long form of the string parameter header is

detailed in ISO 8632/3, clause 6, page 17, note 6.

i

1

I Draft Version - 7 August 1986 Pafe 148
Graplilcs Docrment 86-39 R1 TOP/MAP CG3C AppUoatlon Profile

6 Metafile Constraints

1

1 Eacli of .t lie elements are listed by element class. For each

element, tbe permissible values, basic values, nonbasic values, and

default values for each of tbe parameters are listed. I

6 . 1 DellJid.ter Blesents

1 Bleaant ; HOOF

Paraneter 1: Pad string (string)

] - Pemlsslble Values: Any string of octets with a length greater j thain or equal to 0 and less than or equal to tbe Majcimum String

Length. i - Basic Values: Any

- Honbasio Values: None

- Default Values: Null string 1 li Blenent : Begin Metafile

1! Paraaeter 1: Metafile name (String).

- Peraissible Values: Any string of characters with a length

greater than or equal to

String Length.

0 aind less than or equal to the Mazimua

- Basic Values: Any

- HonJbasic Values: None

- Default Values: Null string

Hla»ent; Had Metafile

Parameter 1: None

- PeraissdLble VaLLues: N/A

- Basic Values: N/A

- Nonbasic Values: N/A

- Default Values: N/A

Blenent ; Begin Picture

Parameter 1: Picture name (String).

- Permissible Values: Any string of characters with a length

greater than or equal to

String Length.

0 and less than or equal to the Meizimum - Basic Values: Any

- Nonbasic Values: None

- Default Values: Null string

Element ; Begin Picture Body

Parameter 1: None

- Permissible Values: N/A

- Basic Values: N/A

- Nonbasic Values: N/A

- Default Values: N/A

Element : End Picture

Parameter 1: None

- Permissible Values: N/A

Page 149 Draft Version - t ji
TOP/ICAP CGM Application Profile Graplilcs Docuent 66-39 Ri

- Baelo Values: K/A

- Honbaslo Values: N/A

- Defanlt Values: N/A

6.2 Metafile Descriptor Bleaents

Element

Metafile Version

Parameter 1: Metafile version number (Integer).

- Permissible Values: 1 - Basic Values: 1 - Honbaslo Values: None

- Default Values: 1

Element: Metafile Description

Parameter 1: Metafile descriptive string (String).

- Permissible Values: Any string of characters with a length

greater than or equeil to 0 and less than the Maximum String Length.

- Basic Values: Any

- Honbaslo Values: None

- Default Values: Null string

Element: VDC Type

Parameter 1: VDC (Integer)

- Permissible Values: 0» integer VDC

1, real VDC

- Basic Values: 0. 1 - Honbaslo Values: None

- Default Values: 0

Element! Integer Precision

Parameter 1: Integer precision (Integer)

- Permissible Values: 8. 8-bit

16, 18-bit

24, 24-bit

32, 32-bit

- Basic Values: 16 - Honbaslo Values: Any

- Default Values: 16

Element : Real Precision

Parameter 1: Representation form (Integer)

- Permissible Values: 0, IEEE 7S4 floating point format

1, Fixed point format

- Basic Values: 1 - Honbaslo Values: Any

- Default Values: 1

Parameter 2 : Exponent field width (Integer)

- Permissible Values: 9. 8-bit with sign

12, 11-bit with sign

16, 15-bit with sign

32, 31-bit with sign

- Basic Values: 16 - Honbaslo Values: Any

Draft Version - 7 Aufust 1986
Graplilos OoonBent 86-39 R1 TOP/MAP CGM App3J.catlon Profile

- Default Values: 16

Parameter 3: Fraction field width (Integer)

- Permissible Values: 23. 23 -bit

S2. 82 bit

16. 16--bit

32. 32--bit

- Basic Values: 16 - Honbasic Values: Any

- Default Values: 16

Kleaent

;

Index Precision

Parueter 1: Index precision (Integer)

- Permissible Values: 8, 6 -bit

16. 16-bit

24. 24-bit

32. 32-bit

- BclsIo Values: 16 - Honbaslo Values: Any

- Default Values: 16

Klement

;

Color Precision

Parameter 1: Color precision (Integer)

- Permissible Values: 8. 8-bit

16. 16-bit

24. 24-bit

32. 32-bit

- Basic Values: 8. 16 - Honbasio Values: Any

- Default Values: 16 Bote: This element must be explicitly

specified in tbe Metafile Description with this default value.

Blement

Color Index Precision

Parameter 1: Color index precision (Integer)

- Permissible Values: 8. 8-bit

16, 16-bit

24. 24-bit

32. 32-bit

- Basic Values: 16 - Honbasic Values: Any

- Default Values: 16 Note: This element must be explicitly

specified in tbe Metafile Description with this default value.

Element

Maximum Color Index

Parameter 1: Maximum color index (Index)

- Permissible Values: Any positive index value in tbe range

specified by Color Precision.

- Basic Values: Any

- Honbasic Values: None

- Default Values: 285

Blement

Color Value Extent

Parameter 1: Minimum color value (RGB-tuple)

- Permissible Values: Any RGB-tuple, of positive integers in range

specified by Color Precision.

Page 151 Draft Version - v iqaa

snil
TOP/ICAP OG3f Application Profile Graplilos DocuMnt 86-39 R1

- Basic Values: Any

- Hon2)asla Values: None

- Default Values: (0,0.0)

Paraeeter a:.Mazlinua color value (RGB-tuple)

- PerBlS8ll)ie Values: Any RGB-tuple of positive integers in range

specified by Color Precision.

- Basic Values: Any

- Honbaslo Values: None

- Default Values: (259,255,255)

Rleeent

;

Metafile Elements List

Paraeeter 1: Number of elements specified (Integer)

- Permissible Values: Integers in range specified by Integer

Precision.

- Basic Values: Any

- Honbaslc Values: None

- Default Values: 1

Parameter 2: List of metafile element class /identifier (Index-pair

array)

- Permissible Values: Ordered pair of indices in range of element

Class/Identifier p€d.rs as specified ISO 8613/3, Annex C. - Basic Values: Any

- Hombaslc Values: None

- Default Values: (-1,1), Draving-plus-control set

uiftMttTit

Metafile Defaults Replacement

Parameter 1: List of metafile elements (Metafile Elements)

- Permissible Values: Any set of Picture Descriptor, Control, or

Attribute Elements vitb basic values

- Basic Values: Any

- Honbaslc Values: Any set of Picture Descriptor, Control, or

Attribute Elements vitb nonbasic values

- Default Values: Tbe default is a Metafile Defaults

Replacement element composed of (1) Text Precision Element specifying

a text precision of 2 (strobe) and (2) Color Table specifying 256

indices. Tbe indices are defined as follows:

Index 0

1

2

3

4

5

6

7

8

( 0 , 0 , 0 )

(299,255,295)

(299,0,0)

(0,259,0)

(0,0,255)

(255,259,0)

(259,0,255)

(0,259,259)

- Nominal

- Nominal

- Red

- Green

- Blue

- Yellow

- Magenta

- Cyan

255 are a replication of

Bacbground

Foreground

indices 0-7

Element r Font List

Parameter 1: List of font naimes (string arrays)

- Permissible Values: Any number of string> in tbe range [0, Maximum

String Array Length], each with an arbitrary string of n octets,

where 0 <- n <- Maximum String Length.

- Basic Values: Any

- Honbaslc Values: None

Draft Version - 7 August 1986 Page 152
Graphics Docuent 86-39 R1 TOP/hAP CGM Application Profile

- Default Values: Kaine of one font capable of representing the

standard national oharaoter (i.e., ANS 13.4) set based on ISO 646

Klenent

Character Set List

Parameter 1: Character set t3^e

- Penlsslhle Values: 0, 94-character

1 , 96-charaoter

2 , 94-character

3 , 96-charaoter

4, Complete

G-sets

G-sets

multibyte G-set

multibyte G-set

- Basic Values: 0 - Hoxxbaslo Values: Any

- Default Values: 0

Paraaeter 2: Designation sequence tail

- Peralsslhle Values: An arbitrary string of n octets.

0 <« n <• Maximum String Length.

- Basic Values: The three characters Esc 2/8 4/2 designating

ANS X3.4 (7-blt ASCII).

i

- Honhaslc Values: Any

- Default Values: The three characters Bsc 2/8 4/2 designation

ANS Z3.4 (7-blt ASCII). Bote; This element must be explicitly

specified In the Metafile Description with this default value.

Blement

Character Coding Announcer

Parameter 1: Character coding annoiincer (Integer)

- Permissible Values: 0, Basic 7-blt

1, Basic 8-blt

2, Extended 7-blt

3 , Extended 8 -bit

Negative values for private use

- Basic Values: 0.1

- Honbaslc Values: None

- Default Values: 0

6.3 Picture Descriptor Blements

Blement: Scaling Mode

Parameter 1: VDC scaling mode (Integer)

- Permissible Values: 0, Abstract scaling

1, Metric scaling

Any

None

0

Parameter 2: Metric scaling factor in millimeters (Real)

- Permissible Values: Any real value in range specified by the

real type and real precision. Ignored if scaling mode is abstract

- Baislo Values: Any

- Honbaslc Values: None

- Default Values: 25.4

- Basic Values:

- Honbaslc Values:

- Default Values:

Element

Color Selection Mode

Parameter 1: Color selection mode (Integer)

- Permissible Values: 0, Indexed color mode

Page 153 Draft Version - 7 Autfust 1986

D
TOP/MAP cxac Application Profile Graphics Docrment 86-39 Ri

1, Direct color mode

- Basic Valnes: Any

- Honhaslo Valnes: None

- Defanlt Valnes: 0

- Penlsslhle Valnes:

gioaent

Line Width Specification Mode

Paraaeter 1: Line width specification mode (Integer)

^ Ahsolute

1 , Scaled

Any

None

1

- Basic Valnes:

- Konhaslc Valnes:

- Defanlt Valnes:

Kleaent

Marher Size Specification Mode

Paraaeter 1: Marker size specification mode (Integer)

- Peralsslhle Valnes: 0, Absolute

1 , Scaled

- Basic Valnes: Any

- Honbaslc Valnes: None

- Defanlt Valnes: 1

Bleaent: Edge Width Specification Mode

Paraaeter 1: Edge width specification mode (Integer)

- Perals8ll>le Valnes: 0, Absolute

1 , Scaled

- Basic Valnes: Any

- Honbaslc ValneC: None

- Defanlt Valnes: 1

Bleaent: VDC Extent

Paraaeter 1: First point (Point)

- Peralsslble Valnes: Any value for x and y VDC in range specified

by VDC T3rpe and VDC Precision

- Basic Valnes: Any

- Honbaslc Valnes: None

- Defanlt Valnes: (0.0) If VDC T3^e is Integer

(0.0. 0.0) if VDC Type is Real

Paraaeter 2: Second point (Point)

- Peralsslble Valnes: Any value for x and y VDC in range specified

by VDC T3rpe and VDC Precision

- Basic Valnes: Any

- Honbcislc Valnes: None

- Defanlt Valnes: (32787,32767) if VDC Type is Integer

(0.9999. . ,0.9999. .

)

if VDC Type is Real

Bleaent

;

Background Color

Paraaeter 1: Direct background color (RGB-tuple)

- Peralsslble Valnes: RGB-tuple of positive integers in range

specified by color precision.

- Basic Valnes: Any

- Honbaslc Valnes: None

- Defanlt Valnes: (0,0,0) or Minimum Color Value

Draft Version - 7 August 1986 PaM 1 ^4
Graplilcs DocoMii’t 86—39 R1 TOP/RAP OGM AppUoatlon Profile

6.4 Control Slenents

glenentVDC Integer Precision

Paraneter I: VDC integer precision

- Permissible Values: 10. 10-bit

24. 24-bit

32. 32-bit

^ Basic Values: 10 - Honbasio Values: Any

- Default Values: 10

(Integer)

Bleaent

;

VDC Real Precision

Parameter 1: Representation form (Integer)

- Permissible Values: 0, IBEB 794 floating point format

1, Fixed point format

1

Any

1

- Baslo Values:

- Honbaslo Values:

- Default Values:

Parameter 2: Exponent field vidtli (Integer)

- Permissible Values: 9, 6-bit vitb sign

12, 11-bit vitb sign

10 . 32. - Basic Values: 16 - Honbasio Values: Any

- Default Values: 16

19-bit vitb sign

31 -bit vitb sign

Parameter 3: Fraction field vidtb (Integer) - Permissible Values: 23. 23-bit

92. 92 bit

10. 10-bit

32. 32-bit

- Basic Values: 10 - Honbasio Values: Any

- Default Values: 10

Element

;

Auxiliary Color

Parameter I: Auxiliary Color (RGB-tuple or Color Index)

- Permissible Values: Any valid RGB-tuple or color index in tbe

range specified by Color Precision (RGB-tuple) or Color Index

Precision (color index).

- Basic Values: Any

- Honbaslo Values: None

- Default Values: Default background color, vben Color

Specification Mode is direct. Color Table index 0, vben Color

Specification Mode is indexed.

Blenent^: Transparency

Parameter 1: Transparency

- Permissible Values: 0. Off;

required

1, On; - Basic Values: Any

- Honbasio Values: None

- Default Values: 1

auxiliary color background is

transparent background is required

Page 155 Draft Version - 7 August 1986
TOP/MAP CGML Application Profile Graphics Doonnent 66-39 R1

gleaent

;

Clip Rectangle

Paraneter 1: First point (Point)

- Pemlsslhle Values: Any value for z and y VDC in range specified

by VDC Type and VDC Precision

- Basic Values: Any

- Honl>aslo Values: None

- Default Values: Seise as first point of VDC Extent

Pairaseter 3: Second point (Point)

- Peralsslble Values: Any value for z and y VDC in range specified

by VDC Type and VDC Precision

- Basic Values: Any

- Honhaslc Values: None

- Default Values: Same as second point of VDC Extent

gleseati clip indicator

Paraaeter 1: Clip indicator (Integer)

- Peralsslble Values: 0, Off

1,

On

- Basic Values: Any

- HonlMislc Values: None

- Default Values: 1

6.8 Graphical Prlaltlves

For all elesents in this class, parameters can have any of the

permissible values as specified in ISO 8632. The basic values are

any of the permissible values that are restricted by the

Environmental Constraints (i.e., Mazimum Point Array Length, Hazimum

String Length, etc.}. There are no nonbasio values. The default

values are not applicable.

6.6 Attribute Blements

Element

i

Line Bundle Indez

Parameter 1: Line bundle indez (Indez)

- Permissible Values: Any positive indez in the range specified by

the Indez Precision

- Basic Values: Any

- Honbaslc Values: None

- Default Values: 1

Element.: Line Type

Parameter 1: Line type

- Permissible Values:

by the Integer Precision

- Basic Values:

- Honbaslc Values:

(Integer)

1. Solid

2 . Dash

3. Dot

4. Dash-dot

5. Dash-dot -dot

Any negative integer in the range specified

for private use

Any

None

Draft Version - 7 August 1966 Page 156
Graphics Docnaent 86>39 R1 TOP/XAP CGM Application Profile

- Default Values: 1

BleaenUi Line vidth

Paraaeter 1:. Line width (VDC or Real)

- Peralsslhle Valnes: Any valid VDC in the range specified by VDC

T3Tpe and VDC Precision if Line Width Specification Mode is absolute

or any valid Real in the range specified by Real Precision if Line

Width Specification Mode is scaled. - Basic Valnes: Any

- Honbasio Valnes: None

- Default Valnes: O.OOl^Length of the longest side of

rectangle defined by VDC extent for absolute; 1.0 for scaled

Bleaent :^ Line Color

Paraaeter 1: Line color (RGB-tuple or Color Index)

- Peraissible Valnes: Any vailid RGB-tuple or color index in the

range specified by Color Precision (RGB-tuple) or Color Index

Precision (color index). RGB-tuple values not to exceed Maximum

Color Value. Color representation must match Color Representation

Mode

.

- Basic Vaines: Any

- Hontesic Vailnes: None

- Default Valnes: Maximum Color Value, when Color

Specification Mode is direct. Color Table index I, when Color

Specification Mode is indexed.

Element

Marker Biindle Index

Parameter 1: Marker bundle index (Index) - Permissible Valnes:

the Index Precision

- Bfisic Values:

- Honbasic Valnes:

- Default Valnes:

Any positive index in the

Any

None

1

rcmge specified by

i

Element

Marker Type

Paraaeter 1: Marker type (Integer)

- Permissible Valnes: I. Dot

2 . Plus

3 . Asterisk

4. Circle

5. Cross

Any negative

by Integer Precision for private use

- Basic Valnes: Any

- Honbasic Valnes: None

- Default Valnes: 3

If integer in the range specified

ElementMarker Size

Paraaeter 1: Marker Size (VDC or Real)

- Permissible Valnes: Any valid VDC la the range specified by VDC

Type aind VDC Precision if Marker Size Specification Mode is absolute

or any valid Real in the range specified by Real Precision if Marker

Size Specification Mode is scaled.

- Basic Valnes: Any

Page 157 Draft Version - 7 August 1986
TOP/XAP CQC Application Profile Graphics Oocnnent 86-39 Rl

- NonlMLSlo Values: None

- Default Values: 0.01 ‘Length of the longest side of rectangle

defined hy VDC extent for absolute; 1.0 for scaled

BlenentJ^ Marker Color

Paraneter 1: Marker color (RGB-tuple or Color Index)

- Penlsslhle Values: Any valid RGB-tuple or color index in the

range specified by Color Precision (RGB-tuple) or Color Index

Precision (color Index). RGB-tuple values not to exceed Maximum

Color Value. Color representation must match Color Representation

Mode.

- Basic Values: Any

- Honbaslo Values: None

- Default Values: Maximum Color Value, when Color

Specification Mode Is direct. Color Tahle index 1, when Color

Specification Mode is indexed.

RiftMTit

;

Text Bundle Index

Paraaeter 1: Text bundle index (Index) - PeralsslMe Values: Any positive Index value In the range,

specified by the Index Precision

- Basic Values: Any

- Honbaslc Values: None

- Default Values: 1

Bleuent: Text Pont Index

Paraeeter 1: Text font Index (Index)

- Peralsslble Values: Any positive Index value In the range

specified by the Index Precision

- Basic Values: Any

- Honbaslc Values: None

- Default Values: 1

Element

Text Precision

Parameter 1: Text precision (Integer)

- Permissible Values: 0. String

1, Character

2 , Stroke

- Basic Values: Any

- Honbaslc Values: None

- Default Values: 2

Element

;

Character Expeinslon Factor

Parameter 1: Character expansion factor (Real)

- Permissible Values: Any positive real value in the range

specified by the Real Precision

- Basic Values: Any

- Honbaslc Values: None

- Default Values: 1.0

Element

Character Spacing

Parameter 1: Character spacing (Real)

- Permissible Values: Any real value in the range specified by the

Real Precision

Draft version - 7 August 1986 Page 158
Graphics OoooBent 86-39 R1 TOP/MAP GGX Application Profile

- Basic Values:

- Honl>a8lo Values

- Default Values:

Any

None

0.0

HlenentText Color

Paraaeter 1: Text color (RGB-tuple or Color Index) i - Peralsslble Values: Any valid RGB-tuple or color Index in the |

range specified by Color Precision (RGB-tuple) or Color Index

Precision (color index). RGB-tuple values not to exceed Maximum . Color Value. Color representation must match Color Representation 1 Mode

.

- Basic Values: Any

- Honbaslo Values: None

] - Default Values: Maximum Color Value, when Color * Specification Mode Is direct. Color Table index 1, when Color

Specification Mode is indexed.

| SlfiasBlLl Character Height

Parameter 1: Character height (VDC) - Permissible Valuss: Any VDC value In the range specified by the

VDC Type and VDC Precision

- Basic Values: Any

- Honbaslc Values: None * - Default Values: . 0.01*Length of the longest side of rectangle • defined by VDC extent

Element: Character Orientation

Parameter 1: Character up vector x component (VDC) - Permissible Values: Any VDC value in the range specified by the

VDC Type and VDC Precision i - Basic Values: Any

- Honbaslc Values: None

- Default Values: 0 for VDC Type Integer; 0.0 for VDC Type

Real

Parameter 2: Character up vector y component (VDC) - Permissible Values: Any VDC value in the range specified by the

VDC Type and VDC Precision

- Basic Values: Any

- Honbaslc Values: None

- Default Values: 1 for VDC Type Integer; 1.0 for VDC T3rpe

Real

Parameter 3: Character base vector x component (VDC) I - Permissible Values: Any VDC value in the range specified by the I VDC Type and VDC Precision

- Basic Values: Any

- Honbaslc Values: None

- Default Values: 1 for VDC Type Integer; 1.0 for VDC Type

Real

Parameter 4: Character base vector y component (VDC)

- Permissible Values: Any VDC value in the range specified by the

VDC T3^e and VDC Precision

- Basic Values: Any

- HonbcLSlc Values: None

Page 159 Draft Version - 7 August 1986
TOP/MAF CGM, Application Profile Graphics Docrment 86-39 R1

- Default Values:

Real

0 for VDC Ty^e Integer; 0.0 for VDC Type

Rleaent

Text Path

Paraaeter 1: Text path

- PemlssdL2>l6 Values:

- Basic Values:

- Honbaslo Values:

- Default Values:

(Integer)

0, Right

1. Left

2. Up

3, Down

Any

None

0

Eleaent

;

Text Alignment

Paraaeter 1: Horizontal

- Peraisslhle Values:

alignment (Integer)

0 , Normal

1 , Left

2, Center

3, Right

4, Continuous horlzontail - Basic Values: Any

- Bonbaslc Values: None

- Default Values: 0

Paraaeter 2: Vertical alignment (Integer)

- Peraisslhle Values: 0» Normal

1. Top

2 , Cap

3. Half

4, Base

9, Bottom

6, Continuous vertical

- Basic Vflklues: - Honhaslc Values:

- Default Values:

Paraaeter 3: Continuous

- Permissible Values:

Real Precision

“ Basic Values:

- Honhaslc Values:

- Default Values:

Paraaeter 4: Continuous

- Permissible Values:

Real Precision

- Basic Values: - Honhaslc Values:

- Default Values:

Any

None

0

horizontal alignment (Real)

Any real value in the range specified by the

Any

None

0.0

vertical alignment (Real)

Any real value in the range specified by the

Any

None

0.0

Element

Character Set Index

Parameter 1: Character set index (Index)

- Permissible Values: Any positive index value in the range

specified by the Index Precision

- Basic Values: Any

- Honhaslc Values: None

- Default Values: 1

Draft Version - 7 August 1966 Pai!e 160
Graphics Docaaent 86-39 R1 TOP/MAP CGM Application Profile

Element ; Alternate Character Set Index

Paraaeter l: Alternate character set index (Index)

- Peralsslble Values: Any positive index value in the range

specified by the Index Precision

- Basic Valnes: Any

- Honl>a8lo Valnes: None

- Defanlt Valnes: 1

Bleaent

Fill Bundle Index

Paraaeter 1: Fill bundle index (Index)

- Peralsslble Valnes: Any positive index value in the range

specified by the Index Precision

- Basic Valnes: Any

- Honbaslo Valnes: None

- Defanlt Valnes: 1

Bleaent

;

Interior Style

Paraaeter 1: Interior style (Integer)

- Peralsslble Valnes: 0, Hollow

1,

Solid

2 , Pattern

3, Hatch

4, Eapty

- Basic Valnes: Any

- HonbcLSlc Valnes: None

- Defanlt Valnes: 0

Bleaent: Fill Color

Paraaeter 1: Fill Color (RGB-tuple or Color Index)

- Peralsslble Valnes: Any valid RGB-tuple or color index in the

range specified by Color Precision (RGB-tuple) or Color Index

Precision (color index). RGB-tuple values not to exceed Maximum

Color Value. Color representation must match Color Representation

Mode.

- Basic Valnes: Any

- Honbasic Valnes: None

- Defanlt Valnes: Maximum Color Value, when Color

Specification Mode is direct. Color Table index 1, when Color

Specification Mode is indexed.

Element

Hatch Index

Paraaeter 1: Hatch index (Index)

- Peraissible Valnes: 1, Horizontal

Basic Valnes:

Honbasic Valnes:

Defanlt Valnes:

2, Vertical

3, Positive slope

4, Negative slope

5, Combined vertical

6, Combined left and

Negative for private

Any

None

1

and horizontal slant

right slaint

use

Element

;

Pattern Index

Page 161 Draft Version - 7 Angust 1966
TOP/MAP CGX Applioation Profile GrapMos Doonaent 66-39 Rl

Paraaeter 1: Pattern index (Index)

- Peralsslble Valnas: Any positiye index value in the range

specified hy the Index Precision

- Basio Values: Any

- Honbuio Values: None

- Default Values: 1

RleiientEdge Bundle Index

Paraaeter X: Edge bundle index (Index)

• Peraissible Values: Any positive index in the range specified by

the Index Precision

- Basio Values: Any

- Honbasio Values: None

- Default Values: 1

gleaeatJL Edge T3npe

Paraaeter 1: Edge t3^pe (Integer)

- Peraissible Values: 1, Solid

2, Dash

3, Dot

4, Dash-dot

5, Dash-dot-dot

Any negative integer in the range specified

by the Integer Precision for private use

- Basio Values: Any

- Honbasio Values: None

- Default Values: 1

Bleaent: Edge Width

Paraaeter 1: Edge width (VDC or Real)

- Peraissible Values: Any valid VDC in the range specified by VDC

Type and VDC Precision if Edge Width Specification Mode is absolute

or any valid Real in the range specified by Real Precision if Edge

Width Specification Mode is scaled. - Basio Values: Any

- Honbasio Values: None

- Default Values: 0.001 ‘Length of the longest side of

rectangle defined by VDC extent for absolute; 1.0 for scaled

Element

Edge Color

Paraaeter 1: Edge color (RGB-tuple or Color Index)

- Peraissible Values: Any valid RGB-tuple or color index in the

range specified by Color Precision (RGB-tuple) or Color Index

Precision (color index). RGB-tuple values not to exceed Maximum

Color Value. Color representation must match Color Representation

Mode.

- Basio Values: Any

- Honbasio Values: None

- Default Values: MaximTim Color Value, when Color

Specification Mode is direct. Color Table index I, when Color

Specification Mode is indexed.

Bleaent.: Edge visibility

Paraaeter 1: Edge visibility

Draft Version - 7 August 1966 Page 162
Graphics Doctment 86-39 R1 TOP/MAF CGM Application Profile

- Permissible Valnes:

- Basic Values:

- Honbaslo Valnes:

- Default Valnes:

0. Off

1. On

Any

None

0

Element

Fill Reference Point

Parameter 1: Pill reference point (Point)

- Permissible Valnes: Any point whose z and y components are VDC

in the range specified by VDC Trpe and VDC Precision

- Basic Valnes: Any

- Honbaslc Valnes: None

- Default Valnes: First point defining the VDC Extent

Element

Pattern Table

Parameter 1: Pattern table index (Index)

- Permissible Valnes: Any positive index value in the range

specified by Index Precision

- Basic Valnes: Any

- Honbaslc Valnes: None

- Default Valnes: 1

Parameter 2: Dimension of color array In direction of the Pattern

Size width vector (Integer)

- Permissible Valnes:

by Integer Precision

- Basic Valnes:

- Honbaslo Valnes:

- Default Valnes:

Any positive Integer In the range specified

1 <« dx <- MaxlmTim Color Array Dimension

None

1

Parameter 3: Dimension of color array in direction of the Pattern

Size height vector (Integer) - Permissible Valnes: Any positive Integer in the rsinge specified

by Integer Precision

- Basic Valnes:

- Honbaslo Valnes:

- Default Valnes

1 <- dy <« Maximum Color Array Dimension

None

1

Parameter 4: Local color precision (Integer)

- Permissible Valnes: 0, Defaxilt color precision

1, 1-bit

2, 2-bit

4. 4-bit

8, 8-bit

10, 16-bit

24, 24-bit

32, 32-bit

- Basic Valnes: 0, 1, 8, or 16 if Color Representation Mode

is indexed. 0, 8, or 16 if Color Representation Mode is direct.

- Honbaslo Valnes: Any

- Default Valnes: 0

Parameter 5: Pattern definition (RGB-tuple array or Color Index

array)

- Permissible Vailnes: Any valid array of RGB-tuple or color index

in the range specified by Color Precision (RGB-tuple) or Color Index

Precision (color index) . RGB-tuple values not to exceed Maximum

Page 163 iMs
TOP/MAP cxac Application Profile Graphics Doonnent 86-39 R1

Color Value. Color representation must match Color Representation

Mode. - Basic Values: Any

- Honhasio .Values: None

- Default Values: Maximum Color Value, when Color

Specification Mode is direct. Color Table index 1, when Color

Specification Mode is indexed.

Bleaenti Pattern Size

Parameter 1: Pattern height vector x component (VDC) - Permissible Values: Any VDC value in the range specified by the

VDC Type and VDC Precision

- Basic Values: Any

- Honbasic Values: None

- Default Values: 0 if VDC Type is Integer; 0.0 if VDC is

Real

Parameter 2: Pattern height vector y component (VDC) - Permissible Values: Any VDC value in the range specified by the

VDC Type and VDC Precision

- Basic Values: Any

- Honbasic Values: None

- Default Values: Height of the VDC Extent

Parameter 8: Pattern width vector x component (VDC) - Permissible Values: Any VDC value in the range specified by the

VDC Type and VDC Precision

- Basic Values: Any

- Honbasic Values: None

- Default Values: 0 if VDC Type is Integer; 0.0 if VDC Type is

Real

Parameter 4: Pattern width vector y component (VDC)

- Permissible Values: Any VDC value in the range specified by the

VDC Type and VDC Precision

- Basic Values: Any

- Honbasic Values: None

- Default Values: Width of the VDC Extent

Element

Color Table

Parameter 1: Starting color table index (Color Index)

- Permissible Values: Any positive value in the range specified by

the Color Index Precision

- Basic Values: 1 <- color index <- Maximum Color Index

- Honbasic Values: None

- Default Values: 1

Parameter 2: List of direct color values (RGB-tuple array)

- Permissible Values: Any array less than or equal to the Maximum

Color Array Dimension containing any three-tuple of positive integers

in the range specified by the Color Precision and less than the

Maximum Color Value.

- Basic Values: Any

- Honbasic Values: None

- Default Values: One element (255,255,255)

Element

;

Aspect Source Flags

Draft Version 7 August 1986
Graphics DocaBent 68-39 R1 TOP/MAP GGX Applloatlon Profile

Paraaeter 1: List of pairs of ASP type and ASP values (Integer-pair

array)

- Peralsslhle Values: As in ISO 8632

- Basic Values: Any

- Honhasio Values: None

- Default Values: All ASP types set to individual

6.7 Escape Bleaents

Bleaent

;

Escape

Paraaeter 1: Identifier (Integer)

- Peraissible Values: Any integer in the range specified by

Integer Precision

- Basic Values: Any

- Noxi2>asic Values: None

- Default Values: N/A

Paraaeter 2: Escape data record (String array)

- Peraissible Values: Any array less than or equal to the Maximum

String Array Length containing any string less than or eque^ to the

Maximum String Length.

- Basic Values: Any

- Honbasic Values: None

- Default Values: N/A

6.8 External Bleaents

BleaentMessage

Paraaeter 1: Action-required flag (Integer)

- Permissible Values: 0, No action

1, Action

- Basic Values: Any

- Honbasic Values: None

- Default Values: N/A

Paraaeter 2: Message string (String)

- Permissible Values: Any string less than or equal to the Maximum

String Length.

- Basic Values: Any

- Honbasic Values: None

- Default Values: N/A

Element

Application Data

Paraaeter 1: Identifier (Integer)

Peraissible Values: Any integer in the range specified by

Integer Precision

- Basic Values: Any

- Honbasic Values: None

- Default Values: N/A

Paraaeter 2: Application data record (String array)

- Permissible Values: Any array less than or equal to the Maximum

String Array Length containing any string less than or equal to the

Maximum String Length.

- Baisic Values: Any

P^'Ve 165
TOP/MAP CGM Application Profile Graphics Docnnent 86-39 R1

- 9onl>a8lc Values:

- Default Values:

None

N/A

7 BnYlronnental Constraints

This section desorihes Environmental Constraints or

implementation dependencies that are mandatory for conformance to

this application profile. Normalizing such implementation practices,

defaults, and options will facilitate uniform generation and

interpretation of the CGK.

7.1 General Guidelines For Blenents

This section is meant to augment ISO 8632/1, subclause 0.4.

Name: Color Tskble

Consents: The Color Table attribute element has an indeterminate

effect when it appears in a picture, subsequent to any graphical

priiBltlve elements. The Color Table attribute element should appear

prior to any graphical primitive elements to insure that interpreting

systems without dynamic color update capabilities can render the

intended effect

.

7.3 Inpleaentatlon Guidelines

This section is meant to augment ISO 8632/1, subclause D.5 and

ISO 8632/3, clause 8.

Haae: Maximum Color Array Dimension

Description: The basic value for the number of color values that

can appear in an array. Cell arrays and pattern tables are specified

by two dimensional color arrays. Color tables are specified by one

dimensional color arrays. These basic value applies to a single

dimension

.

Default: 1024

Kane: Maximum Point Array Length

Description: The basic value for the number of points and VDC that

can appear in parameters for metafile elements.

Default: 1024

Name: Maximum String Array Length

Description: The basic value for the number of strings that can

appear in an array. A data record is an array of strings.

Default: 1024

Name: Maximum String Length

Description: The basic value for the length of an individual string

of characters.

Default: 256

Draft Version - 7 August 1986 Pafe 166
Graphics Doonaent 66-39 R1 TOP/MAP CGM Application Profile

The bundle representations are not settaible in the current

version of the CGH. This implementation dependency detracts from the

open interchange of the CGM. The following default bundle table

values will permit a picture to be uniformly rendered by all

conforming interpreters.

Table 1; Default Bundle Tables

Bundle Type Bundle Index

Bundle

Representation

TilRfl Bnnrtlfl

12345

Line type Solid

Line width 1

Line color 1

Dash

1

1

Dot111Dash-dot Dash-dot -dot

Marhex Type Dot

Marker Size 1

Marker Color 1

Plus111Asterisk Circle Cross

1

1

TQxt...BRadIfl

Font Index 1

Text Precision Stroke

Character 1

Expansion Factor

Character 0

Spacing

Text Color 1

1

Stroke

0.5

0

1

Fill Aren gnadle

Interior Style Hollow

Fill Color 1

Hatch Index 1

Pattern Index 1

Solid

1

1

1

Pattern

1

1

1

Hatch

1

1

1

Empty

1

1

1

Bdge Bundle

Edge T3rpe Solid

Edge Vidth 1

Edge Color 1

Dash

1

1

Dot111Dash-Dot Dash-dot -dot

8 Registered Elements

a . 1 Fonts

The fonts in Table 8.1 are pxiblio domain fonts, available from

the National Bureau of Standards. Refer to the references in section

2. All of these fonts are considered to be basic capabilities of the

TOP/MAP CGM Application Profile. Any of these fonts may appear in

the Font List Element in a CGM that conforms to this application

167 Draft Version - 7 Anfnst 1988
TOP/MAP OGM Application Ppofllo Graplilos Doonnent 86-39 Rl

profile. Tlie font names are a concatenated string of "font vendor" + "font name"

.

Table a BaalQ Font Hanea

1. HERSHEY: CARTOGRAPHIC ROMAN

2. HERSHEY: CARTOGRAPHIC GREEK

3. HERSHEY: SIMPLEX ROMAN

4. HERSHEY: SIMPLEX GREEK

5. HERSHEY: SIMPLEX SCRIPT

6. HERSHEY: COMPLEX ROMAN

7. HERSHEY: COMPLEX GREEK

8. HERSHEY: COMPLEX SCRIPT

9. HERSHEY: COMPLEX ITALIC

10. HERSHEY: COMPLEX CYRILLIC

11. HERSHEY: DUPLEX ROMAN

12. HERSHEY: TRIPLEX ROMAN

13. HERSHEY: TRIPLEX ITALIC

14. HERSHEY: GOTHIC GERMAN

19. HERSHEY: GOTHIC ENGLISH

16. HERSHEY: GOTHIC ITALIAN

8.2 Generalised Craving Prlnltlve Blenents

The following GDP Elements are considered common enough within

the TOP/MAP computer graphics community to varraint registration.

8.2.1 Axle

Most graphs require axis lines and scales to indicate the

orientation and value of the plotted data points. The most common

type of scaled axis is easily produced by this GDP. _The GDP draws

any length line at any angle, divides it into one-inch^ segments,

annotates the divisions with appropriate scale values, and labels the

axis with a centered title. When both the X and Y axis are needed,

the GDP cam be specified separately for each one.

GDR.IPgaTlglgB - -1

HUMBER OF POINTS - 4

LIST OF POINTS - (xl) xcoor

(yl) ycoor

(x2) divis

(y2) axlen

(x3) angle

Draft Version - 7 August 1986

- X coordinate of the axis line's

statrt point in ’/DC. - Y coordinate of the axis line's

start point in VDC.

- The division along the axis in

VDC. If VDC Scaling Mode was

metric with a scaling factor of

29.4, then to have 1 inch

divisions this value would be 1

.

- Length of the axis line in VDC.

- Angle at which the axis is to be

Page 168
GraplLlcs Docrment 66-39 R1 TOP/XAP OCM Application Profile

drawn. Normally this Is zero for

a x-azis and 90.0 for an y-axis.

(y3) tickv - The value that will appear at the

first tich marh on the axis.

(x4) tichd - The number of data units per

division along the axis. This

value is eidded to the "tichv*

parameter for each succeeding

division along the axis.

(y4) This value is ignored

GDP DATA RECORD - Single string of text. This is the title to

be placed on the eixis.

8.2.2 Grid

Some graphs require a grid to be overlaid on top of the plot

data points. This GDP will permit specification of an overlay grid

in a compact mainner.

GDP 1 HUllBER OF poors

LIST OF FOOTS -

-2

- 3

(Xl)

Cyl)

(x2)

(y2)

(x3)

xcoor

ycoor

xlen

ylen

xdelt

(y3) ydelt

GDP DATA RECORD - K/A

X coordinate of the grid's start

point

.

Y coordinate of the grid's start,

point.

Length of grid along the z-azis in

VDC.

Length of grid along the y-azis in

VDC.

Delta between x-axis grid lines in

VDC.

Delta between y-axis grid lines in

VDC.

8 . 3 Escape Elements

The following Escape Elements are considered common enough

practice or of important enough use to warrant registration.

8.3.1 Disable Clearing of Vievsnrface

Normally, the viewsurface will be cleared on each Begin Picture

Element. This Escape Element will disable the clearing of the

viewsurface for the picture that follows this element. This Escape

Element must precede every Begin Picture Element that corresponds to

the picture that is to be overlayed on top of the current picture.

This Escape Element will have no effect on the resetting of the

metafile defaults on each Begin Picture Element. This Escape Element

is a basic capability of the TOP/MAP CGM Application Profile.

Page 169 Draft VeMlow ~ *7 iofl« I
TOP/MAP CGM Application Profile Graplilcs Doouent 86-39 Ri

gSCAPg XDBfTIPISB - -1

SSCAPS DATA RECORD - N/A, ignored if specified

8.3.2 Dasli Llne/Bdge Type

A Significant nnaber of computer graphics systems permit a

client to program the line type for line and edge attributes. This

Escape Element defines the dash and gap length for line and edge

attribute type "dash”. The Escape Element will only ;i|hf feet

subsequently -defined line or fill area graphical primitives. This

Escape Element is a basic capability of the TOP/MAP CGM Application

Profile.

BSCAPB DATA RBCORD - A Single String Of text. This is the

definition of the length of the

line segment and the gap in VDC.

The string Is in a FORTRAB F9.4

format. There is no separator

between the two format

specifications

.

For example, a dash line t3rpe with a line segment of 0.4 VDC and

a gap segment of 0.29 VDC would be. coded with the following Escape

Element

.

BSCAPB IDBBTIFTBR - -2

BSCAPB DATA RBCORD - ”0000.40000000.2500”

8.3.3 Dash-Dot Llne/Bdge Type

A Significant number of computer graphics systems permit a

client to program the line type for line and edge attributes. This

Escape Element defines the dash, dot, and gap length for line and

edge attribute t3npe ”dash-dot”. The Escape Element will only effect

STibsequently defined line or fill area graphical primitives. This

Escape Element is a basic capability of the TOP/MAP CGM Application

Profile.

BSCAPB IDBaTIFIBR - -3

BSCAPB DATA RBCORD - A Single String Of text. This is the

definition of the length of the

long 8ind short line segment and

the gap in VDC. The string is in

a FORTRAN F9.4 format. There is

no separator between the three

format specifications.

For example, a dash-dot line t3^e with a long line segment of

0.875 VDC, a short line segment of 0.5 VDC and a gap segment of 0.25

VDC woTild be coded with the following Escape Element.

Draft Version - 7 August 1986 Page 170
Graphlos DocnMnt * 86-39 R1 TOP/HAP CGM AppUoatlon Profile

ESCAPE umwnrisR - -3

ESCAPE' DATA RBOORO - "0000 . 87900000-. SOOOOOOO . 2500*

8.3.4 Dash-Dot-Dot Llaa/BdgE Type

A signlfloant number of computer graphics systems permit a

client to program the line type for line and edge attributes. This

Escape Element defines the dash, dot, eind gap length for line and

edge attribute type " dash-dot -dot " . The Escape Element will only

effect subsequently defined line or fill area graphical primitives.

This Escape Element Is a basic capability of the TOP/MAP CGM

Application Profile.

ESCAPE ujErriria - -4

ESCAPE DATA RECORD - A single String Of text. This Is the

definition of the length of the

long flind short line segment and

the gap In VDC. The string Is In

a FORTRAN F9.4 format. There Is

no separator between the three

format specifications.

For example, a dash-dot line type with a long line segment of

0.79 VDC, a short line segment of 0.379 VDC and a gap segment of 0.2

VDC would be coded with the following Escape Element.

ESCAPE IDENTIFIER - -4

ESCAPE DATA RECORD - "0000.79000000.37500000.2000"

Pago 171 Draft Version - 7 Autfust —— 1986
Final Report

NBS Order Number 43NANB6 1 2433

Evaluation of European Graphics Validation Suite

30 July 1986

GSC Associates Inc.

13663 Prairie Avenue

Suite B

P.O. Box 2286

Hawthorne, CA 9025

1

213-978-9351
CONTENTS

1. Introduction

LI Statement of the problem

1.2 Approach to the problem

1.2.1 Installation and execution of tests 1.2.2 Analysis of test structure

1.2.3 Requirements traceability

1.3 Summary of results

2. Data Structure Tests

2.1 Structure and philosophy of the tests 2.2 Results of executing tests 2.3 Conclusions

. 3. Error Tests

3.1 Structure and philosophy of the tests 3.2 Results of executing tests

“ 3.3 Conclusions

4. Operator Interface Tests

4. 1 Structure and philosophy of the tests 4.2 Results of executing tests 4.3 Conclusions

5. Requirements Traceability Analysis

6. Recommendations

Appendix A - Size of load modules

Appendix B - Polyline requirements

Appendix C - Listings from installation

Appendix D - Listings from data structure tests Appendix E - Listings from error tests Appendix F - Listings from operator interface tests
1.0 Introduction

This document is the final report by GSC Associates Inc. for contract number 43NANB612433.

Under this contract, GSC Associates provided assistance to NBS in its work for the Department of

Defense Computer Aided Logistic Support (CALS) program. The purpose of this contract was to

make recommendations to NBS to help accelerate and complete the ongoing evaluation of the

European graphics validation suite, and to provide a recommendation for a DoD graphics validation

approach.

This introductory secdCTi will provide a summary of results and a description of the approach taken

in evaluating the European validation tests. Subsequent sections of the report address each major

category of test in turn - data structure tests, error tests, and operator interface tests -- describing

the structure of the tests, the results obtained by executing them on a commercially available GKS

implementation, and conclusions regarding their utility for DoD purposes. A section is devoted to an analysis of how well a few selected GKS requirements are tested by the European validation

tests. Finally, recommendations are made regarding future work and the utility of the tests for DoD

graphics validation purposes.

GSC Associates wishes to acknowledge the assistance of TRW Defense and Space Systems Group

in completing this work. TRW assisted by making a VAX 8600 computer and Tektronix 4128

graphics terminal available to us for executing the test programs.

1.1 Statement of the problem

The great diversity of graphics packages with different philosophies has inhibited the development

of graphical applications software. Graphics standards - such as the Graphical Kernel System

(GKS) and the Computer Graphics Metafile (CGM) ~ have been developed to help eliminate this

problem and to encourage portability between different environments. A validation procedure is necessary to insure that implementations of standards, such as GKS, are consistent with the

standards. Without this consistency, the advantages of portability are lost

Recognizing this, the European Community sponsored a series of workshops during 1981 and

1982 to develop a methodology for testing GKS implementations. The development of a suite of

tests ~ based on the methodology developed at these workshops -> was subsequently funded. The

actual development work was done at the Technical Univenity of Darmstadt in the Federal

Republic of Germany, and the University of Leicester in England. The development work was

supervised for the European Commission by the GMD (Gesellschaft fiir Mathematik und

Hnal Report Page M
Datcnverarbcitung) in the Federal Republic of Germany.

The European test suite is supposed to subject a completed GKS implementation to a thorough test of its consistency with the GKS standards with hopes of discovering errors. The less errors a

particular implementation generates, the greater degree of standardization it contains, yet the lack of

errors generated does not guarantee correctness. As the test suites are developed further, the degree

of confidence in the correctness of the implementation will increase. Basically, the GKS

implementation is tested by calling GKS functions, sometimes in conjunction with input devices,

which generate a response. The responses from these calls are then evaluated and corresponding

error messages reported if the responses are not as those designated by the GKS standard. The

operator interface tests are evaluated a little differently since they require human visual evaluation of

the graphical output from the device chosen for test

The GKS validation test suite developed under the sponsorship of the European Community

consists of three sets of tests. One set tests the data structures internal to GKS; a second set tests the errors that occur when executing GKS functions; and the third set tests the general functionality

of GKS at the operator interface level. All of these tests are at the level of what would commonly

be referred to as ''system acceptance tests” in DoD terminology.

The data structure tests consist primarily of a dialog between the certification program and the GKS

implementation. GKS routines are coirectly called under valid states of GKS in order to determine

the viability of the implementation. The responses of the GKS implementation are then written to a report file.

The error tests check the response of the GKS implementation to deliberately induced error

situations. Specifically, the error messages returned by the implementation are compared with a list of correct responses, and reports of these comparisons are ^;mtten to a report file.

The Operator Interface Tests consist of an "Operator Script” and output to the screen of a workstation. The Operator Script tells the operator what the screen should be displaying, and

provides a form for noting the agreement or discrepancies between the scripted version and the

actual content of the screen display.

The purpose of the contract reported on here was to advise the NBS concerning the suitability of

basing a DoD validation procedure for GKS implementations on the European GKS validation

suite. If these tests are of sufficient quality, their use can save the substantial development effort

needed to implement alternative tests.

Final Report Page 1-2
1.2 Approach to the problem

To evaluate these tests, GSC Associates devised a three part strategy. The first part of the strategy

involved installing and executing the tests in a typical environment in the United States. The

second part of the strategy involved analysing the structure of the tests themselves to determine the

quality of their construction and their modularity and ease of use in testing GKS implementations,

especially on smaller computers or in imbedded processors. The third part of the strategy involved

a detailed investigation of the extent to which the routines test the requirements in the GKS

specification. Each of these components of the evaluation strategy is discussed in more detail in

subsequent paragraphs.

1.2.1 Installation and execution of tests

By instaUmg and executing the European validation tests in a typical DoD contract development

environment in the United States, a great deal can be told about their utility. GSC Associates has

installed the validation tests from a distribution tape furnished by National Bureau of Standards on

a DEC VAX 8600 running the VMS operating system. All three sets of tests have been executed

against an ISSCO GKS implementation using a DEC VT240 terminal and the operator interface

tests have been executed using a Tektronix 4128 terminal. In addition, some of the tests were

executed using the Tektronix terminal and the DEC implementation of GKS.

The Validation Tests were developed in a European academic computing environment and have not seen extensive use within commercial production environments or the DoD contractor software

development environment in the United States. By installing and executing the tests, several goals

were achieved:

1. The effort required to install and customize the test routines for a new environment was

I evaluated.

2. The quality of tests was determined by scrutinizing test results to see if errors encountered

during the execution of tests are due to errors in tests themselves or in errors in the GKS

i implementation.

3. The quality of the documentation furnished with the tests was evaluated. The test scripts

I furnished with the operator interface test in particular, were checked for ease of use and

quality.

I The results of executing individual sets of tests are contained in Paragraphs 2, 3 and 4 of this

Hnal Report Page 1-3
document The results of the installation procedure itself, are discussed below. In general, we

were disappointed with the quality of the installation instructions, the ease of customization of the

routines to a new environment, and the quality of programming practice used in their construction.

Specific comments are:

1. The test programs contain many spelling errors. Additional documentation of some of these

can be found in item 2 of section 2.2 of this report Even output to the screen during the

operator interface test often contains spelling errors! The presence of such a large number of

errois is indicative of a lack of care and a lack of proper quality assurance procedures in their

development

.

2. Directions for modifying test routines is contained both in the written documentation

accompanying the tests and in the source code itself. For example. Page 8 of the documentation

furnished with the tests discusses customization of the routine UWKVAL. When one begins

modifying the code for this routine, additional items which must be changed*to encountered in

comments contained in the code itself. Excerpts from the installation instructions and from the

subroutine UWKVAL that illustrate this are contained in Appendix C

3. Page 7 of the documentation , line number 4, instructs the installer to use the text editor to

search for the phrase "C EFFECT*. From the documentation it is not possible to ascertain

how many spaces occur between the letter ”C*' and the word "EFFECT', thereby, making it impossible to use a text editor to search for the string.

4. On page 8 of the documentation. Section 3.2.2.2, subroutine UWKVAL is misspelled as UNKVAL.

5. The documentation regarding modifications required to the ERNAME is very unclear, for

example, what is the "GDP identified’ and where is the source of the information regarding it

6. Some documentation in the test programs is in German. Appendix C contains a portion of

subroutine PDINIT which illustrates this.

7. The structure of, and comments contained in, the headers to the test programs are of uneven

and inconsistent quality. Maintenance logs contained in many programs should have been

removed before the routines were delivered. Appendix C contains listings from subroutines

ECHEKR and ESTART which illustrate this. Almost all of the programs and subroutines have

these problems.

Final Report Page 1-4
8. During installation, the identical item must be modified in a number of subroutines. Examples

are the number of workstations, the list of the identifiers of workstations and the name of the

GKS implementation. Proper programming practice would be to use a single INCLUDE file to define ail of these items in FORTRAN source code which is the automatically ’’included” in

each program at compile dme. This would increase the modularity of the tests and prevent

inadvertent errors due to inconsistent updates of source code.

9. There are apparently no standards for naming items within test routines. For example, the

number of woikstations is called NUMWK in one routine and NWR in another. This makes

it difficult to understand how the routines function when problems occur.

10. A number of special FORTRAN statements have been left in the test routines for the PERQ

graphics system. Although these have been commented out, one wonders if this extensive

level of customization is required for testing other GKS implementations. If so, general

instructions should be given for adding these items, otherwise, they should be*deleted from the

delivered validation suite. Appendix C contains a portion of subroutine ESET which

illustrates this.

11. The installation instructions contained in some of the programs allocate storage for the item

BUFA. Nothing explains the use of BUFA or the appropriate value to be used for it. After

some analysis, it appears that the length of this array corresponds to the number of memory

units contained in the OPEN GKS function call.

12. Documentation contained in the OINTT routine states that it belongs to Version 2.0 of the test suite, however, written documentation furnished with the tests say that they are Version 1.0.

Also, this procedure prints out lines to the screen which are cut off, for example, "GKS TEST

SUITE...” becomes ”KS TEST SUITE...” and "IMPLEMENTATION:” becomes

"MPLEMENTATION:”. The WRITE statement that prints out these lines needs a carriage

control character as the first character in the front of the text as documented in listing of OINTT

in Appendix C.

13. The last line of Page 10 of the documentation refers to "graphics file”. It appears that this is a

reference to a graphical metafile but it is confusing to installers to refer to it as a graphical file. This is a general problem with the names of other files used by the test programs since they are not descriptive enough of their general function and use. In particular, the names for error file are inconsistent and it is difficult to teU which file is used for which purpose, without making a

Final Report Page 1-5
detailed analysis of the code. This can be seen in subroutines D201 1 and UFUNS.

14. In general, no use was made of proper structured FORTRAN programming practices in writing

the test routines. The INCLUDE statement - which could provide a large degree of modularity

and ease of customization to the programs - does not appear to be used at alL Some critical

items, for example, the number of supported workstations and the names of the supported

workstations - are hard coded in subroutine D2011 ! Many common blocks are used

throughout the test programs. They should be defined once and then INCLUDE’d in programs

rather than hard coded into each routine.

15. Items in some common blocks appear to be initialized with assignment statements rather than

through data statements. This is very poor programming practice.

16. In the code documentation, there are many grammatical eiron, especially in the data

structures tests. Appendix C contains the listing of programD2013 which illustrates this.

17. Before procedure ESTART could be compiled, the statement

QPEN(UNrr=FUNrrJTLE=FILENAME(1 : 10))

which caused the information message:

%FORT-I-DEFSTAUNKJ3efault STATUS=UNKNOWN’ used in OPEN statement

[LE=FNAME(1:10))] in module ESTART at line 90

was modified. This procedure now compiles without producing the information message afterchanging in this line to

OPEN (UNIT=FUNIT,STATUS=NEW’3LE=FILENAME(1.T0))

It is poor programming style to allow such a file OPEN statement to take a default status value

since it can lead to inadvertent destruction of the opened file. The coiTection to this coding enor

is documented further in Appendix C.

18. The installation instructions do not contain a list of temporary files which are created during

execution of the tests. There appears to be no consistent philosophy regarding the use and

naming of temporary files either. The tester must inspect his directories at the conclusion of a

Final Report Page 1-6
test and guess which files should be printed and/or deleted.

19. A list, included in the installation documentation, of which test programs use GKS segments

would aid the user in knowing when to add code to allocate a common block of segment work

space. The adding of this common block is a customization needed when dealing with

segments in certain GKS environments. Since some GKS environments reserve their own

segment work space without the user needing to add a common block allocating storage for it,

this implementation-dependent customizadon can not be included in the test programs. It is something that should be noted in the documentadon, however.

20. Many of the test programs have the following text hard-coded into them: CHAR*80

WKNAME (46) and PARAMETER (NAWK=46). It would be more effecdve to make these

environment dependent parameters so they can be initialized only once.

21. Many of the programs and the subroutines they call could use some documentation giving a brief description of what they perform at the beginning of the code, for example, EREP,

ERNAME, ERQPXR, ESET, ESEXER, and others have little or no interrxal documentation.

1.2.2 Analysis of test structure

All main programs of the data structure and error tests were inspected to determine which

subroutines were used. This process was continued for subsequent calls to subroutines until the

lowest level of detail was reached. This resulted in a complete picture of the hierarchical stracmre

of the test suites, some of which is presented in the appropriate paragraph for each class of test below. The size of the load module for each main program for the VAX environment is given in

Appendix A. The average size load module and the smallest size load module for each test are given

in Table 1.

Class of Average Maximum

Test Size Size

Data structure 410 K 546 K

Error handling 384 K 468 K

Operator interface 435 K 494 K

Table 1. Load module sizes

Final Report Page 1-7
The load module sizes for GKS implementations in other environments are expected to be

comparable to those m Table 1. Based on this information it appears unlikely that the tests will be

usable in environments where there is less than 512 K bytes (half a megabyte) of available RAM.

1.2.3 Requirements traceability

A detailed examination of GKS requirements relating to the POLYLINE primitive was performed

to analyze the test coverage for that portion of GKS. The methodology followed was:

1) The GKS Standard was examined to determine requirements relating to POLYLINE.

2) A subset of these requirements, relating specifically to transformations, and the attributes

POLYLINE Index Linetype ASF, Linewidth Scale factor. Polyline Color Index, Linetype

ASF, Linewidth Scale Factor ASF, and Polyline Color Index ASF was chosen. This subset

was selected to examine these basic features in some depth.

3) The degree to which the validation tests tested these requirements was then determined.

This process is complicated by the fact that the GKS standard is not written in a form where

requirements are clearly and explidtly stated. To illustrate how testable requirements were derived

from the GKS standard, consider the following extract which defines the GKS Inquire Polyline

Facilities function:

INQUIRE POLYUNZ PACUIXES

Parameter*:

G2CCP,W0P,WSAC;3G0P Lm

In workstation type N

Out error indicator I Out number of available Unetypes I Out list of available Unetypes (-a..-l,l..n) n)d

Out number of avaOabte Unewidths (0..a) I Out nominal linewidth DC >0 R

Out rante of linewidths (mioimum.maximum) DC >0 2XR

Out number of predefined polyline indices (0,S..a) I Effect If the inquired information arailnble, the error indicator is retamed as 0 and values

are retamed in the oaepot parameters.

If the number of available Unewidthe is recuraed ae 0, the workstadon supports a continuous ran^e of linewidths.

If the inquired inform adoo m not available, the values returned in the output parame- . ters are implementation dependent and the error indicator is set to one of the foilowinf

error aumbers to indicate the reasoa for non-avaiIabUit]r:

S GKS not in proper state: GKS Muff ie sri one of Ike iinteo GKOP, WSOP, WSAC or SCOP

it Specified workstation tj;pe io tnvaiid

2S Specified workstation type does not eziH

39 Specified workstatien io neither of category OUTPUT nor of category QUTIN

Final Report Page 1-8
A number of explicit requirements were derived from this texL One of the derived requirements

and a description of what must be done to test it adequately are given below:

Requirement:

When the Inquire Polyline Facilities function is invoked and GKS is not in one of the states GKOP, WSOP, WSAC, or SGOP, then the error indicator must be set to 8.

Test:

Put GKS in state GKCL and call the hiquire Polyline Facilities function. Check that the integer

value 8 (indicating error number 8) is returned in the error indicator parameter.

Based on derived requirements and test descriptions ~ such as the one illustrated above — the source code for the validation tests was inspected to determine the degree to which requirements

were tested. The results of this evaluation are presented in Section 5 of this report

1.3 Summary of results

The test suites were successfully installed on a Digital Equipment Corporation VAX 8600 computer

running the VMS operating system. The graphics capabilities available on this computer include

the ISSCO and the Digital Equipment Corporation (DEC) implementations of GKS. Graphics

output devices included a Tektronix 4128 terminal and DEC VT240 terminals. A moderate amount

of difficulty was encountered in installing the tests due to the poor quality of the documentation

furnished with the test suite. For example, instructions detailing how to customize certain

subroutines for a particular GKS implementation were contained in the written documentation

accompanying the test suite and others in comments contained in the source code to the subroutines

themselves. For several routines, both sets of instruction had to be followed.

The error tests and data structure tests were both completely executed using the ISSCO GKS

implementation and with VT240 terminaL A large number of error messages were generated as a

result of the execution of these tests. For the data structures tests, some of the errors were

programming errors in the GKS test programs and some were errors in the ISSCO GKS

implementation which were discovered by the tests. Problems encountered executing the error handling tests were due mostly to programming errors in the GKS test routines. The operator

interface tests were also completely executed with more favorable results. A moderate number of

errors were encountered executing these tests with both the DEC VT240 terminals and the

Tektronix 4128 terminal and most were due to errors in the ISSCO GKS implementatiorL

Rnal Report Page 1-9
A determination of the structure and organization of the test programs was completed. During

inspection of source code for the routines, numerous problems with programming practices used in

their construction, the quality of their internal documentation and FORTRAN language coding

errors were encountered. These problems are documented below in the discussions of specific

tests. Our overall impression is that the data structure and error tests are of very low quality. The

operator interface test source code is better, but still contains a number of errors and examples of

poor programming practices.

The degree to which the validation tests determine conformance to GKS requirements was

evaluated. This was done by taking a representative set of requirements - - some of those associated

with the POLYLINE ouq)ut primitive of GKS - - and determining if these requirements are tested in

the validation routines. The more obvious requirements were usually well covered by tests at an

appropriate level for an acceptance test procedure. Less obvious requirements were poorly tested or not tested at all. Some requirements were identified that could not be tested through the GKS

subroutine call interface. Other forms of requirements verification - such as analysis or '’internal

unit-level” tests must be used to verify these requirements

Our conclusion is that considerable effort will be required to bring the European validation suites up

to an acceptable level for either DoD purposes or for use in "commercial” testing in the U.S. Effort

will be required to properly document the internal structure of the tests, rewrite portions of them

consistent with good programming practices, correct coding errors, and add additional tests to increase the degree of requirements validation. A detailed list of recommendation is given in Section

6 of this report

Final Report Page 1-10
2.0 Data structure tests

The data structure tests check that the various GKS state lists are correctly updated as a result of

calls to GKS functions. There are 30 data structure test programs which are ail contained in the test directory VPROG. The following paragraphs describe the structure, results of execution, and our

conclusions regarding these tests.

2.1 Structure and philosophy of the tests

These thirty data structure tests each have a name which begins with a character "D” which denotes

that they are data structure tests. A common set of subroutines are used in each test. Routines

which are called in most of the tests are PDINTT, PDTRNP, CWRITE, DINTT, CPUT, and

CNTJMER. These routines perform the following fimetions:

PPTNTT - initializes the description file XAIDSR.CIP if necessary, initializes the

common areas, and requests the current test level and whether the trace facility is desired from the tester;

PDTRNP - pyrites a program or procedure name to the trace file;

CWRITE - writes a program name and error message to an error report file;

DINTT - opens GKS and then opens and activates the requested number of

workstations;

CPUT - puts a program name and message number onto a message stack to later

be used in an error report file; CNUMER - writes the number of detected errors, test level, and supported

workstations to the screen and error report file.

For the most part, other subroutines in the data structure tests are used to call specific GKS

functions. For example, DOPKS calls the OPEN GKS function — GOPKS. These subroutines are named by replacing the "G” sentinel character in the FORTRAN Language Binding of a GKS

routine with the character ”D”.

Final Report Page 2-1
To illustrate the degree of care exercised by the writers of the data structure tests, test program

D2012 was analyzed in detail. The following paragraphs lists specific problems found in this test program and its documentation. A complete listing of this program is contained in Appendix D.

This listing is annotated with numbers keyed to the following comments.

1. The documentation in the header for this program states that it is a "LOA” Test Program

rather than a '*L0A” Test Progranu This is a typographical eiror resulting from using the

capital letter "O” rather than the numeral ”0”.

2. In describing the effect of the test program, the word INDEPENDENT is

misspelled INDEPENDED.

3. In the describing the errors generated by this program. Error 1390 is described as 'Try to Set

Linewidth Scale Vector** rather than "Try to Set Linewidth Scale Factor**. The proper term

(according to the GKS standard) is Linewidth Scale Factor.

4. Spaces are omitted from comments many places in the documentation. For example, ’*crcation

date**, '* trace mode'*, and **logical unit number'* are all printed without one or more of the

appropriate spaces.

5. Some internal documentation remains in the headers of the test programs and was not

removed prior to distribution. For example, the project is identified as '*VALGKS

Application'* and the update history of the program is given. These arc not of interest to

anyone but the original developer of the program.

6. The header of the test program indicates that it tests **GKS 7.4**. This refers to a early

DIN version of GKS rather than to the current International Standard version.

The documentation should state that what is being tested is ISO GKS (ISO 7942), not GKS

7.4.

7. An inconsistent style of continuation statement is used in the declaration of common block

PDCTRL. On some lines, the comma indicating the separation between adjacent items in the

common block is included at the end of a line and on some lines it is carried over to the

beginning of the line.

8 . The comment statement, **Dummies For Not Used Parameters'* is grammatically incoirect

Hnal Report Page 2-2
9. In the comment for "Intern Integer Variables", the word internal is abbreviated

unnecessarily to "intern" rather than the full word "internal". Such stylistic conventions make

the internal documentation of the tests more difficult to read.

10. Several large common blocks which occur in many of the data structure test programs

are reproduced in the code of each program rather than being included from a common

external file.

11. Both the asterisk (*), plus sign (+), and numeral 1 are used in column 6 to indicate

continuations. This is poor programming style.

12. The program documentation makes no distinction between the notion of available

workstation and active workstation. For example, the parameter NAVWK is declared to represent the number of available workstations but when it is used as a limit for the DO loop

ending at line 100, it is stated to represent the number of active workstations.

13. The style in which the FORTRAN code is written is extremely poor and shows a total

disregard for consistent programming practice. For example, indentation is used

inconsistently to set apart portions of the code which are inside statements and

DO loops. The listing in the appendix is annotated to show two IF statements, one of which

is set apart by a single space of indentation and the other one of which is not indented at all.

It also shows a DO loop which is not set apart by any indentation.

14. The main portion of the test program loops over all active workstations and attempts to set a range of values of indices associated with Polyline attributes. The listing in Appendix D is annotated to show one such call to subroutine DSFLI. The listing states that the purpose of

this call is to "Set Minimal Index". When the code for subroutine DSPLI is inspected, one

quickly discovers that in fact, DSPLI performs many more functions than simply setting a Polyline Index. In fact it appears to set values for many other Polyline attributes. This

causes severe problems when errors occur in the test since a routine may generate a large

number of unexpected errors and there is no indication in the higher level documentation that

these errors could be generated. A listing of routine DSPLI is included in Appendix

D to illustrate this fact

Final Report Page 2-3
15. When an index — such as Polyline Index — which can only take values from a small discrete

set is tested it would be most appropriate to test all the values than simply testing the minimal

one, maximal one, and the value in between. This would be easily accomplished, would

take very little additional execution time, and would provide much higher degree of

confidence in the integrity of the GKS implementation. The strategy of testing minimal

values, maximal values, and a value in between is most appropriate for those item which take

their values from a continuous range.

The documentation in the headers states that no random values are used for parameters. It would be better however, to generate a random value, or even better, a set of random values

between minimum and maximum values for certain parameters for testing purposes, instead

of using a point in the mid range,

16. During the inspection of the codes for subroutines DSPLI and DSPLCI, it was discovered that

they were virtually identical. This is the case with almost all of the data structure tests. A large number of routines - some consisting of hundreds of lines of code - are identical

• except for a few lines. Appendix D contains listings of routines DSPLI and DSPLCI both

with annotation showing the differences in the programs. Many of these programs could be

collapsed into a single routine with a single parameter passed as an argument indicating

which alternative lines should be executed. It would appear that the developers of these’test

programs were paid based upon the number of lines of code generated rather than the quality

of the code.

17. In the next to the last line of the program, the word program is misspelled PROGRAMM.

18. There is no list provided of all of the errors generated by the data structure test If for

example, error number 1367 occurs, and the tester wants to know what this error is and

which routines could generate it, the only way to determine this is by reading the headers for

all the individual test programs!

2.2 Results of executing tests

A number of erron in the code and documentation of the test programs were encountered during

the process of executing the tests. In addition, several errors in the ISSCO GKS implementation

were found as a byproduct of executing the tests. A representative sampling of both are explained

in this section.

Final Report Page 2-4
2.2.1 General problems

1. The data structure tests are not modular. There is no apparent way to tell from the name of the

program what is tested. Since many routines call GKS functions that are only found in higher

level implementations, they couldn't even be linked to test the DEC level OB implementation.

The tests query the operator for the GKS level number, but this is of no avail if the proper

subroutines aren't available for linking. Programming practice based on proper use of

conditional compilation could avoid this problem

2. There are many spelling errors displayed on the screen which include: "SPECIFIC’

is misspelled as "SPEZIFIC’ and "WORKSTATION INDEPENDENT' is misspelled as "INDEPENDEND" during the queries for the creation of the file XAIDSK.CIP; "WA>Tr

TRACE PROTOCOL?" is misspelled as 'TROTOCOLL" which is queried at ±e beginning of

each test program; at the end of a run, where the programs display results, "CATEGORY" is

misspelled as "CATEGORIE’ and "PROGRAM" is misspelled as ’TROGRAMM".

• # 3 . Much of the information queried for in the process of creating the file XADSR.CIP is already

supplied in the device dependent routines after the user has changed these routines to work

with the site's particular system It is redundant to query for this information.

4. In the creation of the file XAIDSR.CIP, the program at one point queries for information

regarding the OUTIN workstations to be tested. When it asks for the coimection type for the

workstation, it asks for the type for an INPUT workstation.

5. When the file XAIDSR.CIP is being created, the user is occasionally queried for numerical

data and is prompted with the line, '70RMAT=I2". On the next line, "12" is then displayed. It

is not clear what this is to designate.

6. At least 3 of these programs when executed do not return control to the tester and have to be

aborted.

7. In data stmcrores tests involving segmentation, at run dme the error message "»» Error

following link QGMSEG" and also "»» Improper medium code O, LSUO'’ are displayed on

the screen. It is not clear as to what is causing this problem In program D2013 these

messages seem to be generated after the call to QCRSC (Create Segment) within the subroutine

DCRSG. Other test programs which generate these messages are: D2016, D2026, D2036, and

Rnal Report Page 2-5
D2056. These error message do not appear to be generated by the validation tests and appear to be due to errors in the ISSCO GKS implementation. It is interesting to note that the tests do not

explicitly detect these errors.

8. In several programs, in particular D2024, errors are generated regarding the manipulation of

tables dealing with Pattern fill area style. Pattern is not supported on the Tektronix 4128 nor the

VT240 and in several tests the code should query about Pattern facilities before trying to test them. Other programs affected by this problem are: D2041 and D2042. Program D2024 and its error messages regarding this problem are documented in Appendix D. Program D2024 needs

a call to GKS function GQPAF (Inquire Pattern Facilities) in the code before an attempt to use

Pattern is made. This is not done in any of the mentioned programs. Based on the results of

this inquiry, use of Pattern should not be attempted if it is not supported. It appears that the

programs designed to test implementations of the device-independent GKS standard are not

them themselves device-independent!

2.2.2 Problems in specific tests

Test D2011. A "current GKS language binding error" number 2002 is reported when executing

this test. This error indicates that an attempt was made to access a non-available element of a set or list It occurs in the call to GQACWK (Inquire Set of Active Workstations) and is caused by

the test program calling GQACWK with the Set Member Requested parameter greater than the

implementation's "Number of Active Workstations." Similar errors occur in many of the data

structure tests and appear to be due to the "hard-coded" parameters in the source code and the

failure to code in a device- and implementation-independent maimer by inquiring certain

facilities before attempting to access unsupported features or elements.

Many times the error messages generated by test programs do not indicate specifically what

or where the error is. For example one error generated in D201 1, is "1 350 Program starts

with errors". No information is provided to tell the tester what problem exists or how to correct

it The code generating the error and the error message from D2011 are documented in

Appendix D.

Test D2021. There is an access violation error from line 166 which calls DOPWK in which line

393 holds the error. The run time error received was:

%SYSTEM-F-ACCVIO, access violation

Final Report Page 2-6
DOPWK is called and within that there is a call to GQSKS (Inquire stroke device state) which

is the line with the error. Insufficient time was available to completely investigate the cause of

this error, but it appears to be due to an error in the ISSCO GKS implementation.

Test D2024. An error message regarding GKS function GQCR ~ color representation not

delivered — is generated when run on the VT240 (which is a monochrome device that doesn’t

support color)but is not generated on the Tektronix 4128. The VT240 also reports GKS error number 94 (”A representation for the specified color index has not been defined on this

workstation".) This is not an error in the implementation but rather in the test program. The test program should inquire a workstation about its color facilities using GQCF (Inquire color

facilities) before issuing this GQCR inquiry on a workstation that doesn't support color. The

code and error messages regarding this problem are documented in Appendix D.

Test D2041. There was a "current GKS language binding error number 20QT involving a call

to GQACWK(Inquire set of active workstations). After inspecting the code for this test it was

determined that this message was due to the ISSCO GKS implementation passing back an- invalid error indication to the test program in the error indicator parameter. For this particular

call, the only valid error indicator values are 0 and 8. The test did not explicitly find this error and actually made it difficult to diagnose due to the cryptic diagnostic message provided to the

tester. An explicit message such as "GQACWK returned an invalid error indicator value of

2002. The valid values are: 2, 8" would aid in diagnosing such problems. The code and the

error message are documented in Appendix D.

2.3 Conclusions

The internal documentation for the data structure test describes the overall effect of the test The

programming style and degree of commenting does not permit a quick reading of how the effect is

achieved. This is a definite deficiency finom a maintenance point of view.

The whole philosophy behind the data structure tests is flawed. Since no graphical output is

produced during the tests, an implementation could pass by correctiy implementing the update of

certain internal data items in response to the invocation of GKS functions. Unfortunately, updating

the data structures alone is not sufficient An implementation must modify its future behavior —

especially the graphical output it produces - based on these values. This is not tested! The only

valid way to test the GKS data structures is to interleave such tests with the production of graphical

output Demonstrating that a value in a state list can be set is of little value if the implementation

makes improper use of that value.

Final Report Page 2-7
Execution of the tests provides only a very minimal amount of information regarding the correcmess of a QKS implementation. Many of the test routines perform functions other than those

expected and many contain nearly identical code. The diagnostic messages provided are cryptic and

nearly useless in locating and correcting defects in an implementadon. The quality of their source code and documentadon is extremely low.

Final Report Page 2-8
3.0 Error tests

The purpose of the error tests is to determine if error conditions are properly raised as the result of

executing GKS functions. The error tests are contained in test directory VERR and consist of 28

test programs and a number of subroutines. A description of the structure of the tests, the results

obtained in their execution, and conclusions regarding their quality are contained in the following

paragraphs.

3.1 Structure and philosophy of the tests

Twenty-eight main test programs are provided. The naming convention for these programs is as follows. Each program begins with the letters "ER" followed by two characters indicating the

lowest level of GKS to which the functions being tested belong, followed by two digits indicating

the number of this test within that level. For example, the first test program is named EROAOl,

indicating it is an error test which checks level OA fiincdons of GKS and it is the first test program

in the sequence of level OA error tests.

The order of the error test follows the organization of the GKS specification. For example, the first

few level OA tests test precisely the functions contained in sections of Paragraph 5 of the GKS

Specification:

1) EROAOl checks errors generated by control functions (Paragraph 5.2 of the GKS

Specification);

2) ER0A02 checks errors generated by output functions (Paragraph 5.3 of the GKS

Specification);

3) ER0A03 checks errors generated by output attribute functions (Paragraph 5.4 of the GKS

Specification);

etc.

Within each test program there is a well defined structure of subroutine calls. Subroutines

ETITLE, ESET, ESEXER, ECHEKR, ERNAME and ERE? are used repeatedly in all of the error

tests. These routines perform the following functions:

Final Report Page 3-1
fc i i TLE - writes the title of the test to the report file;

ERNAME - determines the valid range of a name;

ESET - checks and sets the GKS operating state; sets the size of the buffer, and the number of

supported workstations via implementation-dependent code supplied/modified by the tester,

assigns a workstation identifier to the specified workstation and disconnects the window

(for PERQ workstation only!);

ESHXER - sets up a list of expected erron;

ECHEKk - compares the errors that occurred with those that were expected;

EREP - writes a report of the errors to the report file.

A number of subroutines are used to call the GKS functions themselves and to generate error

conditions. These are named by replacing the ”G” sentinel character in the FORTRAN Language

Binding of a GKS routine with the sentinel character "E". For example, the error test subroutine

EOPKS, tests the OPEN GKS function - GOPKS. ’

3.2 Results of executing tests

During the process of installing and executing the error tests a number of errors in the tests themselves were found. In addition, one error in the ISSCO GKS implementation was discovered.

A representative sample of these errors are documented in this section.

3.2.1 General problems

1. At least 2 error handling test programs do not return control to the tester when executed and

had to be aborted.

2. Some of the text displayed to the screen is cut off, for example, during execution of the tests,

the statement '*EST IS RUNNING" is displayed instead of "TEST IS RUNNING". This

occurs in subroutine ESTART and therefore happens during all error handling tests. This

problem is caused by a FORTRAN coding error. The line of code which writes this to the screen docs not include a carriage control character before the text 'TEST IS RUNNING". The

source code containing this error is documented in Appendix E. It is difficult to imagine such

Final Report Page 3-2
an obvious error escaping detection and being delivered in the finished test routines. Perhaps

they were developed using a FORTRAN compiler that was itself incorrect!

3. Many errors were generated during the execution of the error handling tests. In general, the

only tests with few or no errors were the tests of inquiry functions. This is because these are the only tests to set the variable REP® in procedure ECHEKR which holds the reported error numbers. If the expected error number array EXPR(I) is not equal to the reported error number array REP® in procedure ECHEKR, the test fails. In the nonrinquiry tests, REP® is never set and therefore holds the value zero. The only tests which are reported as passing in

the non-inquiry tests are the ones with no expected error number (EXPR®=0). In addition,

these non-inquiry tests all get the error message ”GKS not in proper state” after each call to a GKS function since the error is generated by the test routine. The non-inquiry tests which are affected by this problem are: EROAOl, ER0A02, ER0A03, ER0A04, EROBOl, ER0B04,

ER0B05, ER1A03, ER1A04, ER1A05, ER1A08, ERlBOl, and ER2A01. This is a coding

error in the tests which should be corrected.

Two lines of code were added to subroutine ECHEKR which print the values of EXPR® and

REP® to the screen. When non-inquiry programs ER0A03 and ER1A05 were run with these

Hnes, the output showed that EXPR® always contained the expected error and REP® always

contained zero. When the inquiry test ER0A05 was run with these lines, the values of EXPR®

and REP® were always equivalent which caused the tests to pass. The lines added to

ECHEKR are document^ in Appendix E

4. The philosophy followed by most of the tests in examining the reported versus expected erron from a GKS implementadon is fundamentally incorrect The tests set up a list of expected

erron, call a GKS function under conditions where these erron could be reported, and then

check that all the expected erron are reported. This approach can’t work since the GKS

standard places no requirements on exactly which erron are reported in situations where more

than one error may occur. The only requirement is that at least one of the possible erron be

reported.

3.2.2 Problems in specific tests

Test ER0A02. There is an error generated at line 42 calling subroutine ECA which has the error

at line 102. The error message received at run time was:

%FOR-F- ADJARRDIM, adjustable array dimension error

Final Report Page 3-3
A zero values in the parameters DIMX and DIMY (dimensions of color index array) in the call to GKS function GCA - Cell Array — cause this error since these paiametcrs are required to be

integers in the range [l..n]. This error is documented in Appendix E.

Test EROAOS. Calls subroutines ESTXCI and ESFACI which are not included in the Appendix

of the GKS validation routines documentation.

Test EROAIO. Calls subroutine EQPFAR. It is not contained in the listing of subroutines

furnished in the Appendix of the GKS validation routines documentation. Subroutine EQFAR

is contained in the listing of subroutines furnished in the documentation for test program

EROAIO. It is not called and no source code is provided. Apparently, subroutine EQPFAR was

misspelled as EQFAR.

Test ER0A12. There is a run time error at line 32 calling subroutine EQPXA which has the

error on line 75. The error message received was:

9&SYSTEM-F-ACCVIO, access violation

1. The problem is that an incorrect FORTRAN binding for the call to GQPXA (Inquire pixel

array) was used in the test suite. Code calling the correct binding was contained in the source

listing but was commented out Apparently, the test suite was modified to show that an

incorrect implementation tested correctly and these modification were inadvertently left in the

delivered code. One wonders if this is common practice in "validating” GKS implementations

in Europe! There are 7 instances of this in the tests.

2. Once this error was fixed, an error on line 32 in the call to EQPXA which has the error on

line 214. The error message received was:

%FOR-F-ADJARRDIM, adjustable array dimension error

This error is caused in the last call to GQPXA which has values of 0 and -1 for the

parameters DX and DY (dimensions of color index array) while the GKS standard requires the

values be positive integers. These coding errors and the changes are documented in

Appendix E.

Final Report Page 3-4 a
Test EROBOl. There is a run time error at line 42 calling subroutine EINSK which has the error on line 109. The error message received was:

%SYSTEM-F-ACCVIO, access violation

This error is caused by an incorrect FORTRAN binding call for GINSK (Initialize stroke) in

the test program. The current GKS standard is:

CALL GINSK (wkid,skdnr,tnr;^,ipxjpy^et,xmin,xmax,ymin,ymax,

BUFLENJNIPOS,LDRJDATREQ

This includes a parameter not included in the test program. The parameter is INIPOS which in

the ISSCO implementation designates the following the "editing position". This error is

documented in Appendix E.

Test ER2A01. Does not call subroutine GERHND even though it is listed in the directory and

source code for it is included. Also this program calls subroutine GCEVTM which is not a GKS function. Code for this subroutine is not included anywhere in the test subroutine

directories.

3.3 Conclusions

The error handling test programs have a well defined structure of subroutine calls and the internal

documentation is a bit better than the data structures tests. The simplicity of the error routines

makes the code almost self-documenting without extensive commenting. Many errors are reported

when they are executed. Most of these are due to erron in the test programs themselves rather than

in the implementation being tested. Several fundamental design flaws in the tests prevent them from

providing much useful information or from being properly evaluated in our study. If time had been

available to recode routines ESEXER and ECKEKR so that they worked correctly, a better

evaluation of the error test could have been accomplished.

Final Report Page 3-5
4 -rm »ni ^C.KI3 |«UUa £J* *nii m »» aam otn • ti •wfl’ J0t0»a ^

.-

. ^ -n (.-. tv .wrucser. O&iX V u'l 1

7

ii<m^i V|iilTi if1fninFi~ 4ai'«iili^^

Ert^|B|i»lk T)u' firror

t »*' If ' ’• '“

' • «2Jd»6c»iKxirir«w..i«) a-^^^^ ;* trshiiiK iXO ifmn» arfT JBRS3J5 t<a»

V • f'

ai Afpam vf 4ie CBES **'!i»tioo

U ia tla -•lUas* ftaa'»-**«S ' • t* intatu. k'; »M • '> i«

FWtto- "1> A.•^«-o^ol »;!•• •oijccscsalqou ODUit

-2 xibnjqqA fii bencr.-nraafc:

Ttel i^0A12. rhc'* t djw crrop « ilat SI w-aJlisj sutmjria^ SQFXX wte M

' • HV'1 • ' l ^TV^OO UK! wdot tilw txattfiiaol k is jcA

>M « (WMuoiit. adi -.o\ *boO .n«3 >o;.\ EXO

/sr

lbii|iobkm U n lrig<, ;,.TU;t j^>E>TR>Ar* ruruti; j ’4» caO vCQ<0(a ^JDq€ :c pli«i 1 tmr/) u It oficd 10 tlb« tnu idbik Oodi eiilLAf ilii oxtbci bt&4is»f ma ^

.- tA

littiai >«t wi» ^ oRiL Aq^amii^’ c« um taodjlM ao^id^w

»>«»*'* J»mu «b« >A

•d] ot eiora oi »at) 9it *«fl3 to noM isjusaxs «a

f{yfe T?rtu;" itvidtiJ36d) tfoti^cnc^ JOJ

r>^> rh', I

- - \i.n_ ‘r* -.-rtii/*

.

O

T?1

aiavaruq -11

5^i^araSili Xh^rnq fowJ «»* nuawmlai li*’l»a» irjd^ j^7£.«jio# b**'©* '(*17 luii ot XX3KDS bo* J33X323 »*cu>»*ot aboMrt <M t>i«i*Up^

.Ulf J.Xj®O.L *OjU»bblA l» ly,4fil(3<*i!S.r(ibd BVEd J»l«» «o» XTO ocb lo ooawji»«

m err*^ b omi'^d in tjiff i»t: call fo OQPT^ iwhkil bft» rilot: y Q lai -1 /or

pasw‘>i£n nittJLi DY (dfaoMlp . '* of ccto tndn jcaj) ifliniti uc GXS ii..c*:lfijd teqiiom

•ifc , * *

^- - •

' * - -i - . • ' Sr vtloda tje'i?o»i'dve ii:T^.. cxaiiffi T^tvn mU iM 4itr ^

'Jiwitfldlio,

^ •. i J

A^TCiidj t.

^

4> - *

E»Hrt

flfi -itw3i^
4.0 Operator interface tests

Perhaps the most useful portion of the European validation tests for GKS implementations are the

operator interface tests. An operator at a graphics workstation executes a test script and verifies the

functioning of GKS by the appearance of output on the screen and the actions that take place as a

result of operator input The operator interface tests consist of 25 main programs, each of which

calls several subroutines.

4.1 Structure and philosophy of the tests

Twenty-five main test programs are provided. The "OF* at the beginning of each name denotes

that these are operator interface tests. The next two characten in the name indicate the lowest level

of GKS to which the functions being tested belong then, the next two digits denote the number of

the test within that level. Subroutines used repeatedly in all the operator interface tests include:

OINTT, UFUNS, OPENKS, OTESTR, andUWKVAL.

QTNTT - queries for workstation to be used and returns special data needed for certain tests.

UFUNS - returns unit numbers and report file names.

# OPENKS - opens GKS with buffer size provided by the tester.

OTESTR - checks if there is another VDU in addition to the graphics screen and outputs messages

to a separate screen (if provided) or to the upper right part of the same screen. UWKVAL - returns workstation id from table of connection id and workstation types provided by

the tester.

For the operator interface tests, an operator script, of necessity, provides a detailed description of

the graphical output that should be generated. The graphical output is pictorial in nature, and the

comparison - by the operator - of what should be displayed versus what is actually displayed,

consists largely of a visual comparison between a drawing in the manual and the display screen. Text ouqjut in this phase of the testing is also somewhat imprecise - the manual states " ... the

output of a text string may be exceeded (sic) the unit square display surface. The pictures in the

document should be used for guidance only."

Some improvement could be made in choosing graphical output characteristics that must be

Hnal Report Page 4-

1
perceived and differentiated by an operator (tester.) For example, the standard test pattern colon -

red, green, blue, cyan, magenta, yellow, white, and black together with a grey scale - would be

more objective than the "seagreen" and ’’burgundy” of the test programs.

4.2 Results of executing tests

A number of errors in the ISSCO GXS implementation and programming erron in the tests were

located in executing these programs — in particular, errors regarding output to the screen. A few

documentadon errors were also found A representadve set of these errors are documented in this

section.

4.2.1 General problems

1. There were problems getting the terminal to recognize valid input responses for most of

the input tests. This appears to be due to errors in the ISSCO GKS implementation that the

tests correctly discovered

2. When the operator interface tests are run using the VT240 using ISSCO GKS, many of the

tests don't run properly and some of the ones that do only display parts of the images to be

displayed For example, all of the OPlAxx tests will display the title frame and mdnu and when*

a choice is selected from the menu the operator is returned to the menu without executing the

choice. This appean to be due to errors in the ISSCO GKS implementation that the

tests correctly discovered

3. Regarding the fill area interior style HATCH, the integer values describing the style index in

the ISSCO implementation are negative values (-3,-2,-!). These are proper values for

implementation-dependent hatch styles. Since no hatch styles have been registered to date, the use of such implementation-dependent values is required if hatch style is supported by an

implementation. The test routines test style index with positive values only and therefore the

style index never gets set properly. This causes the image not show up - not even an outline of

the area to be hatched This causes problems in several test programs:

a) OP0A07 - at checkpoint 2J, the semi-elliptical shape is not displayed Also, at checkpoints 3.4 and 4.6 there are no hatch examples displayed

b) OP1A04 - at checkpoint 2.3 there is no image under bundled or individual and at checkpoint 2.4 there is no image for individuaL At frame 2, there are no images under

the text "INSTY”. At checkpoints 5. Id, 6, Id, and 7.1e, there are no mountains

displayed

c) OP1A05 - at frame 4, the butterfly body is drawn yet the hatched wings are not. At

Final Report Page 4-2
frame 5, no polygons are drawn at all. The error actually occurs in subroutine

OBUFLY.

d) OP1A06 - in all frames of this test, the butterfly wings are not displayed. The error

actually occurs in subroutine OBUFLY.

These problems are due to errors in the test routines and are further documented in

Appendix F.

4.2.2 Problems in specific tests

Tests OPOAOl and OP0A02. There are a sequence of calls involving activating, deactivating,

closing, and then reopening the same workstation. These two programs work

fine on the VT240 terminal yet on the Tektronix 4128 terminal, the frames following the title frame are not displayed. A sample program was written which isolated the process of

activating, deactivating, closing then reopening the Tektronix 4128 workstation. In these

operator interface tests and the sample program, the second GOPWK (Open Workstation) call

got an ’’internal error in GERLOG” error message and the rest of the calls following GOPWK

had the error message "GKS not in proper state".

When the GDAWK (Deactivate Workstation), GCLWK (Qose Workstation), GOPWK (Open

Workstation), and GACWK (Activate Workstation) sequence is commented out the programs

work fine. This problem is due to an error in the ISSCO GKS implementation - apparently in

the device driver for the Tektronix 4128 - that was caught by the test routines. Unfortunately,

due to the nature of the error it took a considerable time to determine what was causing the

problem. The test routines do not adequately test valid state transitions. Although they

uncovered this error, they provided no assistance in determining what caused it This problem

and its error files are documented in Appendix F.

Test OP0A04. At checkpoint 3.1, text on the screen reads "RANGE OF UNETYPES" and not

"FULL RANGE OF LINETYPES" as designated by the documentation. This error is due

to the test script accompanying the test suite and in the tests themselves not being consistent

Test OP0A05. The first colunm displayed on the screen in frame 2 looks like it is all dots instead

of the individual polymarkers. Also, the larger squares in the top row do not contain the dot

polymarker inside. This is due to an error in ISSCO’s implementation of GKS which the test correctly detected.

Final Report Page 4-3
Test OP0A07. A run time error occurs on line 698. The error message received was:

%FOR-E-OUTCONERR, output conversion error

This error is displayed 5 times. This problem was caused by a FORTRAN coding error in the

test program. The test program attempts to print the value of variable STYLID which is negative value. The WRITE statement used cannot print negative integers. Appendix F contains a listing of the erroneous code.

Test OP0A08. Cell arrays are not displayed at all. This is an ISSCO GKS implementation

problem in which cell array only works sometimes.

Test OPOAIO. After the first fish image is drawn and return is hit, nothing else is displayed on

the screen when this test is run on the Tektronix 4128 terminaL This is because of the same

problem in the ISSCO implementation described above for OPOAOl and OP0A02 regarding

closing and reopening workstations. The test runs correctly on the VT240 terminal. The lines

causing the trouble are documented in Appendix F.

Test OPOAll. At checkpoint 4 the red and green checkered flag at the top of the ship is not

displayed. This is an ISSCO GKS implementation problem in which cell array is not

regenerated dynamically. At checkpoint 7.1b on the Tektronix 4128, the display is not cleared

and the image drawn in the lower left quarter has the text ”GKS” so large that it has been

clipped. This works fine on the VT240 terminaL This also appears to be due to a problem in

the ISSCO implementation that was correctly discovered by the test program.

Test OP1A02. This test contains exactly the same code as test OP0A02 ! This appears to be an

error in the construction of the source code for the test suite. The code for OP0A02 was

probably inadvertently copied over that for OPlA02.

Test OP1A03. A run time error occurs on lines 754, 783 and 812. The error received is:

%FOR-E-OUTCONERR, output conversion error

The value of the variable FONT contains a negative integer value which cannot be directly

printed to the screen. The test routines are strangely inconsistent in this area. Some handle this

"problem” correctly by taking ABS(FONT) and printing the minus sign using GTX (Text).

This programming trick is not used consistently where needed and therefore needless errors

Final Report Page 4-4
occur. Such problems are due to the lack of application of formal software development

practices such as design and code reviews. The erroneous lines and negative number output

code are documented in Appendix F.

Test OP1A04. A message from the test appears which states that the maximum length of the fill area or pattern tables is less than 10 (min. required 10) even though pattern is not supported

on the VT240 or Tektronix 4128 workstations. This is an error within the test program.

1. At line 944, the following run time error occurs:

%FOR-E-OUTCONERR, output conversion error

This is the same problem as described in OP1A03 where a negative value needs to be output in a special manner and this is not done.

2. At frame 4, after the Pac-man and car images displayed - if return is hit, the program leaves

and a run time error is given at line 1327. Frame 5 also gets this error at line 1528. The error message received for both of these is:

%FOR-F-ADJARRDIM, adjustable array dimension error

Pattern is not supported on the VT240 nor the Tektronix 4128 workstations and the program

does not include this portion of the test within the last scope of the IF statement which queries

to see if Pattern is supported. This program also does not query for supported pattern indices

which would be another way to avoid this problem. So when these calls to GSPAR (Set

Pattern Representation) are called, the values passed in the parameters MMX and NMX are 0

and this causes an adjustable array dimension error. These errors are documented in Appendix

F. Once again, it appears that the test programs are not device-independent enough.

Test OP1A05. At frame 1, the flag in the first ship is not redrawn. This is an ISSCO GKS

implementation problem where cell array is not regenerated dynamically when all segments are redrawn on the workstation.

In frame 5 the segment priorities are not changed so the reversed order of the polygons is not

drawn. Within procedure HORSEH, the data for the polylines is scaled to fit into a given area. A FORTRAN programming error was found in this test The variable SCALEF is not declared

in this procedure nor is it iititialized. Therefore it defaults to local variable status with the value

Final Report Page 4-5
zero. This causes no horse head image to appear on the screen. This variable needs to be

declared in the procedure and initialized to 1. This problem affects frames 1 and 4 of this test. Also as noted previously, some of the output to the screen is not displayed because of

invalid hatch styles in the code from subroutine OBUFLY. These errors

are documented in Appendix F.

Test OP1A06. At frame 2, the right side of screen doesn't get clipped like it is supposed to. This

problem is due to an error in the ISSCO implementation that leads to an incorrect treacnent of

the segment transform in relation to clipping when segments are impHcidy regenerated. Also as noted previously, some of the output to the screen is not displayed because of invalid hatch

styles in the code from subroutine OBUFLY.

Test OP1A07. After the tide is displayed and return is hit, only the Tektronix 4128 screen

cleared; then the program disappears and doesn’t return. This is the same problem as described

above for the OPOAOl and OP0A02 tests regarding the closing and reopening of workstations.

The lines of code causing this problem are documented in Appendix F.

Test OPIBOI. At checkpoint 1.1 the screen also says "(BASIC REQUIREMENT)" but this is not shown in the documentation. This program doesn’t respond to the pick input This is due

to errors in the ISSCO implementation.

At frame 2, the tide, the circle, part of the boat and the stars are drawn then the program exits

prematurely. This is also due to errors in the ISSCO implementation

.

In the documentation at checkpoint 2.1, this program is designated as program OP0B04

instead of OPIBOI.

4.3 Conclusions

The internal documentation in the tests is very thorough. A number of relatively minor coding

errors were found in the test programs. Others probably exist that weren’t detected. The tests were

much more effective than the data structure and error tests at uncovering problems in the GKS

implementation being tested. These tests appear to be of some utility in validating GKS

implementations.

Final Report Page 4-6
5.0 Requirements traceability analysis

The quality of any validation test is determined by how well it tests requirements of the system

being evaluated. This is especially difficult to determine in the GKS environment since the GKS

specification itself is not as well organized as a tradidonal DoD System Requirement Specificadon.

Nonetheless, we undertook evaluadon the test routines by picking one area of GKS - - the

processing associated with producing the Polyline output primidve - - for extensive evaluadon of

requirements traceability. A partial list of GKS requirements relating to Polyline was developed

and is contained in Appendix B. Due to the extremely large number of Polyline requirements that

were found, we were only able to evaluate the testing of a subset of them.

Once these requirements were extracted from the GKS Specificadon, they were used to derive a minimal testable set of requirements to validate that a GKS implementadon conforms to the

requirements for processing Polylines. The three sets of GKS tests were evaluated to determine

how well they test each of the derived requirements. From this exercise, we can infer the degree of

care used to construct GKS tests programs, the percentage of coverage of GKS requirements

which they are likely to provide in an acceptance test situadon, and the general quality of the tests.

§

5.1 Conclusions

The detailed results of the evaluadon are presented in Appendix B. In this Appendix, a representadve set of requirements is listed, together with a descripdon of how the requirement

should be tested, an idendficadon of one or more places in the validadon suite where it is tested,

and a determinadon of how well it is tested.

The degree of requirements coverage in the European validadon suite is reasonable for an

acceptance test situadon, especially considering the lack of organizadon of the GKS standard and

the difficulty of extracting testable requirements from it All ksy features of GKS were tested in one

or more places. However, we easily uncovered meaningful requirements which were not

adequately tested and found requirements that could not be tested at the GKS language binding

interface.

If addidonal confidence in the correcmess of a GKS implementadon is needed, then addidonal

requirements verificadon must be performed. This could be done by analysis of the source code of

the implementadon or by demonstrating the correct performance of a set of ’’internal unit-level” tests designed to check the correct implementadon of key features — such as transformadons and certain

Final Report Page 5-1
approximations — that aren’t visible enough through the subroutine call interface to be adequately

testable in a validation test suite.

Final Report Page 5-2
6.0 Recommendations

Based on our extensive analysis of the European graphics validation suite and our experience

installing and executing the tests in a typical US graphics environment, we make the following

recommendations to NBS:

1. The data structure tests arc of too low quality to be useful for validating GKS implementations

for DoD purposes. Rather than expending the resources necessary to correct deficiencies in the

tests, and due to the fundamental flaws described in Section 2.3 above, we recommend that

the operator interface tests be expanded to include testing of the most important data structures.

2. The error tests are of higher quality than the data structure tests. If the fundamental flaws

discussed in Section 3.3 above are corrected, the tests could be used to provide a useful

validation of the error handling of GKS implementations. A moderate effort would be required

to upgrade the routines. The error tests should remain a separate set of tests since they are

difficult to integrate with the operator interface tests.

3. The operator interface tests are of definite value in validating GKS implementations for DoD

* use. A moderate effort would be required to correct programming errors in the tests and to make them more device-independent As stated in (1) a6ove, the test could be expanded to include tests of the most important GKS data structure with little impact on their run-time

efficiency.

4. The test programs are available only in FORTRAN. Since DoD environments are likely to use AdaTM consideration should be given to converting the tests to that language. This would be a

fairly straightforward, but time-consuming process due to the simple structure of most of the

test programs and subroutines.

5. Consideration should be given to restricting some of the options available in GKS when it is used in a DoD environment. Additional constraints should also be placed on the "correct"

interpretation of many of the effects which GKS defines to de "device- or implementation-dependent." If such constraint are defined and promulgated, the test suite

should be expanded to test for them.

i

i 6. The test suites do not test the Computer Graphics Metafile (CGM) and only test the GKS

Metafile (GKSM) in a cursory way. Due to the importance of graphical metafiles for the CALS

program, work should start at once to develop a test suite for the CGM.

I Final Report
fl area’l.vli'ljJc tocu^- thjoru^ v--r -x:

io « r^Iid^^na tttu outit

it eaJ3 hau?Jia?4£> be adec\. laly

ioobtbntmmootfl

si«.b»q*8 aro bo* timt noiubiiav wuiqK* obxjowS *j1j-Ap rfr(l*n» srUnwM w r»

sds 8ifiin n't’ jwmaoirvns niri^Ki 21) U^qx* * ® **•* **** %pHineas ba. ji

lEffVloJ

ifiOhaRs.--;k.-.aJ 220 *W£biUv ») Iiftsw a<i « x*il*PP WOM^ «* awl waasno* «>T

s* ra tsiwobfbb »9WO oi •<ut2i09n aamowi sxb gtuersc’.^ BuBiaiiMH x>!oip«i OoCT-s?*

Mt bitsinaioasi »w ^'fotii Cl noca»2 «i axJnawb r»sli torsawbaul «i3 oj aub b£»,.a*s»

^a«r»inR Jawwjisi uom aft) V> »afe«i ahutsai oe baboKjw »0 aw t«*«o 9*

rw*n kJaamubiu)) arfJ \L nmtnu Btb wb ip*)*"? lo sii Tcra arTT

lu'.s.-« * ahfvoT? 0? taiu .-ft'afaei «»’ adj tnt awdi C.C noi»»2 oi tofaU/Mib

bs^upra sd Uw»/) «rtte aistafaooj A jnonmsaaJqaa 220 ^o iauttotft -jodb adJ \o oaJ»»ba»r^^

m rad) ft'ani/ ars) 1o aiffiEqv s bLsibw bluoftt *»*•> «n» adT .esnaocn ad) abci^ o)

BIS. saaWni lottnqo ad) difw amjsoi oi dicaSUb

-i.., .

• loa ») iaoiudoamajqfi- 220 |nfaabil»v ts; atikv sa^ic* au a») aartrajtii *B«a<r ^

'6i bna rtiw s6 o) ntr« i(rfsu)i«|oaj ;»tw3 o>» bmiiifm H biaow noTte awMbora A

o) babn«i« ad b'; oa )W) ad) P^odt H)mboim^ jrabaaqato-aaivab ai«n mvb slsm |

amiJ-oBi tiad) no aasquri atoiJ d)tw »t«o. tftif mb 230 jraftwjnii »ora art: lo ow abularf J

gffl 01 Xlatil m ansOBrovea Ooa taruZ VJjafiCFi n xi»> «««««"*»

, ad biuow turr )Brtl « a«s «a inlnavooa « aa^ ad blaori* oodrtabto» '«ftbA

^ ad) )o Jfom auDOoBi olqinli aft) o) aub »eaacr«j |iiiKuaflO>anu) Jod d»wwTCtad|ictie vi-uA |

^wiaiKjvSoi boB vxutQo^ - - ... %

... 12

n u nartw 220 oi aSdalirvt ie >0<io ad) 'o aoic* toaabtm at oavij ad Wired) noonabanoO

")^oi>* art) no baoiqad Ml* bbredi nrdsianoo koobibbA. JoammnirBa doO . w baw

JO irfvab" afa o) oaoDab Z'AO daiftw oaaYla ad) lo xn*« )» nti^^^cpsa

attat va) ad) l»)88Ufniwq bn. baoftab m »i«)Mos fta«l ^ "jnabaaqab-nofliinan^

jllKij lO’l U9fl O)

^ ob5^

220 ad) uw xHw bn* (MOO) aHimK coWqanO »u»qmoD ad) )»a) ion ob wun^ iw arfT

^,^0aft) M) witearo l«aWqnj aantnoqmi ad) <» «0 -xm x»ms » «

ji'0Oad)id)aiiu))ea)»<}oIa**bai4anott)JwbluoiUiJO'*.ra«»w

iTRjJJUfCft ^ JIA I.') L J.

t X AnrtX.
APPENDIX A

SIZE OF LOAD MODULES

Appendix A - Size of Load Modules

This Appendix contains a listing of the size of load modules for individual test programs in die

VAX environmcnL The values are in bytes.

1. Data structure tests D2011 - (209K) D2012 - (421K) .D2013-(486K)

D2014-(446K) D2016 - (499K) D2021 . (541K)

D2022 - (421K) D2023 - (409K) D2024 - (457K)

D2026-(509K) D2031 - (420K) D2032 - (435K)

D2033 - (427K) D2034 - (440K) D2036-(497K)

D2041 - (218K) D2042 - (428K) D2044 - (442K)

D2051-(546K) D2052 - (422K) D2054 . (437K)

D2056 - (497K) D2062 - (410K) D2064 - (437K)

D2072 - (394K) D2074 - (446K) D2082 - (395K)

D2084-(439K) D2094 - (435K)*

Error Handling Tests

EROAOl - (370K) ER0A02 » (459K) ER0A03 - (397K)

ER0A04-(383K) ER0A05 • (372K) ER0A06 - (422K)

ER0A07 - (379K) ER0A08 « (372K) ER0A09 - (371K)

ER0A10-C371K) EROAll - (370K) ER0A12 - (400K)

EROBOl - (427K) ER0B02 = (380K) ER0B03 - (407K)

ER0B04 - (403K) ER0B05 - (394K) ERIAQI - (397K)

ER1A02 - (394K) ER1A03 » (468K) ER1A04-(464K)

ER1A05 - (404K) ER1A06 = (468K) ER1A07 = (465K)

ER1A08 - (367K) ERlBOl «= (401K) ER1B02 - (392K)

ER2A01 - (461K)* GKUTIL - (361K)*

Final Report Page A-1
3. Operator Interface Tests

OPOAOl - (444K) OP0A02 - (407K) OP0A03 - (459K)

OP0A04-(464K) OP0A05 - (460K) OP0A06 - (445K)

OP0A07 - (466K) OP0A08 - (453K) OP0A09 - (458K)

OP0A10-(494K) OPOAll - (468K) OPOBOl - (462K)

OP0B02 - (467K) OP0B03 - (458K) OP0B04 - (453K)

OP0B05 - (454K) OPIAOI - (468K) OP1A02 - (406K)

OP1A03 - (441K) OP1A04 - (492K) OP1A05 - (488K)

OP1A06 - (480K)

OP2A01 - (48 IK)*

OP1A07 - (490K) OPIBOI - (509K)

( * not linked successfully because we had only a level 1 GKS implementation which did not

have the necessary level 2 subroutines)

Hnal Report Page A-2
APPENDIX B

POLYLINE REQUIREMENTS
II
Appendix B - Requirements Traceability

This appendix contains an analysis of the degree that certain representative GKS requirements are

tested by the European validation tests. Each requirement is given a descriptive title and is reference

to the ANSI GKS speciEcation by page number. (Paragraphs of the GKS standard contain too

much text to be useful for requirements traceability.)

1. Polyline Bundle Tables Page: 19, lines -11, -10 (-11 indicates coimt from bottom of

page).

Requirement:

The values in these tables may be dynamically changed. In fact, the only way of changing the

aspects of a primitive which are stored in a bundle table is by changing that table.

‘ Test:

Create a polyline primitive with all ASFs set to BUNDLED, and polyline index set to 1. Modify

the bundle, using set polyline representation, to markedly different values. With suitable prompts

to the operator, check to see that the appearance of the polyline primitive has changed accordingly.

Where Tested:

An equivalent test is performed in Frame 3 of OPIAOI.

2« Polyline Linetypes: Page: 20, lines 9-15

Requirement:

Linetypes 1 to 4 are solid, dashed, dotted, and dashed dotted. Every workstation of category

OUTPUT or OUTIN realizes linetypes 1 to 4 with recognizable styles.

Test:

Create four polylines, one each of linotypes 1 to 4. Documentation or screen text to indicate the

linetypes being displayed in their respective locations. Operator checks to see it correct linetypes

appear.

Where Tested:

Tested in Frame 1 of OP0A04 of the operator interface tests.

Final Report Page B-1
3.

Attribute Binding: Page : 16, line 28-30

Requirement:

During creation of an output primitive, the attribute values are bound to the primitive and cannot be

changed afterwards.

Test:

Somewhat difficult to fully test because of the variety of situations where an incorrect

implementation may violate this requiremenL A simple test would be to create a polyline with ail

ASFs set to individual, then change the attribute settings and create another polyline. Check to see

that creation of the second primitive did not alter the appearance of the first

Where Tested:

Equivalent test performed in Frame 1 of OP0A04.

4. Linewidth: Page : 22, lines 1-2

Requirement:

The linewidth is calculated as a nominal linewidth multiplied by the linewidth scale factor. This

value is mapped by the workstation to the nearest available linewidth.

Test:

The requirement is difficult to fully test, since the set of available linewidths are not obtainable via

the GKS inquiry functions. An approximate test would be the output several polylines of various

linewidths, with indic^ons to enable the operator to check for at least an approximate proportional

relationship between linewidth values and physical width of displayed lines.

Where Tested:

Frame 3 of OP0A04 is a partial test.

5. Qipping: Page 51, section 4.7.4.

Requirements:

1) If the clipping indicator in the GKS state list is set to NOCLIP, then primitives put into a segment will have clipping rectangle (0,1) x (0,1) in NDC associated

with them.

Final Report Page B-2
I

i 2) Qipping rectangles are not transformed by the segment transformation, and thus, clipping is always performed against a rectangle whose edges are parallel to the NDC space coordinate

axes.

Test:

1) With clipping indicator set to NOQUP, construct a unit square with POLYLINE in WC with

normalization 0 active, and default setting of workstation transformation. The entire unit

square should be visible on the display.

2) Set normalization and workstation transformations as in test 1. Set clipping rectangle to (0,

1/2) X (0, 1/2) in NDC. Create a segment containing a polyline drawing of a grid

superimposed on the unit square in WC. Qose the segment and rotate segment using SET

SEGIvIENT TRANSFORMATION. Verify that the clipping rectangle is unchanged.

Where Tested:

1) Tested in OP0A04, Title Frame.

2) An equivalent test is performed in Frame 2 of OPlA06.

6. Set Polyline Index: Page 89, lines 6-14, section 5-4.1.

Requirements:

1) Sets the ’’current polyline index” entry in the GKS state list to the value specified by the

input parameter.

2) This value to be used when creating subsequent POLYLINE ouqjut primitives.

3) Return error error 8 if GKS is in the state GKCL.

4) Return error 60 if the parameter does not belong to the set of integers from 1 to the maximum

polyline index for the implementation, inclusive.

Test:

1) Use GQPLR to obtain the list of valid indices. Set the index to a valid value using GSPLL

Use GQPLI to check that this index has been set

2) Use GQPLR to ascertain the contents of the currently-set polyline index. Ouqjut a polyline

with aU attributes set to ’’BUNDLED". Check to see if its appearance matches the attributes

contained in the currently set index.

3) Set GKS to the state GKCL. CaU GSPLI and verify that error 8 has been returned.

4) Use GQEPLI to obtain the list of valid indices. Call GSPLI with with an invalid index.

Check to see that error 60 has been returned. For reasonable coverage, a set of invalid

Final Report Page B-3
indexes can be used for successive calls to GSPLI. In particular, the values 0, maximum

index plus one, and a random invalid parameter should be checked.

Where Tested:

1) Program D2012 of data structure tests. 2) Equivalent test pcifoimed in Frame 3 of OPlAOl.

3) Tested in Test 1 of ESPLI of ER0A03 of the error tests 4) Only the invalid values 0, -1 are tested in Tests 5 and 6 of ER0A03.

7. Set Linetype: Page 89, lines, 15-32, section 5.4.1.

Requirement:

If the specified linetype is not available on a workstation, linetype 1 is used on that workstation

Test:

Use GQPLF to determine the set of available linetypes. Use GSL to set the linetype to a non-available type. Then output a polyline with this linetype, check to see if it is shown as linetype 1.

Where tested:

Not Tested.

Remark: Frame 2 of OP0A04 makes the comment: "Note that linetype number K should appear

the same on all workstations in an implementation". This contradicts the requirement

8. Set Aspect Source Flags: Page 99, lines 6-27, section 5.4.1.

Requirement:

Set the ASFs for polyline attributes to INDIVIDUAL or BUNDLED.

Test:

Set the polyline index to a specific valid value. Set the individual polyline attributes to values

different from those in the specified bundle. Create 2 (or more) polylines, varying the settings of

the ASFs. Check to see that the appearance of the polylines varies according to the ASFs.

Where tested:

Tested in OPlAOl, Frame 2.

Final Report Page B-4
9. Set Polyline Representation: Page 100, section, 5.4.2

Requirement:

Rede&ie a predefined entry in a bundle table.

Test:

Set polyline index to a predefined bundle. Set all polyline ASFs to "BUNDLED". Create a

polyline. Use GSPLR to change the values in the bundle for the current polyline index. Check to see that the appearance of the polyline has changed accordingly.

Where Tested:

An equivalent test is performed in Frame 3 of OPIAOI.

10. Set Segment Transformation: Page 115, section 5.6.1.

Requirements:

When a segment is displayed, the coordinates of its primitives are transformed by the

transformation matrix given by the parameter in the call to GSSGT.

Test:

Create a segment consisting of a polyline. Call GSSGT with a matrix which rotates and translates

the display of die segment

Where Tested:

Tested in Frame 1 of OP1A06.

Final Report Page B-5
^-..7

- ,.. -

IfllitfmW *il-cA f« ?u • sa‘iv<i tilb spG!ff'.^ '-'i t»i« Q, anu-i-iTi

• Rl - ri^tx pS4*M6,

^a .'.vjfera iar^ ^

i\ •‘j f^-.

s»^ i.iymraillCIMa'QSil Mettle*! }*&

02Cu£ ord»fc|tr»saBn«^‘'''

SL-k.l .001

,7tWv'

. ^Wb fsJhnod • la 'fOcaiciBitobsBi » »

*

Inacnt'^r

,f- i 4?^ - Nr f aafipcrfcanii b^vm 5 ofQpi AOt.

'*# it ^

1

'

T. 1

, > ,^!«,attrieio»bn‘'s^ «^ aBfl<toqad. ,OsaoM»^

1 I

«ir31Bwfi»pofxA

-X

' - "- W1I

u!. OQFLF to ^^nni«

.-/?. ^ ’non*A •; trpf. Itoa 03JT'.‘ 1 j :.‘3^ «-uJi -ia: i'-nct*?-, :Arck t. < -f U

ty^ .

'(•j lodttoittJrt rts K.vt)toft?i tti to sdJ »i iaoiPr,M J s««W-

.TO^^OwI!ts«rtiUlalsrtt£•^,•d>'f^OT/t^ww*^«^^»*^^-^

"'S : jkun^f,

_ *'

•_# ^ -., . -;^ - ,r>»m I rii'i* TQ2£!} It-'' .niiiiiijao ifnfla»i *

‘''fi. M S>

**

‘ /i4« c? u. n tjnapicJitomdoB*. Tito ci»i:r;.:^ica sNe

^ fflWlim Jnnm;goii

*0 U»»T<«i«iW

S*t Vaiperf |oaf .i rlagj; P*^ i,n«» .vi?. tcrivi 5.4 l, ^ |«rtS

’ I

.- " IfStD

ASai Sar polylcDa -^ttrib^jocs to'SttOL::' - M- *'4 :4X2D

v« •-' ..

'* jri- S«c toi idS^ i^^iul p jyfiiit to

i^hv^ ^ oeXMh ftt»» * ^

^ ;vr

ll',* H^rpor:

l-fi

SO t »3^’ilia

j(®!ftaecl^TOal ih<^e 'o :^c Lf^zc.y.^-, bvaSfe.' wr/icg cftr .-.ctaag^

"zi A®fc- €3«eic loW tWi tbtf ^

polyBss^ ^-: * - »a4 to te A5vF».

.4JEl£ taSj

‘via
APPENDIX C

LISTINGS FROM INSTALLATION
-i li
Documentation for

Subroutine UWKVAL

3.2.2«2 Details of the sub-program 'UNIC7AL'

This sub-program provides the test programs with

information about the connection to the

workstations in the GKS implementation.

The parameters are as follows

s

SUBROUTINE UWKVAL (WKID, WKCON, UKTYP)

INTEGER WKID^ WKCON, WKTYP

This sub-program provides an indicator (WKID) in a

table with pairs of connection identifiers and

workstation types, which are supported by the GKS

implementation Connection identifiers and

workstation types, which require this indicator

are entered in the parameters WKCON and WKTYP.
t

1

; t >

I

V

»• « f

t/ij

V

I i

4

I

7

"^
Subroutine UWKVAL

I C

r

z 1 °

1 UJ Z 2 1 1 _.* 1—* i i «*r*i w 1- 1

1 . < z o i 1 e U

cr ! 03 s 2 -i UJ 1

1 z I c: LU z

LiJ i c Z LU i K u: Z 2

h- 1 < C. 1 ! K LU H <

a: 1 J- > o 2 > 1 i ^ . L H“ i— lU < < < O h— t ~T

! P. rj3 2 C

i— ! 1- 1 LU » O h* > O 2

i U. z 03 Z z i i p ? cn I

'ii

• UJ UJ c w 1 H- i M jj 03 ^ 1 z •J. >-• — ! d 2 G LU 2 1— K 1 UJ > H K i Km X 2

1 X -u 2 < < 1

' 3 \ 1“ a: > ! 2 Z u.

j

' c O 2 03 u C i Z z 2 2 03 2 1 Z I u. Q c M

i 3 Z C 2 Cii 2s: i 2 i C z C U. c ! z '— r—

«

cr X i Z 1

k LU h- ,u. LL M i l: 0- H” H* O o i j r— X O H >—» i • c- > < < 2 1 ui 1 w H L' uJ z

Ll i !i t —

r

l- ;— i -i 1 z 2 < I < 1

* 1 < ~ ! U.* 03 Z o LU 1 i LU 2 O

Ci 1 r»* 2 ::1 UJ a. z > 1 c i > C z < Cn"

i < ui -1 a: z 2 ^ Q 1 -J o > < c 2

j > 'i Q UJ >s c s i ^ — I » X z L-« Ll

; Li >-v 2 -J '«/ z < i 2 2L i < - 2 LU 1^, UJ ! q: X 0. 2 1 2 1 Z C <»• L^ 2 Ll a 1 UJ >— z 0- LU

1

. w 1 o: 03 *1 iZ 2 1— —> LU

i f“ rj z o »—m 03 \ C 0. 1 2 Z K z < CJ Z 2C f- I Ui II 2 UJ cn LU 1- o i Z > 1 Z LU < LL LU CD cn

j z Z q: UJ a: ipa4

1 < H 1 H K < 03 Z CJ « ^ ! < 2 cn q: o rv q: 01 1 . a: 1 03 03 K LU »iii^ Z O n S 1 (T z Z > 2 z o o C a O i 2 1 - > S Q z c G 3: >—

1 < «_> Ti 2 < 2 a LU 0^ ••-4 o u. -* { O -I 1 03 a: w C CJ LU 2 Z 1 a. IT q: Z cr CJ IT \ 1

i Z Q K z G Z O t

1Vhb UJ a: Ll UJ 0. 03 z 1 K II i 2 LU 2 UJ 2 z ii 2

! t— < 2 c U. > 2 01 2 i CD 1 z 2 2 2 -1 Ll t- I X r“ L.; a;: ! UJ LU tJ 1

. CL 1 1- W

•“s ^

a: 2 LH CJ 2 3

t t *

i* K Z z UJ t- q: 1 a > 1 U/ 03 UJ > ! H 2

UJ < — < 2 2 Ll. 2 i t—< f— i LU M V < CJ 0? i 111 X cr

» 1 u uJ Ll- -1 Ij j aC i 03 z u. z U u- III

«»•

- : < z w O _j T* -J >— 2 2 ! c ** c Ll cn 3 3 <

CD i Z U- U. < 1 UJ f“ < z < i 1 03 u _J K u ^ ! < u. ct: h“ Lu o LU LU I— 1 1 ^ ^ Ul »-4 jU G •T ! X < 2 X z < I C < i Ll z 2 3. < U- i— ! fj r*.

. t~ — Lli V— N 1

! ^ G 31 LJ 2 iX 2 WJ s <» * 1 1
r

cr .. 1 LU 1 C 1 LlI (“ i T“ 1 % < — ^ .v- * Qi z z z uj i < o c c 2 S ! 0. u o o z r LU i :s: < 1- lx' > 1 < 3 2 3 z Z 3 1 « ^ « ' LU LU a 1 P c: a: < i X — -(> -4 X a: 1 U 0. X a. cn 2 Q U ! co Lo cn 4^ 2 2 X 1 z i—4 C h- 1 < a a a cn lu . i a: cn Cl a X 2 01 1 a: O t- lU C 1 o o o U Lu 1 H-4 ' ' •* Z U 1 Z » •-* < 21 t a: a: a: CO 2 LU 3 2 2 LU 2 f- 1 O O O iLJ U LU CO '<.) 1 1—

O o o >-• r- >— -<C ! in LU CO C 1 a: -i -: -1

Lil ^ -1 J -i 3 X - X cn i > o < < < G LU 2 1- i - O O iCJ 2 Z Z 1 Li. Z LU LU 1- lU 1 1 1 ( —> ^ ^ -• 2 X Z Z 1 f«j n 3 3 LU lU i o . . . H Z 1- I CO '-'COO a cn > z < 1 1—4 cn LU III Lii cn 3 2 2 0 1- 1 ^ . . a !- z o cj cn 1 CO X Q Q 2 1 H 1 H-* o ^ o LU ' c; LU LU 1 T 2 a a o X ru LU X -1 !l t— 3 2 3 1— X 2 *— 2 i ^ w — cn »- < ' -1 _i . 2 LU H- i Lu X. < L. 'li. Ll < 2 >21 2

LU CJ **' 4^ o LU cn u o o 11 2

1— K u Z lU !' 2 1— 2 O O C- 4— lU X 11 Z LU Z z Z •' X 2 LU ii LU 2 LU iII[ II

l3 lJ O LjO ill I'j r j jL 2.
Subroutine PDINTT

o G <> c fa * G

n 2

cn U

=<* G a. 2

h“ c *»5

xc¥ < <

H" 'jj

ft

WbT

01 Q < <

ft H

< H 01

ft

ft I. 2 C

01 2 $ o > 2

? G CE II ft 2 H ft

ft

!l G <

}- O c 2 V < CJ C 01

H* >-< G

01 LU IT H” G -J 'JJ < t-=t i=* a Oi o G lE z 1-^ G a: ! 11 h- Tu Z 2 < CJ I! o C r>^ t—

<

H* h0. ir K .1 LO G 2 2

G 1—

t

h«K> '3. U I 3 CJ

LO *-* 01 < 01 LJ

a: U LO O OJ 2 .V" Ut C^’ -» i—* ^ o5 2 LiJ G Z <

z cn 2' ' C G c G .%* 1 ’ LO <

z H-

»

G 0" >c

>W

!f l( a: x.!—

CJ LH

LU '<C r- cr o o

Ti; o

it

o ^

II i; z ^ ^ J^cn t i

^

2 !r 3 z

P > C i—

C!- O C5 cr* c>

Tii n

i:

I! n: cn :— cjt C 2

c: o

O

II r. «5T m

>

it I! CJ< H

a « z o

Z Z *-f <

O O O

O

II ;: 9 9 z z

S C2

_! Z

C- ti> o o

rj n

!! K II c c *—

«

Z Z w S S G

X < uj ll _J

cj> O O

ra ^ n

II ti II X c

i.0 f- cn < a <

c a c

-I -I -j O c?

ru

•>

.'

i:

II 01G (“

01

a. <

o o

o;2

C

>

2

UJ

q:

a! m

!i II

I 2^ 21 <

CE a >- < < K

z z >- 0x2

O CI> *-•

JJ <cX

Ll.

LJcn<

Ll 0 .

If II H Lii 0- QJ ^ <

1- ar 01 f“

LUX K

H O

til Z

2 «J C « O

u.

Ui <

I”

01o

< <

H“ K" G G

G G

2 2

G G

-j -I

2

UJ

Q

a:G

a:G

Ui 10

H“ H*

q: a:

' 3 !l ' ir •* q: LO G

UJ CM UJ «J -J — ^ o

h— Ll. " G * !i G 01 UJ 2 LO 111 G

< Z 2 2 <

'-0 G < G f- a. ^ u1

C-? ^

-J G

a_ w

UL cr

jjj

a c z

< z OJ

OJ G C-
r O
GKS

CERTIFICATION 20

F77

UTILITY

SUBROUTINE

FOR

ERROR

TEST

SOFTWARE

Subroutine ECHEKR ^ 5

1)

M u u C

CQ •« C

1)

b ^ o

•£ ^

cs

— ^ T3 o

4c 1i1 * 4c 1 E 1 S

4( 4c 1 3

4c UJ 1 Z * 4c T 1 E K

4c O 1 Z «, * 4c U UI Ui 1 E G 4l UI K 1 Z * Q UJ 4c X Ui 3: a 1 o • u; 4t use H 1 ^4 E

cn

M 4c < 0. 1 Ui

cn < 4c Q Ui E 1 E E * < IL 4c K cn q: c UI 1 UJ « CL 4c IT Ui 1 E E * * cn 4c Z Q !T ^ UJ 1 « Ui

34i cn H4 4e o c o i E Z * i~e 4c -< ir E < CJ 1 Ui

4e H UI E LL 1 Z E * H cn 4c >-» Ui Ui 1 E * cn Ui 4c Q UJ cn z 1 X

3?£ Ui K 4c Z E Q >-< >>< 1 o Ui

:4c 4c O Q Z h” 1 e • * 1 4c U Z K 3 1 z

:4c li 4c Q cn Q 1 E 3

:4c Ui 4c z LL E Z Ui E 1 E Z

is Lj cn 4c o •-* O < K S 1 UJ X «

:4c 3 -i 4c 1 E Ui E * QC < 4c H Z Ui Q UI cn 1 3 > H U. 4c Q. < Z Ui X 1 -1 z h* * 4c « O K H Ui 1 3

is 4c t£ fi

U z 1 < Z cn cn

:4e 4c O Ui Z UI Z < 1 Ll « E E

4c cn a Ui E UI z 1 E < 05 a tn O s 4e UJ C X X X Ui 1 E > E E E E E Q Q H 4c c < 3 UJ H E J Q Z C E Q E E E * 3 4c 1 E E E E Ui E

CL 4c 1 cn J cn E E cn

:4c CO 4- 4c 1 cn cn Ui Q E a < < * 3 4c 1 < < < E E E E

:4c Q 4c 1 E E E a 1- Q H

:4c J— 4c 1 Z Z UJ CJ E E cn cn

:4c CJ 4c 1 H « « H E K* H H

:4c a h» 4c 1 cn cn -1 CD E E E E cn # 4c 1 Ui cn < UJ X O E E E 3 4c 1 < h- E E E E H

Ui cn 4c o 1 E a X E * Ui Ui 4c Q 1 cn Z H UI E E E E E

:4c > ir 4c 1 UJV Q O Q Q , 4c 1 J CM E E « K .. 1 4c UJ 1 3 < < Z £ Q E O E E £ , 1 4c a i cn u i- 3 E E E E E

:4c cn (T 4c z 1 UJ « O Z E H ffl Q Q a * UI ^ 4c < tfS I E Q H CJ 03 z cn z z Z

:4c . . h” ^ 4c z OS CD 1 Z CJ *5 3 3 3 3 * : UI U 4c UJ V, V 1 -J E X _i 2 2 Z Z Z « Q E *-• 4e H r«i 1 < E Z

:4c I < CD 4c z Ui o 1 CJ . . CD O

4c H IT O 4c H "S 1 M Ui z

4: 3 < -I 4c < < o n I o -J H“ z cn E 4c < Q. 4e z G CM t Q 3 Z a E E M

4c 4c 1 -i LO CJ E E E < < 4c 4c 1 UJ . • X E E E E E 4c # 1 E Ui Z E Z Z Z + + * +
Subroutine ESTART

4c 4c 4c 4c K 4c

4c 4c 4c 4c (T 4c

4c 41 4c 4c < 4c

4c 4c 4c 03 4c H* 4c

4c 4c 4c r 4c 03 . 4c 4c 4c 4c < 41 UJ tr 4c * 4c 4c q: 4c UJ UJ 4c 4i 4c 4c 4c o 4c O H Q 4c * m 4c 4c Q 4c h- UJ 4c * 4c 4c 4c q: 4c z Q 4c * 4c 4c 4c 0. 4c. H- < H 4c 4i 4c 4c 4c SC as 4c

• 4i 4c 4c 4c V- 4c < < CD tr 4c • 4c 4c 4c CD 4c H GL Z UJ *

4c 4c 4c UJ 4c 03 a H 4c

4i 4c 4c 4c l-> 4c O K 03 4c

4c 41 4c 4c D »- UJ «

4c 4c 4c J 4c UJ 0. CJ K 4c # 4i 4c 4c J 4c z z UJ 4c

4( * 4c 4c < 4c N« >i^ 03 UJ 4c 4c . 4c 4c H X 4c UJ 4c 4c a: 4c D UJ UJ H 4c z 4c 4C o 41 Q Z I 4c 4c 4c IL CM 4c Z 1 as o H > 4c K 4c 4c CD 4c Q J 0 O 41 u. * 4c 4c 03 « N4 1 D a K 4c a 4c 4c X cr 4c « K 1 03 UJ X Q 4c K

IT 4c 4c U 0. o: 4c 0. 1 Q O UJ 4c 03 IT t 4c 4c O < UJ 4c 1 UJ a N4 Iii4 4c UJ <

03 U. h" 4i 41 «J 4c SC 1 z < ^ u. 41 -J H

UJ Z 4c 4c a U 41 u 1 < X 4c G

H O « UJ 4c 4c UJ < 4c 03 1 Z Q O Q 4c u. O

Q 4c 4c CD s a: 4c UJ 1 UJ z o 4c (T CVl Z 4c 4c Z M < 4c Q 1 as < X z 4c o Z

C 4( UJ 4c 4» Q D ^ I 4c 4c < D

(T . QL 4c 4c z o ca CJ 4c 4c z Q A IT . UJ 4c * r < 4c 4c as > o

UJ UJ . Q 4c 4c O Z . UJ 4c 4c UJ li. . Q UJ z 4c 4c U H z 4c 4C H” . « 3 G

< . UJ « Z 4c 4c . a < 4c 4c X K 3 Q

z . H a 4c « UJ z a z 4c 4C UJ as Q >

K . ^ 4c 4c ^4 K 4i 4c < 3 • <

D 41 H 4c 4c <-i «9f Ui 4c • « 4c £ K K Z CD * < 4c 4c J UJ 4c 4c O 03 UJ 3 H

IT O « K 4c 4c o 1 4c as CJ -J Q Z

< •-< H * Z 4c 4t i-« UJ 4i o 1 4c u. »-• 3 M

H CD 4c UJ 4c 4c K a H A 4c 1 4c Z U. * cn < Ui 4i z 4c 4c M UJ . z 4c 1 4c 03 as Ui UJ

UJ O K 41 UJ 4c 4c Z Q 03 1-4 4c UJ 1 4c X -j IT

41 4c 4c M O 4c CJ 1 4c CJ Q <

UJ u. u. 4i Q. 4c 4c > 4c z 1 4c o UJ o u. z »-• a 4c Z 4i 4c Q . Q , , 4c < 1 tn n 4c 03 CJ as G K 4c # K Z s 4c z 1 03 m 4c a CJ G K tr z 4c 4c 4c Q UJ 4c UJ 1 V, V 4c ^ as G

D UJ Q 4c 4c 4c 4c UJ .. UJ 4C K 1 0" 4c z < Z UJ Q O CJ 4c 4c 4c 4c z q: UJ 4c Z 1 UJ 1 O o 4c o o o <

tr CD 4c 4c 4c 4c O U. z 4c 1 H 1 V. 4c £ K Z UJ

03 CD : 4c « 4c 4c V- I i-i < 4c < 1 < 1 n o 4c Z Z K S

D UJ D K Q q: z 1 Q 1 CM CO G z o z <

CD o > 4c 4c 4c 4» O D Q < 4c 4c CJ u »-• • 3 4c 4c 4c 4c K < Z 0. 4c 4c

4c 4c 4c 4c 4c 4c + + + + + + + + + C C C CJ O a c c c c c c a u o a O CJ O CJ CJ C c c CJ

o JJ.JJ-U.

COHMON/CCOS/OKCL.

OKOP.

W80P.

USAC.

SOOP

INTEGER

GKCL.

OKOP.

USOP.

USAC.

SOOP
Subroutine ESET

o

”•* f

1 Z

z 1 LU

VJ 1 z i w r* • < 1 q: ! H i— 1 LU

hi 1 < cn 1 i~ ' a: f <

01 t cn cr i Oi ! G 1 01 1“ 1 q: Z ! Qp

' O 1 u i 3 2 i r—

ia^ i i

i < 1

1 L. I Lu > 1 Z rH 1 H- S 1 o ~J 1 <

i hi <• •» i 2 ! cn z t 01 Lu ! '^'2] 01 • i CJ K c—4 1 < 1 z Lu i ci — i o Cm Z

C t h- cn 1 < G CJ Q 1 1 3 Z. iie: ! a.

{ Li 1-- cn i + G < Li i o i LU s K- Ijj IS ; < 2; C5 i H- o 01 3 K*

i z LU 1 < < J“ ! < >««

1 r“ c a: 1— cn ! z lu s: } cn LU o z cn ^ ! z 1 cj z a. o Z i z r« •j i !l uj Q l{

1 c z o ! LU b- 2 o LU Z f 2 l: 1 H < LU w 1 z 2 _j 1 < h*4 < 'i G ‘X,

t

1

f Z

Z

<

CJ,

! G

1 O

vJ O

<

l: cno

iL

Nk9 LO i C G 2 LU i2

iJj : i Z U. C. z

cn i LU0.

r*> !

i LU on LU

• i

, L* z ^ 1 i LU

r— !

i r» < j G o 1 - — I

Z cnr

<

^2 (T

CD < a

o z

z

ovi 1. Z

< ‘cn 2

o LU z

H»LU

LU -T* ' • • h* H

< <

z 2

01 cn

2^ I z

H” 2

—

z :'ij

Lj 2

uu u *— < z 1- Z <

1- < O >— 2 01 z r“ S-^ on W CJ < rr ”3-

•> / ^ H 2 > '

• 1 1-*C3 <

C LU O X }-* Z

< Z i~ cn z w

< G Ik—

9

< H-l cn z H"

Cu < O w aa4 2 <C -N C z < 3 ; c L-> —

1

o 01 2 LU 01 N>4 2 01 01 Ni4 3 3 O 2 Z 2 Z h= z 3

o c . 2 < Z

2 G 01 c ci c 2: lU LU h» LU bU 3 01 2 3 Z

z . »—

»

< CJ 2

L, LU LU LU 2 u 2 II 2 2 2

h- h” Z K 2 0 2 2 2 0 U < < Z < 2 <

LU ,u> H” D f- G < 2 2 1 0. cn 01 U tjl 2 01 t—

1

1 on CJ CJ 2 < 01 2 2 2 < V CD H* K* 0 CJ >-> 2 2

LU Z Z <

H lU 2 2 > 2 01 < 1—

•

r ^ 2 I-— n> < LU 2 2 —

»

Z U1 Z 01

j— LU ^ 2 < C

'O 2 LU 2 2 2 <r r*. 2 2 2

1

1

i

! tr

! b

! LU

I K

1

i

i >

i

{

; a

i UJ

i ^

I 2

! °

‘ s

I £

I

! Q

I CJ--

t Lii

! cn

1

i cn
mSCnNMlICT

THE

HIMDQU —

PF-RQ

UOrmSTA'f

ION

CiNi-V

CALL

GDWIUWCl ) i11 o K<j cn ! U

Ll

IT

il! Liac

Li

cnu z Z . Li X LJ H a

1- LL C

u.<

h- LJ cn 3 <1^ ry < - z c )-^ o H* C I" Li < ZI i- z o <

tn

-1 . -J . c G

LO 2 -J Li CJ c 1-^ cn

1—^ - q: cc

L- QC 21 Li a Z < (T LL 1-4 < LL(j

it 1 1-4 ~7 oc

UJ i n I Ui Li * h* H' i < < : H“ H— ! Oi Ll 0^ i CJ >—» CJi t a ^ z Ll

Hi . rr Z < 2C

Li C

tr

LJ Li z cnc

-1

cn o

LJ r/J

•-J e- I f z< z o

Q. . O Li O Z O . -1

-J ^ < Ll

vj !-• . Z :s: -4 CL Z

tl G -J

*-> C O O O LU OO -J -J C J Ll ^ }— t-4 CJ cj Z C c c z Q sJ Li

cn DZ

CJo

-i<

CJ cz

LJz

Hi iJ. i-zoo 23 £

LJ Z

c: IL! O O CJ CJ u CJ ccc

'J
Subroutine OINIT

o

<

1 -• •• -« ( 3

1 1 Ui

1

1

1

1

1

1

h*

•

1

i X 1

1

1

1

•

{ UJ i 1 O

1 1- 1 1

1 cn 1 1 rj

I UJ 1 1

1 j“ 1

1 1

i UJ i Z

I

1

1

NOI

1 1 X I Q 1 (Si

1

1 H I 1 X

J

1 t H 1 UJ

1

! > 1 < 1 > <

1

1 S3 i h* 1

1

1 I z 1 o

1 1 a 1 Ui 1 z

1 1 UJ i X 1 Q t t Ui H“

1

1 U. !

1 Ui Z (Si

1 :$: ! 1 q! •N, 1 c UJ

1 3 1 O 1 X >-4 rI I O 1 i (Si A 3

J H* 1 X 1 t Ui 3 UJ < c:

1 3 1 1 UJ (Si 1 Z Ui X -J K Q

1 O i UJ i o i 1—

X < (Si h* Z U,

1 « 1 CS 1 z O i H < z Ui 3 X Ui cn H O 1 t UJ o 1 3 z u H” Ui X z

H Z 3 1 H- 1 X n Q 1 C ^ « H UJ c

• Z - cn C « i cn 1 Ui * CJ i X - H .A u

1 * Ui # (T U. UJ i 3 1 LL Ui tsi \ ffi Z 3 O 3 o 0. H*

1 ^ s < Z 1 X 1 UJ (Si I 3 (Si « o o X <

1 cn 3 < -1 * < 1 I X 0. i-« V. 1 (Si z o C? o K

Ui O H < z z i Z i X 3 - ry 1 3 **« C*Ji o % 3 K cr < (J u. i O 1 UJ ^ X \ 1 ^ u. « 2 < £ cn « i ^ i X < Ui 1 < 3 (Si tn H M K X ^ ce M cs ! H- 1 h“ X X ^ 3 1 Z z z 3 3 «i4 Q

i Ui > -I Ui I O t Ui CL X 1 oc ^ 3 3 G o 3

< IT < X K 1 UJ 1 U. H X X < 1 Ui < U> U. o

UJ (J X. UJ (J UJ CJ 1 cn I O U UJ X 1 H Z 3 3 Z H H= q < X o o o < 1 1 < C5 1 X cr M UJ < Ui < CJ 1 ^ < UJ > Ui X 1 cn 1 Ui X UJ < 1 UJ UJ -J -J Q H— X H X UI h“ H* < 1 ^ 1 X < h“ h- 1 H— -1 -! < X t—j q: J

1 X . . z Z X 1 X i < X z S ». . X . < < c QC o UI

N4 O . • • l-» u 1 K J

1 z cj *-» c !

1

. . Ui . CJ CJ Oe 3 u. 3 u. 3

i

1

1 ^ 1

1 o o

1

1 1 c f-S Ch 0"

(

o o cj o cj o o o y u y u o u cj cj u u CJ
Program D2013 r

it s: « is

Hiz

it 3

tj ? z'«»• 1^ V <

CT . o

V

LJ 3^ z !«. V — z 3

-—

r: z

< c <

. 0. 3 —

c? » »

* a? rj r“

Oi o 4: , G 1—

>

< ' r* (/i 3 Z

3

o w HI 3 K c-

•w< <

r“ B <

r \

* «— W Q

< h- r-* cr. x: 3 2 <r •V 36c r. i' - H

cn 1 »

* ^ X a.

<

z z

O 3

s. z

- K

a ^

cji

Z

G

O f— H- 01 — c (“ • 4 '• < z > Hi CE <

Q .r c c ;— w Hi z Hi I— 0. CJ z 01 < 0- - a iO' Hi 01

>—

1

H h: z h: >c' z z z Z Z a

z H < Z 5 Hi *-4 cr — •^4 c 2C H- w fj! I— H I H o Z <• . X HI C

0- < 0_ Hi r* -G z 4-4 Q H I— U) z '< u •s. ’—

a; C i— 01 . Z

z r u.- S— HI d Hi 1- < < Hi ,u_ > a

< Ht r.n G a: z T~ 0- Z o Z W 4 z

z O 22 it 9 < z <c H- < a: CD . < a: Hi G

< Hi I-. Hi < Hi H- G 01 Z Hi z G <

-J r HI o r 01 II # LI > CJ < 4^ HI Z • u. *—fc HI z

LH < Z Cii + < 01 z * Z Hi c? . < z }— -1 Z

»>4 2 »—

4

G z Z HI Hi s < 1 a: 0. z o: _J 'T -irt 1- •' c 1- z i“ X z Hi -I a: Hi Z C— o: r—w 01 li D V. HH 0. It C. i“ H O C 1 II Z T o K Cl a: HI o: < 0 0 — 1- >0 O HI H f“ a: u. H 0. LI cn f— < h- H G 01 HI CJ u Hi cn CO !— 0. IT T < H ^ z C1 41^ z r“ HI G H »-4 0. CJ «-i c C H CJ o: X 1 4»^ "r «<' a: C5 < cn z cn H HI 01 <r H! a; C >“ Hi HI z 2^ < O O c Z -J 1-4 H sJ u 0 Li z

HI G z 0. CC •—» 'r“ H- i~ a •%<» -I G 'li Z -• •— H -J H G 0 o Z - : H- Ui -j Q li :i Cl lOl < a Hi z 1- H‘ Q G

-> t -J < Hi t—t r Z < c o

Hi U < 0. H- G a: 01 0.

4. z

» O o Z ( _l CJ q

< C 9^^ f

( z HI U"i O < Hi i-H 01 CJ h- HI 1— L Hi z Hi in o —4 < < H H •sJ Z W-*9 H- Tli H —j C3 01 •r^ HI r“ < H -J a. >-- 01 CJ —

H I-* CJ it 01 -J Ol 'J u Hi Hi Z < < 'ji H < k—

4

t—

4

-J ^ G r— < » O < CE < w G H rt HI Q U o Hi G

21 22 < z < H K" (H • 4 01 H. < 2 QL SC < G H LI cj q

Ci NiN G W Z CL “• 2 1—4 o cn 01 < z h~ <—

4

O 111 >— l_ sJ 'H r-' H- *- V— G

it J? ti it i= 4t S it * 3 *

it a J? it * a it u*^ it

i: it rt - it - it it * a
T C

fi

Lu3 ie t 1 « ujz K *

03 K oi

H“ s 3 {.Z 4e < ill ^ • s o c: - *4^

:i: rr ?• cs 3

CJ

-^» ui % » » » * ? < cn o LJ s: H 2

a* cn 3 b ¥ • <1/ IJL 03 a Lo s

U3

M X n Z u. o iiJ <

ul! ><> o 3 '•>» Z Ui C- aj ' w in Ci » •'- Z O c. z o LO X < < < cn 2 1 •t” tr t Q H E tG < X o

li. H" U. >- OL X S Ui o *-• Z G 3 o K X • LU < 3 < C 2 Mb < 3: K 2 O >WI LJ cn o: < O

i#

•t® 1^w 2 O 'll. M a; o c.n s il. vH Ll. q: w cn K S s C 3 u; cn ic u. - C G 3 ^ )mm aJ 3 < *» •«i^ — i 1 S - 2 2 > 2L Gi 03 i. z H* LO >-4 !Z 3 2 s Uj ::i <

0. H

U3

U > < 0. u] 0 H 2 ::^ > < . a:

?" uJ 3 < 03 Ud 3 cr ra Z UJ 2 3 < Z G -- 2

Ui c ^ < O fU • H z < 2 a »-4 > z «« !I Z O. Z 2 U Ui h*

:s: a > C5 O G li LU •MM s X ru S 03 3 Ul CD G H- 3 2 3 lU r«

«fe H K o 2. if X K i; 0. H* o z H- m 111 :te 2

cn C CJ CJ ^ Z LU Z CJ G CE J— is Z z z c G «. O O <W G 111 3 < — C LU cr

*k M«» s < Ui 2 Ul

w G o z z c < 2 Z 'V' <«* CJ ji^S 3 3 }* CJ 2 K (1 r 2 c Mi* C5 Cu 2 i-* c:- O 3 2 2 CJ 03 < 2 1 , f K

-i1 Cii lu f« c? H til in -j Z -J ll. -! CJ s 2^ 2 G K

573 < <c z cn G 2 cn “li o U -J Ll. 111 li LU O. < 2 2 c CJ CJ G c c < c _! Ixi >>* U ^ u

CJ Uu G 0. o o Q 2 O LU C Ll CJ < 03 < 2 < t 2 < .f* ^ G C 2 2 Ui ij -1 c-1 1“ 2 < is tr U. •i Z 2L ul cn w < ll, ill S’ H *-< CJ ill H- « z + C n X B s

li" ..^ » c « i.'*. 33 9

t-t jj: o 3 Cii 5f S A M* 9

bJ>GZ

UiX*9 n

OTKPT

STKPT ” 1

CALI.

CMUHER

STOP

'PNOGRAMH

D20M

F!r4ISHEl>

LNO
OPEN

TEST

REPORT

FILE

WHIG

HAS

THE

SAME

FILENAME

OF

THE

TEST

FILE

WITH

FILE

EXTENSION

'TXT'

FNAME<

1;

10)=TNAME(

1;

6>//

TXT'

OPEN

<UNIT«=FUNIT,

s

ta

tus=

'new

'

,

FILE=^FNAME

(1

:

10) )

RFILE=FUNIT

I

Subroutine ESTART

r

01uiK

K

GOUi

H*

Cti A 1 z

Z o \ 1 z

Q ^ . V. 1 H

(M ' 1 G

cn It II 1 Z

q: It Z II 1 IUJ II C II 1 > I z

O ' 1 X

z - 1 K

. < UI < 1 UI . • > • 1 > % 1 a

0. UI o UJ . 1 Z H • • a «i . .. 1 a

Ui Ni4 z . 1 z

D Z < Z 2 1 cn G *-i* « u o 1 z

IL >0 a . • K Q 1

. . H H A * ^ ^ H z 1 Q

1- cn < cz Q , -0 2 < a 1 G

(Z UJ H c C Z .. CQ H > i Z

a Ui K Z u. z a 2 -• Z Ui 1 0. z UI 09 > a — K UJ 1 z

Ui < 01 Z 01 > Ui 2 Ui CO z z 1 « 1 a

(T z Ui (Z Ui Z Ui Ui a 1 z 1 O ^ Ui Z « z < K J z 1 Mi 1 Ui I a 0. C3 * K a Z Z a I - 1 cn 1 G

h* in z Z Z 2 K CO Z 1 < 1 n: 1 2

o 3 ^ O o z >-» 1 r»4 1 o 1 X

O Z z o o < 1

1 H « 1 z % II <P4 c3 o n Nk 1

1 M n 1 Z

UI II o ^ n M 1 < 1 z W 1 G Q ' a UJ cn 01 < • ' II 1

1 2 01 z 1 M

< 's z z z UJ K < 1 H 1 z z 1 Ui u. z 2 2 }- X 2 S M4 1 IB* 1 UJ 2 G 1 CJ X q: < U U Z 2 G ^ 1 z 1 -i z 1 z

w H X 2 2 »- O K K M i o ni n 1 M 2 CJ 1 G

Ui Ui < CJ II II 2 UI < z 1 a II II II il 1 Ul II 1 H H Z -I «i O 0. »- r i z z CJ Z 1 -i z 1 G

o: ' K -1 J 2 2 H QJ •»

i CJ Q G < c z 1 Z z 1 (T tr o ^ UI < < Q Q 2 Z O cn 1 ac 01 Ul o G 1 o < 1 X

2 2 U. O « U > 2 O 2 U. >s G 1 O O 2 3 G 3 1 z CJ O 1 K

.

.

• • CJ 1 u 1 z 1 CJ 1 CJ 1 Ui 1

( tn c 1 —
APPENDIX 0

LISTINGS FROM DATA STRUCTURE TESTS
r<Tw

^ ' 2i- a XWMB'^^A

8T23T BHUTOUHTe ATAG MOS^ eOMITBU

,* ’ r'’5!

r

Ui* V

i-.*#

ui

yu Of

U ^ A ^ Id y X V N. I I ^ i ^ 7 lit « 49 t n * *"• it ••• -» s ar ^ ssSg u QSiZZ

iM

« Wi« X * fu a.- Cj J, 4i

U;

’f ••'

vJ *&

k f. § 5 - lAi U -

- I'^ i w ^ — Z - . X - 1

% ;i\f' ? r^

•

•4» _ ^ k ^ ^

», ^ ^ - tdk. ^ «y ** ^ biu • - cl

^ i-'C*-" . . » • QC ' I

Id- y Sirs ^

S

’ s i X c i

• _

j»- r ^ I

.

O ^ ^ *^ 4 - >» 4 ^•Z -€ i •N O ». ^v I - 9 ^ < ^ *4 8 4^

. !!f

i

.-* f. 9

* 7 * «« i v’ »

X i ^ ^ y 1 n!

l!|ll

S . .1

-^'
Program D2012

r

I <>

1

1

^ A ^

* ^

^

I I

n

O^ ^

^ * ^ « •

I ?

II u

* Crf ^*" ^ Cl Lu

;.*» ^ i- I

~ ^ CT

in

* * * 5P * ^

w->

CO «o 0-OOi-«-,

VC

O

^ *

4c # sit r 4e J?t

-J >

lL* G

H- CL

G

G

m

G

o

-:l

r>- LUZ

D

-J

QO

'O^'O’ '0'

o

lu T' 0 c?* iT X Cel 4- * G LU < X 4 2 I V^ I

1 C•y 0

(n

««4P <

0G

CO 4 F'. Z

c

21 z

A < Uj 4 < 21

a* . 1 f— 4 «Oi^ CC G tu ’ 4 LU h* LU 4 r~ :£ 4 in tn z a. lU LU z 4 . 2» 0

4 Uj LU »—

«

> H* h“ < 4 p z z sr 4 !— !— -I i— 2 < < iT 4 Jj 3 ia.' 4 G > u: (f 1 G < 4 < -1 LU 21 p

4s 1

1

! CL z z z: 4

1^'

. ^ H z “r

4s S ^ w *-» c 4 ;— ^ a. z 3

4 rK CL _i £ 4 iU COl 4 -j P f- G 4 «. , q: 4 -i H“ f“ 1“ < Ll < Z a. LU

4s ^ < LU LU Lll tu 0. 3 ^ 2 Z f— 4 Z G cn in G LfJ 4 2C V- II 0 LU

w. Lu Q Q lu Ufl CL - < 2 Z

4 (- ^ p Q w c:* 3 4 CO r - ^ 3 <

4 LO 1— }— K 9^ < -! 4

* • •** C z

> > >

H. Cl z

f- .— }-

<C

cj > ^!

<

a. r rv & < m >**»< z 21 a 0 4T »— 0 0 :U XI

4 H” z X z ix < 0 z 4 3 X 0 '— u~, 0 X Ql 4 G LU G c G < Lij 0 cU X

1 c G 4 0 t Ci in c J- 0

4 LU 1 C X X X 0 0 <n X 4 0 *y* 4 Z G z z X X cri 0 0 i2J X < X 4 \ z z

4 c :U LU LU LU Ui 0 0 w-^ G G c 0 < 0

4 z G a. 0 0 C5 0 in z 0 4 21 G z

LU 0 i> 0 _1 4 0 H* <

4 z uU 2 0 0 l> < 0 0 0 I ! 4 Z G 0 -0 X

4 < 0 0 a 4 c G < r-1 z

4

o« QC

rpt rv ,-il w 0 { 1 3 4

•s. ro

'ji <

G..

A'a

LU

UJ

^ a ?{t

r_2 iji !.•' i:ji :

iu &. a a 41 » * :=

G

q:a

01

CLLU

3jL -4: ii r- ~ Vz. ^

9 *. 99 ;?

h*U

iL

"5

9 «

a:

h“

c

rj

• U z

. 'I <

< «! iU

LU U. D

U G

U <S * 4i

4: ^

a a 7 a

0: Ct

LU>

a 4l 4c 4: 4s J}t 4c ic a 4c 4c 4i 4-

<

Jr z

< c

_1 z

CU Z

LU G

C cu

<

CL j- Q

LiJ 0 Ll c: <

C‘ lU 21 O <

u _: 0: < <: LU o u o « >-i LU O o H

4cf 4^t

lU

!-• 'J C.J -u 0 o v^.= ij o cj> >:.j o

4

44

O CJ v^J qU

4

4

4

O
o o

o

Li; Z Cl r

LL O

LU

UJ

g: X

< ir ^ cj 2

QJX

LU

C.Z 2;

HiX

pcp

cn

2.' c

Q-y<

c

LUtr

r>i^ h]

>2z

z

z

H

z

z

n

<

Cl] <

— uJ

I-

^ n

5J- z

o

ITS ca<

<

<

0:

LU

I li I— < 'Si X <

o

cn - * . LU o X o

u*i S ^

< — 02 ^<00 XX--

^ O ^

o -j z X

< X CJ 2 Z

o

*J]

cr>

Xr'ft

CJru

-1

C5

Cu

-J0

<

1 J -Io

K

2

u*^ X

X X'G

Z

C

X

X

c

SIX

<

C5

- X f— X z c X 2 CJ z 2 w 0 0 X 0 2 0 0 r ': n 2 z <3 3 C . _ ;— G 0

^pK

•* X r- H X «. > < < CJ X •13 K- • Si G X < G G CJ X 0 LiJ G ,u- X X T“ •*v 3 < >— -K r'^ X i-— X 0 . p . X 0 < 'Su IjJ rv ^ K < G X 2 < , 0 * X '> c. <J G <

Q OD cn X 0 X cc 0 0 0 iW 0 LJ 0 \ .. < t 0 — q: G G X . • « . 0 : G 0 • X X <-v G <i 2 X 0 X 0 n 2 2 rs Z X 2 Ci »- •. 2 lli ;— 'll < CJ O' 2 1—

••"I - X < z - l— •'J* r—

*»• ~ X X

X

hS

w O

< X

X

- <

uj X

in u

< o

si fw X CTj o o

o

>0 2: G . X lA G o yj - < - H X cn X o (-• < . ox K-^XXOZxGXXLn OC'Q*— <ox <G XO •. OOC? — C»Os5 - n X 2: - X T

- X 'oj li cj Si e- .

z G.- X -:f •X CJ X 3 0 0 0 vn G X „ G X •y CJ X X K 3 0 a 0 u

I*V« X - •—< Q X 2 — 2 < c< X X L. P X 2 X X X rj «J K <0 X O' 0 X 0 X n i *

* X > X G X w X G C X 0 c X X r* X 4i- G X X G X S X X < 2 'jj < < » - «-«^ Z G 0 — r-j a- 0 z 0 0 0 0 G 0 c- 0 G ^ 0 . )—

t

G X X • « >-* 0 * X X 0 C- . ^ 0 X X - < - X.J f- l'*' X G 0 > - - /*

H* z. * GOO

o * z

. G X

X G _< b z 5

< o * X - C; 0 2 2

« X

X K

O G O «

X' O - > . O - O i- 2 o

^ G X G O X Z <

2 2 X C

iij —( C? _J X o . e

o - c -

• 2 r- o X X G

Z r- X C. X G X X

X G O O

o

iir.

< u

X 2

>

0 <

X <

< o

Z . o -

UJ< o

X *— X X Cij 3 1*0 n X - X LU X < « J 2 G c > , »:: , n GX 2 X-t2:^<

>

X

>

X

XXX ^ X ill «J 1

1

i O < o CJ o X X X X X — u

<C < ;— <i—Oi— X X Z G Z G Z X X — CJ — X —

o

X

t—

CJ

X

X

o

X

o

2

X

o

<

SiG X CJ X CJ X

Z < X

- X

X H- c z

y~ X

< i- O Sj

X

o

O

^ titl

X

c

CJX

o

< ^ >• Sj O S G

Z X ‘-^ z r XXX

G X C

X r- X

X' Z X

Li.; —• X

F :t

5? ^

t - t:

X

- X

X z

X G

> CJ X

X X

o

X

H-z

X

X

u

2

<

b

— O' z. X . X X <

G a z

X o o

z,

:

I

E

2:

Z!

cj- o

_J< Z

X c, X c::i

* o X X c z z c O X 2 X X < - O X Z z rn ZXCCcjGOGaGZJ-Z G‘^Z 22 GX 20 G<<!t OOCICJOOOOCJCOOO

• — G G

— G i— < G' O

X »-* V.J O X 2

< > < X X ^

X CJ O O

X . • • O G i- •-

- ^ I w > < ,—

X 2 2 G

G ^ X 0000

W- sJ vj

X 2

O O

>x

<r> X

4 + + + * 4 T 1. 4. A

I
— Z

f»^ CJ 2

w«{ C4 ;— c • o Z z ;— z

h“ •. C5 cn o '21 > cn

y' • QC z CJ "

’r" cn r u 3 Q= iLi K H” CO a z

r«-s »— rc O cr H cn CO < z z Ll

C- I w O o H’ 1—> * '-' 3

Lll c o H z S3 -r> z z a O « 3? c? < z < CS c

c- < rjj si z .. CJ h“ - W z M ra s Lj < o 2T 2T z > z

QLC

i3 <o

1=° »w LI

CO D rV- 1—

iSX

H*< Z Z z z CJ z < o ;— 3 |_ l>- 3 <--• i—

cr* Q_ z S3 C 3 < o: a CO o « ' •»> < t » z a >—* z loiB <I z <3 t * O Z C X C o > 3 CJ D hi c*r* L»« q: Wbd H* cr- H CJ < > CO f” 2T i— > ' 1 L rjl !3 LH }— Z r” Li r- < . < cs 2 2£ o z z < a: < 03 z O 3 3 ramA O — > o O C < < z z a 1— Z r“ z > s CJ z O O O 1 < 3 z i-» sJ z < 05 c 03 < < 3 z « T* ^ cn o < 2 C‘ 3 z « a: i“ z Z X

LU o \X O 2. 2 }“ C G 3 a a 03 z h* o z 2 <. CJ

Lii 1- z o - < T~ ;'V' 2 C }m~ i~ CJ LJ

w z sJ z < 3 <

u. o tr < T* LlI o a Z t"n c Z z < CJ > t Lon

Ll! < - H- O'.: o CJ < z )— ! a > z z ;J Q1 z CO Z O CL :i: a: o G < a z z 3 z z 05 h* Li Z 3 iw 3 ? # «! C? c:» o o « G o < z w CJ a < Z c 1 L H= i— X z O t—» iS 3 3 3 o C5 z 3 CJ z a o i“ G in -J < <

!;ji T! j o a. H o c 3 H CJ :> I c < < w«/ CJ z z rv» LL‘ i—< z < o -J lii C U. tZ H“ cn cn •—1 3 t—1 3 Z < < 3 CJ H* O T <3 U -1 e oc al Ll Li c Z CO H- < 3 1“ cn r 2> 3 » c

-JW * a « o a; Ui -i H-t *Mii < < z 3 < < <r K < z z z ?** cn ~tf ! < a UJ < < < 2'. < Z Q_ r* z o z z < z ,. rt C! z o a c- crs c cn O c o 3 lil 3 C? G 3 Oj < > W Ifj o i— •*c z . l«-^ « o - Ui o c- r~ 3 z c 3 cn «3“ r“ C‘ o ^ iJ^ a cd > d d H O cn r“ (T z :C z z •> L z G

u; •aJ < a. o .._.l d u I z W*

w 2 2 >“ l; } rv 1 1 3,

i'*n _j Z -J c. < <L' ii. 3 r* > < a t—4 w . L- < G T" 3 -J z

21 o C cj o c -T* •s. z Z cn

f-^

Uirf z z .. w«» o

03 3 < < 3 z z z z cn -J z o w < < Z Oj z z 'Z ill >a H” jcB z 3l 3 CJ z < o o C5 e o o Q ci e o o o CJ s5 o CJ o CJ 1 a 'T < c SC 3 03 2 G faM :s; CJ 3 X. a z t; H 3 3 > Z ! *. 3 Z < f z < 3 cn H" 3 < 2 H C G 1 z V z z Z 3 s: ^ < < z \ >-* Z Z L Q < z > fv* > Z Z < w Z' -J Z HK < z < O 03 CJ z z Ni a > c 2 Z 3 3C z < h“ Z z c z o < 3 < > 3 h* CJ c < G 3 ra G <1 G < z 3 2 CJ u G 4 z * ! Z z o 3 3 3 1 CJ G z z Z < Z a W z z Lk V V 2 t * Ui X > z 3 *—» z H“ Z z : C CJ l«0 j— Z G z z z Z Z w < Z T* CJ TT z zi Ui z CJ T C c CJ CJ G f G < w<s 03 l*V

Cif* < Z s < z < z z !

LlS #—» w G z Z z z z 21 K

i. z |ad0 z z z L! J O Z o z >4 r < 1- < ,-r 3 < < c c —• G Q Z -r c -T“ z z z z (j CJ J i—. z CJ «r >-«» •J + +* •i + 4 T X L + 4" & A jK 4 is 4 Xf. =<^ i ¥ * :tt »

Si. s 4 if 3?< 3 3 Z’ Cj ij CJ c- Vj

Komncsm
r«/sTA

NAME/

^D20J2

fMJTIAHSATION

•:all

pdinii

f

rf

HPT

=

STKPT

4^ 1

rt

IK<Q

TKrr

>

-

NAMF.

o

<

H"cn

c:LlG

c.UJ

<z

LTr;:!

c

h*

2!o

:j ICO !“

LJ cr.

<.

II G

O c

m

O

. :k X

<

=«t z

G 3

LU 1 «

... . « f“ z

X

A :L z

ic —7

- 2f < X

, * o

3

«

—9’ _^i

:ac TT"

:4i cr G

Q

s rj

3it .. 1- 3

CM

2. U

» c 1“ 3

LU U . r-cn O CP A <

* i— o c

A cn r/l LU cn 3

A Z LU z h- rj c 3 . <

»—

r—

• "Z. 0. < iz t—d Cl < ^ t’ V

K C 3 X

cu L» .» c z LU

LU z < t 1 i ir~

Ll. < 2: CP H -

'j. cs: c a: LU z

LU 2 z . <

<•

OJ Q . -I

-* C

< Ui

! <

c <

e -X

I e

o

vL Q.

<

Lu5?a: a

3 Z

> < Z

cj < . Ll' <1

< LL 0- 3 - Z Z Q CL -j

c: u: ct

21 LU 2:

-• t- Ll

2: Z c2 C- LU ' ' Z

C X * - ^

2: H- LU LU - C- Z Z LU < z

. O Z Z <•

»n Or

a

c.rj

LU - c

c z rj

<

z ^

X

Ll!

• 1

1

Im A < K »— 1- 2 C2 *W 3 Z H X A z -j OL Lu a. d tu LU

0- V. A w ! i: CP 3 Z J z LU 'aJ i-« t— A LU < L- 3 Z H>* H H- z cc z A 1.. K CL < Ll, < —

.

2. !U b < Ui 2: C A Hi* 1— Cl •-•K- Lt X r^* c: — Z «A* T* 2 21 LU 3 < H UJ 3 3 I jv fn < C; LJ A 3

"2> 3 Lu > G t_- 3 A CJ O C X CP Lu Ll ! ! A j*** 1 C- t—

•i-- ! G CJ -1 o A ’ ~I 1 3 w 1 3 r* K < f < A f e ; C < < <

•**, o 2 I 1 < T» a: A < 3 Ll ju c cl.

rj, z u_ LU 1- A r^i u 3 H-t -H

r^ A a ,-r

..> •A A A A A r

A tr A A A -

; r

*> CP I.J** i. .•

e

LU X <

Z LU < 2

z z

<

i- Z

'W ^

CJI —

Z. < L.;

C. ' LT.

LU -! >..3 0- LJ ^ H- 2. ,C LU Z

Z 2- CL -r

>1.4 ^ ^

_ Z Z -

i? >- G C

G Q

I

< LU

LU G

Z <

< G

Z

. Lu ^ >

C 3

Cf? C

< -J _J LU O CL ^ >

X Lfi -J U'j Z

< G < C) ^

Z LT’ Z

«! -J - 3 !~ 3 >- U < LU < l-i

>.> lO i/i

Vi

ir.

f

I

I

I
q (

0-Cu IW

iL E2 c.

cj<

Llolo O '•j; O < < <

-J Li. _J

Li. oi Ll. —i

<C * C 2 U 2 :- —i Ct- ^ - < o z z

i~ « ^

•>r. z P z J \ LL? L* O

i' J

55

LLCuOc

Lu <r<Q£

Ll

r- i-“ lii u: . z

LLi 2C <

LiJ » . Hi* 2 X ! 0 z r> ^ IL 2 2 < < LJ v«

n- < LTj ulJ rj

y s LU iLi Z w IT. z :u L0 •w z c < Z ”7 cn < 2 iXi 1—^ 1 2 *--• i—1 H in : f •«. Ll' u. z « q: X

u. I C*il Z cn Isa z w •« i~ a* h* 0. Q 'w> 1 o -* c C,) LJ 2? ;— a. a_ o: C£ < W J u:

•'r* U.* ;~ 4.- ;r 2 z H* iL ^»l L- L Z 2 3: c: H-4 * UJ 2^ Ll* cn z G —• , 1 J LJ LU 4: ! * j r— (L- Z jTf ii cn 2^ CO .>< 07 u? Z- !“ 3 V ij. <c Ll *>* —

!l 2 a. c- z 0 s: L

^4 Ll \ —4 > -1 L.- >~ i\. LiJ Ll ;—> 1 - : i H-o r- .J : --• J 1—t

•>J^ 5 G CL 2*

u. Ci ; ;i-. < - L. < ;-^ h— Z «.<' * < Ll^ < li. <; U.' <l c < *Mo C' Li. *T 3^ Li»> C.0 Li.i f— < kvJj Lij - *-- ^- *

•j 0 V,.' '.-> i-* ij * — G LT2 U'

A •>. O' s v A A: •A

It IT c - •> 4 4 it u C.' i^‘ i*^‘ .^*i f.i (c
Subroutine DSPLCI

r:

•*s, b

Ui~T

z

z

_J

z <

cr rrj

* a. o

jj r z

C’ oi ^

'I _i Lii cr-.hi z

UJ '—

- - CL* a

;- < z u. LL *- Z i;

' F,

*“ Z kLrf Cik i o z

- <

CIO < z -

'•! CL jJ 'I h~ — >— QL C i. z -* a: ^

i- c 0: 0. I- c . C“

cjX

‘ <

ac 2

w i“ cr z

ir 3

LJ -j

CLZ

D

»w< <

L*Z Cl < UJ rC Hi C HIX z

X

L*J cj

<

LJ a: Q i- Z

QJX3<

>0 q:

!—

a:

iu ^ r— G -J CJ U. <

LO

a:C3z

z

H

- cnq: 2 £

ii—' <

X cr<

' X

!: <

•^1*1 ^ c

1 UL* I— 2 a: a. 3 3 Z

r z _i X

G

Z

Z tLl’ <

-J

Cl o

u

a: H

z

^ A

o --

a:Q

X

X cn a: X U UJ ^ cn

Ui Z Xf SiE - C —

UJ *-*

-s»» a:

a: Li

hLi X

O

L: X

:- G Z X H

X L- L? < — LI X

X'< t—* o

c —

Z X . < 21 n

c,2 .. X Z‘ c<i X ^ ^

Li X

X ijj ^

X

X z cn X L 3 X

L' ffi G LU z

3 ^ Z -JQ

!- X!«» Z b 3 o

- in

>_r

1. J o rj

< <

X

Tli C*J < G

< 1—

X o lMi4 in

. w

—

iTd C X < «i* < < O X <

—

X i~

. * . z <

O X 3 —

1

< < w • X rv X . < •V

* X . 2l I- X

3 = O CJ rt 3 ^ z •— •— < X X X - > G H- - • G G 'V' G G -• Q_ 3 3 X Z X X o « • U. * 3 - < G z CJ

i—• 0*

- z cE G>—

G X

cn G

o t 1 t X < LJ

^3 • X X G >0 •—

« 2l r*v z X rr^ X < 1—

• r~ X ^

J » ; p z < 3

n. G - - :£ ~ G *

» » ? IT- X

X

Z

Li X

> X

L- uJ

o:. c-

«—•

r»- X .«i X! LJ n: >

z X

•cX

<j

1-^

in

L ^ X X

< C

r"

X z

cn X X — O X «j

- X - o X -J z

X c

X X

3 X

lL' l

cn :.' • Xj

« r

nj ir X <

<» -I

LU L

X X

iLi < L! Z

1? o e iZ X Lj Z

t- e r

Z uj ^ G ‘—• X *“ X

t;^

X <

3

G

(Xt

Ll)

tj

3 O -• < Li »—

Z' CD X ;— < cn Li o

•— Uj u oJ Z < X

- X X

X H C

c z fx ^ X X

< I- C5 X cn <

*-r > Oj — CD cn Z X . ^ Gi ii- cr G X C

X h- X -W- --W X X t* n 4 *

r« 7

V V “ X X 'J

•X X Q 3

z n r G X <

cn . 2

rj X X X 3

< . . X ^ :s Z X K

G . cn G cn cs X cn X X z c

X

<

X

X

oX

X

rL

Z CJ ^ CJ X U

'Xo

z z < G

b - ^ G < r X 3 Q X o

£,z

H-G

O

G

\ t- L <

a: I-z

c < — q;

>“ <

< “ X

»— >G X - 21 Z. J* < <

z z

2lZ X

a

X*h-X

c

X I*X:X

i-'S <

cnG

X 0x0*^

G 3 rj G

G ^ X XX Utf IL> lirf mjm I” ^ i~ >“

CJ

CJ n < G

z z <f <

z -c G «?
1

I

I

I

in <! oc o Cu *3" a: cn in 0 O Tii 0 n rv 0 c- o >• ^ 0 •n N 0 o 0

o o C o o ra rj Cii Til rj rj rd Cii 0 0 i^n

C J 0 0 0 0 0 T -T u"^ n

CD CD m Oi CQ GD a H) G3 W CD 03 0 0 0 0 0 0 0 0 0 0 0 0 0 C 0 0 0 w w 0 0 0 0 N rv r^ fv 1^ IV {V fv tv |v rv .v rv !VO

IV tv (V IV IV ^ V ,v V ,v V

o o o c c c o c o o o o c o c o O O O O o C O o o O O O O c o O C O c

I

-J * CQ. X

a > 3

cj! r” CE

X‘ U r- 10 z r

n '2:

tj.1 !— H- CL - C

>-!'»-

1- C 3

_I O -1

\

< -i Z a.

cn

<

z z UJ

jT

K <:

j <TX <

< K

z <

c.

K

0. H*

C.T z

ILZ tl <

z --

9 X

^ K

K CD

a.

>- u:

f« X

ca z

0 0 r- -0 n c. i z c- 0- c- 2». W

Ui i"K 0“ i> !> 0“- 0

O' o !>> O' 0^

.-N !> o O' O' 5> CJ:

-hi. 0“ Ll: w c a 0 Q p 2: Cf

O'- < u. I- 1.

CL

c- r* H- Q 0 0 u 0 Z 0 w

C c-;? o >“• o 0 C5 X CJ CJ 3

!>' 5 X Ui X tvi C£ X z X

u. '. •

: 3 X o •-* X X X 0 q: X Q r*V" “T" _j ^ !iJ o UI > ui z Ll* Li Ui u LlI CJ Z X o 0 o 0 H* o 0 X O 0 c X

o z z z Z « z z « T“ a X uJ X ui ui • X Ui X Ui <» 0 X

CJ X Z LU X z Ijj z Ui X z UJ X z 0 X z 0 X

t UJ • Z Ui X z UJ z Ui • z 0 z 0 tk 0 X < 0 X < X < 0 X < CO X < 0 X < 0

l; Z X z X z U’ X z z .•V' z Z X z z X z

< w Ijj w Ll! 0*J UI UJ .. ^ HI •> 0 w

CJ 0 >—

«

0 z -r. w* CJ 0 m* 0 X 0 X

o 0 z CJ Z z 0 z V ij z ’W’ ll z X

tr 3 X 1 «w ::i '— X u: X Z X X

H* II X X X Z 2^ z X X Mha X CJ M C 1- UJ It 0 i-o Ui !l 0 f“ Ui C5 h- Ui :t 0 H“ Ui * 0 ?—

>

u M C3 g X e e 0 CJ e o C CJ O O c sJ o CJ 0 CJ CJ CJ o <J ^5 CJ <_

-•Pi ^- z < z < z < z < z < ~T < z < 1 I -1 ! u 0 0 u u <J «i U 0 0 t

I I «

!

1 L ! •J ! \ -j u r •Mil u u u u •— 0 Ll f Ll < X < Q Ll < < Lu < u < < LL < - < u < <

o H-S t_': « CJ CJ C_3 0 o CJ CJ vJ ** CJ CJ *«»> CJ

IF(.NQT.

(MSERR.

NE.

O)

)

GO

TO

‘?999S

07B53

CALL

CERR

<

1

,

NAME.

MBERR

)

070b4

IDFLAG-O

078^)5

CALL

GGCHSfMHSERR.

RCiiSP)

07057

IF<

N0T.

(MGERR.

NE.

O)

)

GO

TO

99991

07058
r

O Cii n «9* N 03 CQ3COiLaDCj03 N N fv rs jN. oooocooo

o rj cn^mNaDC^o rj n'TiDr^CDi>o — rj^rin r'pvrvr>-r'r^r^rv!ij(i}(EQCDtiiaccCk>ooc'cs cDiiiOdiQDCDaDCGaaciiicscjCkSjroDcciiicc:

rv rv N rv fs, rv n r. ^ - occooooooooocoooooo N rv O o

N 03

i> O

C 3

rvO O

O cj n m

o o o

c^- 0- o o

o

rvo

3

O

o c c o

a.ai3

UJ<

z

Ui i! c_> C

<

; t -j Ul <

c- *-»

o O' 3 Sj 3 3 W G 0

O' Ch O' O' !>. O' O' a 0- o O' X !> I> i> 0- o 0- 3

. Q

o Q Q G o

l- K 1— h- T*

k“

.-. c <w c G Ll w o G aa o -»

iU> 0 t—

0 0 o 0 a: fj'. c: > X LU X -•a. < 0 ?>. 7*’ q: F— .•^ a' ;— ;i (3 q: 0. X n f -^ z r%

*-''' ^ UJ z - ' ‘ ‘ 3 LU 0 uU > LU CiI Lu G

- O 31 1— o 3 O tjj paa o 3 1- o 3 G 1-^ 0 r a 2 z a _J z ^4 *% Q1 LU , q: lu a q: ui IX fjj a ui , i<v4 0 111 D1 Z Ui a: z u z LU q: z UJ a z LU 0 Ui ( Lu 0 T»

LiJ • S LU . z UJ Z LU 23 q: Z C z c Z <

H

3 2: < 3 OC < 3 (T < 3 < q: a: < 0 < 0 d < 2 3 Z z a: z Z 0 z Z X Z LU a: z z < z UJ « LU a >— LU U.' a GO LU w a

1 3 ^ 3 3 GO 3 aiw 23 3 >—

4

CJ H 0 Z >» ^ Z 'W 3 Z 0 Z w •W z w 0 0 t—

X h“

2: < - X < •a.- X < X Z a: 0 'r—• 0 ' X X UL X 1 «J X 2_ 30 0. o: O h- Ul i! 0 H LU i! 0 K LU ft

il 0 LU II 0 1- Ui 11 3 Ga o )• 3 f'' CL? C CJ c 0 O 0 0 0 C 0 o 0 in 0* ,^K 0 c 0 i'^ 0 0 G d 0 z <

—

y

< z < Z < z < < ' aj -t -{

‘^. -J -S -I J -1 f J _j 1 0 » 1 0 f • -j Ll _i >— li- aj a' -J Ll «1 -J lT _l 0 il 1

1 f w Ll ! <I IjL —

< c < u. < Ua < 2 < u. Q < Ll < c < < < 0 o < < » CJ CJ -< r^i r^.n i— 0 1^1 1*^ 0' 0 0 0 0 0 i-' 0 VJ

cn

O

o

0^

0- iv

ll? 3

rr- i>,>

rv3

i>

f>

xO

•-n o

fv

ro ra

nr* S

f--* i> 0^ O'

O' ;-w «a O' -v ra. w Q p G

K

G w c* ;n o

C C' < 0 < T.

C;' -• 0

CT. < -* aO 0. a- r-«. ru 1 r*.. i-i ^a. N »-a O 0 c rj a c Tii a

a *a1 a- 0 z

0 0 a lU a GO 0 a. 0

z z 0 2 0 M z 0 I < X Z GO z G

o z > G < z o < 0

< a H < Z q: < z 1—

s

0 T- a a-’ a a-' 0 •a' aa Ll 0 0 w Ha M a*- _ ^ WW i—

a

a»> 0

a: cr 0 z

- Til rv Z cc a: Z i. W 0

r“ :: 0 0 r- 11 0 0 1— 1! 0 c

c o 0 0 0 0 o o 0 0

z < z < Z <•

• 0 0 0 1 0 0 0

Ll 1 0 Ll I

* 0 0 0

Ul C < < 0 0 < < LL 0 < <

0 0’ aa Na O 0 faa aa 0 0

n Tij 3 r»*i

:«i.i 3 i*k. w 0 O'

O' O' O'

>a. O'
I r

^ ra n in <1 O IL o Cii n m -0 o ® o «i4 CM n m <0 o m o w n in >Q N 03 O ^4 fii cn o m rj un >0

ca ni Cii r»i cii CM ru oi n n n n n cn n n «!? ^ in m in m in in 'O nC -c >c

O' O' O' O' O O' o o o o o o o O O O' o O o o o o O' o o o o o O O o o O' o o o o O' O' O' o

O N o o N O O o p" N o o o O N O o o o o o o S o N N N o o o o o o o o o o o o o

O O o o o o o o o o o o o O O O o o o o o o o o o o o o o o o o o o o o o o c o o

<

c.z

Uj

z

LU

O

<

-i

o

23

£>

!>

rvo

GO

0^

rsO'O'

O'

O'

o*

inN

o

>

o

pvO't>

o*

n

fv

O'

O'

O' a

K

Q G

rj

O'

1“

G.Z

r—

1

w

1-^ w c o Q G e w o O c o

G o o o o o < O o < o < o Q

A ^ LU < < 4^ 1 o -J o 0^ G

1 G o: -s o -1 iM d G < o u. G Ll O' <1 Td 1- )-

b O 0. G Ll G f t h«Bk G G t G •-< G l>4 A G O < z

p Cli o Cli 1—^ o ra •-4 o CM o rj d o ra •w o ru o ra LL o r»i Q 1Ul

. , }- G

*4 Ll *»4 O h” 1-

• H LiJ s. lU C. u LU « . Lii « -! LU LU Z G

z UJ z z UJ X z UJ G z LU 1 z LU G z Ui > z UJ •J z LU Ui z UJ Z

u- z c z X Z z c . Z H* z h* b

z C z rr LU 1 B < IL b < CJ b < CJ b < u o < Z b < G < CJ b < > b < UJ H

z « < z ir < Z G < z < z < z »>4 < z < Z 1“ < Z CJ CM G Kf « J ••

1 •*1^ -J »s < h” Z

i d 0. u. CL u. Uo G u. d v4 M Ll z z z

Ll. X tn CJ G M CJ Va«> l=* H Z 1- ir X -w K z X z < w z < Z < Z Z z Z G

ni 01 K CM G a CM iZ CJ , Cli z K rj z u. Til U. CM K u. CM Z -i Cli z H" H

4

•# LU. o p- il LU a !*» II LU a II LU C 1“ 11 LU C3 i— !i C2» d G 1“ 3 UJ G K II iU G H* 11 LU H* G II G O U G O O G CJ o o CJ CJ G o CJ CJ a o CJ CJ c CJ CJ Q o u CJ Q G CJ a o o U G Z Z

z < z < z < Z < z < z < Z < z < z < Z Z H (V

1 ^ 1 , -1 -J 1 1 I

t 1 J 1 -J -1 .J -J -1 .J -J t .u -J -1 Z G

r zj n U. 1 Ij •w n Ij d d d -J f Ll f J u. 1 -1 iL ! -J z -1 -J H* H* c

3 < < Li. Q < < u. Q < < u. Q < < ll a < < u. o < < u. < < Ll a < < IL a < z < G 1— LU r U G o — >-4 o CJ CJ CJ CJ CJ »-« CJ CJ t-^ u CJ M CJ CJ CJ 1-4 U Z G Z LU 1 o O' G o >0 m n ru 1 G N o o o o o o o

1 O O' o o o o O' O' .->. 1

?K o O' O' o o o O' o

o o o O o o o o o O'

/V.
Subroutine DSPLI

rv

-0o

o

o

un G O rj

• < G <

IT 1—4 cn tr rj

u fj < 03 z < M G c % G Xj

a

rj O d < « < < o G <

z >—f d 1- d d

L! •» « Z <

z o d > D < d < < W G

d uJ d d < d

f- d <• X j— G -> o Q o O tj d d h- < H-4 z •• < X 21 3 d d « d -* H" h" Z > O G 1— G H- . G G d G h- z d Z d G G z G d G X

< d I? X CJ> 1 3 d Ji d rs 1- • < G d 'Z r^. £ G

b“ G G O cn d d H- < G «• d O Z d Hi* G c G HH u z UD «. G d d G U3 Z CJ LU D d G d X r>* z d X C3 G < < L:i a. >jJ d •-4 G Z < > d h" z z G G 03 X G n d H- d z G X Hi* H* -0 >0 <J u. }— A d G •• LU t-i Xj o • d d >-4 < Q d o G u- z « r* z m G *• F“ G G

< i— < z 0. H* UJ c 4 «. ITJ in 03 d o d G z Z

0. G X G Z i— G d H-% d G d G < C <

uL ::^ G u d UJ < X G ill d r f 3 G d Z n Z d —4 d Q J— d • < («•> z z C5 *—• > d <• u. Z > d c d < < i— < 03 G G < f- Z u G d *-• Z X U ( G G z < — d ' LO cn G d d 3 Cu G O « t-N z G o HH rij X G c 1— X * CJ z < o -1 G n G n — o « H* G d d z G 1^ • •* < d 0. d Z G N-4 C d G Z < G X X O s. G d C H- < < UJ d d « • G . c G G Z d X X d !G 3

rj d U O d d G c d z -1 d d LU 1— fv G CJ (3 ra m O > a d Z 't— < t- G > (—

h- d Q d, CJ G UJ H- 1- c LU LU d G G d < i-H '>“• < G G G Q G G 3 < <

2C a: X X < 'Ji z X a. d »-4 d G d Z G Q G 1-^ n G G K 2 > CJ G O O 0 Z Z K G d d K Lt d d G G z Z 1- LU d UJ G d Z G d < G G (J Z G d G z 03 2 X 03 * 03 Q i— UJ G u LU < d K CJ d d UJ M G d < H4 G (J G H>4 G d G z *-< Z G 3 G

Q Q c K Z z G Z < • O z i- a X Z Z z o UJ i-H G d G G X M d a. mJ < UJ G z d Z -J d d K Q G < O G cn d <J Z d O G Q Z o h- d H X d rs» c K" X < H d UJ H d O K G G H-4 1- z G o d O 1-^ CJ o >Q d d LU d 1- G K 0 Z CJ a < Q X Cl G — < * i— Z o O Z CJ i— CJ G < —

I

G G 4C G d K d G d UJ d G CJ Z > G G G d rv* G \ Ji di iV» K LU \ 1-4 d G G G X z G LJ G G X

h“ Z d t. G J

1 d G d Z rv* i- d 1 d d z _ G d U o O j“ < 1— — < UJ tj U. < < UJ dl Lu H-4 LU U LU < LU 2 z G H-4 Z Z G Z < G

Uj o d o < C.J u O O •G < O u O G 21 O d d q: O < c z 03 < G < 03 d z d o »i>4 UJ Z UJ -J -J UJ d LU LU Z G G O G Q G H f T* G d G 21 d 1- < < o O •— z < < H* < K o Z h* d f~ q: U» G < z G G < Z < G a: Z X G O c z G iz UJ LU z z c Z G iz z d Z d iz HH G a Z < 3 >C 03 o d t—1 0) U. d G Q d d HH o -J o H-4 G *-• G 2 G G z G «T + + + -f

JR « <» « * 9L * « ^ s 5«t ic :«e A ^ *

'O 'J o O CJ CJ u O u IJ G

O

o G G G
I

I

I

I

I

I

o

luac

CL I

I

I

I

K

2

a

L.£

a.

I c

o

Ui

a»>

2

CO

O

03O

O

<

-J

i*

u»c

V

cn

cnI*2

O

cc

LUUi

h-2

ca *1“ m <i n; o

o o o c o c

o o c o o o o

03 ca GO C3 CO C3 C3 o o o o o o o

Q

cnqT

03

T*G

a.X

u

c:

IL

cnM

cn

}“Q LU

>-* 2

2 <

^ Z

(T

ocLUO

<

-I c

< <

LU X

a: cj

V.

0.

cn

z

<t

K

C3Z

LUZ

<

2 --H

n a.

I— i“ cn

0- ^

2: f- :s: 03 I- w cnH

f- Ccn z

!>

0"

0^a

c

o

It u

CJ<

crH

H”a

2

^ ^ ^ Ti] Cii 00000000

CDCOCOCOXQ'XGO ooooooco

cn >0 rv

Ctl Cd Cd Cd 0000 00 03 X X 0000

CD Cd fd rd n cn o o o Q X CB CO 03 0000

n >0 n n n n 0000 00 03 CO O 0000

CO i> rd n n ^ T 0000 GO 0 0 CO o c c o

c^<t“'Ol^0C^’-‘rd

ooooococ 0-0 00000O3 OOOOOOCO

H=

a,z

LU

H

z 0 U3 in n rd LU 0 0 0" O' O' 0*- i> O' 0" !> i> O' 0 O' O' O' t> 0^ 0^ O' 0^ O' O' O' t> 0 O' O' CJLU

O' O' O' < a 0 0 Q Q G a

H- F- K f“ •M* H" A

OL H C -J 0 c Ll C Z a 0 a G

z Q 0 a. 0 0 0 0 a. 0 W 0 O. 0 Q» 0

LU QC 1 0 LU q: Ni 0 -J CL 2 QC X QC 0

« 3 CL 0 IT 0» QC 0 2C c IT 0 q: X CL LU LU 0 ^ 0 > LU Z UI CJ LU Ll 0 CJ 0^ lU U

0. QC 0 0 0 0 h- 0 0 tr 0 0 »-* 0 0 !->< 0 0 a: c 0 ir 0

> Z •> Z Z

ui

z b 2 Z z

H* IT LU a: 0 « 0 LU ac LU 0 ui CL Lii QC ui -I OC Z 0: 2 2 LU tr 2 LU CL 2 LU 2: z LU £ 2 0 cr 2 »»4 LU . z Ui z oc . z LU . Z LU 0 Z 0 , r“ ixi 0 {£ < 0 OC < cr tr < 0 K < 0 cc < 0 2; < 0 CL < 0 CL z cr 2 Z 3C 2 0 QC 2 X K 2 ac 2 z 2: 2 z c: 2 Z 0

LU « ^ LU b 0 LU ^ UI 0 N#» LU w Ui «> 0 0 0 H- 0 z 0 0 31 0 a. 0 IL cn CL cn

<r 0 0 Z U Z w z 0 2 CJ z Ll Z X z 0

ir 2 -) ^ IT o: ac Z X 2:

*-» 2: X

H" i> -U . C a. o; z oc Z . 2: 0. h* ac CJ u

C 0 1- LU 1 : 0 H- 0 !I 0 LU II 0 K 0 11 0 H 0 II 0 h» LU ;i 0 f- iu C3 0 0 a 0 0 0 0 u 0 0 C CJ 0 0 Q CJ C c CJ 0 C5 C 0 0 0 a CJ 0 0

< z < 2 < 2 < 2 < 2 < 2 < 2 < ZI

-1 -1 f -i -U -J . f f -i -! -1 . -1 1 J -J -J -I

* -J -! , -J 1 t -j ll 1 Ll •J G G LL ^ » -J Ll -i -1 Ll w _j Ll 1 1 Ll 1 <: a < Ll < c < Ll < < LL < 0 < IL < 0 < Ub < a < Ll < Q < Ll < Q < Ll 0 0 •-* 0 N-S 0 *-» 0 1-^ CJ CJ CJ N, CJ u CJ CJ CJ CJ CJ CJ O- 0 r-. m >T rs ru

O' O' O' O' 0

* O' O' O'

O' O' O' 0- O' O' O' O' O' O' O' O' O' O' O' 0

O' 'O' O' O' O' O' O' 0
n ^ >0 rs CD in m m « u's o o c o c o

CD 0 QD Q CD CD O O O O C C

rj 0 ^ >0 N

'O 'O >0 -O *0 '0 o o o o o o

CD CD 0 a 0 CD c o o o c o

CDO^ruCD-tf

-0 'O rv c o o c o o

0 0 0 0 0 0

o o o o o o

-0 0 ch fj

.’V rv rv 03 m

o o o o o o 0 0 0 0 0m O O O O C o

0 m >c o o 0 0 0 0 0 0

o o o o o c 0 0 0 0 0 0

o o o o c o

o — rj un ^

C^ O' ^ D' ^ 0^ o o o o o o

0 0 0 0 0 0

o o o c o o

rv o c nj ^

«> O' o o c o

o o ^ ^

0 O 0 0 0 0

o o c c o o

rj

i «J c

UJ-J 0 O' 0 rv

O' 0 0

O' rV O' O'

O' 0* O' O'

O' O' O' G G c Q

«K^ K G w ^ Q Ll G -* 0 ^ 0 ^ 0 f—* 0 0 f 0 0 > 0 1 0 Cl C - ir K- 0 0 0 0

u u ^ z —» txi 0 - 0 CJ LU > 0 0 0 0 0 0 0 0 0 H- r % . z « . Z z *, z • 0 0 - 0 Ixl - 0 0 0 0

yj 0 Z Ixi 0 Z 0 0 Z LU 0 Z 0 * IZ 0 . z Ixi . z LU . z 0 z 0

< 0 0 < 0 0 < 0 0 < 0 0 < 0

2: z 0 Z z 0 Z Z 0 z z 0 z LU

• 0 . 0 . LU LU 0 »—

0 0 0 ^ ^ 0 0 Z

u z - z - 0 Z CJ Z 0 X W Q; < ^ a: < -- 0 < 0 z 0 h- . 0 LL . 0 f 1 0 _l LU It 0 H IXJ 14 G >-• LU It 5 }- LU

rr

ti <3 L_ LU !i CJ CJ C fr> Q 0 0 0 G u CJ e a CJ e 3 b CJ 0 0

< Z < Z < Z < < -J -I . -I -1 1

• .J -i I -J I 1 -J -1

lx. -J lx. U- !

^ t Gl 1 1 Li. ? < U. < yr U. < C U- < Ci < u. < Q < CJ CJ t—» sj- CJ i— H-4 Ij »-* CJ Cj CJ CJ

<

>0 in

lx.

•i* 0 ra

CO 0 >-4 0 0 0

O' t O' 0- fX

O' 0 O' w O'

c> O' O' O' c Q

a

G G c r— h- z ;— t- c A

0 0 0 3 G 00 3 0 3 0 r- < 3 < 3 -- 3 < 0 ^ <C CJ 0 1 n -I 3 \ 0 N — Z 0 0 rv 1

1

<cr < - >0 LL

LU =r Ll G k M ra J'' 0 0 n •- 0 .. 0 0 ru 0 0 Cil z ^ -

•* h» -1 0 LU • X , X C _ LU a Lii u 0 LU . 0 0 Z LU Ui Ll ui LU U3 Z »* z z

1 Z 0 0 Z 0 M

z Q z 0 Z < z < 0 T” 0 . z 0 0 < z < z b < Z -J b z CJ b < > 0 < z 0 Z z ^ < z 0 < H-« < z 1- < z 0 0 *• .J -i I Z 0 0 •>r Ll Lt CJ 0 il ^ 0 3 z t- 0 3 0 0 J- -J w »" z -1 ::i 0 0 GL G 0 0

* rj 0 rj 0 Z . rj 0 Z f— 0 It 'J!' 0 5 11 Z r. 3 ;; LU c K i4 0 0 K ft

14 0 0 c CJ 0 0 CJ (J c 0 CJ C.3 0 3 CJ 3 c 3 3 3 g 3 3 3 z < z < z < z < < .J -J G _i • ( -1 -i 0 % 0 0 0 — Ll J .J ^ 1

1

-J f 0 1 0 0 0 0 1 0 < c < < < c <r < < ! { 0 < < 0 0 < < 0 Q < < CJ 0 0 ‘J CJ 0 0 3 •— - 3 3 3 3

0 O' 0

O' O' 0

O' rs O' O' 0 0 0 O'

O' > O'

0

O'

O'

O'

"00

>

o

2^

m Tf n ru 0 0 0 0

O' O' O' •>

0* 0- O'- O'

•V '"V rv 1-K.
I
^ ^ m,rn ' ^ Q m CD " ^ $ 8 » 8 «ta 8 ji<!Sg 8

illISliilllii

m m §» «ig' a O

S S S S ^ i i ^ $ 3 S $oec>popoooo

“ - - ^

g f 9

a. p

* - ^

• •^*SC5.T>«*' rJ4 p‘‘«*‘- tiSfcai ^

.*rg*c^ -**«ayU

'**’ k ^

S* -3K«W'' 2R Sng '-«^ 3:i^ MX sV3 © 5 I I9

— ^ c»n *ta o<n

0^ ;-^ TM «^3r1 ^ -C '*^ s^<*0 t

Jr ?< <t% ^ ^

.

>0 >'0

ss^%4,

Ok^it ^ f ^ f

1 1.*^-!

. ta^ 4 L» .1- •*» ^ SE1&s*&feS^S^5 '

•-^ ^ j^‘- - >•' J r-» •« «i^ •— -^ 1^ ^ i. i’? e - < § ^ ^ j; *
!>o<

LL

hi>

LU-iH

03UiH

H*Z

Ui

Q1ccDoQ

Ui

h-DU

UIX

UJHOzoDOuH

tn

UiH

Uiz<

0^

GiQ

°X

cnz»-< u.

CMo

ru

fiz<

ITOQe

0.H

cn

Ui

Uiz<z

IT

Ui Ui D K Z Q

U. «K J 9 z ^ Ui z Q < cn Ui Q o ^

Ui Oon

Ui a H m UI

QJ •* « 3 3

(j a

-i u. ^ O M ^ < Q Q ^ U H Z <

UiU +

ts3

CJ t**«**«* ' **4e *

4(

41*

4i4b 4b

4i

4t4e

4i4b*

4b4B

4c

4B*

4b

4b4b

4b4b

4b4b

4b«

4b«

4b

4B

4b

4b**

4b«

H>

4b S t <H * cn *

4b Ui t U 4b < ^ tr

4b H

4b 4b * 4B « 4b o o o ( zz ni H ^0. z

Ui s a t- < Q e o> K IL ^ _J t-a ^ Q

U. < Z *-» U Ui

IE

UiHZQ

O.SSu<H

cn

LUo<

cn

GO

UIzHZ Q Ui Z X

Ui or3

Ui (J < H e UJ H CD

4b 4b 4B 4b 4b 4b O O <K

cnz<XoaXXzQXX H Ui X z

as < H Z

CD Ui <-« ^ Z« I H H“

CD 3 H

H> O U. XXX Z C8 K 3 CD Q CD i K Ui CL 3Q CL H Z X

CD Ui H Z E CD

4b

4b4B a

UIX

cn

CMO

CMazz< X X

UI o Z Q 3 X Z IL U ^ ^ 0. ^ Q O < H Z u cn Ui
Program D2024

Error report file

r

O fi fi

Ui G G

q: fi fi fi X X

Ui z Ui Ui G G G

2> O q: X X 3 3

Ui z UJ z G z M

-J K 3 C 3 o 3 o G Z G Z

Ui < 1-4 1-4 1-4 >« G o G o Q K -J H U J fi H-* fi H

Z Ui < Ui < G < H H Ui C K fi K Q h- H < H < Q cn Z Z Z O O 4- Z Ui 4> H UJ 4- K UJ 1- G + z Z 4- z Z

cr 4* a cn + a cn + Q G 4- G 4* G

+ Ui 0. 4- Z Ui 4* z UJ 4> Z G 4- z G 4* z G

+ ^ Ui 4- q: 4> X + X 4* G G <4 o G 1 o a; 4> .'0. 4- X + , X 4* X 4- X 1 + Z 4- 0. Ui 4* X UJ 4- X G + X + K X 1 + 3 < 4- Ui IT 4* UJ X 4- G X 4- < G 4* < G I fi UJ 4> S 4« X + X + H X 4> 4- X I + (T CS 4> z s 4* Z X 4- Z X 4* Z 4* Z 1 4* . < Ui 4> UJ cr Ui 4* UJ X UJ 4- G X G + G X + G X fi 1 4* 0. ca 4> ^ Ui C3 + -i UJ a 4- -i G a 4- G 3 X 4- G 3 X G 1 + Ui -1 Z 4- fi H Z + fi K z 4- fi H Z 4- G O G > G Q G X 1 K IT ^ 3 4> Z H 3 4> z K 3 + z H 3 4* X G a 4> X G a G 1 •-4 2 3 < 2 3 < z 3 < Z X Q Z X Q Z « 1 Q < U. Q a CL fi a X fi a X fi G fi 3 fi G fi 3 Z 1 U1 Ui s: Ui e UJ X G X G X Z G X Z « 1 K q: K o t- Z H Q H z H O H z H O H f“ 4“ X 1 u < Ui (T u X Ui a CJ X UJ X fi X G X fi X G X fi X G X 1 Ui cn tr Ui Ui cn X UJ UJ a X G G G X G 3 GO G 3 G Q ^ 1 43 K -J Ui H K Ui K H UJ K H G H O X 4- G X CM 1 Ui -i •> Ui H •• Ui 1- G K .

.

G G ..X G G • • X O 1 Q 1-4 cn Q < m fi < a fi < G fi O G fi O G CM 1 u. ir ac XXX X X X X X X fi X fi X fi 1 (T O O (T Q fi X G fi X a fi X O G X o G 1 Q U (T c fi X a fi X Q fi X o fi X a: Q fi X Z

C Ui ir H Q tr Ui X H fi X UJ X H fi X G X H fi X G X O X G X o < 1 c H Ui Z Ui c H- Ui Z Ui X K Ui Z Ui X G Z G X H G fix 4* G fi X i fi Ui u. Ui U Ui Cj UJ ^ UJ fi Ui ^ UJ fi UJ G G fi 4- G G fi K G O 1 G

Ui < IT M UJ < X Ui < X G < X G < Z G G < Z G G 1 H

O. J- tc < X H X < X H X < X H X < X 4- G « X 4- G M X 1 fi X < 3 U. . ?< < 3 X X < 3 X X < 3 X X < X < . X < X < X t G

Ui o u n UJ fi u cn UJ fi fi G fi fi G G fi X X 4} G fi X X I K

IT X X X 3 3 H 1 G ^ n < « ^ o < in ^ Ift < G ^ G < •4} tf) fi X 43 fi fi X G 1 fi + CM ru (D LL CM CM O X + CM CM G X CM ru G X + CM CM fi <4 CM c^a fi G 1 O CM O cn 4- o CM o cn O CM O G + O CM O G 4* O CM ^ G 4- O CM ^ G K 1 G

+* O Q + ^ O fi + O fi 4- ^ O fi 4* O fi 4- O fi 1 X 4* 4- + 4* + O -4 O i G

+ 4- 4* 4- 4- • • .. O 4- • • • • O 1 X X + 4* 4* + 4- 1 X 4* .. 4- + 4- . * 4* .. .. f 1 G

+ ^ K tr + ^ X X 4> X X + «t X X 4» •f 1 4* CM < < 4* CM < < 4- CM < < + CM < < 4- CM XX 4> CM X X 1 X 4* O U. Ul CC 4> O X X X + O XXX 4- O X X X 4- O fi fi ^ O fi fi I G +• CM cn O < 4» CM cn C3 < 4> cj cn fi < 4* CM G fi < + CM G O X 4> CM G O X CM 1 4» fi Q O U. 4* fi fi fi X + fi fi fi X 4* fi fi fi X + fi fi O fi 4> fi fi O fi O t X 4« CD 4* m 4* G 4- G 4* G 4- G CJ 1 G 4- CM Q <f CM fi 4» ^4 CM fi 4- CM fi 4- CM fi 4 CM fi fi t a

+ 4- 4- + 4- 4- 1 z 4* + +• 4- 4* 4* 4- + 4- + 4 4- 4 1 3 4* 4* + 4- 4 1 z
Program D2011

O

n

hiK

0^<

i—cn

(Si Q»O

n

c*i

-I<

CTj -S

t-i

liJ o

lii

fJ3 G

-Jo

raQ

UJE

(T

Q

U.q:

LU

a.

o

Q

Q

n

a

Uj

I 3

<

(jcn c

r»i -I - CJ ' UJ 2

0 UJcnc

1 -j

1 o <

03

3jf «u C

1 O

2

UJ >

CJ E

<

cs

UJ

f l»4

CJz

Ui

•ic -F* E

<

a

X2

* >ma z o < o t; a X

< UJ Q U. X X

o . o Ll C5 tK 3 * 1- a cn

rj < cr o> cn E •u z X w

}^B> 2 cn UJ UJ z

CJ u. aC E 1— -i ft c r —

1

hi E 0- Ul cn CJ cn X r~; X

u. < a UJ 2 a

u. o: 2 cn ^*5 Z O 5 CJ X

c. UJ o o G ac UJ •»

-?* <

c m a » O cn T 3t f” X C

QC cn Z O H* UJ Ui UJ a. cn L E CJ

cn 0. UJ UJ Cj < E E E S X < 2

E •» cn E UJ UJ < < < ft o H* Z

UJ —

>

* UJ H* < E E C 2 2 Z < cn X E

« E Ul E o Z < < <.> * cn «> z <

< z « E < z •w Z Z d UJ UJ UJ cn * z rj cn a: 1 a

Z UJ 0. s < Z G O « UJ h= H* h“ X i“ 2

X z Z . UJ UJ cn >-» fiii* -J a E cn G i“ o

2. !f r“ q: ui K H cn C5 K K a CJ * H* z h" Q X a

1— & UJ w z »-« h“ < 3 3 3 Ui ft h* a H* f** a a X

H- X. 2 •u i“ cn C oc CJ G -J J u CJ CJ e ft a H- Z E a X

cn < lu C. & ix K a: d 3 G Lu CL U iL ft < Lu o 5^* X cn 03

*» 0» h- us Z 4> ir G CL < u o O U boftd ! t -J ft h= CJ CL z a if cn

'^ X

cn < -J Uj ft 3 CL G .j <nS ft cn < X a i: z H*

u. 1 t ft CJ CJ 2 Ll -J -J -J » < LU < < < ft a G X X' '

CT» UJ i—

=

< Ll UJ ft i—

'

1 -J 3 vj cn o CJ o Q Ll ft UJ -J X X X X > H

cn <L3 CJ H- o =» -1 I < < < UJ < < U. z ft CJ >«>• < o ac o X 1 r“ < 2 < ft I u CJ Cj CJ CJ *ai« UJ UJ 2 ft < O 2 < h" H* E X X c

i »— rv* Ll. Z « < < < u_ _J ft c X E a X cn X < r—

E W«i r* U! CJ O cji UJ U ft X cn E a cn CJ CO

ft ft 4e ^
Subroutine DOPKS

t*? ^ in >0 Q O ^

r. N rv ^s N

rj ru Tu Cii Cu Cii Cu c o o o o c o

o<«inNaD 0 CDCC*U'O'OGD-^n^in

5nmLnu'3 inin«'0 '0 'C'0 ^f^Nr^r^

rvr^rvrsr^.r^rvNNr>r^f^r^r^t^f^

ra cu Tsi cj ca ra ra ra cd rj ru ca Cu ra cj cj occoocooccoococo

<

H-0. H

lid o

<

• o

o

c

HC-z;

LU

C- O u.z

O' O Lt o in O ^4 C

G <

G r- Li -J < z Li Ll

-1 G Z 2

L. G 1^.* k 2 < 1-^ ra H- r%^ z .

>-* uj ra X II •—• c 2 w

3 < 1-^ z Z 'M' •7 < G < q: !—

4

•Si c: < GC -i G q: o Li cr C X U. Hi «r' G H“ K 3 2 Lj a LJ 3 2 2 X LU < H4 G z 2 U G 2 «4 < T~ IT < 1 H Z < > 0 < cn 1 0 0 o c z O l: G G G >-• Li > < H* d d A ul H 2 G K 2

11

11 z G Z ra o G

11 II !l “5 , K 3 >-4 i“ r“ V* o '— 'O c: o L: Ll 2. cn

«r 3 Z < tii < (T o Z Li LJ G G z

ra n 0. c -1 D H o Li i> G G < !i i: ^ o c u. z C G k_J G Z Z 2 H

o i-i z z G p-> h” 2 X X X X O 1- -1 «I }. H- K K w s: 2

z Z 3 3 -1 z -1 -J Z Z Z h- < < < i_- < < Li. a < ll < w IL o G G 2 G f— 21 c: CL Ci CJ o <-;• O *—t G G »—

G o G z 2-

cf z ra n

"C '«j 'C > r*^ i> -K

*>• G* O' s.

z

irD

H Q
Program D2041

*

*

*

4i

« s

cn

H :ie Q Q 4c Lli in

»— X

«

« E * < Q 4c U. A U. « o s 4c cn ra in 4i « E 4e o %

4c a 4c u us 4c cn cn o 4c CJ o Q fj 4c <

o 4c H" u CJ 4e cn O S

>

u

X

<

E

4c

4c

4c X

<

E

sa P“ z o 4c E O E

u. Ui Q 4c Ui o X

o < E 4c K E (Ji < tr E 4c Z E l-< cn Ui 4c z u. :£. z h* 4c Q X t-M 0. Ui cn 4e E O E « Q Ui 4c E li. Q cn z H 4c U E ZJ Ui •» 4c < —

cs O X 4e H H“ E o »-« z «> % H Ui 4c cn E X CiS % ui in *. X 4c E < a cn X X UJ < 4c C5 H Z H* < X o z 4c < cn E X

o z < 4c « cn z <

z z d Ui 4c z ra cn 1 E

3 o Ui H 4c in ^ Ui h* H o . Ui Ui to M 4c X E X cn 3 H o in H* j- X cn d E 4c HZ HOE E

z •-» < 3 4c H E H E E E E cn CE E U -i CJ 4c E ^ H Z X O H E H

O 3 3 Ui o in 4c < EQ fiui 3cnxcn

0. < (J u o o 4c h* U E Z E II cn 3 E Q 4c cn < EE n Z H C Ll> ^ -J J < •-< EE 3 H E CJ ' -J

'W'

“jl J In (j a 4c UiH_IEm«E>i“ ^ < < Ui < •-« u. z 4c u ^ < H< u O E E E

•< u u u cn u o Ui 4c < CJCi<HHX:iEa u. -J z 4c E E Z E E cn E H < H

(J in Ui 4c ^ EHCnXECnoE

# *

* « * *

« *
Program D201 1 &

Program D2041

Error Report File Q a Ui

Ui IT cr

tr Ui LU

Ui > Q . > 2 J 3

-J UI Q 2

Ui Q Ui

fi Q a cr cr Ui Ui H Ui o + (T K + tr o + > 4- IT ++ Ui Q + UJ 2 + 4- cr > 2 + > + 4- UJ + + + Ui + 1 1 1 + J tr + -1 >-» + o a + o 1 1 1 tii + Ui a + Ui + 2 1 i 1 + Q Q + Q I + H IT t 1 1 + cn i + cn > + CD O Ui CD O I 1 1 + tr H- > + cr 1- + cr 2 > + + cr 2 o 1 1 1 o o O O H + Q « 4- 4* Q »-» Ui Q 1 i 1 + tr z X + + tr 2 X + + IT IT ^ + + cr a ^ Ui 1 t 1 + a: K + + cr o + + IT UJ Ui + 4* oc 2 1 1 1 + Ui Ui Q + + Ui Ui + + Ui »-« Q + 4» Ui UJ < cr 1 i 1 N« *-• + fM Ui U. O U. Q 1 1 1 Q X »-• 3 + Q X *-» X o + a X « K + Q X < u. 1 1 1 LU J- CD O + Ul K CO O + Ui H K O O + Ui H- 3 CD IT I i 1 H *-* 2 0 + K ^ z ^ + H •-•2 2 + •^0 3: UJ 1 1 1 O 3 2 tr + O 3 z cr Ui + O 3 UJ + (J 3 2 O Q IL 1 i 1 Ui cr Ui Ui o Ui tr Ui o + UJ Q UJ + UJ < Ui 1 ^ 1 1 W Ui K o o +- K H Ui K O O + H H 3 + H H -J LU CD 1 1 1 LU CS K H O O + UI C K H O O + Ui X -i + Ui cr ' TD Q ^ i i 1 Q < H < o o + Q < H < O O + O < :T < Q < CD a -1 o 1 1 o K < CL O . + H < CL o O + H O > + H :r -i O CM—

IT CD CL O X CD 0. + IT CD + IT CD Q i i 1 O Q . + Q 0*^0 O 0. Q O >• 1 * , (T 2 H Ui O + a: 2 H Ui cr X H Ui + oc 2 H- cr a 2 1 1 1 tr < -1 H + a: < -1 K + cr < J 1- cr < Z Ui 2 < 1 Q 1 1 Ui IT 3 O + Ui cr 3 O Ui tr 3 X • • + UJ tr LU H Ui s 1 UJ I 1 o < Ui ..a + O < Ui .. o + O < Ui .. Q + o cr u. o o 1 H 1 I Q U. 0. Q Ui Q U. (L Q Ui + a IL OL O Ui + o cr < tr Q 1 O 1 1 . cr Ui X Ui e + cr LU X Ui q: + cr Ui X Ui cr 4* cr 3 UJ cr I Ui 1 1 ^4 0. Q Ui H Ui + a CL Q Ui H Ui + 0. Q Ui H Ui 4» CL O CD 2 (L 1 H 1 t a > + o > + O 3 + 3C Ui i UJ 1 i Ui o o ni Ui >-« o o Ui + O CM O Ui + O CM 0- K < Q 1 1 3 + n m t> CL -1 + * Ifi Ift C^ JL J + in n o CL J 4* « in o o CD CO 1 1 1 UJ n o X Ui M + n o X Ui CD ^ o X UJ + 4- CD O Q 2C Ui 1 CD i 1 ^ Ui o + + ^ Q + + ^ ^ Ui Q 4* 4* CM OH I cr 1 1 + + + + 4- 1 O 1 I H + + + + 4- • • • • i cr t I CD + + + + + + i IT i 1 Ui

•f + + + + o + 4- 3C 1 Ui 1 1 H + ^ CD + CD + •f ^ CD ^ + + 3 1 I 1 ^ 2C < ^ :r < + ^ s: 4> •4 ^ CJ 1 U. 1 1 a + O 0. OL + + O (L 0. + O 0. 0. 4* 4* Q ^ ^ ^ ^ i a 1 1 UJ + ru Q o + rj Q o CM Q C9 4- 4- ru o ^ ^ 1 1 1 H + Q Q U + Q Q O + + Q Q O 4- 4- Q o o o o t tr 1 1 cr + + + + 4- 4- CM CM CM i Ui 1 i o + CM + + ^ CM + + CM 4- 4- O Q Q I a i 1 CL + + + + + 4- -4 i 2 1 1 0. + + + + 4- 4- 4* 4 1 3 1 1 3 + + + + + 1 Z 1 1 CD
Program D2021

(

1

I

4t *

**

«

**

4i* n

«

41« G

*

*

UiK

‘

cr 0 4i <

«

41 CO 0 • * <

4c a: 3 • 4c 3 > u.

4c u < Ql

4c < Z >i>4 4c Q

4c Z A

4c Q a

4c

4c 3 cn < 4c tr z 3

a: H 4c Q UJ 4c 3 cn 4c Q z 4c a. > 2: 4c 1 4c H

< < 4c Q 4c z cr 4c 4c 3 w 0 ni Ui 4c 0. 0 0 3 > 4c Q cr CM < H 4c 0

On h“ Q X 4c »-4 - 3 ^ U 3

' 4c aC UJ Z 0 u 4c 3

H u. < A < 0 4c z

s - ll. IT u. 4c 3 Z G lU 3 a Q. Ui 0 0 D 3 Z 3 Ui y

0 C in c3 Q < ^ I K

1< ' y

* Q IT n *-< 0 Z cn Z CM H 3

iz ^ ^ J 0. z z z A

4c < ' . cn < 0 0 *>« a C*3 U UJ CM Z «« ill A 4c m Ui u « 1 « ^

r 0 w B z 4c a Ui z 0 (T K Ui H

|:^<CM Z4 < Z<^ 4c z < z 0 Z < Z 3 3 3 |3ZQZ >-•, -Z UiO. 4c a < Z 3 H 3 < 0. + Q- ^

1 'O IZ 4i z z . -i 3 cn QL Z O Q d

1 >^j-* Daxi HIT 4c < K Q » a ^ O 3 <

*«OLUHHOr:i H H 4c UJ cn Ui os a CM ^ 3 ^ 0. j <iz^^crHi“^Qj'^Q 4c z H cn 0 > CO 0 -J z C u. f o:<cozc3aicnK<uja. 0 4c 0 « H 0 0 0 < 3 K y n c Q lUZ'-i«D_^Q.HU z 4c •-* OS 3 Q. n o: CD * 3 < a •qsh jQcni :ca3<«j ui 4c H 3 0. Q H BOO os 0 0. rc Q ^ UCJ <0.,_aCH QS-I 4c < U u 0 < 0 y 3 « -j \0< *-• WKKCnuiH<U.tll 4c cn 0. U H » < CO < \fi j 3 a: < u. ^ ce<H>jHa.cn^cj^ui-«u 4c « -1 ^ -I Q < Z -j Ui -i z 3 y 4c j -i U -i 3 u. 1

1

Z

iz X < z < c h Q. K cr u- z cr 4c < < < < 3 3 O 3 Q H H» Ui a < u. •-•UQ>-^O30ZCnK»^ LUH 4c M CJ U CJ Z z u z M 0. y *-<

' H 0

112?* * * * 4t * * 4c z 1 4c 1 * * * 4c H 1 4c c c c c a u u u u CJ c c c c U CJ y
Program D2024 r

O 4^ < V. o

X <

u. Z A u. o Q »-4 CM < « \ -j • fa <

UL. N. >-4 -1 O A > -J a < o z a

o -1 < HH CJ z 1 o UL J Q ' « < u. > • ^ -1 fa Z

, o ll >>» t»4 o 1-4 1 < X o

ca z « Z « o J >-* X

< • Q o a z

0. O o 4

u. c 1 Z > a

< c ni z

X in o

. z < -] < fa Q

C3 * o -J a 0.

• 0. •-* u. 03 z z X

:C H o . o « Z >

IT < « ir -< « o z

• ru f- H fa H H Q < 4

CM V 03 Z « V, H- < z > Q « O UJ < H UJ z fU u. « 0. . 03 • U. Z X V. 1-4 X

IT ^ uu a + e Ui > H a Z

n

m

UJH X

O X to UJ K

UJ QL

a X

HiH

C9

03 <

Ui UJ ^ IT H cr m £T

o O^ 3u.

X

£

^ H-l + X

X Q 03 ^

z

a

I-<

K

Z

UJ

03Ui

O

<

u.

'O ^

fa X . < X Q C3 q: fj X I < < a ca QL CM < 1 X ^ < < G Q 1-^ tr fa X <

O UJ ^ z K Z X O UJ o z u. z < Ui O »1 Ui Q Z 0. CJ Z < 0. O UJ Z -I Q - Z h4 H < Q . Z H4 u. cr -1 X H Q 4 Z 44 a. Ui ^ Q o

* z ^ z ^ Z Ui - z z ^ z 4 Ui Q z z 1 z ^ z cr 4 z Z CJ UJ « 1-4 - -I • r?7 [ tl 1-4 , H4 * Z UJ Q CJ X M 4 »1 4 V. ^ 4 UJ n z

Z K z H ^ H < Z K Z H < H cr z z > z 44 Q H Z K > < H IT Z Z 4 ^ H- DL a. z 0. < H 0. CL Z 0. Ui < >1 2 ^ + CJ H 0. 0. Z Z 0. X < K 1- K Z 03 2f Z »-* a: ^ Z cn z a: 11 5^ H Z Z U CO a: z a: >« H G Z G QL Z 0. « c: 3 Ui 2 X 3 ^ . IZ 2 UJ 2 X 3 h- • ir ca «j Z X ts 3 UJ 3 a X 3 ^ 4 : af Ui :r

•4 H4 UJ >4 ^ w ^ N4 «<• UJ 44 < < X Q 4 X X 1 44 UJ 44 < ^ O 44 H 3 Ui 3 ^ U- 2 Z UL ^ U- 2 Z JL 44 O % ^ H Q 4 LL 3 Z CJ w Ll W 3 ^

cr K e IT q: H tr cr R Z CJ o cr H c cr H -1 X UJ X J X 1- H -J < UJ < -i < H H O n X X II II 44 Ui _J < Ui < -I < H H —

J

cr UJ IT D < h* O < f— Ui X < u. ca u. < u. Ui X U »-4 , Q 1- H a Ui < 0. ca CL < 0- Ui X < CJ ca CJ a. X 03 cn X 03 03 CL X 03 03 X 03 03 0. o 4 O CJ Z Z IL < 2 X X 03 03 X 03 G IL X G G

U O Q Z Q c a U O Q Z Q a a CJ < II o o —

X Ui X H4 n 1 z C3 Q Z Q O Q CJ O c Z Q

Ui Ui UJ 1-^ Ui • « 1- O 1 O 03 OQ-lKiiUi 44 Ui UJ 44 J J J ^ . J J ^ -1 . ^ UJ Z fU u. CJ J CJ Z O 2 H- ^ J J . -I r -i

-I X _1 X -i X J ^ -J X «I X J X J in J z X o 1 Ui Ui U Q Z X -1 X J X «i -0 -1 X -1 X

< UJ < Ui < UJ < < UJ < Ui < UJ < < -• a o Q o a Ui < UJ < LU < < Ui < LU <

CJ O U Q o c o CL u a CJ o CJ a CJ a. CJ u. u Q CJ ca U Q U o CJ 0. CJ O CJ Q CJ Z Z z o z z z Q UJ z Z z c z Z «-4 »-4 H4 H4 H4 J- Q 44 44 44 1-

* * * « * * * « * * * * * *

- * * * « « 4c * * * * * * * * * * 4c 4t * * * o o * * * u u U c c c CJ CJ CJ W O

^ CM O CJ u CJ _ CJ u

tn

in

rij

r

\

c
I

Subroutine DOPWK

O

o ^ ^

o o o o

in <s O o ^4 CM < 4

“ N 03 (^ o CM CO 4

- in m 0^ o CO 4

“ m 03 CD CM CO m -0 N o CM in >0

CM CM CM CM CM CM ca CM CO n n n CO CO CO n <3

" •M" in yo m m in in in -Q <1 'O >0 CM CM CM CM CM CM CM CM CM CM CM CM CM ca CM CM CM CM CM CM ca CM ca CM ca CM CM CM CM CM CJ CM CM CM CM CM CM CM

CO CO CO CO CO n n n CO CO n CO CO n CO CO n CO n CO CO CO CO CO CO CO n n CO CO n CO CO n CO CO CO n

o O O o O o o o O o o o o o o o o o o O o O o O o o o o O o o o o o o O o o

I

n

<

UJ

a:<

u

(E

CM

(S

a

I

CJUi

C53

C3Hi

cs

o

0. ziB4

CEZ:

h-QX

QJ

lii e

5

o

UJO UJ( . c:

CE Q * LU

03

ra

CMca

. \n O CM

H. c

-IQ

Hi Hi D D

Z Z

HZ

a o

H

QZ

H"Z ^

^ cn CM c

o c

i> -I

H. O <

(J

Hitr<

a

<

Hi

(E

<

HiCE

O 1^ o «

{E

IE

IS

I>l>

O'- Q

<

£

z

o

* o

o <

X -! Q Ll

Hi »*-» O *

« U

D Hi

<S E

Hi <

E Q

o a: 6

o

CJ

HiE

<

a

aC£

n

E

CME

HiE

<

HiE

CD

K=<! £

E

CM Hi i> CO

n

s

CME

<

HIE

<

HIE

gX

u

HiO

o O 0^ < O E O 0^ >—

1

G E 0

^ o

0" O O Ch in E H* S ch ^ m O o b* E «>4 0^ E

< (> ca E o E 0* CM < 0

^ O E E

u E < o O Q II _ II « E C C Q II U ©

o H E O El o Z Q H < E G •—4 o Z G —* E Q K E •-4 o ^ k ^ Hi E a H H4 © H* © -- O

CM < CO cn i-< 03 . i-* •> < CM < «t E E I-* < CM < in o

o in «! in c5 C5 O C «i4 * E Q in E in C5 < G « E O in E in 4^ o CM E CM • < o 1-4 o E <5 CM E CM - E A Q *—

o E o CM E CM - ^ fi •»< E O )—

(

CM . Q <-• Q ^ >-6 E E O Q 4>4 1-4 « •. E < < E E E ^ ® ^i4 * ® < E E > 1-4 >-4 * « E E Q *-« E c S E z Q ^ E E Q E E Z O E E Q

z z *- « E o >- > * O •* Z Z »-• E © > © ^4) ««4 Z Z

< a: o »-* CM E h“ E o o e < ^ < 2^ CM i-« CO K E © O < «i4 < ag H Z . Z 3 E . E 2 < 3 E . »- Z .23 < . E « 3 E % K 2 Z 3

* H • ^ S h- z « E E o E •> H * i-« E H Z « )-< E © E H * M4 E < E * w Q E . ^ E ^ E , —4 Q E E 5P< Q . CM U Z • O Q V • ^ n B 2 in rv O S O H-» 01 »-4 O CM O E d »-4 »< E »-« d d G

E < H O < "SS. E E < t> E < H < X E < 0

^ E < H E

a

a H

o a

z

«i ^ -I < Lk <

E -I l> Hi H. {> CJ Q

t-4 Q

HE ^

Hi H U Q

X

E

U

-I ^ -i E Q H < H <

I

E tj M o U

+

>-« © © Q C

• + © -» © «^ © M y •-4 y

•t n in ^ 0 G

CM CM ca CM CM »4 l> 0

^ O (3

«. ^ o O

l> 0

^ o O

l> 0- 0* 0^ 0* (h 0*

^ Hi Hi

IL D D Q Z Z

« >-< h“ H* Z Z ECO N4 Q Q

o -<

rj CM

0^ o

. ^ a

o

O (> E Z (^

. l> -I

. c I £>< H E E K

a u Q

z «

. -I ^ «i E <

»-« U

E Q

EE

C U

Q Z

K . -J

-I E <

« (J

-JE

Q

X >

E C

U CJ

o

i>

E

<

O

n

o

o

-J<

(J
Subroutine DSCR

tn N CE

CD 00 CE 00 00 00 ^ ^

o o o

o-^cN^*43NOOfyn^m>ONa3Cijnf^o^o*-* t>ooi>i>«>«>ooooooc>-^'^^'>-»rarij

OOQD0COQOQOQO^>(^•O'^D*C^I^•OC^‘OC^•l>C^*

oooooooooooooooooooo

o

CJ(T

6

u

azcr

CJaz

LI

2^< az z u

(D

a

^ UJz

+ <

0.

::^ 1-

cnz

o

o

0^o

0^o

f-c

Cd

II ^

-i

<

Lio:

*

azLi : HUJ u

o <

ui az H <

Z X I-I <

o

I— H

Q. II Q.

h* H

07 I- cn

QII 3ZK aC H- cn *- Q. w cn

a: ^- l- I- Q- cn 03 z

O

<

IK

I-0.z

o Ui <

< A

IK IL. K

H- »K w

Q. < Z -- Q K

Ui ^ CJ K

^ K tr OL

« 3 z — < K o Ch Ui ^ cr C3 u i> < K CJ az 0^ % K Q. tr o Q H Z (T Ui N >-

0. Ui o CJ a o <

z . CJ q: 1- K O t-4 Li C3 q: • < 0- t-

- CJ H- o L O 0- K : az K UJ o z

CJ - CJ m 03 (T O Ui

>K o q: rj C5 A u i- ,

Ui

o

<

azH

- a

c az:

3 U

H-i ncn

1-^ K «3* ^

q: qz h~ H

a a

3. 0.

-j -1

-1 _i

< <

CJ CJ

, ni

CJ

a:3

az O CJ

It 03 e o

<

L. J Q <

»-» o

. CJ LU IK Z . < Oi

z

• aC3

H

3

OLU

o

UIe

<

u.

O 0. < aO -I K

L 07 QK a:

^ c . II 2 t- o u c

^ Q ^ U-

*-< CJ

ra 07 IK 0- ^ z

az

I- « Q

CL K

O. -i-J }-

< 07 CJ z

i H

0.

20

07

cr3

f- Q

UJ Z

IT LI

0^O

O*

O'

«>

03

0^ 0^ O !>

!> O

t> O
1

D2024 :

1024

EXPECTEC

FILL

AREA

REP.

BUNDLE

NQT

DELIVERED 2

DSFAR :

1223

DATA

ERROR :

SET

FILL

AREA

REPRESENTATION

GQFAR :

0081

CURRENT

OKS

ERROR

NUMBER

iDSFAR

DSFAR

FAILED

+-+---+++••'1-

2.

ERROR

DETECTED

4+-f-+++-#-++++4'+

Program D2024

Error Report File Q Q G G a a O S Z

LU lU LU G G S s S > 3

U4 z lU z lU z i=« kX > c > o > c G Z G Z >-< G o G H -i H Q Q »-«

LUI < lU <

i—

UJ < K Q H- Q o h“ }“' < h» Z z Z O h- O H

h=

U + H“ LU 4 LU 4 z Z 4 z z a cn + Q cn 4 * O G 4 G 4 G z LU + Z LU 4 z G 4 z G 4 Z G s + S 4 S 4 o G 4 C G ! 0. 4“ , 0. 4 0. 4 »-« S 4 Z 1 a. lU 4 CL lU 4 0. hi 4 K> G 4 Z 1 tu IZ + LU s 4 UI s 4 < G 4 < G i s + S 4 s 4 S 4 K Z 1 z a: 4 z tXL 4 z s 4 z 4 Z 1 Ui S LU 4 LU s LU 4 LU S G 4 G s 4 G Z Q 1 LU C3 4 LU Q 4 G Q 4 G 3 S 4 G 3 Z G 1 a K Z 4 Q H z 4 Q h» Z 4 G G G 4 GOG I 1 z K 3 4 Z H 3 4 Z 1- 3 4 S G a 4 Z G C3 G ! 3 < Z 3 < Z 3 < Z G G Z Z O z 1»4 ( a a. Q a 0. Q Q CL O G a 3 Q G CJ 3 z 1 a: hi S LU e G S z G z z i z 1- a H z H G K Z H O H K H G 1 IT LU cs U s LU S CJ s G S U tr G S U ZG Z 1 UJ cn cs lU LU cn s Ui LU G IS G 3 G G G 3 G G 1 <i 1- Ui H K LU H 1- G H G S H Q Z CM I H LU , • Ui H , . G G • • z G G •• Z O 1 < cn a < cn Q < G Q G G Q G G rd i CL <r 0. a. CL s si: U Z U Z Q 1 G o c c o S G C5 S G G Z O G 1 a IS a c s C a s G lU Z O U Z Z

LU e J- Q K lU s H Q IS LU S H Q S G Z O z G z cd < 1 H lU Z LU IS h* LU Z LU S h" G Z G S K G a z K> G a z 1 Q U uu ^ lU u Ui ^ UJ CJ G G G U G G CJ 1- G o 1 G

lU < IS »-4 LU < tr « LU < e >iM G < Z G G < Z G a I K

0. H < a. H s < IL H is < G H G Z H G M z i O X < 3 lU pi X < 3 U. X < 3 G X < Z < X < z < Z i G

hi Q U lu Q cu LU Q cj

m G C2 Z G <0 G Q Z G 1 h- IS q: S 3 3 H” I G

tfi ^ O < n jft < m < U3 G U z <1 in cj z G 1 Q

fU ru i> 0. 4 ru CM G a. 4 CM Cd G (L 4 CM CM CJ 4 CM CM u G 1 o CM o cn 4 o rd O G 4 o Cd O G 4 O CM ^ G 4 O CM ^ G 1 G O Q 4 O Q 4 o o 4 ^ O Q 4 ^ ^ ^ Q 1 Z 4 4 4 O 4 o 1 G 4 .. o 4> .. .. o 1 QJ 4 4 4 4 i Z . . • • 4 4 . • * • 4 1 G Z Z 4 z Z 4 Z z 4 4

CM < < 4 CM < < 4 CM < < 4 rd z z 4 CM Z z O z z z 4 O z z z 4 O z z Z 4 o u 4 O u u <r rd G a < 4 Cd G o < 4 CM G G < 4 CM G G z 4 ra G o z CM Q Q o z 4 a Q o z 4 C Q O z 4 c c O u 4 z Q C5 o O G 4 G 4 G 4 G 4 G ra

CM Q 4 CM Q 4 rd Q 4 ra Q 4 ^4 ra Q C3 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4

Li. Q

trU

csnDZ

APPENDIX E

LISTINGS FROM ERROR TESTS
ii
INITIALISE

INVALID

WORKSTATION

CATEGORIES

WOUT==“l WIN=*“l WOI=-I

WISS=~1

Subroutine ESTART

O

>

e

Q

«•«< ^ ^ ^

3 ^ ^ 3 ^

U 3 3 II 3 3 H II it Cn I! It 3 Z •-< 03 O »-« 2

zQ

1“<

M

1

1

1

1

1

1

1 o a o *-» r s c 1 UJ 333333 i-4 < 1 H

< ^ <

1

1 u o ^ ni n ^ m Ni 1 z CJ o o o o o

•-» z I

1 Q Ul Ui Ui LU LU LU < 1 Hi

•-< H= 1 CD w ^ K X 1 < H H H> h“ H K >“« LU I < H <<<<<< Z o o o 1- 1 u.

(0 U U U CJ u u >-• a It u 1 . C3 a sc sc 2e: 3^ -1 03 Q I ft H > X. 333333 Ckt < CD « 1 > z O cr i K < < _I 1 o z *-< 3 U.M

Li. t-« LlMU.MU.MU. q: i Q 0. a. < \ ^ I

ULi 1 H z z 1 lu u h»U

U3

CJ

c.} z 1

1

WHITECVDUO,

'</A»'»

'

'

HRITECVDUQ,

M/A)

'TEST

IB

RUNNING

.
INTEGER

I.J.

NP,NF

LOGICAL

PASS,

FAIL

DATA

PASSi

FAIL/.

TRUE.

i

.

FALSE.

Subroutine ECHEKR

Q

UJH

U

UJ

0.X

UJz

<

XH

s

UJH

<

UJ

tro

a

UJH

O

UJ

0.X

UJs

Q

(T

q:

UJ

UJ

UI o z

IT t> a

Q < t> o

UJ o Ui >

1- CD h- -1 ir cr o IT Z z

a o K Q Ui Q

0. tr o 0. X

UJ c: o UJ K cn q: Ul cr 1-4 ^ A

Q a 0. UJ z z UJ > z Q tr < Ui H C9 . z Z 0 Ui X ir K UI UJ. X

o H a UJ O c X cn H . UJ 0. cn . UJ c

L h- •-* tr H UJ < cn K Z a

CJ o z tr UJ cn o **>» tr z

UJ Ui tr < Ui z o c <

0. <S X u. CJ 0- CL u : Z X UJ H o z z X X tr < Q

UJ UJ >1^ h- 0. UJ UJ

ir ^ cr tr Oi UJ H ^4 cn Ui q: UJ z a CD 01 tr UJ + . IT + Z ^ Ui ca UJ . L o , H -1 -J O a CD

. + z z + UJ LL UJ 1-^ 1-4 IjJ 0. cn tr Q cn . D -1 -i Q Z a, . z H* ^ ^ UJ <

Q z cn K Z * Q H • cn u. u. tr tr 0. cc < <o < < CD H cr -1 11 Z UJ z

cn (T • 0. . u. u. u. < O cr L , IL H II z cn 1? cn UJ o z cr II z X UJ O -J -J X4 tn < . M Z K U X tr 3 IL cn cn -j 0. o o cn ^ Q -J -1 Ll UJ 01 0. Q cn < tr <

cn II z Ui cn u. UJ 3 z < H tr X UJ UJ u. a 0. u. < < . < « J cn < ^ Ll < 0. Ui J tr z UJ tr z 1-4 0. u. u. tr (L UJ u. u. 0. z X •<— 1-4 03 IT a u. z z 3 Z Z UJ < cr z z ^ CD 0» UI u. < J UJ z X4

II ii cn ^ cn u. a a Ll Ui Ui Q

0. ll UJ U. -1 z Ll s U. UJ z

z z q: u M Ui UJ CJ CJ 4> H* H Ui UJ cn UJ Ui cn <

X UJ X X UJ 1“ u H- CJ CJ r* CD U O (J CJ CJ CJ CJ CJ CJ CJ CJ CJ u CJ CJ CJ tj

CHECK

NP/NF

HAS

BEEN

INCREASED

BY
I

I

\

1

p

1

I

caica)

ir

I

cn

q:o

tr

2:a

LiK

U

a

LiU

Li0.X

UJ

<

a

z

o

til

Subroutine ECHEKR

Li U. 0 Ui

QL 0 q: X K r«i < a

Li cn Li

Ui 0 cn K

Li u H” EZ U

c

h" c

00 c

IZc:

Li

0.X

W lii 0 0 Ui 3 K — 0 Z e 0 0 n a Ui c 0 0 w UJ IZ C 0. a q: 0 H* <

Li iii m a 0. K IZ K z G u H X 0 0 cn

ir Q UJ 0 0. cz 0 z 0 0 . UJ 0

0. Q 0 •*« 0 ac IZ Li e •w UJ S + IZ 4- c: IT A u K . UJ (Si -i J UJ cn

Ui 3 a Z -- z < cn

cn >c . 3 < < 0 Q <

0 C 0) 1“ ui a u. u. 0- UJ 0. Q z Ui 0 ^ Ui il z i> h* z

q: . U> -I K 11 0 Z II z

c: \L c: - 3 (r N>« U ^ 0 cn IZ LL z + tl) -h w < 3 0 0. cn 3 c ^ "5 a u. tn < K Li < K a

:i i! X U. II i: S' U. Li. i: L. Li U. 0 Z CL UJ z

CJ 3 0 “5 —9 cr z 0 Z iZ Ui UJ Ui cn _j z I Ui .J

UJ u C 0

K 0

< 0 0 0 0

-
CHECK

ERROR

GENERATION

FOR

OUTPUT

FUNCTIONS

AUTHOR:

M.

MAGUIRE

APR

02i

S.

T.

YEE

OCT

84

NO:

ER0A02

i

Program ER0A02 I

cn

LU

cnz

Q

K

z

u.

cnz

a

K

3

0.K

DQ

K

CJZ

D

U.

cro

u.

H

D

0.

H*D

Q

O

z

ITa

tJL

q:Q

0.

Ui

q:

o

z

z

D

tr

ITQ

q:

q:UJ

H

(TQ

0.

UJcr

QD

cnUiH

q:o

cr

irUi

ca z Q < fU cn tn cr > Ui o o o o

Ui U. ^ O a: < OJ o ra H zt *-4 UJ c O 1 CM 1 X H D Q —• ir OJ < 1 <

Ui cr Q > % < z Ui 1 o < o

< > . Oi < < n o

z H O H IT z o • • o .

.

Q cn Ui D < M G> ^ < H cu . . H

IT CJ -J Q o z 1 o ' ir ,

,

UI 1 K Ui U. > a: o X q: « 0 H cn < UI cn z U. * Ui o ^ 0. ' Q Ui o cn cn C Ui % a ^ q: A cn h* -J z •0 K -fc Qj a. A cn .

.

K cn u Q H < Ui A tn « m % Ui H cn Ui o Ui O Ll S u . Ui I - K « cn H Ui UJ H

cn <j tr < Ui X K X cn % Ui cn ca CJ u. I w LU H -1 <r z X < >

•V cr cn H IT o (D ^ H 03 OL UJ tr < u. <

z < Z Ui Ui 'i-' K in tfS K ' m UJ Ui X Ui cn UJ UJ Ui cr o >-« o o K UJ < • . < * z X UJ cr ir z K Z Ui -J H Z X X Z X X J < -I K -1 *C -1 <

z »b4 Z K Ui cr ^ X -I'-I Z -1 Q z O Z < J- tr Q \ ^ O N. 's > < >- < H ^ -J <

(J CJ >-• CJ 3 U \ V. Ll V V. -1 CJ -J u X CJ -J CJ -i tr * * * « o o UJ M Ui 3 Q o 0. 0. K IL CJ O o

U O CJ CJ CJ CJ CJ CJ CJ U CJ CJ u U CJ CJ u u O CJ 0 U CJ

<

CJUi

<

CJl
I

Subroutine ECA

1

I

I

I

J

I

I

! » 1

o

I

-J G

Q a O

CJ CJ L ^ «, * o H O H \ -I . G

Cl 3 6 3 O 3

C3 « G . G

1* Lit Ui ^

V ^ e « e

« 0. :sC 0. « 0. Cl Ui ej o Ui s: O G

UJ e CJ « e

E Ui X o Ui G O G

C ^ u X

3- + -j > + -j u > + G

e ^ s -1 e a Z -J G ^ Z G

. H 3 < G H> 3 < e «. K* 3 ^

|c J Z U IS ^ Z U Q X G z a

E 3 II oi Ui o 3 U e G G 3 II K tn z ^ Ui Ui « cn z e G • G Z

> Ui 3 H o - > Ui 3 H G G > G 3 H

OLir z ^ s < u. e z ^ Q ra OL e Z G

- - 3 Ui 07 ^ • 3 G G • 3

1 a: cn K 3 ex e -» G G 3 e X e ^ G

t H Ui Ui w Ui e H Ui e G 0. K G

» Ui J (T z H- X ^ Ui u e H X ^ G G e

C I 3 . < ITS Ui «« Ui < X 3 . •C G G < X 3 . u u cn H* a: G ^ G CJ a G H G G m (> G U LJ G H* I Ui Ui c < .. in Ui u Ui o Ui Ui o 3 .. U3 LU II U G O Ui G Q

0. ru Q II e z z n OH ^ tr z

n Z Z -J -1 -J -i . II Z Z G ru G G G * -L .• CL 3 -i -i -i .. CL 3 G ^ G G G ^

< < u. u. Ui > H Z < Ui < < < Ll u. G > K Z < G G < < < G G

Q M Q. K G H U Ui (J CJ (J i-e M« G H G K O G G U CJ CJ 1 > Ui > G

1

1- H 1-

REPORT

TEST

PASSED/FAILED

T0TAL=T0TAL+6

RESULT=.

TRUE.

CALL

EREP(

RESULT)
Subroutine EQPXA

Z

lUI

HO

Q

U

J

<

>

z

Q

Z

UJz

z

X

z

z

X

zz

o

z>

cnUi

(T0.

HI

tr

UJ

-Ia

u

J

<

z

Q

Z

UJ£

z

X

Z

z

X

o z

z z

o

o

z

UJ£

X

Z

z

X

z

z

Q > > + _i Q > 0. Z 0. CL ^ Z -J Z 0. • • H 3 < M * • X H

O X X ^ Z U a X (3.

Tl* -J UJ ^ 0. o 0. H 3 II UJ 0. 0 U 3

UJ z . z or cn z ^ UJ Z z % cn

* < ^ z UJ 3 H (L < >-4 (-4 Z UJ

IT « Q tr z J a q: Q 3 X ^

H 2 z 3 o ^ 3 H 3 Z 0

QZ c: Q (T ^ cn C3 q: tr >-« < , ; 9 X

UJ o < C3 < UJ Z 2: H UJ •«— UJ 0 < C9 X lU Z X U. X X z -4 Ui -1 cr H X u. X 0. Z UI UJ 0. cn 0. UI X 3 . ra UJ UJ (3. cn a . Ui X

cn H <3 3 o d n u cn H cn 1^ cn H a 3 0 c a 0

UJ Z O O z ^ UJ UI 0 . • CM Ui II UJ Z 0 0 Z UI

Ui ^ ir z 0 It U 1-4 tr J > -J O UJ — «j ^ . z z _i J tr J 3 0 UJ ^ J

-1 (T J Ui J II 0- -J ^ 3 J ir -J UJ < It w Q, I < 3 < (T < (T U. UJ < U. U. H Z < Ui < 3 < QZ u cr u. ui <

u u u (3. u z s u cn

UJ H Ui u L3 O. z IT CJ

K

J

D

cnUJ

cr

0.

UJ

q:UJ + -J z ^

D <

z a

II z ^

D K

Z ^

D ^ cn I- UJ J e

3 . cn H

UJ Q

cr z

u. u.

UJz

z3

irO

UJz

d

z

q:Q

UJ

Ui 7* z hcncn UJ 1 UJ 3 Ui . UJ

• <3 • ^ X ^ UJ X a

a . X X X

03 UJ X Ui 3 i X X X

(73 O

Z

H"

CDUi

. O

UJ (73 Z II H

UICD n UJ z

n ^ ^

Z ^ 3 UJ 3 -J UJ Z < U. HU'-'

O

II ^ U- ^ ^

<

u

Ui UJ

CD UJ J

UJ

Ui

CDUi

-i

-J<

u

Uicn

UJ
J

Program ER0A12

C

I

\

i

<

0

1

<c

1

I

1 1 c

1 1 CM

1 ! G

1 m 1 Z !

1 z OS 1 o <

1 o 1 =! C

1 H 1

1 K> u 1 CJ . « 1 U o 1 z %s H

1 z 1 G u

1 D 1 U» G ra

1 U. 1 o

I Ui 1 > X H- ra

\ > Ui ( e >Q G

1 > 1 ra G 1

( « i G H <

I 1 O o n

1 <5 1 z CD G o

1 Z CD 1 Q ca >k9 Ui Z . . CM

1 k-4 1 D G I G H

\ 1 a < u. X ^ 1 »-=> G 1

! (T 1 > o o Hi« Ui 1 G G <

1 Q .« 1 u. - o X G X 1 Z o

I U. CM 1 »-« D Ui o O ^ 1 G H”

1 03 i H* D Q A z z GL 1 Z G .

.

1 Z 1 X Q > z H»5 »»4

\ j—

)

G K

1 o e 1 < > • ra < X 1 o H G

1 0. 1 H « H4 X X -t Q 1 G

1 H < \ CD Ui D < «<«fc o G Ui U, 1 > >

1 < 1 u -1 a o Q 0. X 1 < < e>« H

1 e 1 •-» > cr O it X Ui M 03 1 s X G

1 Ul < 1 z u. . Ui O X X 0. Z 1 X G

1 z > 1 S Ui Q I < < <> H>

1 Ui 1 «» 'O H X * *=< 1

1 o 1 o H* Ui ^3 G G X ^ K 1 G Q G 1 O

1 CD 1 Ui O Ll X U X n ' U i G < G < G ,

1 or I CD CJ ts < X H X CM * Z i X X X X X X , H

I o CM 1 tj K U. ^ Ui G i 0. 0. 0. G

t IT < «>« I 'V CK CD X » ^ U> i G c 0. a 0. o cri G

1 IT < i < Z U! Ui ^ H» * 1 it ^ 1 Mi G G G

1 Ui .

.

C 1 a o Ui < <« % > 1 Mi G G o

1 cr X. i K Z Ui K Z * * X i X G S G e G G

1 c Ui i Z H -J *-• (T X X X ^ i oJ Ni4 G G G G

1 u I 1 z o z < X G G I G < G < G < G <

1 Ui H* CJ Z U. V. •V 'v fS 1 0 CJ C CJ C CJ O G

\ D Q 1 * * * Z I z z z G

1 u < Z 1 O ^ 1 M H4 G

1 1 o

I 1

1 O <u U CJ U CJ o CJ u CJ CJ C C C C C c c CJ CJ CJ G CJ CJ

CALL

ESUli
Subroutine EQPXA

Z

UJX1- a

u o

1 ui

J z

< . > a

> CJ Z

z 3

-I< X

Q > a

Z > . z

UJ 1 £ Q ui

z z

z >-# , Ui Q K Z

z 3

3 , X cn X

X z Ui o

r z X , z • w

X 0. 1 X z UJ , O Z z tr Ui

z z _ Ui z

>

Q > 0. + -J cn Z 0. z cn

UJ 1-4 « . X H D < Ui

UI S3 X OL -J z CJ 3 UJ

« 0. o - u 3 li o Z . z cr cn z ^ X

< -4 z UJ 3 H O Q w

ts (E 1-4 a 3 —

X z < . X

UI 1- 3 z - o 3 cn -4 Ui X tr •-4 < Q a: A cn 3 1 X

Ui Q < a X Ui z h- UI >-• O UJ

ca LL X 0. z 1-4 UJ X K Ui n cn

UI 0. cn c UJ X 3 Ui Z II Ui

H O D C d il u cn H* cn . a z o Q z UJ UJ o . . UI z

-1 u. UJ « -J X z o II l-M -J < k-* tr ^ > -i O UI z z -J 3 UJ <

O Q X -i Ui < il 0. J 3 -1 UI u

z D < o: cJ (T u. Ui < u. U. 1- z < UUi U U 0. z *-« q: CJ t-4 »-4 cn H CJ 1-4 UJ

o •

• (J

J O

<

> -1 > o

z»-4 -J Q <

Z >

»-4 >

UJ z

z

c

z z

Ui H

z 3

cn X X Ui z z X

z z

z 0.

Ui X X Ui

X o z z X

i- z z z UJ

1-4 « a > > -I- -I A Z 0. 0. ^ Z -J

1 UJ Ui 4 - H 3 <

Ui Ui C3 X X 44 -1 Z CD d 0. o 0. It 3 II UI 6 z - z X cn z

>14 z UJ 3 Ha: X X cr »-• Q X Z ^

X Ui Ui H 3 Z 3 o w 3

0. X X cr —

4 * a X ^ cn »- O Ui UJ a < a < Ui z aC H- UJ 3 cn cn U. X X z 1-4 UJ ^ X

H Ui UJ 0. cn 0. UJ X 3 . U. —*1 H O 3 a d II o cn H

-4 J z o O CD z Ui Ui o

^ -I J u. Ui 1-4 —4 X z

Ui UI < UJ < t-4 X ^ > -I O UJ -J . cn UJ u cn a Q X J Ui II CL -I

-1 J z 3 < c < X u. UJ < u. u. UJ UI Ui o cj (L CJ4 z a CJ H4 1-4

u

UJ

~rG

(SQ

ITaz

Uis

UJUir

<

X.<

Q. CM

H

.. CL UJ >

QL I- >
I <n I

3.O

cn3

H*

UJ

cn

..

m ui a II z r ^ D -I K Z <

cn H o

UJ

UJ

UJ

IZUiX O UJ

ra cn

II UJ ^ -j

Ui <

UJ CJ

-Jau<>>zaz>-• UIrzXrzXrz o > Z 0. Q X Z 0. a Q Z 3 < > s z H »-« a ^ a <

u» X

OL

h“ O z o

UJZ J z ^ D <

(J u O

-ic

-J<>>

UJXszX>

0.X

flL

*. C o«z ^z Qzl-l < a X

0.

cn o 3 O a> -3 o

UI <: H Z CJf z K U D z cn Z UJ ^ z O w . Q Z

UJ Z Z M UJ . UJ X Q II U Z UJ UJ ^ «I ^ Z -J Z Ui < H< CE U ZXzH3O<zu<aa<zz

-jzXzoz

cn< zzzoHOzm QZ Z

h* Q Q « Z H< X H Z Z z z a G zouJ<>zazz Oczr

cn X Z O « z 3 Z X X z Z Q i-e r s '»X' Z 3 Z X z z > -> « z H o g X X z ^ z o z z z z z z z z G Z G « z « G z Q > > z H Z Z z z z ' . z < < z « z z M » , . g K Z H= z z a X X G Z z o z A Z Z cii z * z « H z Z Z 3 < CM M CM z Q G X K 1 z z z •-» Q 3 as 3 K Z z z K 3 Z 3 G 3 Z «3 X X Z Z Q z o m z a z o < a < z K Z 1 G . ^ Cii as OJ G Z X X

*0 z Z II u z II z z G z H a Z Q X — !- O 3 o G .. >0 ui M H in z CM Z z Z C G g 2 G II g 01 z z z Z t-< . z z z Z H 3 Z Z < Z z < z z 3 z 3 Z z z z ^ z z g G z g Q z z Z z Z K Z < G G G u. z z 3 < z < G r- g Z 9^ z z g g z g

CJ o CJ CJ CJ CJ

U CJ <J z a z !-• i-< LU U O O Q

V.

U (J u g u
IF<EIND.

NE.

0)NR»1

REP(l)=EIND

CALL

ECHEKR<

RESULT)

IF

(RESULT)

NUM=NUM+1

I

F(.

NOT.

RESULT)

CALL

EREP(RESULT)

I

I

I

Z

LUZ LU UJ K UJ LU

cii 0.o 1 s q:

cn Ui LU 3 a X X

LU o ^ LU ^ LU

. ^ CD cn 03 cn rv uj e II II UJ U UJ

(n X

.. pv UJ tL ca -I O II K - -J -J z z ^ 3 LU UJ < Ui Ui <

3 -1 w UJ UJ o cn UJ o K Z < u. cn K o NH LU

LUH

o

-JO

(J

J

<

>

>

z:a

Z:

LUz;z

I o - z o

a >

z a. a X

(L Z . <

C «

H 3

(T

a <

Ll X

0. H a

z o

LUe ^

(T ^

3 <

a u

I

I

I

o

i

1

1

1 -J 1 m

c 1 CJ 1 H

1 (J

J 1 a

< I 3 1 3 1 z 1

1

1 O X

a 1 Z X

z 1 >

3 1 HUi cn 1 X H

UJ 1 a . z X 1

1 X X

0. 1 X

1 UJ 1 az a 1 X - 6 UJ LU 1 o n

1 X X

> + «j »-4 1 X

. a. Z -J < 1 X >

H 3 < X 1 <

’ X ^ Z U V, •-* I X z

O 0. D 3 II Q K 1 X

z - X cn z ^ X -J X 1 X

Z UJ 3 K cn 3 X 1 •-* <

a ^ X z -J 03 1^ . cn c 1 X 3

z 3 0^3 < ^ Ui X X 1 X

(-4 ^ . Q X ^ X X X 3 X 1 UJ ^

a < UJ Z :£ H Ui < X X 1 X X

X Z >-• LU J X H H* H X z 1 cn 0. . UJ I 3 . X a -X 1 3 o Q II CJ>CnH X H II X 1— 1 c5 <

o o z ^ UJ Ui o H ll H X Z 3 1 z

M ^ X z X X X o 1 M .

.

3 -J o LU ^ -J . 1- < 3 X 3 X 1 X

UJ -J II X .J X 1— X X 1- a a 1 G

X < X X UJ < X X O O X < X Z 3 1 O X

0. (J z X o X K X O XXX 1 X H

X 1 X 3

I <
1

Program EROBOl r

1 ^

li

I

m

z

Q

M

H

U

z

ZJu.

cnLiu

>

LiQ

H

3

a.z

03Z

o

o

z

3

u.

03

LJU

H4>

LiQ

D

CL

CL

1 Lli 1 . Q UJ

1 03 1 h» O 03

1 ! sr 03 •

j

1 I < 0. ' -1 03 1 o Ti n

i < 1 H c3 Q * < z 1 O o

I >-4 1 03 < O O I I W

i 1 LJ 03 03 « •» ^ i s 1 1

1 »—

»

1 Z 1“ 1 o s C9

\ z 1 a Z U C3 Z LJ I o O

1 »-4 1 D M qT < fV »-« Z 1

.

.

1 ! a o 03 • O D 1 H .. .

.

1 cc 1 > Q 03 3 ' cs u. 4 IL > Li K>

1 Q 1 IL . a LL 3 * o a 1 03 Ui UJ

1 Uo i . D 03 OL ' IT 03 i 03 03

1 m 1 H D Q CL a - Li O o UJ 1

1 Z 1 cr Q > O 03 X Z OQ U I 03 H H

1 Q S3 i < > ^ < 3 z i Ui G G

1 M LI i O o V < H- X > 1 H UJ UJ

i H IL i 03 Li D OL s ^ OS ir UJ 1 h® h“

1 < 1 V ^ C3 Z J Q o o Q V Q 1 cr

1 e 1 -> > u IT O 4 O IL 1 o Ui O

1 LI LJ 1 Z L, •> a: o UJ o ^ cr Li 4 H 1 H LJ z

o 1 z Lt i cr LI UJ o ^ (L flS 3 1 < M

o 1 Li > 1 V. V. J • o «5 CL i CJ o cr o 1 O • 1 a < 03 LJ H UJ Q K S X Z 1 G X H

s I H- 1 Li O iL O cr ^ . 03 a CO M 1 -J LJ u z 03 H

Ui 1 sr 03 (j cr 03 LJ O < »-« X Li cr rv 1

1 LJ m

1 o 03 ^ ! UJ LJ h® U. H OS UJ 1 UJ Z Ui z Li z

s 1 cr O i -1 cr N. r CD cr UJ 03 1 03 03 « U3 «

< 1 cr S 1 < Z UJ Q z Li Ui H 4 »-S 1 •-* Ui Ixi >-< UJ ir 1 Li .. O 1 Q o < o O LI < -^

S •* «J 1 -1 J

i2 1 cr s 1 K Z LJ M z UJ H Z « < 1 < -i < -J < -1 P 1 s: a Li 1 Z K cr z H» J »-< cr X •* X M 1 I-* -i « -J -i F 1 O I 1 z Q Z < Q Z < fl£ O ^ h- 1 1- < H < H <

Iq. 1 UJ H .. 1 LJ »-• > LJ u 3 U. V . V. M I i-i (J M £J LJ

1 13 0 1 4I 4 4 Z 1 Z Z Z

1 L3 < Z 1 o ] M4

I CJUUOCJOUUU (J L? U U O CJ CJ OOOCJU OU 0(j u u

INITIALISE

STROKE

TEST

SET:

OB-104

CALL

EINSK

/S
INQUIRE

DEFAULT

STROKE

DEVICE

DATA

CALL

eODSKIWTI.

SKDNR.

1.

MLDR.

ERR.

MBUF.

NPET.

NTHPET.

EAREA.

BUFLN.

LDR.

Subroutine EINSK

o

o

Ui

q:h

<

Q

cn

q:UiH

UJz

<

(T

<

u

Ui

X

u

ISo

e

-J

cj

Ui

Ui

<

Uics<

Ui

<

UJ

IS<

UJ

UJ

Q.. >

QL

^ 3

CJUJ

ISh-<

a

o:a

^1

z

u.

<

UJ

IS<

Ui

n K

< X

UJ cn mui

<3 q:

H

X

cnUJIS

Q.UJ

q:

Ui + -I r ^

X <

z <J

ti s

X H- Z ^X

0.Q

cvi <

Uis

<

UJ

< a

Ui UJ s s

< H

Ui <

. a

K * Ui S

Q. Q

. -J > * a. z

-» -1

- u. X D

Q. flQ

S

z

o

Ui CD

UJ *

<

Ui

s

<

Ui

H

J3

CD

Ui

s

3 UJ w

K

-J3

cn

UJIS

0.

UJ

IS

UJ + «J Z J

3 <

z u

uz3 H

Z J

3

Q.O

cn

z

UJX

H

1-3

O3

d

Ui

z

3

Q

Z

<

K

3

G3

d

UJ

cii cna

z

<

d

z3

d

Ui

Ui (T ^ . q: G o e IS ^ G 3 Z

lO in Ui H UJ Ui H- Ui 3

UJ X G Ui ^ S ^

1“ X G Ui ^ IS H* o o t- UJ G Z X 3 . ra UJ UJ Z X 3 . cn G .

li It < G rv. G CJ G H G N G CJ G K G H

A o * * II Ui o UJ Ui O • • « Ul It Ui o Ui G G .

.

n G G

It ^4 cn O II —

IS Z o a ^ S Z G II Z

X. II II z Z ^ -I j J — z r j ^ Z Z -I • X > z »- .. 0. 3 -i ^ -j -i L 2 -J .J -J ^ 3

CL a. UJ Ui > H Z < UJ < < < IL u. < < < U. Ll K Z < G

N4 H4 CL G. H- G K u Ui Q (Jl U I-* G K (J UJ CJ (J CJ G K CJ > Ui .

.

UJ . , Ui K K tG

UJ
APPENDIX F

LISTINGS FROM OPERATOR INTERFACE TESTS

Subroutine OBUFLY

r

>

L

z

q: »-» piCJ

o

d

Ui0

z

<

crLJ1

H

O

K

<

<

Q

Ui

<

cn

D«-l»^Z*^ 3 »-«-J»^Z ^ ^ ^ ^ QS ^ ^ ^ ^

1> .3 .-J .Z .3 .-J . .03030<03030 ^ II U U ii U II li 21 It il il

II ^ ^<1

01

o

o

CMOQ

c*d Til CM ra X > -H -P< ^ ^ x>x>cra:x>x>«j 33 -1 -1 ZZ 33 -1 -IZ 3333 << 3333 <

>

Z «- <

II

II >-• Ui3

> Z O

_J i-» o

z H n

< z

o o

U Q

o o

* * X >

> >

a a

a Q

cs a

u a X > uj > > 3

a oz

a Q M u. Q K M

2 Q

O Z

U Ui

U1 3

crH

<

UJ

0.

UJ

cr

> >

-I cr z z

< <

X X ^ -I cr z z ^ "^ < <

CM « • «. w cj O 0^ Z -I ^ H. -I -I

cn cn a. (L. O C9 o O ^ ^ ^ -J ^ ^ ^ J

< < < <

o u u u

>

>

c

a

a

X

>

a

- o

CM ca

»-« CO

cn «

< <

u. u.

CJ<

u.

CM<

CO cn CO u. o o o o

-J -J ^ -J ^ ^ ^ ^

< < < <

CJ u u o

r4 <^

•< o

.2 £ s s

on<7t:^

^ CM n I CDM ifl < IQ U- <»- CD «

Cd ot J

< IQ O u

n

>

33

U O

< '•» u. <

icn u. o o

CM>

3

CMX *>< 3 I « *< O u» w flj <

U. !J» (3 91 -I -I -J

_J J «J < < < IQ {U U U U

I,

o

o— cj

O

CM o

o
Program OPOAO1

cn

4c

:4c 4c >-« Q

4c H K 3

4c < < 2 4c 2 Z < Z z a :4c 4c cr UJ cn Q Q , 4c u a < a: t- •

:4c 4c Q u Ui z Ui O H u 4e 4* cn cn < X »- CD < :4* 4c cn 2 2 K <

01 4c CD < > > Z

LU « 4c cn Z IZ < -i 2 < z

y~ 4c Ui H Q O Z H 2 2 :|c 4c > OL Z z z 1—

Ui :4c 4c H a Hi4 % < >4 QJ 4c h- UJ 2 X « cn e tr 4c Hi< cn < cn X z c CJ cn 4c 2 CD o

cn 4c Ui 4c H < < Ui H < 4c 3 4c ' cr -J H cn u A <

01 01 4c 4c ^ 0. 3 X o 3 < z

iil < 4c 4c < CD 2 cn < Q z

a. Ui 4c 4c Ui h- U. Z 2 z z o 4c 2 4c 2 3 Ui Ui 3 z Q < a a u 4c |M4 4c < 0. o X -i »-4 CJ 01 4« 01 4c 01 K O 2 a z a a 4c OL 4t U. 3 01 01 3 cn H -i in o

lx. h- O 4c

4( i—

4c

4c O UJ Ui Q K 2

UJ H D N z

f- 2 4c 3 4c U. 2 CJ X X

cn

i- c. O 4c 0. 4c ^ o 3 < Ui H UI z 2 )—f

4c i- 4c o (Z 2 H % 2 a r- > 4i 3 4c < UJ UI < Ui 3 z c

a: < K 4c Q 4c o CJ 3 X U < % 1-4 z

a. H* Z 4c 4e CL 2 1-4 CJ cn Z > X in z

cn 3 4c U. 4c O < H Q a: cn a ::i: 4c a 4c Ui 01 ^ 2 < cn Q 2 (Z 2 4c 4c 2 H- 2 < O Ui z < O a Q 4c UJ 4e < cn UJ X cn H Ui X H < * 3 O 4c u 4c cr UJ 0. cr H > X K > 2 X 4c 2 4c u. K 0. CL < Q H A X A z O ^ * 2 3 4c < 4c ' < cr Ui 3 01 Z n Z a >-* O Q Ui * tr 4c cr in ^ % H UJ z cn 2 < o > > K > X 4 « M 0. Q Q Q Q 4c < 4c a 01 in « 3 X cn 3 4 Z K < a Q t-H M l»4 4c Ui 4e u. o O l> CL 1- <-« cn Q < CM o n s <

h* 3 I r;^ X 4c 0. 4c H a Q cn X X > X > H*

cn UI 3 3 3 3 4c QL 4c o d 3 ^ H4 z Q z CM cn 3 o: 01 w 4c < 4c 2 01 o UJ < H

cn Oi C n z a: CC f— 4c 4c X a CD z UJ H* Z 2 X z X K z a cn a 3 3 3 3 4c 1 41 a X 01 X UJ 3 2 cn < % 2 O 3 3 Ui 2 < Q. CJ 4c 4c < (j a X X CJ 1- H Ui z 2 X < < 3

lU 3 K < c u Q < 4c 4c Ui cn a H H- < 3 CJ > z >-• z Z H“ z (J o O Q

UI o o O o 4c 4c X CD o CD CD UI Q > < < o CD O CD CD z Z 1- 4c UJ 4c z cn a: h* < cn -J J -I 4c 2 4c 3 -1 -1 -1 3 Z O z z z 3 z z Z u < a Q -J J -j 4( < 4c < -J -i -1 < K Ui Z cn 3 -J Z z z z z a

0. < < < < 4c 01 4c cr < < < < Z H- X X < < < < < X z 3 u cj CJ CJ CJ u Cj 4c u. 4c o tj CJ CJ CJ Q < H < a Z <J CJ CJ o CJ CJ 3
Program OPOAO1

GKS Error File

Ifi us a a a a a a a a a a a a a

49 49 49 49 49 49 49 49 49 49 49 49 49 a a a a a a a a a a a a a

49 49 49 49 49 49 49 49 49 49 49 49 49 a a a Ifi a US a Ifi a a US 01 US a a a a a a a a a a a a a

.£ 4= 42 £ £ 42 jC £ 42

49 49 49 49 49 49 49 49 49 49 49 49 C c c c £ c c c £ eh> £ £

•rt •t< •r* •*c4 •#« O •p< Q

(.

9!• L t a

0•• a

a a a a a a a a a c a a £

£ 42 JC 42 42 42 £ o jS S

49 •«9 4» 49 49 49 49 49 •49 49 49

••i* •fi4 •*< •r^ •«4 •*<s c •*< £

a a a a a a a a a a a

a a a a a a a a a a a a a

)Q

I 1

CO

O (~ c a Z 3

4» u cn 0. p c < :£ G a »-i C5 C5 G3

ni <1

O .. 3 .. a. .. a. .. 0. .. a. .. a. G a a Q a a a C a a a G

-1 49 a 49 o 49 o 49 cs 49 O 49 O

01 m 49 a G a G a G a G a G

Hi 49 a 49 49 49 49 49 « Ul 49 US a a a a a a a a a

US 49 49 49 49 49 c (. a L a {4 a (. a u a

a a a 49 a 49 a 49 a 49 a 49

S. 42 a !A & US C4 us a. a a, a

s. C 49 o o o o o

o u (. a L a L a L a L> a

Q. C c

O.JZ o.^ a.^ a.^

.. a.

a» O

<4^m a

(. ns a& ta a

(-> 01 Sc £

•• 0. a Q

49 O

cn

49

ifi a

49

ns a 49 & a

o

;» a &4=

0.Q

O

G

a

49 u V a 49

o> a

9

a o.^

a

49

ns 49a

^ 0. a a

a. o

o G

o> u

ns a a a a a a a a Ifi a a a G G G G G G G G G G G G

2: cj 2: 2s: 2: 2: 0 < 0 0 0 0 0 0 0 0 0

.. 0. a C

49 O

ns G

49

til a

ni a -;9 & ui o a

a. ^

ra

.. a. a a

49 O

<a G

49

ut a

4» a 49 a. iA o

(. a & ^

ns

us G

2^

C5a

49

49a

(- O. a G

o G

Ck oo

<

G3

• 3

CL <

_ _. _ ,Q»:i<a.:i<H-:i<lLi<cji<3iaa.2:<i-»:i<33CGG OOGOCdGOOGCSOGOOGOOGOQGOOGGOGGOGOOGOCdGO 333333233332

49 49 49 49 49 49 49 49 0 49 49 C £ £ £ £ £ £ £ £ C £ £

£ E •«4 £ £ ^ £ •^ £ C £ ^ CJ £ £ •*4 ••4 •44 •r* -rH •«4 < -t4 •»4 49 49 49 49 49 49 44 ^ 49 G 49 49 49 0 {4 0 0 0 c. 0 (> 0 £ 0 (. Q (. 0 3 0 Cb 0 (4 Q

£ 0 c 0 £ 0 £ 0 £ 0 £ 0 £ a c 0 £ £ 0 £ 0 £

G W < G cj < G

2C G CJ X G CJ X G CJ -J G cj Z G u X 0 3 G 0. ^ G 0 X G u 3 G

fl

<1 >0 CM Ifi in m CM in n in m « in <1 Ifi m N CM in 4* in G N «

0 «4

i £

\ £

1 E! 1 E

1 £

1 £

i 1 c £

1 £! £

1 £

I £

1 £

0 0 0 0 0 0 0 0 0 0 0 0 0 0

•r* •*4 *4 •»4 m ••4 •*4 •»i4 •f4 "F< u 49 U 49 49 L 49 L 49 u 49 (- 49 U 49 L 49 U 49 49 (. 49 49 0 U 0 u 0 U 0 u 0 U 0 U 0 u 0 u 0 U 0 u 0 U 0 U 0 U 0 u U £ c tm E E £ u £ E c. c L E U E £ £ £ (- £ C

U 9 tm 3 5» 3 (- 3 3 L 3 u 3 t4 3 U 3 L 3 c. 4^ 3 £ 3 f. 3

c
Error

-

3

GKS

not

in

proper

state;

GKS

shall

be

in

the

state

bISAC

Function

3

GCLUK

Error

-

7

GKS

not

in

proper

state;

GKS

shall

be

in

one

of

the

states

WSOP,

WSAC

or

SGOP

Program OPOAO1

GKS Error FHe

C

c
Program OP0A02

i

t

r

* :4b ft ft « ft ft « ft ft * « ft ft

:4b ft ft « ft ft * :4b ft ft * « ft ft

3k :4b ft ft o « ft ft z :4b ft ft z T« ft H* :4b 0 ft ft cs :«E :4b ft ft Ui « % H= ft ft H :4b U ft > ft

:4s G < G z ft -1 ft Ui * 4 Ui 01 > a ft -J ft tr :4B z ' < Hi < •X ft < ft Q •M 3 Ja>» 3 1" ft Z ft LL -1 z J U ft G ft Ui :4b > UJ < < < ft ¥b4 ft a G « £ ft 4“ .ft > :4b 0 < G i1 X ft ft Z 0. 01 z G G ft Q ft Ui 3 4B LL 0 H> Q 4” ft Z ft Ui :^e :4b 3 M < < < ft G ft 01 _TL 4e < itt < • • 01 -J X ft U ft U ' o 01 < Ui U> Ui ft ^aaBP ft 03 Z Q CM H 0. X ft ft a Z :4b 0 G 0 o ft Z ft 01 t-* G 4B Q < s: 0 ft G ft < K H >4 4B Z 0 01 01 01 X ft M ft Ui < H « < 0. G G H G ft ft -1 H- 3 « < « G 3 Ll z X ft < ft cj cn H ke UJ Q ft 4” ft z cn £ H 01 H U 4~ ft G ft O 01 G 4c < G < 0. 0 X ft 2: ft H a u :4b 01 :4b (S Ui Hi £ t £ « ft X ft 3 :4b G 4 u. K -1 G CM 0 G ft G ft Z 3 :4b 3 U 01 z X « ft 3 ft C 01 ^1 * :4b 01 \fi «

'* u On 0 Q Q Q X Q ft ft

»-» < Q Q d o •¥ s Q W tTi « > « M M »-« ft ft H Ui »-4 »-« »—

:4b < « Ll 0 (> 0^ 1 fi 4“ t X ft < ft < -J :4E Ui u »-• 3 < 3 3 ft G ft 1- U 3 3 3 3 4B tB 0 d «e X fU 2l 4” G ft ft cn ' w» w # u z m 3 01 G X ft U ft 2: :4b Q X e • 0- ^ >— 01 3 h“ 4— ft ft 01 .. 3> 3 3 3 1 4b a 01 X Z G G X Z G ft 1 ft Q Z < 0. u 4E < Q U X X 3 UJ G -j >x Ui ft ft 3 C C U G < * ft lU a G }-=* 0. 0 D K 3 u a 4“ ft ra ft o O 0 :4b ft I 0 u 0 0 0 0. 0 0 u X 0 ft ft UJ K * Ui ft 01 ft UJ ft cn cj -J J -1 :4b £ ft 3 -i -J -i j -] u -J ^ < «J u -i ft £ ft o z J J -1 :4b < ft < -j -i G Ui UJ J ft < ft U D < < < < :4b 01 ft 01 < < < < < X < < -J < X < ft X ft U Lu ui ui ui ui u. ft Q u u u u u u U U u u u U ft X ft

(

U CJ o cj(jicjcjy(jcjc?o cj a UUCJ OCJCJ CJCJCJOCJU«J
Program OP0A02

GKS Error File

a:3

Q.

o

o

d) o Oi Ol 01 01 01 •p p p p p p

<n rq <q m 0) tq •p p p p p p

01 III lA UI UI UI

01 01 01 01 01 01 £ p p p p

•p p p p p p

c c c c c

•«4 p p o

L (. u 01 0« 01 01 01 01 c P p a

-p p P p p p -.4 c

01 01 01 01 01 p

01 Ol 01 01 01 01 XI p p * p p p

-i* p p p

p

m iq iq 01 <q >q x: p p p p p

p III UI 10 UI UI cn cn cn G G‘ cn

a: o a: aC a: o < o O O O o

cn o .. 3 0. •• (L .. CL .. a. .

,

Q 01 0* Q 01 G 01 Q Ol Q 01 -1 •p 01 P o -P O p o p o p

tr 01 p iq cn Q cn <q cn 10 cn 01 Ui -p iq P p p p p

o la p m 01 01 tt (0 01 UI 01 UI UI p p p p

c s» u rq X iq (. 01 (. 01 X 0.

•1^ Ol 01 01 P 01 P 01 P 01 P 01 O

a. UI a. 10 P UI CL 01 0.0

u o P o o o o o cn Q (. 01 (.01 (. 01 (. 01 c.

(. & C (X P &P a, p & p p (- (. p p p p o

01 c c c c c c

•*< *0l c c c c p o

p p p p p <

>0 •p p p p p p cn c o c. o (. o (. a c. O (. o 3

c o c O CO c o c a c

HI 3

-P CJ CO 0. _i cn cjxcnoxcnoj cn CJ 3 cn (L j

c < 2C o CL :s: < D a: O 0. C5 o cn o o cnoocoocicno O CD O o cn o 3 3 3 3 3 3

« UI

01 01 Ol 01 01 01 01 p p p p p p p

01 0) 01 (q 01 01 01 p p p p p p- p

UI UI UI UI UI «l UI

01 01 01 01 01 01 01 P p p p p p p

P p p p p p p

c c c c <v c p p a p p% o p

(. (. 01 (. (. 01 (.

Ol 01 c 01 01 c 01 p p o p p o p

p p p p

p p c p p c p

01 01 p 01 31 p 01

01 01 01 01 01 01 01 p p p p P p p

^4 p p p p p p

p p p p p p

Oi 01 iq 01 01 01 01 p p p p p p p

UI UI UI UI UI UI UI G cn G G G G G

a: a: a a CJ a a a

o o o o < o CD o

G

.

.

0. .

.

0. .

.

.

.

3 .

.

0. .

.

.

.

(L

01 o Ol G 01 01 01 G 01 01 G

p o p o p p Ol p CD p p CD

tq cn 01 cn iq <q p • 01 G 01 01 G

p p p p <q p p p

UI 01 UI 01 « UI p UI 01 UI UI 01 p p UI P p

(. 01 (. 01 (- 0. (. (. 01 (L (. 01 01 p Ol p 01 G 01 01 01 p 01 G 01 p

Q. UI a. UI a CJ p p p UI P CD p UI O o o cn o p a o G o

(. 01 X 01 (. X (. 01 (. C. 01 & p & p a (. p c p p p (. p p p a p p o p

c c c c c c c

p c p c P CJ p 01 p c p a p c p p < p p < p

p p P G p p p G p

o X o (- o 3 a o u a (. o 3 o (. c o c o C 3 c o c o c c o

* or G

a

cn CJ X cn u 3 G CL -J G 0. X O 3 G 0. -1 G CJ < h“ 2C < D a G CJ a o h- a < D a o 0. a <

O cn O o cn O O G CD CD G CD CD G O CD G o CD G

3 3 3 3 3 3 3

I

I

i;

I

cvj >0 40- m Cil in ^ in ^ in nj m G N CM in ^ m G fs <0 <0 ^ m 0 N CM «

o p p p

1 1 1 1 1 1 1 1 1 1

1 1 c c

1 c

1 c

1 c1 c

1 C

1 c

1 c

1 c

1 c

1 c

1 c

1 c c

o o o o o o o o o o o o o o o p p p p p p p p p p p p ^ ^ -P U

u o u o u o C ^ C c ^

3 U 3 (. 3 (. li.LUlJ.LU li. UJ

p (. p U p t- p (• p (. p (. P (. p (. P (. p (. p (. p

u O u o u o u o u o u a u 0 u o u o u o u o u c (. c (. C (- c (. C (. C (. C (• C (. C (. c (. C (. c 3 u 3 u 3 (. a (. 3 (. 3 (. 3 3 (. 3 (. 3 (. 3 (. 3

IL hi iL G IL G LL G LL G iL G U. hi LL G G G G G G G G
Program OP0A02

GKS Error FHe

0 0 0 0

o 3) D 01 01 0 0 0 0 0 0 0 0 0

•P 49 44 49 44 49 X X X X X X X

Q rs IQ IQ IQ 0 0 0 0 0 0 0 0 0

•P 44 49 44 49 44 X X X X X X X

0 0 0 0 0 0 0 0 0 0 0 0 0 0

O at 01 01 01 0 0 0 0 0 0 0 0 0

4S X X X X X , X X X

4» •p 44 49 49 49 49 X X X X X X X

c c c <4= c c o> c c o> c c c «b> •M O o •-< •«4 o •44 --4 •-4 o

(. 01 p p 0 s» u 0 u u p. 0

0> 01 o 0 0 c 0 0

>— 0 0 0 c

o 4S X a X X o X X X a

^ 49 44 44 44 X X X X X

«4 c c •fi4 •«« c •-4 •—4 •-4 c

Ot 01 01 0 0 0 •-4 0 0 p

•-4

01 %

01 01 0 0 0 0 0 0 0 0 0 0

X X Xe X X X X X X

-«4 ^4

f-4 1-4 l“4 ^4 »—4 i-« 1-4 (Q IQ IQ IQ 0 0 0 0 0 0 0 0 0

4£ X X X X X X X X X

0 0 0 0 0 0 0 0 0 0 0 0 0 0

03 CD CD CD CO CD CD CD CO CD CD CD CD CD

b: b: b: a :£ a: O O o o o o o O < O o C9 O o O

CD

.. a. .. GL .

.

0. .

.

.

.

c. .. tL .

.

.

.

3 •• 0. . . .. 0. • • 13- .

.

CL .

.

SI o 01 a 01 Q 01 0 a 0 Q 0 0 0 Q 0 0 Q 0 O 0 a 0

M o 44 o 49 O 49 44 o 44 O 4» X 0 X o X X O X O X o X

Q CD IQ CO IQ CO IQ IQ CO 0 CO 0 0 X 0 CD 0 0 CO 0 CD 0 CO 0

49 •P 44 44 44 44 X X 0 X X X X X X

0 01 0 01 0 01 0 0 0 0 0 0 0 X 0 0 0 0 0 0 0 0 0 0

1 49 49 49 49 0 X X X X

1. >Q (Q IQ (- c. (. 0 0 a. X P- 0 p. GL p. 0 p- 0 P- 0 pc g01 49 01 -P 01 49 01 Q 0 44 0 49 0 Q 0 0 0 X 0 Q 0 X 0 X 0 X 0 3

a, 0 O. 0 ex 0 aO o. 0 0> 0 aO a X a 0 ao a 0 a 0 a 0 a O

a o o o CD o O O CD 0 X Q o D o o o o D

\t~ 01 P 01 t“ 01 (- 0 P 0 P- (- 0 p> P 0 P- 0 p 0 P- o.^ o> ^ (X 4S a. 14 o.^ ax a (- a c a X a P- a X a X a X a P.

1 44 49 o 44 44 Q X o X X X o

C C c c c C C c c c c c c

•«4 C >«4 OS. o

>c o c

cn u X cn

ib: < K b cn o o 3

c •44 C CJ *44 c •44 C •44 o •44 0 C •44 CJ •44 c •44 c •0^ c •44 O •*4 44 ^ .44 •44 < X -44 < •Q< •44 •44 < X X CD X X X CD X X X CO X X X X CD

p- a L 0 3 a p- O P- o 3 2^ o p- o p- o 3 o P- o p- O p. o 3

o c o c c c C 0 c 3 c O c o c c O c O c o c

:£ S - u -J CDU3DtL-ICDO X CO U 3 CO 0- CD 0. X CO u 3 CO 0. ^ CD U X CO PJ X CD (j 3 CD 0. J

< 0. s: < D O CL < < D c CJ c K- < 3 C 0. < K < H < D o 0. CD C5 o CD 0 O CD O O CO O CO o o CD O o CD O O CD C5 O CD o O CO o o CO O o D CD CD CD CD 3 3 3 3 3 3 3 3 3 3 3 3 3

[

in Cii in W in in 03 -G -0 in 03 CQ m 0“ in in 03 ra -4 44 «4 •4

c

I c

1 C

1 c

i c

1 c\ C

1 c

1 C

1 c

1 c

1 c1 C

1 c

o o 0 a o o o o o o 0 o Q o

•*4 •<4 •-4 •44 •«4 •44 •44 •44 •44 44 •44 •44 •44 X c. (L P P. X p. X p- X u X U X X p- X p- p p. X p. X (b X

u o u Q u O u o u o u a u o U o u o u o u o u o u 3 u

c p

/• P. C P. c p- c p. c P- C p. c p. c p. c c p. C p- C P- c

3 p. P. 3 P. 3 p. 3 p. 3 P- 3 p. 3 p. 3 p. 3 p. 3 3 p. 3 P. 3
Program OPOA02

GKS Error FHe

UI UI UI UI UI m

SI 0l Si 01 01 01 Ol 01 01 01 01 01 4* 4» 44 49 49 49 49 49 49 49 49 49 m m IQ CJ IQ IQ IQ IQ IQ IQ IQ IQ O IQ 4» 44 49 < 49 49 49 49 49 49 49 49 < 44

I/I UI cn UI UI m UI m UI UI m cn m 3 3

01 01 01 Qt 01 Ol 01 01 01 01 Ol 01 Jd d d 01 d d d d d d d d 01 d

44 4» 44 49 44 49 49 44 44 44 49 44 49 44

IQ IQ c c **• 49 Q- C c «U c <IU c 49 Ck a UI O ••4 •»4 a •«4 o *»4 o UI O

(. 01 01 01 c> u 01 (- 01 u 01 01 01 01 0/ c d c 01 01 c 01 c 01 c d c

jd o 44 o d o . d o £ o 44 o

4» 44 49 44 49

•rH ••4 c c c •»4 c •«4 s c c c

0* 0/ •t4 •f4 01 01 •f4 01 -*4 01 •*4' -04 •*4

01 0/ 01 01 01 Ol 01 01 01 01 01 01 01 01 d d d d JO d d d d d d d

^4 *-< i>4 ^4 ^4 •04 004 004 ^4 ^4 »-4 ^4 0^ •04 f04 ^4 m >0 IQ IQ IQ IQ IQ IQ IQ IQ IQ IQ IQ IQ d d j= d 4S d JC d d d d d

U1 vn UI UI UI UI UI UI m UI m « m UI cn cn cn cn cn cn cri cn cn cn cn cn cn cn u 2C sc: SC s: s: O o O o O o < O o o O O o o o

cn

.. CL .. a. .

.

* . , . O .. 3 .. 0. .

.

.. a. . .. a. , . .

.

.

.

01 Q 01 a 0l 01 01 a 01 01 O 01 Ol a « 01 a 01 Ol 01 4» O 44 o 49 49 49 -j 49 01 49 O 49 49 o 49 49 o 49 49 49

10 cn IQ CO IQ IQ IQ tr IQ 49 IQ cn IQ IQ cn IQ IQ cn IQ IQ IQ 44 49 49 49 UJ 49 IQ 49 49 49 49 49 49 49 49 m oi ui at UI UI UI o n 49 m Ol UI UI 01 01 UI 01 UI m UI 4» 44 UI 49 49 49

IQ c- IQ U 0. (- (. 0. c u C. IQ (4 0. IQ ^0. L a (0 0. (- 0.

01 49 01 49 01 o 01 01 O •«4 01 01 a 49 a Q a 49 a Q a 49 a 0 a a Q

a. UI cu UI 0.0 a. a. O CL UI & o & UI a.O & a a. 0 a. a 0

o o o cn o o cn (4 o 49 o O CD a O CD Q 0 CD 0 o CD

01 u 01 u u u O t0 c- a (. a u a (. o.^ d a. u a. & c- (. Q. c o.^ & ^ c^d a. 1- &4= & 1- a a (. 49 44 Q o C- -04 49 o 44 O 49 0 0

c c C c c 01 c c c c c c C C

•i4 c c n4 -04 cj •*4 01 c o c o c 44 y -04 -4 <j

-04 -04 < < •»4 < 4.4 < •«4 < <

49 49 49 CO 49 49 cn IQ 49 49 49 CD 49 49 CD 49 49 CD 44 49 cn O u Q c- Q 3 O O 3 C O (4 o »- O 3 O u 0 3 O U 0 3 0 0 3

c Q C o C a: c X c X u X c O c o c c o c C O C. a: C X c

X 3 3 3 a 3 X • X X 3 3

cn U X cn o 2 cn 0. < cn j CD 0. 0. 49 u cn 0. X cn tj 3 CD OL -J CD u 3 cn 0. X CD CJ 3 CD 0. < cn -j cn 0. < K < 2 sc O D XL U xaa c < X O H X oX o 0. X <3:^g>-a£:<D O c X u X 0

cn o o cn o o cn o o o o cn O 1-4 o o cn O o cn o o cn o o cnoocDcDocno 0 cn 0 0 0 0 cn 3 3 3 3 3 3 3 3 3 3 3 3

m tn Q N in 173 n CM -0 ^ -43 in GO N CM in GO N in 03 N in c*3 n

0

«4

-4

1 c

1 c

1 c

I C

1 c

1 c

1 C

1 C

1 c

1 c

1 c

1 I C c

1 c

f 0 0 Q 0 0 a 0 0 o 0 o o 0 0

•-4 "•« •IH •-4 -04 44 •-4 •f4 04 •f4 •«4 (0 49 c. 49 (. 49 (. 49 (0 49 t- 49 (. 49 49 u 49 (. 49 (. 49 (. 49 (. 49 u 49 0 u 0 U 0 u Q u 0 u 0 u 0 u 0 u 0 u 0 U 0 U 0 u c u 0 u 0

c. c (. c c. C U C u C (4 C (. C C u c (. 1= (. c P* C (0 C (0 C 3 3 (. 3 3 (4 3 t0 3 (. 3 (. 3 u 3 (0 3 3 (. 3 (. 3 I0 3

Ui u. Hi u. Hi u. Hi u. Hi H. Hi LL Hi IL Hi u. Ui Ll Hi U. UJ iL Hi Ll uj u. Hi Ll Hi

I

I
Program OP0A07

X

o

s

a

C

C3

<

° I 0.a

H

<C

^ 1) c

.1 £

u

CO

-I

rao

N

o

o

tnn

n I tn

i-< i/ri ^

< <n 2

U.

cn u

O a Q

-J< (TJ CJ U.

raN

>

H=

Lii QL

<

tSa

llo

X o

(;j w

X

Q

-Ia

U3^ jj

< »-» U- X

cn u

o o

^ Q

< CJ o <

< <

CJ u

zO

UJcn

ijj i £ O ^

z

LU

cn

LU

tr

a.

H=O

<

q:

UJZ

LU

cn<

Q

U.

lU

H-C

z

tr

LUcnX

Q

£

O

LL

H

Z

LUZ

z

«*

*«

A

*«

«*

*

*

*

:$e 4i

*

:le.

cn

LU>

H

cn

:«e «

4e

5je *

sje

:?e

<6*

46

4s

46

46

46

464c

46

LUz

<

S

X

UH

<

46

46

46

4646

4c

4646

46

rvo

<

o

LU X

r—

0. O

4646 Q

Z

4646 X-

• > < G z 4e < 46 cr LU n \n tn o

cr < (M «

46 2

46

46 o tu H

•• CM CM 0. K> o a 46 cr 46 Q cr

• Z fv X 46 LU 46 tn Q in

15 X ^

. 1 lU Cl 46 :4 rj s u. o H « 3 4e H= 46 O 2

N

cy H

H

X X CM aC ^ 4e < 46 . o

. -» O

H» -i X cr 46 0. 46 r cr 2 O H LU < H 46 48 I 2 C

X CJX Z cn X cn 46 1 46 X s cr Q «i i_ 1 J{ t—

4

LU H X LU 46 46 «J J c < X

I* H «i a s cn X H f<J 46 cn CJ C9 LU w O

X

<! -<C CJ < lu c. o O G 46 46 C5 O Q O CJ •-» H 46 lU 46 u ^ lU

cn

CJ cn 46 z 46 -J J ^ 3

<

a LU q: 4c < 46 -I U -j < _j

CJ

li. •-« Ui z < < < 46 cr 46 < < < cr < LU CJ lu CJ CJ CJ 46 Ll 46 CJ CJ CJ a CJ e

mm
FOR

EACH

SELECTED

VALUE

OF

THE

PATTERN

INDEX r

inOio zuI

Oi<

u.

tno o

-I^ II <o “5

LlJ Z +

-5 H

UJ I cnIT “5 I -» “5 ^ w w H K

II Ul <

cn o 5 cr -j ^ U-

<3 cn I . <

<3 Ul n

UJ cn ^3 o . H

Ui

cn ^

q: -i

Ui ^ a ^ -J o

-I

-I u. < M CJ

in ' o • . -I O UJ

cs + < o>

UJ a H ^ ir > 3

Ll o »-* QO > m• ca mo -. z o < X IT H H o a

-J -J < < u. CJ u az

Ui

UJDZa u. u *-• az

UJ o

'T

cnUJ>H

cnuK<

U.a

UJ

03Ui

*-* H<HZu

03Ui

cr

0.

Uiq:><

0.03Cz<u

UJ-i

UJ03 z

UJIK0

Ui

cri 1

cj ej a o cj a

UJcco

0.0.D

CDKaz0z1uK<I

CJ CJ o ou

I-<az

in

rj03

in

rvo<

CJ UJ

03-I

UJ o

UiK

q:Q

CL0.

z>03

03OzzuK<

CJ CJ

AND

DISPLAY

FILL

AREA

USING

EQUIVALENT

ATTRIDUTES

SET

INDIVIDUALLY

cn

LiKD

cs X

LiJ Q X

UJQZ

irH

H-< OOoa Z q: • L!

l-S c J

-1 NS Q Q S cr Z

CJ a Li 3 d

*-* a:

Ui

H-ZN4 o

CS

tr -I h» G > • z < ll h“ Ui ss Li o

cn J cr NS 02 > < Ui < O

Li z K Ui CQ > <

Ui cn (T -t H" -I > m X < J «j cn J u.

H- cn \ NS G

cn . C3 UJ \ LL in CJ Ui « o ^ < C3 % u

or o < M i Li «i <D q:

tr ^ o z Lu I Li ac ' 3

Li o ' Ui « K CS < ^ Ui c HH 1 o ^ I K < X X a 02

«i« K > Z q: u < a ^ Li a X - H - Li NS V— J— »n Q Ll NS n o CJ > -J -J < -1 ' O Z •s > W « NS > Ui H > > -I o * . Ui % > CL s: K K O J ^ J Ui SN 0. «i in > ' d cn 3 cn cn CJ u. m Li Ui o X Ui < ' cr in X < ^ ^ o «J a H* Q K z * < r!i J s cn i . > < UJ O O cn * SN n Ui n Z Ui < « cn CJ K ^ -i z N. « X CJ . cs < 1- u.

u. < < < n m + cn > a J O ' K X •NS < w NS < cn

0. u. IL LL -0 'O ^ H- J •-« n O NS X «| X or NS <- a cn cn cn . . o cn Ui cn < H < u. a -J V 1—

h* K ir o o o NS o o o o o o > a H ^ CJ < Li O *-« Ui -J O O O CL iL < NS H- cn a o cs -1 U- Li Ui G n II li cn -i«i-i-in II tr u. Z J Z Ui O < < NS H -1 K ^ Ui cr < ^ _i 3 »-• Ui Ui Ui cn K _l CJ Q NS -i ^ -J 3 (L 02 < < < < O O -» li. z z cr < a: < < Z (L CM n O

CJ u <J (J X > > Li UJ Q Ui 3^ CJ 3 CJ CJ NS < sS SS J H SN 0. Li Z H* IL u. IL -i z NS G Ui cn 02 cn < L U cn < < < CJ « < oo

Li

-IczD

C3U<

LiO

cnD<

LiZ<za

cn

(T<

0.zou3<

cro3a I c

(J CJU CJ CJ u u U CJ o CJ CJ o

^ X

cn 1-4 Ui -i H o

D CJ Q • a ^4 c cn X

H X »-4 H CJ -J < « a

0. CJ H X . -J X 0. u 03 < X

U. CJ u

LU Ui - a a 0.

0. X

X

fj z H CJ I c Z « o M a CJ

u. Ui

tn < a

h- ir 0. pv Z z

LU Ul H

« cn z Z

h* LU o o a

cn a >4 u. K

X a. 111 H 03

tu LU 03 < M4 4^

% X IZ H a. a m

o * Z z Ui ^ '0

(T O H Ui • < X a 03 a a a «

n Ui t-4 UJ z Z 1-

CM -J M H q: D w cn o I < w 2 0. 2 a X

Q u o X H Ui 4«» X

K UJ £ IT a 1- X

cn 03 X X K 03 H0. H X O O *-* u. z LU a K <J 0. X 03 UJ

1-4 II q: o Z LU 03 LU O H

X o »-4 O o: I K J J

U1 z 0. -i u. 0. CJ 2 < <

Q UJ z <D II II II H“ J < U CJ Z Z < H CJ 0. Ui < a

t-4 CJ U. 0. 03 03 CJ a

Program OPlAOS

o

a

<

a 2

Ui a

a

X >

D >-< Z n a A X z

1- H CJ Ni^ Z Z

Q Q V. a a Z

a a n X 03 X Q

Ui

I 1 CJ X X 1-4 4^ 44

03 CJ > Ui u n u a 03 a

> a a «>4 X n a a »-4 < Z n m a -* CJ 4^ X u CJ a a

UJ >0 >0 a % ^

% CJ a a

< 4^ X . n m a % O % 1- • in 4^ 43 ru in -a a H

LU n in A <0 Z Z n X ^ ru ci - cri «

4^ Q

0 ^ a m a m M 44 a

a . in ^ CM in w fN Q % K ^ in s N % GO H* 1- a a

« 0 X X z z a a

UJ n . K h* n ^ n w «-» Q Q a X

a X 1- 0 a X X X X X X X X a a a

< CJ Z a 1- a H u CJ K 03 cn 03 CJ C J -I a ^ a a a h— < < O

o

Ui a J ^ u Ui a a a X II II H- < UI < 1- J H -1 i- a H a a K a a

z N4 CJ 03 CJ a 1-4 «i « -J a 44 a H Z a a

a a z a < a < a < a < 0 a <

2: 2 1-4 Ui Ui 2 0 2 u 2 a 2 CJ

SET a a a

h—

-

u o cj CJ u u CJ O CJ jj u a cj
z'

iT

I

I

a

m

Q

Z

D

CQ

-J<

Q

QZ

Z

c a.X

cn H

Z

a.

CD a

LUIT c n

u

Ui

cr

Q.

U — U -J ^

f*5 Q ^

>p< «-* X C*3 CJ Z

X '* <J ' I U

^ ^ ^ «

trQK

U

<

u.

iS

Lli QZ

X

cs

e

}—

CD

S

c

h=U

<

U. O

z

o

in CM .

% m > Q z cn

u. in «S , m

n

• in . < M X Z

< , < n * • . cn • « CD X < , CD H CD in • u. in ll « m X Z m u CD * < H z < ra in CM in fx < < « < !-> CD Q n -0 % GO z o z CD X U. U. cn ^ rj X + X Z X

CD O CD n cn in >Q Q Ui Z X CD < X H" II < X X X X X X X X X • ^ > -I X (J II < X

CD H X ^ CD u H“ CJ H- <D 1- u h“ H

ll’ o . < 0. H tj X CD CD K> C O LU rv C5 C5 O «C5 o O i: 1 II U. z z U O GO O

H“ LU Ui Ui LU LU ^ 11 ll < II -1 Li. ^ H* .J r“ K* CM »• r»i «i H u X z ^ z -!

-i H < -1 -1 .J >—c .J -1 z Ui tj X _! < -i < < LU CD < (T < cr < z < Z < Z < X X > > < o z X < CD < <

(J CJ CD < CJ Z (J z u z (J z u z CJ < u u. z H U CJ < O u

CD<

0.X

Ui

(T

(J

LU

cr

LU

CD

Li

CDLU

tr

ASAF<8)=0 CALL

GSASF«ABAF>

URITE<CH3.

M!3>MF0NT

CALL

GTX«.

425,

.

43,

CN3)

WRITE(CH1,

M

PREC
I

I

I

I

I

<

D

a

a

UJ

-ia

z

D

a. a. o

z

C3

IT O 0. 0. X cn X o X CD X

X —X »>^ —* tr H H- CJ X 1-4 A

u n u -J o CJ z n UI CJ CD CJ J X n c X tr < c cr X CD Q X

X (j A X cj u CJ u. Ll CJ 0. X u X CJ CJ u % « % (j < CD CJ * CJ « n n U. CD •o A «Q <l n CM n % > QL ^ ^ z n >0 n Cii •c n >

, . •t . < o tn u. n u. n , , , n <

, n C*5 z ^ X < . CJ < n * n * n • • LL tn u. >-4 m X m >-4 -• U CD - < CD -4. m M » Ll tn u. * m X

\n CM m N < . CJ w ^ ^ H 0. < rj m ^1^ CM •—

tn N <

\fi IN % m » o < a. 0- w CD CD 'T % cn % o m «» \fi (M 1 0. CD CD li. X U. m CM ^4 CM

«w» n n CM N N- ^ Q, CD X X - CD - O CD cn n n w 1^ m ^ X X X X X X X >0 . > -I X CJ CJ 1 < X a: II < X X X X X X X X n > -1 K u H* u CJ , O , < OL X , CD CD ^ cn K < CD CJ K CJ H u h* u H“ CJ H" d d < 0. 0. O w O w o •W o II II II II C5 CJ <r < CD l> o o X c> o V CD w CD CD CD >- CD n II II II o CD

Ui Lli Ui A ^ II < n w CJ Ui Ui Ui Ui Ui II H K K ra CM -1 0. CL ^ ti. ^ _{ U. J K J H 1- Ji K _1 •-4 CM CM J 0. -J 1-4 -I 1-4 •—

>-> ^ «J X CJ CD -J < J _1 f— < -J M* -J -J J ft-4 -i J _! CD < tr < cr < q: < X X > > < X X < cn < < UJ CD < (T < cr < ir < cr < IT < X X > > < X

u 3 CJ 2 u 3 u < < < < CJ u - CJ CJ < U (J CD < CJ CJ 3 CJ 3 U 3 CJ 3 O < < < < CJ u ^ I

UJ

tn

iii ir
r

o

CJH>X

UiK

Uicn

Q

Ui -J<

-J QZ

3 0. 0. 3

O

«< < a X cn X >

3 o X ^ I A 1—9 C X Z C3 UJ o n o A -I ^4 Q

IT UJ C Z K -.H n a Z

> Q u. o 0. X A O X O o

cn Z w o

a X « ff* *> » o ^ 0

* CD z A o A X ni ' th CM CM CM > Ui M U. CM cr Uo • CM Cd in < h" Q < . 3 < C3 X CD • CD o 3

e o CD < Q cn in M ^ m u. m X G

3 _} < 1- < ru m w CM ^ in N + <

O Q ^ cn O % ^ ' in % xQ X

1^ m « «, G

-J o o U. X o O Uu « * ^ • « . m -< CM IL X

cn H* <03 0

il o -* X

« -I u»

-J -1 <

o < cn o a <

II cn<

03O

J

<

u

X

K

O

J

<

o

H

X

UiH

1“

UJCO

UJe

u.<

03<

03<

03O

-!<

O

X 2 X

H- <J K O X> Q

Ui d -J < q: < O 3 U

n

I

o

UJM

tr3

V C*1 X X H O

UJ

-1 H

X X

H O

C ^

Ui

-I H

QQ X . X

H O <

O II II

^

CM > -I

. < a.

H U O

-J *-• -I «

< K < tr 0 3 0 3

«j fj ru —J J Xl^ «j

< X X > > <

o < < < < o

I-<

H

X

UJH

H»

UJ03

H

Z

o

Llcn<

II K

Z

a

u.

m »-» O O 0.

it II OB

U.<

03 03 < <

ASAF<9)=! ASAFC

10)==1

CALL

OOABFiAQAF}

CALL

GTX<XST.

.

22,

STRU
DRAM

ROM

HEADINGS

AND

FILL

AREA

(BUNDLED)

Program OPlA04 ^

^ Z ^

o

in

aH

O

o

X X Z X Ui X

Z ^ HI 1-4 X

< LU < X < ^ H <

ll. X U- CM H u. n Ll Z X H Z X Z X -- z

' K O ' ^ CD ^

^ ^ Cil

(J ^

« o

o

o^ n

^ X

(JO (j

, o « 'KO'H ^ CD O CD > ^ >

' O-J' O-J' O-J' o

CJX

u

h“

CD>

rao

z

Ui

n-6

ui

> ^ K

c4 (*^ ^ 53 J "i

^2

^ ^ + + + 2 CO

1 4i4Xx^^XXH-iXx ,-4 X X Ui ' X H4 H4 M

Uih-'^OX'-OX'^O ^

X O KO

O

X « Ho tn

1 >n

1 m

1 Q O «J J UI N Ui Ui ,i^ Ui < ' w 2

. .K-i<H-J<K-i < K -J -i H ^ > ^ <

U. «J nj -I H Q . n J »-»»-'cc<za:<ztr< z cr < Q X < CD > <J H II w^3qw3<j^3CJ w 3 cj Q O CJ Z 1- U. . -I >* * X X

uD «* NN

43 . „• “

n u «

H 2

CD M o

> > Q

M 1-4 u. u. u. n < < i-4 pm 1-4 CD J

u. u. u. >

z z Ui Ui Ui Ui -* H-

•w CD CD CD CD X Q CD Ll U. -1 J Ui z z

M Ui Ui UI Ui Q Ui

li < X uX

>

CD

-Io u. (J M

>

K -•

CD 3

Z -P

lit *-i O

z

UJ

CDUi

X

<

>

UiH

X

ca

(TI-K

<

3

<

ITQ

Z

UJ

o

o

o

H

-1>

CDZ

CD

ca<

CD ^ z n

>-• X

^ Z (J CD UJ . ca X H

< H CD>

' in ^ o rj

n ^

^ LU ^ 'OX • . H“

CD -1 e X >

O H -J ^ CD -I z <

Ui I-* CJ

ir u. 3 ^

IMPLEMENTATION

DEPENDENT

FILL

AREA

INTERIOR

INDEX

ELSE

CALL

OTX(.

125,

YST.

'--V/CH3)
I

CO<

\xl cr<

-I

cn<

hi<UCZ<

cn

q:<

cn

cn

Ui

<u

hi>H

cnUJoz< o

(J>

cnJ>

}“z

Ui

cn

LU<r

0.

cn

Ui>H

cnxQX

LLi H* ^ «

.2 £

*- 3 o -r o

CO a

CJ

[2<X

.a 1 Z H z l-« 1 o cn 1-^ X >>« z > H M 2 cn H z < * z CJ \ cn % o H X Q 1- It * X Z X >- < X ! X

H- hi X H > o < cn < t” X »— X 3* cn z X > Z 1-^ n X

QD ^ ^ LU X H X UI a ^ N 'O cn X * X cn K o m . . Ui X X X < « QQ ^ tn X « X a cn cn CJ m . iD (D X < Q X H a z p*< -- - CM . O Q ^ Ui Ui X C3 < a O N O - X X X X X a: X z

03 0:^0 < 3 X 3 h“

M

A ^ *-«> •^CM-^cn « 3 . < w < Q cn o

CM CM cn o ^ . tn O LU -i X X Z X o ^ ^ ^ 3 X -- X « < X < Z z X

H- ^ 1- I < X < > X X z l>4 *o« <Ui<X<Ui<Z z a: cn I II X C3 !l X H* cn o X X t lJLtiiLL<U.:^U.D 2 LU CJ O X X X cn O X z X X D

cnxcnKcn<cna o 3 H cn hi X > Z cn >-» cn ot-ocnc-ior X o o o >-4 o ai X 1 H *-< X z H o X o X o X X > cn X ^ CJ CJ -j-i-j-i-j-i-j-j CJ ^ ^ ^ m 3 < X < t- X X X

LU -1 -1 -1 H* C3 CJ f— X H >-4 CJ Z X X H X <<<<<<<< X < < < X c Z X X a X < X < uuaocjuucj U CJ O CJ cn Q X cn CJ cn CJ cn X
CALL

QSFACKCOLIX)

(

«4 X Q

X X CJ Ui

CJ Cjl V -1 V N» Q

< O V, % Z

D * UJ V 3 C -I ^ X -J ca

N-4 > ' Q < 1-4 % • Q < X

> H • Z 3 J UJ 3 rj cn m cn CM 3 Q A > CM a n -I o UJ Q z o C3 in H O Q in »-4 O H

Z 3 cn Z 3 CJ d 3 »-4 o UI M % C 3 < « 1-4 + a

> + o + flO 3 Q >

Ui 0. •• ^ > z ^ > Q *• > Z — CL > tr

u. > H N>* U. CL > X M U. 0. 1-4 u. - 0. H

> < m ^ SL cn < - O. UJ > < - < in H

cn CM X cn 03 Q CD in X cn CM in <

CO < n w {> IT UI < ^ in Z Q < 'C Ui < CO fii ' n o Q % in M Z Q % <

(T u. M o Z ll o M ^ li. w Z ^ «>4 W UJ a H cn Ui cs 1 II cn UJ UJ 11 B cn UJ u n cn Ui o: < UJ I X Ui < Ui X X IT < Ui ^ ^iZ\U X X <

q: cn cs CJ K H •4 UJ CM cn (T CJ H > CM 3 n CD a: Ui — CM cn cK CJ H

111 o K w o Z I O h- O H ^4 a -OH ^ ^ 05 O

H- Ui > UJ cn > UJ J

Z U. H- «] U H— U «i «i H -J U. o u ^ ^ H H J

< •-• -I f“ < cn < -j -J *i^ -I H < CJ < -1 -I cn < < J J u.

cn < < tr < UJ CD cn < < (T < UJ cn CD < < cn cn < < tr <

< u CJ 2 CJ CJl < H < a CJ 3i U cn < h- < CJ CJ H < < O CJ 2 CJ H

UJ Ui UJ Ui UJ UJ Ui cn cr cn on cn cn cn

u u u o u cj u u o cjoo UCJO uocj u u

I

I

I
f O rj><X

«3«. ra X * > > t, < < « > X X X 4c < X X £ « X . « z 4* z X X «» 4e o £ X 4c »—« X Z £ X * H £ Z £ « < Z X £ z £

LU Z X £ z X 4c cn Q LU Z LU £ 4c LU LU cn z z z £ it IT U LU LU o • a. Q s I 4c Z 0. K • « X 4c h* 3 LU X O £ 4c O Q (C £ m « z ie z o o Z O «. z 4c cn z in in H in ie % !U IX « X O X K LU H* o £ o £ H 4c m 3 H O in £ in £ U 4c GB o Q H X X 4c * >»<i < X £ w ru cn 4c m a: o> £ £ « o 4c K 1;. r a Q , a Q X 4c m O Q K < Q X >-« c» 4c tn ^ 1-^ < cn LU e o s: < 4c n Q < Z o 3 3 , 3 3 cn 4c . 3 < »-« o cn 4c »*> 03 ai — LU 0 0 0 Li. LU d X X in X X X ic X 3 cr Z o n Ii » cn LU m < < , < < £ « H ^ H- < [i ^ ^ < Q . X h* X X 4c O Z cn Cii cn cn LU cn u! o cn cn Q 4c 3 LU u ^ ^ ^ ^ o !X Q o o o o K> 4e -! o 3 H* J O. o 4c 0. O C »«« LL Ll U. LL X X X X Z 4c < U- lu < < < < 1 H £ -i -1 X £ X X X X 4c LU U ^ CJ _I ^ cn cn cn cn < lU Z < LU < « Z < X < *-* 3 G 4c cn o lU ^ J K < < < < tj cn o cn Q u cn U Q K h* 4c -J z I < < lU LU Ll J Z X X z X O ie Ui LU u CJ <J m X LU X X X X o 4e (

iMi ii

FRAME 5-

CHANGE

OF

PATTERN

REPRESENTATION
SET

FILL

AREA

ATTRIRUTES

BUNDLED

«N CM> o - ^ cn <

cr0. >< > X X < X z > a: « z < c.

q: X z CL X z X Q ' « Z 2 Z X Z Z

t“ Z « < z X X

h* Z Z z X z z z

LU z lU . cn z z I

LU LU ^ K % X

q: I z

0. H* * ^ ii z

ill X O 0

q:

A ^ Z in in o o z . « X z in in « H- O z

q: X o n z

u: K O z

1- C5 in z ct CM K * « X , < X Z Q (£

0. Z - • Z ^ HM

u. Z Q a • r < Q . HH IT 2 3

cn UJ cr 2i: • n Q < z O 3 3 2: cr

>— Hi* . ««-' o < < o o O Ll Ll o cr cr in a. 0. o It It it cn lii m < < . CO cn

II <: Q . CL 0. K 0 o

ra n cn lit H cn cn o o cs o o o • J J w> 0. J -1

U. u. ii. Ll -I X «l X < < < < < < -1 h- Z -J -j IL Z U <J Ll

cnm cn cn < lll z < u < -« Z LU H-t < < < < u cn w O cn cj 9 cn a

LU IL -t z Ll j z

q: Hi* LU LU LU LU

cn

LU Z z o HH HH H K 0 U 0

LU LU 0 >

cn H l> * < 0 0

LU > « X o Hi* Q < t- Q O HH X

cn u H4 HN < O cn < 2: :s: 3 H

LU LU 3 3 cn H z Q t— ir z a: cn t- cn LU a Q 3 3 lU cn aC z

LU 1- Z < -1 1- LU ^ HH

cn O < C CJ I- u h“ o z •»-4 0 0 u. 0 0 D X LU 0 C D G cn -J -I -1 ir

h“ 1- o -J -J a -1 -J c cr < LU C < < z < < Z D

CJ X o CJ CJ CJ LU CJ CJ LU cn 0 IIIII(
Program OP1 AOS

(

d

>

<

cn>

H

f

<

3

Q

>»-# a

z

(SI m

C!< % a

LLin 09 z Ll 3 cn CM ^ H a < cn . Z cn K <» Ui Z H- z o H- U. o Z

e cn CJ cn z 0» J

in ^ in < z > in

cn CJ 0. cn LL! cn cn o cn cs O CIS UI < >

cn -I n ^

G _{ 1“ 1 -1 < UI < Ui < <

CJ CJ cn CJ cn y u

X

O

cs<

z

Z ^

LUZ ^

O C3

LU cn

cn tj

Ui o

K

< -J

in j

z <

o o

o

z

<

u

H

<

X

UJJ

>

H

cnz

o

13 z

a

z

> z

^0^ a Z UJ X

Q l>X U c t—

t

z a ^

o Z l-« z

z CJ ^ o Z "0 o h“ z S n

cn cn n UI C O

I <

d 3

k-« z

ra 3

9 C-20 cn cn z o S - ra < cn < 'S 3 n

d

<

a ^ « d

H

z

<

d z -- ^ o

Ui o CM in X .

1“z

inz o

o cn

UJ J

cn o

cs

Ui

cn -j Q -J

-J <

CJ CJ

<J U O £J> O CJ CJ CJ CJ CJ CJ CJ CJ CJ a CJ o CJ CJ CJ U CJ

OPERATOR

PROMPT

CALL

OTESTR(WKID.

15. O)
Subroutine HORSEH

rj

QjZ

<

>

-J

Ui

cn

LLl o

3

cn

Lli

f". Z

Ui

o

c

UJ

h~

cn

LUH

01 O

<

a:UI

0.

ru

Ui3

z cn

4* ^3

^ Ti.' CD ^ w >

> 2: ra u

q: Li < z

Ui >

z

o

m ra X X

ra a:

tr cj

< Ui

UI z

T

< :? ur) n

>

Ui

GTQ

Z

> > -^ Q0 -0 <

UI1

CJ

00

n

*0

>0z

in >

Ui

<i

00

rv ra

. 1^

i>

rv IN.

(X ra n ^

fN pN

fN >0

. fN

ino 3

^ in

>0 3

>0 0-

in

-0 o

un -n

in fN>

. ^

- 01

in <

^ 'jj

. T

\

m , m un ^

. 'i- nG

- . ra

un - . o m , in m

. in ra

5nin o

. ra ^ in ^ m

in pN . m

.in * n

- • rv m . n

ra . m

un . fN

in in o «r . n

in X • mam . « Ui

-0 I >

1-* '?

'N

>n <i -

. rv ^

>0 * - ^ CD 3

. . O

3 in <33 ^

X o n

ra . < m

UI o o

V 02 . Tc O' 3

i> . ra m - N ^ O

c O' ra

. m . \ ^ 3

<03 m

PN . .

^ in O'

«T 3 m

- o * 3 3 '-. 3 <1 n

m

«a- . 3

• - . m

- ra - . 3

ra -0 >0 \ . 3 « ^

. . . >c 3 -in . «T 3 >C «T . . n . . . -

. • • >0 ^

- O' m ^ ^

-c -0 . . 3 . ^ -

. • .mm

- ^ . m fN - 3 . ^ - m

. - . ^ m

• PN - Tf . 3 IN ,

. . . , <j

- - - n . <i 3 ^ - ra pN «T . rr

- , 3

O' in c

. ra . 'O ^ 0

^ O' 3 c’

ra m 3 3^3 . 3 . OD * ^

O' «r 3

- N - ft m > m « , ra c T ?r m

. < . . >0

• Ui - . . 3 I PN n . ra ^

m

m N

o m

^ un

O' un m

^ o

fN

<T

m

o

un

. X m

- UI rj 3 m

< a . -r _

«T 3 O'

. <c

IN - - O' IN m

. ^ O'

^ 3 . . m. . ra IN

» m o Ui

IN . . O' . - *

. m m N - . pv pN rj m

3 m o pN in

m

m

«T

m

ram

m

ram

>

Ui3

o

z

m ra ^ o - o >0 o -n IN m

3 3 9^ I— 4s G 4s z > z N. Ui 3 H- 3 4s H 4« A Ui S4. m 3 0 PN O' m m 0 - j— G < Ui 4e (J 4c ra «r -s a» n IN |N 3 3 3 ra m m ^ >0 IN 'O 0 •43 fN

' I CJ H 4t 4c z -* 3 *“S z Hi4 4s 2 4s >0 sn N N N N

Ui U U 4s 4» X X w U ra X > X > N. 1- z G 4s 3 4c z -• 2 X UI z — ra >

< K 4t < 4s 3 < ut 3 3 <J (J Ui Z<-**• K 3 Z 4s 3 4s 3 < Ui > u < < Ui Ui >

D Ui G 4: 2 4s Ut Ui X Ui (U z UI 3 z z Ui Q G CJ H-4 & 4c 0 a

U. 3 3 4c 4t UI -i -I -J Hi < < 2 a cn 3 4t 4s z 1- < < < -i-i h* H

3 3 Ui 4» 4s z Ui Ui UI C < <

Ui 3 0 •Jm 4f 3 3 3 Iq 2

-0 - m

o

r

4s 4i ^ 4s it 4s 4s B

O

Ui

IN3

a

Uio

u:

0-3

o

I-<

I—

m m

ra ra

0^5

-j •- — _1 li

II < —

01 Ui O

m <

u CJ o

UI 3 2

u o

EYEX(

I

)=EYEX(

I

)ttSCALEF+0.

EYEY(

I

)=EYEY(

I

)itSCALEF4

0.
System Deveiopment

Corporation

A Burroughs Company

INTERCHANGE AND GRAPHICS STANDARDS FOR CALS APPLICATIONS

REVIEW AND ANALYSIS OF CALS-RELATED REQUIREMENTS FOR GRAPHICS STANDARDS

CONTRACT NO. 43NANB613292

TM-HU-900/000/00

31 JULY 1986
ai^orrAoiJ‘«HA a^AouATs soimoaho qua aowAHOHrrMt

se

(f. T> ^ . -y . r* Ih ti - 14 # r»

. . .

.

mt. i->- . "S.^iQ ‘ - o ir. fi fi ^ 'y ^ if' 3 -c ** - . ? «T V ^

>. V

M

J . Subrouitne HOB r^ -

inemqobveQ motevS

' ‘ ' • ' noil6io0op

jt . aa : 3 tn ^

frrvloo

% o ^ -r O ^ » irt ^ o

, n . ^e V

A ' ‘i 3? ^ 5 ^ ¥ ^

u . X -45 ^ ^ j . 4

^ <r.r?

U} . # 4 1 e • •,,^*•13 3

,

m < *-» Clt- «E

ia

*

. #• •• ^ •*• ^ V '_- »

. ** a Q « *• " ' -O •# 1/^ ^ #. 3K. • * SI -w - w ^ vt p ^ Z. • - > ^Z

1$ h ¥ ' • iu H_r

« IT -• - «“*•'•* 21 « -< .T wH

* CL. # . ^ ‘ ' .

f

4f <I» ^ ^ . . . <r .04

on ^ .*. it. ^ y ^ ^ _ „ eM Oi ^-*Ui ®'«<<hC0 n-.

-. r% m , . , ^ 1 ^ <5 •“Hi ^ , fs .. ,. # . ' tn rx Q ^ * - .

. . fa . 'r ./j /i «r . rt ^ ' *“ •!' IR ^ ‘‘--‘•TO *#0*

54 %4:« . . *0 #'2- i^ r' -

'^ • • t . . •• "' *f ‘ » tj^li^ O Jrls^o -:

$

* SS'w S- 3h-r4£»^v . vi^Sa»«i3i

.

* ATS. 4Q ; «<>.-. X - ^ « , o «-% •

Iw .% n «T) >- Ti t . ^ t^f% - «. .*< 04 ^ 5i •• iR a ^ c > ^

j tt < 43 . " C -w

A*.!-^ • • « * • - Ai rs n ‘X ?s n • o r'4 «f N C " f4 f4 ^ T -r « 4 O 4ff >

. , » 4J »

• » »vxA^ •. -S£*‘ 4 A*' n ^ ^ ^ ^ . o tp ¥ 4 • o

43 —

Awm

.ifi «i

I'!

* »l -T J*. W. Of^ Vjf * • X •- <Ti >« ^ —

• < * cc < w I . -5 • ^ • ;r < 44 V * r* >

T ikiiU >J ^ ^ <

1^ w tM tu ttl 31-<C ^

' * 8512 i

• i U

jm. V 4‘

'ii

_

- it .«

ocJ^io(sitH4<rr
System Development

Corporation

A Burroughs Company

INTERCHANGE & GRAPHICS STANDARDS FOR CALS APPLICATIONS

REVIEW AND ANALYSIS OF CALS=RELATED REQUIREMENTS FOR GRAPHICS STANDARDS

CONTRACT NO, 43NANB613292

TM-HU-900/000/00

31 JULY 1986
r:.

, ft

4

tnemqolavsQ (n8tey2>

noDsioqioD

ynKqmoO A

' snoiTO'j'i'^A 80^ iasAQWATt ED!H«as2 I aDnwoanni

'M

X. »

.’ »"r

-:% yj

y 225tpC?^T2 JaiHSATO m 2tiq((iSlt®3S MTAJ3A-3Jft3 21 2'' JAM 0*» V3^3H ' Jh

j» :f -

j' <r •'

S^Sna81«AMC^ .OH TOA^tlMOO

’*

ft l|;

% 'i- lA :Jk

, •*’nV ' ''’ #1

00\000\00c-tilf-^
31 July 1986

System Development Corporation

i i TM-HU-900/000/00

Section

TABLE OF CONTENTS

1. Summary. . . . . l-l

*2. Introduction 2-1

2.1 Purpose 2-1

2.2 Scope 2-1

2.3 Approach 2-2

3. Factors and Criteria used for Analysis 3-1

3.1 Existing Ongoing Efforts .... 3-1

3.2 Existing Computer Graphics Standards 3-1

3.3 Questionnaire and Other Questions 3-1

4. Graphics Standardization Efforts ..... 4-1

4.1 Graphical Kernel System (GKS) .... 4-1

4.2 Programmer's Hierarchical Interactive Graphics Systems

(PHIGS) 4-1 . 4.3 Computer Graphics Interface (CGI) ........ 4-1

4.4 Computer Graphics Metafile (CGM), ....... 4-2

4.5 IGES/PDES 4-2

4.6 Bindings. . . . . 4-2

4.7 Cross Language Bindings 4-2

4.8 Common Storage Formats. .................. 4-3

4.9 Combined Text and Graphics. ................ 4-3

5.

Surveyed Projects 5-1

5.1 Printing and Publishing Systems . 5-1

5.1.1 AIPPS/600S ..... ......... 5-1

5.1.2 APPS ................... 5-1

5.1.3 NAPPS 5-3

5.1.4 NPODS 5-3

5.1.5 ATOS 5-4

5.2 Paperless Presentation and Maintenance Aids 5-5

5.2.1 MEIDS 5-5

5.2.2 PEAM 5-5

5.2.3 JPAPS 5-6

5.2.4 EMPS 5-6

5.2.5 NTIPS 5-7

5.2.6 CBAT 5-8

5.3 Automated Data Repositories and Product Definition Data . . 5-10

5.3.1 DSREDS/EDCARS. ................... 5-10

5.3.2 TD/CMS ............. 5-11

5.3.3 EDMICS 5-11

5.3.4 PDDI/GMAP 5-12

5.3.5 EDASRE 5-12

TABLE OF CONTENTS
r

• ’" '*' ".-‘

5" 5n6Wior#vaC maizv?

.J . .. . 1 ,U

•iBf: \'<A

^^^>^TM03 y 3 jet 7

* .<,-. . . * —- ' fftlOf-ril Bhfl«*K3 I.t jE

* ' ,fc,i!iin;c'«l(v;»>J -iJ-5««:.:' 8nHi:.a

. . N*« r*lMinoU»«P

«> V

•' ' n«r#ti iDWQi^3 .

• «iiis*?il'»trtoinj »vi33»**»jnl feJ»»'y'»''*fH

, •>i3 > isMonr 'sJuq*®; C,».S|

'»Juq«b3 ..... ?-; /

^ i3oq\Z33I «.> • .

. . * ,ejnfbflt 3 •] **** *****

^ ctO^O '•'  ‘ ** *** *

^ nocwoO 8*^

, . tfA Jj*** J

I ftjj' f iinfr pnfifl^* ' • •

• l-l-«

^

, , . zqw S. 1-?

. . t.I.S ... .2C0q« ».!.* .ia-‘4

. ..... 2t)TA ?.I.! ^

; ;

• * 2QZ3H X.X.C

.•.•*•*••* WA3^

E.S .0

2W3 ‘.S'*

-I'Sil'

:

^.= •*'’"’'|SSJ,taS’TS

'•' *';!!!... tww i.t.i .

• • • • *-^» • * e3J«03 t.t.? *•?.:: .AAWUOOq ».c.2

3A2AG3 ?.C.2

30 3JSAT

* « * 4

/ i
31 July 1986

System Development Corporation

1 i i TM-HU-900/000/00

TABLE OF CONTENTS

Section

5.4 Summary of Projects Needs 5«12

5.4.1 Keywords 5»12

5.4.2 General Notes on the Technical Manuals Area 5-13

5.4.3 General Notes on the Data Repositories Area .... 5-14

5.4.4 General Points on Graphics 5-14

6. Reference Model 6-1

7. Results of Analysis 7-1

7.1 Short Term and Long Term Solutions 7-1

7.1.1 Short Term Solution 7-2

7.1.2 Long Term Solution 7-3

8. Conclusion and Recommendations ...... .... 8-1

8.1 Conclusion 8-1

8.2 Recommendations 8-1

3.2.1 Applications Standards Interfaces . 8-2

8.2.2 Raster Operations . 8-2

8.2.3 Higher' Level Application Software Standards. .... 8-3

8.2.4 New Input/Output Facilities . . . .

• 8-3

8.2.5 Val idati on/’*/ eri fi cation. 8-4
1I

('II
31 July 1986 1-1

System Development Corporation

TM-HU-900/000/00

SECTION 1 - SUMMARY

The effort required under this contract was (1) to identify graphics interchange

requirements for logistic technical information in order to establish a unified

interface with industry for automated data exchange, and (2) to assess current,

intermediate and long term capabilities for applying computer graphics standards

to specific CALS applications, including identifying and prioritizing critical

Research and Development issues. The following actions were taken to meet

the requi rements

.

Applicable documents relating to the CALS program were identified, accumulated,

and reviewed. In addition, fifty- four documents from surveyed projects, along

with questionnaires and personal notes, were compiled into a CALS information

database.

Participation in on-site interviews, in addition to feedback from NBS tours

of other government facilities, was consolidated into the database of CALS

information and used in the analysis.

Feedback was analyzed from questionnaires circulated to government personnel

representing Automated Technical Manual Systems projects. Paperless Presentation

and Maintenance Aids projects, and Automated Data Repositories and Product

Definition Data projects. The NBS-sponsored CALS Workshop, held 24-25 June,

1986, provided further input from DOD projects and from industry, as well as an opportunity to further understand the requirements of the projects.

Active participation in the development of graphics standards provided a broad

overview as well as detailed technical knowledge of the current state of and

short term plans for those standards. Membership in the executive committee

of the graphics standards organization led to an active role in the

determination of future directions for graphics standards efforts and an insider's view of the advantages and shortcomings of the emerging standards.
31 July 1986 1-2

System Development Corporation

TM-HU-900/000/00

Ongoing analysis of the resulting database led to the development of a high

level reference model of CALS interchange requi rements . From this model,

analysis provided a suggested use of current and planned computer graphics

standards, as well as obvious areas for further work in standardization.

Finally, two plans for handling the CALS graphics data interchange problem

emerged: a short term plan, the standardization of a raster based CALS; and

a long term plan, the inclusion of vector capabilities with the raster based

CALS.
31 July 1986 2-1

System Development Corporation

TM-HU-900/000/00

SECTION 2 - INTRODUCTION

This section contains the description of the purpose, the scope, and the approach

to completing the contract.

2.1 PURPOSE

The Computer Aided Logistics Support (CALS) program is tasked with solving

the problems resulting from the current paper-intensive logistics processes

within the Department of Defense (DOD). The obvious solutions require automation

of those processes, and a first step in the automation is a review of the

diverse solutions currently in place within different government agencies.

The results of the survey will then provide input into the overall design of

a unified interface for automated data exchange. A necessary step in the

development of the interface will be the provision for standardized input/ou-tput

of the data. The media of computer graphics, the subject of this report,

will be an essential element jn that interface.

This contract is tasked with identifying computer graphics standards currently

being developed, and areas for future standardization, that may be used to

facilitate the automation desired by CALS. In this report, CALS applications'

graphics interchange requirements are identified, and current, intermediate,

and long term capabilities for applying graphics standards to these applications

are defined. Critical Research and Development issues, resulting from the

analysis of these requirements are detailed and prioritized.

2.2 SCOPE

The objective of CALS is to standardize interfaces between agencies, within

agencies, and between government and industry. Specific areas of investigation

for this effort are the preparation of technical manuals and the storage and

retrieval of product definition data. Special emphasis is placed on graphics

requirements for data interchange and review.
31 July 1986 2-2

System Development Corporation

TM-HU-900/000/00

2.3 APPROACH

In order to fully analyze the requirements of existing CALS-related projects

and to develop a knowledge of particular areas that could use graphics

standards, a database of information about the projects and the general

direction of the CALS program was necessary. The approach was to generate

the database from existing documents, face-to-face interviews, and

questionnaires, and then to perform an analysis of the data by categorizing

the benefits of current graphics standards, categorizing the requi rements* for

interchange of data in the CALS environment, developing an overall general

reference model, and applying the categories of standards and requirements to

the model. From this analysis, areas where current and planned graphics

standar^ds may be used, as well as areas where there is a need for further

research and development, were identified.
31 July 1986 3-1

System Development Corporation

TM-HU-900/000/00

SECTION 3 - FACTORS AND CRITERIA USED FOR ANALYSIS

Factors and criteria applied to the gathered data included information about

applicable government projects currently in existence or planned that address

the CALS problems. Also, the status of standardization of computer graphics

functionality and the future plans for other areas of standardization played

an important roll in determining the feasibility of future directions. Finally,

inherent knowledge gained by experience with computer graphics applications,

along with answers to the questionnaire sent to government projects, was used

to determine critical areas of applicability of graphics standards.

3.1 EXISTING ONGOING EFFORTS

Current solutions to the logistics paper logjam were reviewed and analyzed

for effectiveness and for possible melding into the overall CALS environment.

Common requi rements , problems and proposed solutions are evident from the

detailed reports that emerged from responses to the questionnaires, face-toface interviews, and analysis of written documentation.

3.2 EXISTING COMPUTER GRAPHICS STANDARDS

National and international standards in the field of computer graphics are emerging, with many diverse standards being developed. Section 4 provides a brief description of the graphics standards that are currently being generated

and general points that relate to the CALS effort.

3.3 QUESTIONNAIRE AND OTHER QUESTIONS

An NBS-developed questionnaire was circulated to government facilities that

met the criteria of paper-intensive logistics activities as well as to those

that had begun to attempt to use logistic technical information in digital

form. This questionnai re included a section dedicated to soliciting information

about current computer graphics use and perceived future needs for computer

graphics capabilities.
31 July 1986 3-2

System Development Corporation

TM-HU-900/000/00

In addition to the questionnaire, certain other questions have been developed

to be used during the evaluation and analysis of the data received.

a. Is there a possibility that the data on the screen may be changed?

If so, is the change for 1) redisplay or hardcopy output, or 2) a permanent database change? This question helps determine whether

modifications to an image on the screen are local to the terminal or must be fed back to a permanent database, such as through an IGE'S or CGM interface.

b. Is there a possible need for 1) presentation (report) output or 2)

is the displayed data temporary (working data)? If presentation

output is required, a CGI that interfaces to multiple device drivers

would be useful.

c. Is there a need for auxiliary data (non-graphic) to be saved with

the picture? This question helps determine whether a IGES/POES type

of storage standard is needed rather than a purely graphic (picture)

storage standard like CGM.

d. Is the system a highly interactive one? The answer to this question

determines the need for complex I/O standardization, and may indicate

dynamic picture modification (PHIGS).

9. Is there a need for diverse input devices? If so, a CGI graphics

interface that provides many device drivers may be a suitable solution

f. Will the required input/output devices always be available everywhere

the system is to be accessed, or will downgraded I/O devices be

sometimes used? Again, if there may be variations in I/O devices,

the device independence of the graphics standards is a solution.

g. How much existing "old" software/hardware is there? The amount of

existing software determines the feasibility of converting to standard

interfaces. In cases of large amounts of existing software, a short

term solution may require the implementation of a translation layer
31 July 1986

System Development Corporation

3-3 TM-HU-900/000/00

(Page 3-4 Blank)

between existing software and standard interfaces. If there is a lot of "old" hardware, conversely, there may be upgrades in the near

future, suggesting that the prescribed upgrade time might be used to

convert to the new graphics software interfaces while the system is

al ready being modified.

h. Is there a need for three-dimensional manipulation? Is there a need

for a three-dimensional model? These two questions determine different

approaches to three-dimensional graphics software. If there is a requirement for three-dimensional rotation, but none for an internal

model, then the three-dimensional extensions to GKS are indicated

rather than the more complex system provided by PHIGS.

i. Are there plans for the use of personal computers for standalone use

or as online devices? The use of personal computers in a system

implies limited I/O capabilities, limited resolution to the screen,

possibly no color capabilities, and limited memory avail ablity. Some

graphics standards, such as PHIGS, define implementation facilities

that would not fit in pc configurations.

j. How much Off-The-Shelf (OTS) software/hardware can be used? The use of OTS software/ hardware is a cost effective measure, and standardization

of interfaces leads to the development of such software and hardware.

On the other hand, if unique requirements are imposed on the system,

standard software and hardware may become burdensome, since translators

would have to be written to and from each standard interface.

k. Is there a need for conversion of the output to other devices, such

as hardcopy, large screen wall displays, or a speech synthesizer?

If graphics output is intended only for a single vendor display screen,

the need for a standard output is not so evident as when there are diverse types of output devices that may be required. However, even

the most simple application meant for internal use by engineers may

one day require the output be targetted to a large screen display

for management review. The use of a CGI-based graphics interface

facilitates the addition of other device drivers at a future time.
rr

w\

noti.^:v>J''lPe«]or»v90 ne3r<J

W.ooo',o6e.i;«.*rr ^

Ir'.' to *» xhh^u???^^irr?rig..f?<? «v«^v»4tiOM t#il[ *n. - *

* rCiVtL^%4ft

ifc*r *ftJ lobe^PQu ad xi^ .yfarttvho^ .na-o-iaff •%ro Jtft

,«^ wVni‘iii^ %'5^VsVbKV*^‘*w^Hrt» «iwh«? \t - •.

, J

, * . ,

. - IX '0 < U' |)^f C for it I s'* *

cetf:7*T I^A V

- .«swii W’W .« ’«uw ^' i ^r e'wjir 50f ''-s5i*^r ftRc*um v1

>i’!'

' . -iS wt*

-

- jr^ •, . --r-j' r

\-*^

!»iT(9JnJ nr-ioi tnop .noUlJtr. >»(*oUn9*'^^»»« *'f' »«»•»"'!“?*' • jfc I bills ,S„iUW9MMi*#«*-*'lr.()*M >.Mb«5. . *-)

*' ju r^itt f5 <Hi ‘ fp* 3 , % 5. 4 ^ \ 1 ‘ r ! Mb *.-c.r65p5f» ' 0 »cb

. ^

>b»s«X8 » *'t r**3bn*tos. Unoesw 'o •*« «*X- liMivsfe wrtno »

,n**Si* iRj' ^not.r<yTit»^&»J‘»i«Vr •. MtJmii.^

»l>4^ .<^^^^i^ll"fi“^0«»5r^^3 •^.' fiWI 5C

st:rjg» l‘»•..'^• . ;%«i;ft«nbpl»fiOS X il JM son b:i*o»i J»H

T'-.n

,

.>!(

'"iv „t» .k ^'.9^1? ^tT ^iWSA^fJW: rtxi«iw#<

noh»s<l^9•bn^lV•‘bW^^'•<lr^^^ •*'^ <eWd% v.oi;,

grSph ci^

tied 6 Tgf^Jt J ‘^-iir^/tpfiwaifaifb^ e soT\^Of»*

aoirrUO* Oiabnat? iioaa o3 ad <d a^td oruo*

•ffnicei/

, natfpg x§ ^.al-T® v' aJj^tW ^Jf «s^ <«fi. 1

’ w«V« 'fi9b*v3 DS lofl biabnin i •'Ol b##n artl .

rtAv* *ifivWoH.' b’*TJyaf> ad X»«»

^uu^Tccr^^ laqx^ . ‘i

^ vsa^ faniaJrtf it^ Jnaaia ftO‘^aoMocrft '• \ - * > X®* * P^*Wicfv’* ifi casif5 or laryt ^

sho»*t

vifQ2J’Ji-fl9iL%3f fc baJiaotV af<3 sni«>fTtW w ^

I . iw -^qii rt rte ^ t pn of;, a 1ay*r ,1

tot'^or»B t>a?6<J*^3’a aau anT .iwrva'i

.o«tJ »1U3U1 » 3 » »i»vnb 9S»v*t> *»»Hso 1 o flotJibb* »H 3 tsl»3rns*1
31 July 1986 4-1

System Development Corporation

TM-HU-900/000/00

SECTION 4 - GRAPHICS STANDARDIZATION EFFORTS

This section contains a brief description of applicable current activities

within computer graphics and other standardization areas. In general, each

subject presented here represents a critical part of the CALS effort to provide

automated data exchange, since each describes an effort to standardize one or more interfaces.

4.1 GRAPHICAL KERNEL SYSTEM (GKS)

The Graphical Kernel Systan (GKS) is already U.S. and an international standard.

It defines two-dimensional graphics functions at the user interface level,

providing the programmer with capabilities to create graphical output and

accept graphical input from diverse graphical devices. In conjunction with

the GKS functional specification standard, calling sequences to the GKS functions

are also standardized for common programming languages (language bindings).

4.2 PROGRAMMER'S HIERARCHICAL INTERACTIVE GRAPHICS SYSTEMS (PHIGS)

The Programmer's Hierarchical Interactive Graphics System (PHIGS) is another

user interface level graphics standard. It provides a richer set of capabilities,

including support for CAD and process control applications, in a dynamic,

highly interactive manner. An hierarchical database architecture is at the

heart of the PHIGS design, with an accompanying ability to archive and recall

from storage these structures on one or more workstations. The PHIGS standard

is currently in development.

4.3 COMPUTER GRAPHICS INTERFACE (CGI)

The Computer Graphics Interface (CGI) standard, currently being defined, describes

a standard method for exchanging device-independent data and controlling commands

between applications programs and graphics devices. The CGI is designed to

be a standard interface, on top of which graphics applications may be written.

Conceptually, the CGI lies 'underneath' a GKS implementation, and talks directly

to graphics devices.
31 July 1986 4-2

System Development Corporation

TM-HU-900/000/00

4.4 COMPUTER GRAPHICS METAFILE (CGM)

The Computer Graphics Metafile (CGM) standard defines the data format for

transfer and storage of graphics data and commands. The contents of the CGM

represent snapshots of images generated by the applications program, that can

be stored and re-displayed at other devices. Along with the CGM functional

specification, there are three standard encodings for the CGM: character

encoding, binary encoding, and dear-text (human readable) encoding.

4.5 IGES/PDES

The Initial Graphics Exchange Specification (IGES) and the Product Data Exchange

Specification (PDES) are definitions of data exchange formats used primarily

with Computer Aided Design (CAD) systems, to provide transportabi 1 i ty of product

data, and its associated display, from one CAD system to another. IGES is

currently a standard; PDES is under development.

4.6 BINDINGS

To provide portable application software in general, programming language

interfaces to functional standards (bindings) must be standardized. Specifically,

for applications interface standards such as PHIGS and GKS, standard bindings

to frequently used programming languages must be defined and utilized. As

new computer graphics functional standards are developed, correspond! ng bindings

will be generated. Similarly, when languages are updated, or new languages

defined, each functional standard should be reviewed for possible new bindings.

4.7 CROSS LANGUAGE BINDINGS

Multiple-language facilities require access to a functional area such as graphics

through more than one language interface. Standardization efforts just getting

under way will help resolve this problem. The definition of a common languageindependent procedure calling mechanism and of common data types will provide

access in a portable, standard way. The standardization of these common elements,

however, will involve a thorough survey of existing methods and data types,

and must be accepted by the programming language community.
System Development Corporation

31 July 1986 4-3 TM-HU-900/000/00

(Page 4-4 Blank)

4.8 COMMON STORAGE FORMATS

For graphic data exchange, common data storage formats provide a means for

transferring a picture from one system to another. The systems do not need

any commonality except for the software that reads/writes the picture storage.

The computer graphics metafile standard (CGM), with new extensions currently

being defined, provides such a standard data exchange for graphics data.

4.9 COMBINED TEXT AND GRAPHICS

New standards are being developed to define the combination of text and graphics.

These standards must take advantage of existing graphics standards for I/O

and for storage, if a more general use of the standards family, such as CALS

requires, is to be achieved.
w-w«?':w« ...

' ij.,)

>JfS

I

' m tfdft

no/Qfi

•uTiR. c,3AF«»a jcrinu .ivJP*'

!TAM(104 iSMOTZ MOHMOO

,-^»l

^w.'V VoW -3

i

'

' fc * * #. ^ ' ^liii

|i"'<.»^l t ,.

' .»ntod^»i9^ ftv«t»r/

T

b!.<;«Jvfh, *><$ c^t$r ;«^t ( . •** ’ **.

.

,. “. .. i3lH<>ASS ORA TX3T^ 03«Hrt03 ^ ^

’^Mhifl((JsfM»52R9>4e ixotjinKifWS *H3 ir^b OJ l>*CCl*y*b |b>9<l tb-'tbfltJt W»t1

« W. J^^ScV^klftlchans*

**:!•?«* I i2«-''3?.,^’-?5^‘ A^=stt*3i?1 ^SLfAijr-

^ gB. ,.3» •d 0^ It

Cofti^otMT ^CA0J <<? ?Ai>fC- , c in5{J0i*tt^; iv V ar^uct

jni Ilf r*or*alfd fUpt*., vs"*m t® imh?-' Itfap-n’

currtflli/ tt.,‘.igtft^l »0n U vng«r

.

4.6. aiNomv - '

To- prc^ldt l.ppHCAl^Cni r» r 'TR?i^r^t, ^'4 ^Afl944^*

" ti

I' Interface? to fttWCtto^Ji* ft^gft i* *3n4ar'74«^ Sd^.ficin/,

'or f op^ ’ c I * * : ns Tottf^fct ft4j*dirss <i *‘*f!*5 mM itindsrd

'‘0 fpt^uap'*’/ pro-2*^.<if n^ 'pr^i.j'- » f:\iiX

^ gt*'-nr4 (ttHttid. ^,A4

7?iew :.itnt>ut<rf |rav^*o j cdi^ftS|k>roi‘tifJ^indtt9i

vf*0; b« |«ni?<^Ar<a. - .p*a 4ev • ’if

,/la; r /uncH^ns* ‘ 'or* ntir offtd ngf.

».» caosS' U'/'; iAis BtNoiy^?^ . , . ,^

><ut tip!'#- V4p«|t*4 9Rj ‘*eniir# >c :tii. f s ^>nctional arit^ *f.^ ipftics

v.'rwjn mor* t^S'l^ «!» 1 afF^ j '.» inUr'ice. I«B«rJ*r-4 Uo« ''Xn sfrortf ju»C i'*tt1ng

irMar «a--^H1"'> .>'-:. a'i.>'((» tb'; 4*fV^frtW'of < c'fiwo'* Itb^icatT»; - '

' ,».,,*

;p»^pc>dUf’i> Cii •‘3r: Vt iat4 tys^ti uHlI frr Pyldfjf’

;:ictc‘>s tti^lCfcai^vinMdlzation of iHgtp:' c1«oiintA,

. hD»^ibrari. a thof-oti^ 8uf*v%>‘of tt1#ttng ,i»(et^dP$‘4od’ dati' ?

<n<5 iwBvtM »cf.'-»i?t<Hi b

y' *fti» •r'vjrajts'iri^ cswwonity. ^|

• •. ’!''

JBF
31 July 1986 5-1

System Development Corporation

TM-HU-900/000/00

SECTION 5 - SURVEYED PROJECTS

A common reference model, shown in Figure 5-1, may be used to further understand

the general interfaces that apply, and to demonstrate the areas where computer

graphics standards may be indicated.

For each project and system surveyed, a brief description of the project is

given, followed by observations and suggestions limited to utilization of

applicable computer graphics standards, particularly in relation to the reference

model. Key words and phrases are added to the general description in brackets

(e.g., [raster format]) to highlight appropriate points.

5.1 PRINTING AND PUBLISHING SYSTEMS

5.1.1 AIPPS/600S

Warehouses full of pages [raster format] that need to go into a database are

the inputs to the 600S system. Although they desire input to come from CAD

systams [CAD], in vector format, for now "history has swamped us". They have

three modes of output: laser printers, traditional typesetting equipment,

and CRT screens [multiple device output].

Although it was felt by representati ves of this project that the format the

data arrived in, and what was required to be done with it, were not important,

since they could do whatever was needed, there seems to be advantages to some

consistent format for their data [image storage].

5.1.2 APRS

This is a pilot program that could tie in with EMPS (see below). It is a system that produces tech manuals (TM), tech bulletins (TB), changes to TM'

s

and TB's, depot maintenance work requi rements, and repair parts documents.

Input data comes from word processors, though they report it is expensive to

write translator programs; CAD systems, of which they have several, including

AutoCad output in IGES format; typset reading optical character readers, a near- future plan, so they can read from the AIPPS database; and, in the future,

DSREDS [diverse input sources].
31 July 1986

System Development Corporation

5-2 TM-HU-900/000/00

HETEROGENOUS

DEVICES PROVIDE

NTERFACE TO

USER I/O

Figure 5-1. High Level Reference Model of CALS Graphics Requirements
31 July 1986 5-3

System Development Corporation

TM-HU-900/000/00

Internal formats in APRS are used for 1) CAD data, 2) raster graphic manipulator

output, 3) media converter output, 4) word processor output, and 5) mag tapes *

They modify the raster images almost all the time, but sometimes have to go

all the way back to the CAD system to make the modifications [raster format]

[vector format]. They feel that raster data formats are too large for on- line manipulation. They need something fast and structured. Although data

compression techniques help, the compression formulas slow down storage and

retrieval. Their raster storage requirements are enormous.

They recognize a common document maintenance problem: to store the original,

a backup, and changes (both the original and a backup) [configuration management].

They use non-standard graphics languages and hardware, with no raster standard,

no raster to vector conversion capability.

5.1.3 NAPPS

The Navy Automated Publishing and Printing System is used to develop training

manuals for NTSC at Orlando and CNET at Pensacola. They want to be able to

batch process their system, and want transportabl e, identical pages. Their

system is pc-based, "not too esoteric", since they need blue collar composition.

Associated with NAPPS is the Logistics Technical Data Automation system, which

is converting aperture cards to optical disk [raster format]. They have a huge installed data base, and can't afford republishing. The Navy is currently

acquiring CAD/CAM capabilities, covering five different engineering disciplines,

to provide support for the preparation of technical documentation [CAD]. Since

they are providing services, they don't want to maintain the database.

5.1.4 NPQDS

The Navy Print On Demand System (NPODS) has the problems that technical manuals,

milars, vellums, and aperture cards [raster format] are input to print static

manuals, which are only paper copies. Their solution is demand printing on a
31 July 1986 5-4

System Development Corporation

•TM-HU-900/000/00

laser printer. They feel there is no sense in offset printing. The original

is used for mil specs, and standards. This system should be operational before’

October. A major problem they perceive is that data transfer rates for raster ^ images are simply too slow. Their work "brings the 9700 to its knees".

,

This effort includes a contract that requires the conversion of aperture

cards to optical disk [optical disks]. They estimate a cost of 15-17 cents

per card. The drawings are up to E size. The need for optical disk standards

was stated.

5.1.5 ATOS

A Wright Patterson Air Force Base system, the Automatic Technical Order System

(ATOS) is currently in Phase 1, which is a computer-aided publications system,

similar to APPS. Phase 2 will be taking data from paper, mag tape, and

contractors, in a predefined format [diverse input sources]. However, it.

will be at least a year before this contract begins. They feel they "should

be storing code, not images."

Phase 2 will include graphics workstations, with pan/zoom, cut and paste,

2-dimensional graphics capabilities, 1000 x 1000 resolution, 8 shades of gray,

no color (but the database should be expandable for color), the capability

for print-on-demand on a variety of printers, and input accepted from 100

different contractors. In addition to the workstations, there will be printers,

both high and low speed, that can handle foldout pages and a minimum of 300

pixels per inch [multiple output devices].

Perceived ATOS long range needs are: a) an intelligent database where other

AFLC systems can extract and supply TO information used to produce printed TO

page [image storage]; 2) a system to convert raster pages to this database,

since there are 20 million pages; and 3) ATOS database support of AFHRL

enhanced presentation and interactive maintenance support [product data].
31 July 1986 5-5

System Development Corporation

TM-HU-900/000/00

5.2 PAPERLESS PRESENTATION AND MAINTENANCE AIDS

5.2.1 ME I PS

The Militarized Electronic Information Delivery System (MEIDS), from the U.S.

Army Ordnance Center at Aberdeen, is attempting to develop generic hardware

to deliver text, graphics, and visuals [text and graphics]. Plans are for

the "electronic page", with interactive capabilities, color, motion, and voice

activation. They require text, graphics, and line drawings, with a distributed

database and interaction between publications and communications [diverse

input sources] [multiple output devices].

Input is scanned bit maps [raster storage], with some conversion for foldouts.

Output is CRT display, and structured alphanumeric data. They also

feel that the bit map approach requires HUGE storage capacity, but they don't

want to base their design on the breakthrough technology of current raster

to vector conversion systems. They decry the lack of a standard for optical

disks [optical disks]. (ANSI is working on a large format, but MEIDS needs a small disk.) The cd rom access speed is too slow; MEIDS needs high speed

i nteroperabi 1 i ty.

MEIDS needs a graphics standard that permits economical porting to other hardware

and for hardware upgrading [image storage] [portabi 1 ity] . They are interested

in the long term maintenance of images [future enhancements]. They do not

currently have 3-dimensional graphics needs, but mentioned that they may in

the future. On-screen manipulation requirements are limited to pan, scroll,

and zoom.

5.2.2 REAM

The Personal Electronic Aid for Maintenance (REAM) is a closed system, and

there appears to be no obvious need for standards, other than human factors

standards to help provide appropriate interfaces for the user of the system.
31 July 1986 5-6

System Development Corporation

TM-HU-900/000/00

5.2.3 JPAPS

Another Army system, the Job Performance Aid Production System (JPAPS) is a two phase procurement. Common features of the current systems are text files,

graphics files, and document design features [text and graphics]. Due to

changing display technology, refresh speed and memory enhancements, they expect

to be upgrading almost immediately [future enhancements]. They "need to get

information on the screen in a hurry".

Phase 1 will involve [multiple output devices] [diverse input sources]:

• Research and development - techniques for displaying large schematics

and line drawings - on small screens with low resolution (70 lines

per inch). This includes conventions for overcoming the minimum

resolution for printing 200 lines per inch. • The identification and developing of authoring tools, new and existing. • Analysis of 'common authoring requirements for existing technical

information delivery systems. • Applications of artificial intelligence. A first attempt will be for

indexing and accessing information (tables and cross references).

Phase 2 will involve the development of software, some hardware, for proof of

concept.

5.2.4 EMPS

The Electronic Maintenance and Publishing System (EMPS) is a project for

transferring maintenance information for the Patriot system to video disk

[optical disk]. They use read-only video disk and have no inhouse capability

for mastering [future enhancements]. They are doing display-aided maintenance

pictures, using a digital technique and high resolution screens. The system

is IBM PC AT based, with software in Pascal and using dbase II.

They perceive the following needs for standards:
31 July 1986 5-7

System Development Corporation

TM-HU-900/000/00

• Input: subject matter, formatting, content, composition, media

(conventions for the input of data from contractors)

.

• Authoring; line drawings versus video, computer-generated text, interaction. • Production: color use, presentation methods, use of motion and audio,

formatting. • Software: common language for product! on/authori ng software. Currently

programming is all being done in C; they anticipate the use of Lisp

for AI related projects.

Storage is of display format, graphics, pictures, and text [image storage]

[text and graphics]. Archiving requires input standards for contractor

information, change control procedures, maintenance, and storage.

e The optical disk needs standards in file design/ formatting, interface loading

and changing, and hierarchical data structures.

Standards for delivery include display si ze/ resol ution, color, input device

design, textual criteria, design of portable terminals, database safeguards,

database design, and human interface requirements [multiple output devices]

[diverse input sources].

The system will be evaluated by USARMTE at Ft. Bliss in January 1937. Plans

are to dovetail EjMPS and APPS.

Their input is from Cromemco's AutoCad software. They want to be able to go

back to the CAD system for major changes [CAD]. The maintenance function

must modify almost every engineering drawing.

5.2.5 NTIPS

The Navy Technical Information Presentation System (NTIPS), being built by

Northrop, involves:
31 July 1986 5-8

System Development Corporation

TM-HU-900/000/00

• Computer selection of modular specs • Automated preparation of contract packages • Automated authoring.

They need optimal association of text and graphics for improved comprehensi bi 1 i ty

[text and graphics]. They don't want to tell the user at the authoring terminal

how or what. The system is designed for shipboard delivery, with eventual

voice input/output [multiple output devices] [diverse input sources]. I.t is

to provide display manuals and training manuals. There is a three services

study for the requirements for this system, (see CBAT below)

Technical issues to be resolved include:

• Standards for acquisition of data • Repository of digitized data for print on demagd • Close association of text and graphics.

They consider a data-exchange standard very important [image storage].

The Navy has proposals for the content, style, format, and medium for data

products. Also, they feel that test routines are absolutely necessary

[validation].

5.2.6 C3AT

The Computer-Based Aids for Troubleshooting (CBAT) project is a 5 year Research

and Development effort. It will be coordinated by IMIS (WPAFB) and NTIPS.

It is required by CALS, to document the advantage of a paperless system over

paper, and to gain user acceptance.

This system presents user-ori ented technical information, in a six

part approach:
31 July 1986 5-9

System Develooment Corporation

TM-HU-90Q/000/00

1. Establish a workstation for developing portions of electronic

presentation

2. Expand the database for apx-64 (fault detection)

3. Demonstrate in the field the feasibility of electronic delivery

4. Establish the feasibility of interfacing el ectronical ly presented

information with in-system diagnostics

5. Use AI techniques to improve the organization

6. Define functional requi rements.

The first phase, to establish a workstation, has just begun. It involves

off-the-shelf hardware/software compatibility, with Unix-based tools. They

will be using a Sun Microcomputer , and NTIPS and AFHRL software.

The second phase, to expand the database, includes an initial apx-54 electronic

database, on loan from AFHRL [future enhancanents] . It is an operational

apx-54 and a pc, with fault pc boards, troubleshooting tools, and text and

graphics [text and graphics].

5. 2. 6.1 CMAS/IMIS

An Air Force system, the Air Force Human Resources people are developing CjMAS

at Offett AFB. It uses voice and software programmabl e function keys [diverse

input sources]. A novel idea is the use of peel-away graphics. In 1987,

phase 3 begins. The biggest risk is identifying information flows (information

engineering analysis). This system is to be used for new weapons sytems.

5. 2. 6. 2 ITDS

The Improved Technical Data Systems (ITDS) is developed by Northrop. It is

aimed toward solving the question: Where are we going to be in IDD*'? And

then to identify, develop, and adopt the standards to take us there. One

main problem is raster versus vector. They perceive that interactive electronic

delivery, portable devices, and several output devices are part of the future

[multiple output devices]. They recommend GKS for graphics.
31 July 1986 5-10

System Development Corporation

TM-HU-900/000/00

Interfaces to be looked at are: 1) producer system and archive [image storage];

and 2) conversion coding of existing paper TO's and archive [raster format].

They expressed a need for fast graphics. IGES is currently used as a design

tool [product data], and CGM could be used for portability, since they are output o-nly [portability]

.

In the future, the engineering database from CAD/CAM systems will be the main

input to technical publications [CAD], The direct use of engineering drawings

saves money (the use of high speed vector graphics), and provides quick retrieval

of information (zoom and pan and color).

They are looking at 1280 x 1024 touch panel color displays for the future [future

enhancements]. Currently they use a 5i2 x 512 flat panel display.

5.3 AUTOMATED DATA REPOSITORIES AND PRODUCT DEFINITION DATA

5.3.1 DSREDS/EDCARS

The Army' s DSREDS and the Air Force's EDCARS system supply engineering,

procurement, and drawing storage. For input, they use scan/digitized existing

drawings [raster format], with interactive file retrieval. They use CAD support

software for an engineering workstation that provides a look at the drawing

in graphics so that changes can be made and stored. The images are stored on optical disk (juke box, read/write). They use 3D for manipulation of the

images, with only 2D storage. There is a CAD/CAM interface to the disk, with

a raster graphics interface to the QA terminal.

Conversion of aperture cards is a 6 - 8 month effort to store most of them.

They use IGES and CCITT G4 (raster) standards. They convert the 2D IGES file

to raster and store 3D IGES by bit stream only. They are using IGES but only

need 2D, non-modi fi able images. So, they could be using CGM if an IGES to

CGM interpreter was available.
31 July 1936 5-11

System Development Corporation

TM-HU-900/000/00

5.3.2 TD/CMS

The TD/CMS is a system of 57,674 lines of undocumented code. Rockwell, in

1965 wrote the original code; in 1976 they rewrote it. However, they provided

NO documentation. The code works, but no-one can modify or extend it. It is

written in Cobol and Assembler for the IBM 4341, with 137 input data elements

and 93 output reports. It is based on card input, and mag tape and card output

which provides a pull tape for archival. In the future, they hope to provide

hooks into DSREDS [portabi 1 ity]

.

The software trees down, but not up. They need this capability. They have

already spent $600k and they still can't trace the code. A preliminary

functional description of the redesign will be available this fall.

5.3.3 EDMICS

The Engineering Data Management Information and Control System (EDMICS) is

the Navy version of DSREDS/EDCARS. It is,a future product of the CALS initiative.

It is the centerpiece of the Navy's answer to the CALS initiative. They want

standards throughout. They want to represent images digitally [image storage].

They need database management standards for structure and query languages.

At the conceptual level, it will be the same as EDGARS/ DSREDS. But is different

in that it will specify more standards, and it will have more interfaces.

The specification is in draft stages right now; it will be released to industry

for comment soon.

They are looking at vector versus raster, with the initial opinion that they would

like to get it 100% into vector mode [vector format]. "The Navy needs vector

mode". There is a relationship to the aperture management (digitization)

[raster format], with a proprietary compression algorithm. Soma Navy locations

use digital based optical systems for scanned drawings, and Portsmith, NH has

the data management initiative. There will be an attempt to exchange files

[portabi 1 i ty] with DSREDS. INFODETICS is working on decompressed/recompressed

format into CCITT.
31 July 1936 5-12

System Development Corporation

TM-HU-900/000/00

5.3.4 PDDI/GMAP

The Geometric Modeling Applications Interface Program is a system to use product definition data. The GMAP builds on PDDI. They are attempting to

replace engineering drawings [CAD] with an electronic interface between

engineering and manufacturing. The results are a departure from IGES, since

it contains non-geometric information (features, tolerances).

The end deliverable is to supply CAD feed to USAF/SA-ALC for IBIS (Integrated

Blade Inspection System) and RFC (Retirement For Cause) inspection system.

They are working with PDES [product data] to define entities in generic form,

not purely for the aerospace industry. 2D and 3D requirements coexist, but

they feel it is not redundant to have both. They need a exchange format that

is machine-readable, like IGES but smaller, not human readable [portabi 1 ity]

.

5.3.5 EDASRE

This DLA system, not yet procured, will be a part of the Navy procurement

EDMICS. They receive 14 million aperture cards [raster format] annually.

They may need more interfaces than EDMICS, to the Army, the Navy, the Air

Force, and to industry. Some of their drawings need modifications. The DLA

doesn't update the drawings; they normally receive revised drawings.

5.4 SUMMARY OF PROJECT NEEDS

5.4.1 Keywords

As may be noted by the keywords found in brackets in the above section, there

were several common requirements and conditions that became apparent. This

section will attempt to give a brief description of possible standards that

could be used to satisfy these requirements and conditions. In some cases,

there are no existing standardization efforts; these cases pinpoint areas

where further development is suggested.

[CAD] - IGES with PHIGS or GKS to provide device independence
31 July 1986 5-13

System Development Corporation

TM-HU-900/000/00

[configuration management] - procedures (to be developed)

[diverse input sources] - CGI, GKS, PHIGS (all device independent standards)

[future enhancements] - GKS, PHIGS

[image storage] - CGM, PHIGS Archive File, IGES, raster storage format (to be

devel oped)

[multiple output devices] - CGI, GKS, PHIGS (all device independent standards)

[optical disks] - formatting standards (to be developed)

[product data] - PDES with GKS or CGI for device independence

[ portabi 1 ity] - all standards in general

[raster format] - enhanced compression techniques, standardized format, rasterto-vector conversion technology (to be developed)

[text and graphics] - standards currently in development

[validation] - validation test suites and procedures (to be developed)

[vector format] - GKS, PHIGS

5.4.2 General Notes On The Technical Manuals Area

In general, the technical manual requirements are for a common DOD approach

to SGML, with a committee to define the requirements of publishing.

For product definition data, there is a need for IGES to transport between

CAD systems, for CGM to transport to publishing systems, and for a raster

standard to store the print-on-demand images.
11 July 1986 5-14

System Development Corporation

TM-HU-900/000/00

They need confidence in the standard products oh the market. This implies

strong, reliable validation procedures.

Configuration management must be a separate system from repository and

publication systems. A data interchange standard is needed. A standard

data access would be beneficial, such as a standard query language.

They need a raster- to- vector conversion capability. Product definition data

is not needed to be carried along. They need a family of standards. They

are looking at compatibility issues between IGES/PDES and the graphics

standards. They want text and graphics capabilities in a single standard.

5.4.3 General Notes On The Data Repositories Area

There is an expressed need for textual data standards and database standards.

They agree there is no alternative to IGES as a product data definition standard.

They stress the need for validation of IGES translators.

5.4.4 General Points On Graphics

There is a short range need for saving images in raster format, especially in

those data repository areas where historical aperture cards are voluminous.

However, for long range planning, they agree they want to transfer to an allvector format. Identified problems with raster include configuration management

problems for modifications and the possibilty of maintaining two or more versions

(raster and vector from CAD systems), the size of the storage required, and

the time to update the display with raster data.

They need validation for the standards' interfaces to provide security and

portabi 1 i ty.

There are some places where IGES is used that CGM could be used; however, in

most cases both versions are needed.
31 July 1986

System Development Corporation

5-15 TM-HU-900/000/00

(Page 5-16 Blank)

There is a continuing need for potential upgrade to future hardware; this

implies the building of applications tools on top of CGI.

A single standard is needed for combined text and graphics.
1

nt't5'*?wr*C''^ n*9jl'^£

I" O0\3Q'^^f>'?'C'’*‘’<

« fiftita a5*^ se*'’)

uaV«lDOoen* ;',‘r j)C

m-M

1

,V Iff u

i»r’ -•*-•" ' 1 rivf '•,|*“ tt A *. "dt.

«! ^Ney '??i^«flrirt|*r!:--.- »i?l>r ton««*«W'tC- l-'if. r. .;.ct f»f It!'<'!>*-,*^‘

« ... «!:«, - ' . •. . .

i K’''Hcrt ' IP Cirf-vi t1cn?|* *\itp Thtr.^^

irt Voo'*.' iitj- Ujii|«l ''^Xm , VfSCl .l ’ -‘

-' - . '• ’ ' .'^‘. JS- The.*4«mt ;r»:'* .: ^ ;*••.;€ i*‘. . .sf'<

. 5rMLjii''

‘ '. ,-H^ 1 u^i:u^.: 'ji

^-'•‘f««(^'fr'iin : .t-'tp . ... jl/Jji;^,ju«fc

" ' T. y^( ' < .

'

/• ; ,K «P’—

in^iK th^rt ; '>-ti- a 1 * v'^ mX 4 % i ^*v=r d'

Th€y i'!»*f$t :r»« r, i# *5t*

i:. ‘

,

' ^ ^ ;-4.3 *«i(?€r|?

^

1»'* , .. i .

' '

rhert' '*'r Wf<«d ^ii

those Idta , s<«^M ! f

' * ‘c

i *' -arti/it* .^tpes '

•>ff cjiinii .4f*

*or lo»tg r/r,^ tntyr.

^

Idiiit*^^ •rT^'P^^* ^ ‘ ‘ M|afi :iyn

'Qif’ik^dW'* T.fi»l'i*5M 'Hff ‘w a«*.,p>5r4 ‘iion1-^1 , iK* su€ p4 in

to vp^f tf>* rj'{«r' 4#|».,

- %' \v

> .J *

-

J:4iy f9ti* fn

portxb^Uiji,

. H'

'k'“ , . snt i-'XHo otl^di *'y: > *t t-hut t1 aj4di ’«^v4r,

4iOSt Citts ' nrr»'

,

"i

»w i
31 July 1986 6-1

System Development Corporation

TM-HU-900/000/00

SECTION 6 - REFERENCE MODEL

Figure 5-1 is an attempt to show, on a very high level, the interfaces described

by the surveyed projects. The circles in the figures represent software systems,

and the rectangles represent data formats.

The major software systems include database management systems (A), CAD systems

(B), document preparation software (C), and other graphics applications software

(D). In addition, there is usually some software interface to the diverse

graphics output and input devices (E).

These software systems interface with various data formats, including the

data repositories (1) which store image representations, the engineering drawing

database (2j which is made up of product definition data and graphic data,

and scanned raster image data (3) which is primarily data from aperture cards.

Vector to raster conversion software/ hardware (.4) is used to transfer the CAD

data to raster devices and to the data repository, and raster to vector

conversion software/hardware (5) may be used to convert some of the CAD data

output to vector document preparation format.

Within CALS, many format conversions are required. In almost all cases, format

conversion in one direction can be performed automatically because the new

format contains less information than the old format. For example, a 2D vector

model contains less information than a 3D model; therefore, the 30 model can

be automatically converted to a 2D vector model. Conversely, however, a 2D

vector model cannot be converted to a 3D model without the addition of

information which requires human interaction. Figure 6-1 illustrates this

conversion hierarchy.
31 July 1986

System Development Corporation

6-2 TM-HU-900/000/00

a

tn

CO ^ o o

CO _ — o X X

CL a. o o

w Q «

o— CO CO —

3 LlI O

3

X

Z

o

Q o O

d H— < o hQ o CO o

O CO < o

CO

Ld

3

O

Ld

QC

O

<

QC

Ld

<

IS3

Ld

CO<

cn<

Ld

CO<

CD

<

Id

Q

O

ir

LdI—

CO<

QC

Q

Ci; q: Ld

a o ^

H- QC QC O O Q Lti Q Ld Id

li > >

O Q Q

o CO

. • -rf"

cn<

13

Id

QC

3

— tr X <

o 2

QC

3

X O Ld 3 1—

Ld

CO X o

Id <

I- IJCO CO a

Q o

O X

X 1—

h- Ld

Ld >

> o

3 O Ld

Id d <

d < m

3 IS CO o

CO o < 1— < H- Ld 3

Ld 3 Lx. <

Lu <

Figure

6-1.

Conversion

Hierarchy:

Automatic

and

with

Human

Interaction
31 July 1986 7-1

System Development Corporation

TM-HU-900/000/00

SECTION 7 - RESULTS OF ANALYSIS

This section details the results of the analysis previously described. The

results are divided into two plans: a short term method for quickly

implementing CALS philosophy and a long term plan for full implementation of

the optimal CALS architecture.

7.1 SHORT TERM AND LONG TERM SOLUTIONS

From the resources investigated, two major graphi cs-rel ated opinions emerged,

in very clear and consistent statements throughout each project:

1. There is a tremendous backlog of data that must be accessed,

manipulated, and output, currently in raster format. Much of this

data is archived on aperture cards that must be digitally scanned.

Data in this format will be a part of the CALS database forever.

2. Many of the current and future graphics data inputs will be originated

at a CAD or CAE terminal that has capabilities for manipulating and

storing 3D solid product models and/or an image in vector format.

The database capabilities and engineering facilities provided by

such systems, as well as the current trend towards lower cost, make

their use highly desirable for production of the original drawings.

These two facts negate any attempt to determine a single, inclusive format

for all CALS graphics data. Any solution must be able to handle both raster

and vector types of images.

Vector images can be translated into raster format. In fact, in most cases,

during display of the image on a graphics device, they are converted to a raster representation so that the hardware graphics engine can display the

image. However, the reverse is not true, given the current state of the art.

Although the command-and- parameter format of a vector image, such as "draw a line from point one to point two", can be fairly easily turned into a series
31 July 1936 7-2

System Development Corporation

TM-HU-900/000/00

of on-off values for a raster display memory, it is much more difficult to

recognize that same series of on-off points as a contiguous line. A major

problem exists in simply checking the resulting output for validity and

completeness. There are several industries that are attempting to resolve

this problem. While raster to vector conversion is cost effective for drawing

modification in some cases, currently there is no cost effective solution for

document archival.

7.1.1 Short Term Sol uti on The least common denominator in terms of technical difficulty is the raster

format of documents. The existence of raster scanned documents does not

preclude the capture of hand-drawn images, CAD-generated documents or alphanumeric databases. Therefore, until standards are available to handle

vector- formatted data, it is recommended that a raster based CALS system be

standardi zed.

In such a system, CALS would store a raster facsimile of all DOD documents.

Any document could then be located and transmitted anywhere in the world in

seconds for display or printing. As standards for more complex data elements

become available, CALS can be modified to store, retrieve, and integrate them.

CALS could also store and retrieve binary files that do not conform to a standard, although it must be recognized that such files will be of limited

value after time, due to inevitable modification of the systems that created

them.

Raster image databases should be easier to manage than text, graphic, or

inventory databases, since raster images contain fewer internal structures.

This means that raster databases will not require distributed database

management systems, enhancing the possibility of fast implementation.

Although much discussion by the surveyed projects has revolved around the

problems of perceived slowness of display, and cost and amount of storage

required by using only raster as the database format, current technological
31 July 1986 7-3

System Develocment Corporation

TM-HU-900/000/00

trends are towards cheaper storage and faster decompression and raster display

devi ces

.

This short-term solution allows for the accommodation of current archival

images as well as providing for the gradual development of the long-term

solution described in the following section, without impacting the day- by-day

performance of the projects.

7.1.2 Long Term Solution

CALS should support both raster and vector formatted data. The proposed long

term solution is, while continuing to keep raster scanned documents in raster

format, to migrate all incoming data to vector format. This means to encourage

originals to be prepared on CAD systems, with a ’standard format for transferring

and storing the vector version of each image. This format is al ready defined:

it is the CGM standard format for the graphics operations, with a backup of

IGES/PDES for the product definition data requi rements.

In addition to using the established CGM and IGES/POES standards for data

storage, there is a need for standard interfaces to the target display devices.

Many situations, from the soldier in the field attempting to upgrade or maintain some equipment, to the logistician in the office updating some

information in a document, to management personnel briefing DOD Chiefs, require

diverse devices for display and input to the data management programs that

provide these capabilities. The emerging CGI standard, in addition to the

GKS and PHIGS application-level standards, can be used optimally to provide

the required device independence. A secondary benefit of using these standards

is programmer portability for application software devel opment/ modi fi cation,

and the cost benefits of increased availability of off-the-shelf hardware and

software.

There will be, then, a standard storage base of images, in vector format if

possible, that may be indexed, retrieved, and modified if necessary. The

primary representation of the image, however, will remain the raster formatted

version. The last step of every retrieval will be a raster! zation step.
31 July 1986 7-4

System Development Corporation

TM-HU-900/000/00

This solution provides both a quick, global access to documents and images,

from the raster version of the image, and flexible storage of the same image

in a format that is accepted from contractors in a standard way. The perceived

configuration management problems with a dual representation method have actual 1 been dealt with over the years as multiple versions of documents were created

and maintained. Older versions of a document can be controlled in raster

format while newer versions, rewritten or amended in alphanumeric or vector

format, can be controlled in their new format. Controlling these multiple

versions of documents is a capability that CALS must have whether the versions

are in the same format or different formats.

As described above, reformatting such as raster to vector conversion, requi res human input while the reverse vector to raster conversion can be done

automatically. Reformatting requiring human input should be controlled as a new revision while automatic reformatting should be considered part of the

output process. Because the output process can have several conversions with

intermediate buffers, CALS must be designed to accommodate multiple automatically reformatted versions of a document. If automatic reformatting requires

extensive computing, the intermediate results may be retained until the source

document is changed.

CALS must also accommodate multiple identical copies of each document to

provide spatial diversity for survi vabi 1 i ty of the combat readiness document

base. CALS must have an integrated, on-line backup capability.

In addition, CALS must manage redundancy to speed distribution and conserve

bandwidth. Copies of frequently used documents should be kept at remote

locations to avoid frequent retransmission of recently received documents.

To the user, these remote duplicates must appear transparent. That is, the

user should have the same assurance of currency, and use exactly the same

locate and access commands as the user would use for centrally located documents

The system should automatically select documents for remote duplicate storage

and automatically choose the most accessible copy on demand. The foregoing
31 July 19S6

System Develocment Corocration

7-5 7M-HU-900/000/00

(Page 7-6 Blank)

requires that CALS maintain virtual synchronization for multiple spatially

distributed copies of documents.

It is of paramount importance that CALS have a well defined release mechanism

for documents. The older manual systems could easily identify the release

copy of a document and could easily require that all copies be made from that

master copy. The CALS document release mechanism must identify the master

copy of each released version of each document and assure that all copies are

made from a released version.

The CALS document release mechanism will separate released documents from

documents undergoing revision. While CALS may or may not contain preliminary

or working copies of documents, such documents must be separated from the

released documents CALS is intended to control and distribute. If CALS

contains only released documents, the release mechanism becomes a CALS input

requi rement.. If CALS contains released and unreleased versions of documents,

the separation between the two types of documents will be extremely important.

CALS must maintain multiple versions of documents because each release

describes parts for equipment that may still be in inventory. Because the

cost of archiving CALS documents will probably be very low, because CALS

documents will be well controlled and archived documents will be easily

identifiable and not be confused with documents in day to day use, and because

equipment previously in inventorymay be recalled to active service (or may

be in the hands of the enemy), CALS should maintain an archive of all versions

of all documents entered into CALS.
1

, «''/

.!( VWwsofavsa msJZ'iZ wmnm^ - («.„ U w.) * t1N1s n^on pravidin <t quIck, qIoimI t

- locufl^enti ifttJ , i

* • OfTi D«yil5pn»rit Coiwr*t1

aaei %

' " - ' a^fjsnujoob isifqoo bfJuoHliTa^

Iri i„^oninjt th|t fn‘ ecctJ>tt4 fron cdutfttct i**^ 4 ttMn^ir4 V4/, p rcfti

1 1 on v<^<in a «:*j<i 1 dcta#1lj

u .. ..... _.L ... .. rt«.a k)Ai. ineniui/Ob £ it .YnO.9

j6tofHI*3‘lfl*t.'

|,:f'?.S3«[r yW

»e<

93*t«#!ta«iS f!^it

/ii J\!t « t^' ^ .,;. ij _^!^».|, r~.i -..S<*.,^-. - H. r=-. -fc- ...V.-...,.. ^ . T*'*

'

. - . '

' . fW

• 4 V wh«‘Jl ha'* ;

" j- *Vr?J.j n s rh :hf |aTT« or* for^a tl.

. .s 4 i -# V na

j

Vnotr»ff l>«^fef^^^ a »*5^

«?: *'4"^4?To ^VA‘"

' w. «.

^ mr

• ?'.'Vr;- N do* ft iroOD Dftfj

IP V f V ’

, tiCIMlOAH OfriM'! aiiro««t!

»(Af*i:en'*1v# ccm'ffiting. •^V r • «.•’:' afr '^viltt sfi. .v' tftaln«4 Unt :

t

,th“ i^ect

*.o..../.r.r.4u. nIuniM. ^5

® *c-,i ,*u»a,^ .^c.M«»v^.^ ftl *d rf<s* 't»3 5‘« -pl *«*d>-oMb

v.m Voj BPfVt«.SVtJ3t p; bpf If.PP'' Ml x»« v-03n*v«l Sf X^ePdWS^ 3«»,

i ' .. 2.JA313 *4n h aJh9Pw:i0t> iffcjTO

hniidwt-fUt^ af ^reqatotiy^sOtf doclibalKs Toe a bi ^WJOta “l ^ Yocatstons to a^ld f;*|qy«nC af r^-crj^Iy i^cpi vdd dacum#rit4|JTM

^q. th^ jyitr^ r3»ot<i dtj^Hcbtef «uit aopi^r trains. pa u, tih $hott!d h^fv« the aaTUranKa turrervey. and u*;» ectctly the siar ;

"ii'iV

iieh' $hott!d h^fve the

locatR (thS' ittess

fhfe ?yi%«ia 'l«0v^'^'

’'*'

.

'. .v’ "f . 'V -, ' . ‘1 '4| 'I*’. - * >.'

. Ana c^oosa thflrtbs^ "•cc^'ifble eiapy cn a^wnd. Tht
31 July 1986 3-1

System Development Corporation

TM-HU-900/000/00

SECTION 8 - CONCLUSION AND RECOMMENDATIONS

3.1 CONCLUSION

CALS must support raster images because almost all documentation either lacks

an al phanumeri c/ vector form, or, if one is used, it is nonstandard. CALS

must support standard alphanumeric and vector storage formats to facilitate

full text searches and CAD input/modification. Choosing to remain with one

or the other format exclusively would result in losing the capability to ac*cess

archived raster images, or in losing the design and solid model information

and the ability to search for text strings.

The raster-only short term solution is suggested, since it can be applied

early, easily, and cheaply. In addition, a successful raster CALS system

would almost certainly be able to inspire a budget for additional vector

capabilities.

For the long term, however, CALS must also provide portability of software

tools and ease of transfer of images and product data from one system to

another. For this reason, CALS must accept documents in vector and

alphanumeric formats as soon as standards for these formats are established.

8.2 RECOMMENDATIONS

CALS has been created to manage DOD's information. The best way to do this

is to create a fully integrated information exchange system. To go electronic,

the DOO must be able to display and print any document at any location,

worldwide. Such a system would allow computer management and use of the DOD

information database.

In addition, the DOD must begin to implement CALS quickly, in order to build

on the interest and enthusiasm created so far. The complexity of a totally

integrated system implies a leveled approach, with both short term and long

term plans. The DOD must prioritize CALS features by desirability and

technical difficulty.
31 July 1986 3-2

System Development Corporation

TM-HU-900/000/00

The following subsections detail some areas where there is a clear need for

future standardization or activity, in order to achieve the DOD objectives.

3.2.1 Applications Standards Interfaces

The interfaces between the applications standards should be clearly defined,

with well documented descriptions of the functionality and data type

correspondences across those interfaces.

Specific areas where such interfaces need to be determined, and the benefit

gained in determining them, are:

• I6ES/PDES to GKS/CGI/PHIGS - to allow for standard graphics interfaces

to existing and new CAO/CAM systems. • GKS/CGI/PHIGS to wi ndows to UIMS - to provide standard interfaces

from graphics applications to the user and to the specific user

interface capabilfties of. devices. • Various DBMS to DIMS and to GKS/CGI/PHIGS - to provide a standard

method of database access from the graphics applications and ^rom the

user interface management software.

3.2.2 Raster Operations

Current computer graphics standards were developed with vector graphics

capabilities as their primary concern. Recent technology -has provided the

industry with a proliferation of raster oriented functionality. In addition,

the image processing world is melding with traditional graphics applications,

particularly in the area of document preparation, a major CALS concern.

Existing and new computer graphics standards must be reexamined in light of

the prevailing requirements for image manipulation in combination with more

traditional vector-oriented functionality.

Another capability that must be mentioned is that of converting raster images

to a vector format that can be used by CAD systems. This is an area of intense
31 July 1986 3-3

Systsm Development Corooration

TM-HU-900/000/00

research and development, but no current systems have been designed for use

in a document archive.

Any raster to vector conversion must be checked for errors. To estimate the

cost of using raster to vector conversion, the level of error free conversion

must be established and the number of operator hours required to achieve this

level must be measured for each proposed system. While the cost of checking

is usually less than the cost of redrawing and therefore very cost effective

for drawing update, the cost of checking is still many times the cost of storin

a compressed raster image of a drawing. Therefore, raster to vector conversion

is suited to drawing modification, but not to drawing archiving. Similarly,

OCR is cost effective for documents being edited, but is not effective for

text documents being archived.

Because raster to vector conversion operates on a raster image, drawings °

stored in raster format can be connected to- a vector format when extensive

modifications are required. Simple modifications can be made in raster format

by any one of several existing commercial systems.

3.2.3 Higher Level Application Software Standards

As application areas are identified, new software standards should be

developed, built on top of the existing ''family" of graphics and database

standards. This further standardization is suggested to make available more

off-the-shelf specialized software that uses the newly standardized application

standards as a base. Some areas that may be approaching sufficient maturity

for standardization are management information systems (MIS), user interface

management systems (DIMS), business graphics capabilities, and database access

routines (already in progress).

8.2.4 New Input/Output Facilities

As technology advances, the facilities provided for user interaction change

and grow. The requirements for such facilities drive the need for a standardized access to them. Near future I/O devices that meet CALS require-
31 July 1986 8-4

System Devel ocment Corporation

TM-HU-900/000/00

ments are speech synthesis for output to maintenance engineers, along with

voice input for areas where other input methods are not feasible. Video is

already being used for training and manual preparation; a standardized format

for video would enhance future off-the-shelf software availability. Low cost

eye tracking devices, with the device mounted on the display rather than on a head appliance, may prove ideal for cursor positioning on images.

8.2.5 Validation/Veri fi cation

For CALS to be successful, there must be validation 1) the risk of

incompatibilities between contractors and OOD systems; 2) the risk of

unrel iabl e/noncompl iant sources of data; and 3) the risk of rejection of

data.

Although the val idati on/ veri fi cation subject is listed last, it is probably

the area of most concern for the CALS project. To meet the stated goals of

providing cost-effective automation, with unified interfaces for automated

data exchange, each part of each interface must meet certain requi r-ements

.

These requirements are stated in the applicable standard for that interface.

If the requirements are not met for even one connection in the system, the

whole system fails. It is essential that some means be provided the

government and industry to determine that the software interfaces comply with

the stated standards.
rr

,^.,0 for c«)ttu4l «?^''|[M

^.-4' ii XdAntLt^v 4 »»#r ^%»y* ..,'"5^. ,.”f»’ \.'^\

_ . .. V^*- S4 4a ^ 'ilB fc’Atv O^^KU$ ' <1^ '^^‘ilir>>"«

i#'l

a* , Idanftiiy ,el*x<l^,int•^c^«n.,)• *i^fttir«-'*)4rti:* in CUU, ioD.Vic.-

V r#.

'P«fe^'iCa tiow*, -iSAR?

^

'Sn/"

p.

», .

*

ii lPi:;. t . «»»«

i». i».^t of tertu** 1/ taifonartg.# jixandatr'f}* ^ •^e« ^ IK^; ' 5ic 5o0»»fiplicatt.tj-,« (*.g?, SCrft' U « ?roS|{ii»d

''i-'h auBc»»*i5td jji biliihxnQ

yijck

4

,- 'W^ntatlon vof t««u«Jl atanaArtfUtioT cxLs jaa»<S on rn- «DCV% , t

\i^

'»i* fey *

-a

. ci v* ,» x< Report CJitS Stemting Group on tjtsxi ji-p (pritlim*^ inmcv raioort thri^A. r»i*w> *^4*" ^ ^ i ^ .

in*cy r»port thrfcO' w9feir»%aiitAi: ,8o-»ho»« , itn*i» r«port ^ • c fix a&ijtft*! • - - ' - . _ I, t¥

• ktor 9c-^«*d, <jr«4t. plan -AC *ix mootnx, -ttr5| 3C .iQnc3»fanci«»

_ ^ ^Vr^-T^ni^' in .„ ;*

. . i . -jy'i ,_j <*i . fiilj

4.

•A* :.3.l •*sosi tho'ieiia^i^ xpxeific / .^»nae.. Snd jidyalop « o«p«c on^ *aOh; '

' VV

X. <Ju«n.tifi«*t4dnyf th* *ov,c^^^ innaront ift’'t;re s.'.hj. "" approxca for «p*clfic CAtS sppUca-Uo.'is r «^* . s and itxpactad b*n*f itfi o^f SGww cool®-, tn ‘acUitae'*

^ "<1’ i« prapAi'-itt-cr. of infonsation^tor iaUvarv to DoC-.

-^*'

r.

1*^!.,

‘"‘"f

^^n«l Sfa^nio*.'- rncKfi# an cvrtanc Approacftax '-*« inc#gr**lna CAL5 - r«iavafi* c«3tt and grapnidt * tan-Aar-.a .

.'*

r\« 1 ia-a.a» fckt f' .*,.u

4«Uvaral^|iTn j 8.x mcncaa at\»c go-anoad) ' *’•' •*

n ,• ,ji. . t

' '* MiiMiv a?

-

' , i4..j£‘ortrwn.rrr''!i davtUp^rc ana .aXkdation wnara naadad to maat CAW scnadul* oa^ac-lvti'

(' i.4l * r

1.3 TEXTUAL STANDARDS

SPECIFIC TASKS

FY 36

1. Assess DoO needs for textual interchange standards:

a. Identify text interchange requirements in CALS applications (e.g., technical publications , LSARr reprocurement data)

b. Recommend a set of textual interchange standards for

specific DoD applications (e.g., SGML is a proposed

standard for CALS interface with automated publishing

systems). Assess specific near and long term benefits,

limitations and impediments in adopting these standards

for DoD use; the need for bridges between different

textual standards; and alternative interim DoD

approaches pending availability of the recommended

standards and validation procedures.

c. Develop a plan to expedite the development and implementation of textual standards for CALS based on the

above findings.

Deliverables : — Report to CALS Steering Group on tasks a-b (preliminary report three months after go-ahead, final report

at six months)

“

Plan for textual standards area (outline three months

after go-ahead, draft plan at six months; firm plan

at eight months)

2. In parallel with task 1.3.1 assess the following specific

issues, and develop a paper on each:

a. Quantification of the "overhead" inherent in the SGML

approach for specific CALS applications; availability

and expected benefits of SGML tools to facilitate

preparation of information for delivery to DoD.

b. Interface standards for text and graphics. Include an

evaluation of current approaches to integrating CALS - relevant text and graphics standards.

De 1 iverables

;

— Separate issue papers (incrementally delivered within

six months after go-ahead)

3.

Accelerate textual standards development and validation

efforts where needed to meet CALS schedule objectives:
a. Provide a plan for development and implementation of

SGML, validation procedures. Include criteria for DoD

selection of validation projects. Identify schedule,

resources, and recommended responsibilities for developing validation software.

Deliverables : — Quarterly status reports and a final technical report

(eight months after go-ahead)

Tentative FY. 87/88 Tasks

FY 87 and 88 tasks will be firmed up in the tactical plan delivered six months after FY 86 go-ahead. Tentative tasks include:

FY 87

1. Integration of SGML with the proposed standard office document architecture and interchange formats (ODA/ODIF).

2. Prototype the registration of a CALS document in SGML format

with ANSI. That is, for a selected document type (e.g.,

an Air Force tech order), define the elements and mapping

of elements to appropriate formatting primitives, and

register with ANSI as an SGML-approved document. Evaluate

the need for and recommend an approach for further SGML

registration of DoD documents.

3. Specify a Navy DIF to SGML bridge (2-way).

4. Prepare a guidance document on the use of those subsets of

SGML which are required by DoD.

5. Complete development of initial validation methodology.

Prepare report describing initial methodology and begin

evaluation of methodology.

6. Submit CALS defined document type to registration authority

in X3V1.

FY 83

7, Continue to validate and enhance, if necessary, validation

methodology on prototype SGML systems.

8. Prepare a report aescribing validation methodology and

procedures

.

During FY 86-FY 38, participation will be required in ANSI X3V1

which is charged with the development of ODA/ODIF and SGML t:o ensure that enhancements to existing specifications reflect CALS

requirements and to ensure registration of CALS documents by tne

SGML registration authority.
1.3 TEXTUAL STANDARDS

This section of the report addresses three specific tasks under

1.3 Textual Standards: Task 1.3.1 Assess DoD needs for textual

interchange standards. Task 1.3.2 Assess the Following Specific

Issues, and Develop a Paper on Each: (a. Quantification of SGIdL

Overhead and b. Interface Standards for Text and Graphics) , and

Task 1.3.3 Accelerate textual standards development and

validation effoirts where needed to meet CALS schedule

obj ectives

.

1.3.1 ASSESS DoD NEEDS FOR TEXTUAL INTERCHANGE STANDARDS

1.3. 1.1 Identify text interchange requirements in CALS

applications (e.g., technical publications, LSAR, reprocurement

data)

.

CALS applications have a number of requirements for text

interchange, including:

- the need for a standardized way to exchange textual

information (documents or parts of documents)

;

- the need for the exchanged documents to contain a variety

of content, including character text, pictures, drawings,

figures, and so on;

- the need to output the interchanged text on a variety of

media (e.g., paper, CRT, laser printer, photocomposer);

- the need to pull together parts of documents prepared or

processed separately, and, conversely, the need to

distribute parts of documents for separate processing;

- the need for a standardized way to represent the

appearance of the document (e.g., multi-column text, various

fonts) ; and

- the need to use parts of the interchanged text in database

applications.

(For another project, NBS prepared a paper on users requirements

for document architecture and interchange format which can be

made available to CALS.)

1.3. 1.2. Recommend a set of textual interchange standards for

specific DoD applications (e.g., SGML is a proposed standard for

CALS interface with automated publishing systems) . Assess

specific near and long term benefits, limitations and impediments

in adapting these standards for DoD use; the need for bridges

between different textual standards; and alternative interim DoD

approaches pending availability of the recommended standards and

validation procedures.
There are a number of standards which can be used for text

interchange. Two of these standards, SGML and ODA, are of

primary interest to CALS. (In addition, there is a defacto text

interchange standard, IBM's Document Content Architecture (DCA)

.

The major limitation of DCA is its parochial nature.)

The SGML standard, a representation language for character text,

has been recommended to CALS for technical publishing

applications. SGML can be used for publishing in its broadest

definition, from single medium conventional publishing to multimedia database publishing. SGML is used to describe whatever a

user chooses to identify within a document. This results in an

implicit document architecture, defined by the user. And it

should be noted that while SGML is effective for representation

of character text, there are some ambiguities in the way SGML

handles other types of data. For example, SGML does not specify

the format of graphics content; the user is free to describe

this information any way he chooses outside the document.

On the other hand, ODA defines an explicit document architecture,

including a capability for incorporating various content types in

one document. This document architecture is the form of the

information transmitted through a network. In fact; ODA relates

only to the structure and format of a document in open

interchange. This standard does not attempt to standardize any

processes performed on the document either before or after

interchange; therefore, the entry, editing, formatting and

internal storage' of the document may be different in each system.

(Before interchange, however, the document will be translated

into a standardized form (ODA) . The recipient will translate the

document to his own internal format and then process the

document.

)

To summarize , ODA addresses the problem of document interchange

between unlike systems and SGML is a tool in a standardized set

of tools for document management (everything from initial entry

to final output)

.

The two standards are at different stages of development. SGML

has become an international standard, is a planned national

(ANSI) standard, and there will soon be many implementations

available for CALS applications. The ODA work is a Draft

International Standard and only prototype implementations of ODA

exist. However, there are applications for the use of both the

SGML and the ODA standards and it is likely that there are CALS

applications for each. It is possible that future text

interchange products will focus on accommodating the two

techniques; that is, systems may be developed which can bridge

SGML and ODA. This topic needs to be investigated further and a

detailed report is a proposed deliverable for FY87.
1.3. 1.3 Develop a plan to expedite the development and

implementation of textual standards for CALS based on the above

findings.

NBS staff are active participants in several national and

international voluntary standards development efforts related to

both SGML and ODA. These standardization efforts include the

American National Standards accredited standards committee X3V1

(Text Processing: Office and Piiblishing Systems) and the

International Organization for Standardization (ISO) Technical

Committee 97 Subcommittee 18 (Text and Office Systems) , which

include the SGML and the ODA projects. The NBS role on voluntary

standards committees, both as technical experts and unbiased (our

viewpoint is not product-based) mediators, cannot be overstated.

The plan to expedite the development of textual standards is

based on this participation in voluntary standards activities.

With regard to the implementation of textual standards, NBS

sponsors the NBS-OSI implementors workshops which we plan to

expand to include implementations of textual standards in FY87.

1.3.2. IN PARALLEL WITH TASK 1.3.1 ASSESS THE FOLLOWING

SPECIFIC ISSUES, AND DEVELOP A PAPER ON EACH:

1.3. 2.1 Quantification of the "overhead" inherent in the SGML

approach for specific CALS applications; availability and

expected benefits of SGML tools to facilitate preparation of

information for delivery to DoD.

An issue paper oer se has not been prepared; however, the

following is a report of what is involved in quantifying the

overhead in the SGML approach and of the availability of SGML

tools for CALS applications.

A reliable quantification of the "overhead" inherent in the SGML

approach for specific CALS applications is especially difficult

and cannot be answered with any precise figure due to several

important factors and considerations. These are listed below.

o In an SGML approach to document processing, there are three

distinct aspects:

- the design of the document type definition,

- the actual marking up of the dociiment, and

- the outputting of the document to some medium.

Since these processes are distinct, it is reasonable and

correct to assume that, in the case of complex formatting

requirements, the nonprocedural martop of an SGML document

will be substantially easier than the procedural mar3cup of

the same document. In the case where the formatting

requirements are simple but the logical structure of the

document is complex, the markup process may require extra
effort.

o Overhead in the SGML approach must be relative to some other

approach. Every document has overhead in the form of markup

even though much of this may be transparent to the user.

Without knowing what other approach might otherwise be used,

it becomes difficult to state whether more or less overhead

is involved using SGML.

o It must be recognized that there are several forms of

overhead (e.g., the extra information that the operator was

required to enter, the extra information stored with the

document that was added by the text processing software.)

Again, these types of overhead exist in all documents,

regardless of the method used to create them, so there, is no

reason to believe that the SGML approach would be

substantially different from other approaches.

o The extent to which markup minimization is employed, both in

the document type definition and in the document elements,

will have a great impact on the overhead involved - both in

terms of operator effort and extra file information. This

is especially true when data tAg minimization is used!

o The amount of rework required for a document must also be

included in estimating overhead. Since syntax directed “ex*

processing software may be available for SGML users, -“he

amount of rework should be reduced and rhe effort spent in

checking documents for completeness and correct structure

should be virtually eliminated.

Since SGML is now an international standard (ISO 3879)

,

tools

should soon become available. Already there are syntax directed

editors and formatting systems which are front-ended by SGML

parsers and these are available both domestically and

internationally. Although many of the systems are currently

incomplete and need refinement, this will certainly come with

time. Also, systems to tap the information in SGML documents and

store that information in a database will permit data retrieval

beyond the capabilities of systems that operate on procedurally

marked up documents.

1.3. 2.

2

Interface standards for text and graphics. Include an

evaluation of current approaches to integrating CALS - relevant

text and graphics standards.

A discussion of the interface standards for text and graphics is

included in the Graphics Interchange section of this report. It

is important to note, however, that the textual standards

described earlier each make use of graphics standards. Since the

SGML standard allows any content to be defined by the user, the

user could use an arbitrary graphics standard in defining

graphics data. The ODA standard specifically mandates the use of

particular graphics content architectures (part of the CDA
standard) ; these graphics content architectures are based on the

Graphics Kemal System and the Computer Graphics Metafile

(described in the Graphics Interchange section)

.

1.3.3. ACCELERATE TEXTUAL STANDARDS DEVELOPMENT AND VALIDATION

EFFORTS WHERE NEEDED TO MEET CALS SCHEDULE OBJECTIVES:

1.3. 3.1 Provide a plan for development and implementation of

SGML validation procedures. Include criteria for DoD selection

of validation projects. Identify schedule, resources, and ^ recommended responsibilities for developing validation software.

A paper describing the framework for developing a validation

package for SGML validation software has been prepared and was

presented by NBS staff at the TechDoc ’86 Conference. The paper,

which defines a methodology for developing test suites to test

conformance of SGML software to the SGML standard, is attached.

Included in the paper are criteria for DoD selection of

validation projects and schedule information.
. ' Vi’ BolftqBUZ lolx/qatoO »4Uf tan ecmSm^Z

ijpnftcsiT tfrA<^[^W

’v'*r^r:~T'’'^4rr «i; m

^r n i^X ^ or n<trvi*

rttvai;r#4 t.o •nr-^r/

: •»» iw\a*!’wSwi if* «M?S'»LS~5';iK;-

^ _ jll^i f^i An.fi. ^hn iuoiucwrswit.

ter/>r^ cricxc 6iw5'.pcrp& 1x1# Xn

JU. tjrtift L^; rXftir

5ui‘.cur:r of ' oir|t ?:.»quir«d to^ f

^ r^-XT»»t.lnr ' r

pLtsw- .n*ir»«j »c:^twort ’""liij La £ *'' fiiX

r miikmrit et' rfvo^ < 'sjjouid r#^suc^* r. < choOcin^ dbcn»4U*t»'’ fwr cor.

shQ\i*d bo vxrtiailly oil .nntir:

$ilncii 5Q-tl is nou on (1S> 3375

*i^i<iaa.'r: , ifOcn taTpCiMi nv^o \1 .“# ^^7 •‘^-T‘5 »?!tt

edit. :'• ond torWW.U'iC' orari^fiao wblcn xri tt..-cnr *ondtiii

. r-orioT'!^ and xhaoo itro, ovoiiabA^ be •- n .dfla.#r*‘r. rally

. :^5rnablonmll3?1’ Jlil ttoJc.- riai y cr dino ry^roaa,ar

lAcoi^ietSO :i»d *rofl.'*s«:'-!«n1L. HlJI «-U1 w^o^t Ui)i

t,LJXoii' AX»c* ^ inforcotisn -Lii SC

Otb‘.r*»'' !j5^d(X#ant^ •' ^ 'fcaAe viil pOtbllC

tiwi d5lpr^lll'^<i's rjr:at '7pe?-aX0

. r' ^ —

i.X rnport i*' *5t4ndoei^t — - 9rtnti

.jfttiojn of <;.? appro*cj'T:j ^''.Into^aoin^

tibct ‘ !3

\ dl«f itaje:sion of *tba to# 'A»ood«*irJ! :• -or '’oro and s i#

InclLidcd iri Ir:7.orebanct# «^oooie;i tm* ropert . le

la iJape.'^uSirtv ti^' er > scondonlo

«i.trlL«rv^iacii -taxn p|Mi ora a*.;** '^t.i.-viarda, . ... ,...

§ICSiili' Mioum^^jvy cemart to bs oy lliO--

UTi«r Ui«i*an arbitra •/ »t*jftdJird 1" daClai:^

.., jaLfL. . 7b#®oeA a^XtCu^xd J5p#^llx«lly ninda*.;* Ibe -laa*-,#TM

gi^ptiica centonl: srcntta‘’:X'jxW (part. ^ “-ba onX i "

•din
SGML Parser Conformance Testing Methodology and Framework

Jim Heath

National Bureau of Standards

Institute for Computer Sciences and Technology

03 July, 1986
ABSTRACT

This document focuses on the development of a framework for

testing SGML validating parsers. It examines the need to develop

test suites, some of the particular problems associated with

testing SGML parsers, approaches that were considered, a set of

guidelines to be used in the actual test suite development, the

actual organization of the test suite, and the test procedures.

It is expected that the National Bureau of Standards will

actually develop a set of validation procedures for SGML

validating parsers to support the Computer Aided Logistics

Support (CALS) initiative of the Department of Defense.
1 . Introduction

The goal of SGML, like the goal of any standard, must be

recognized as portability in some sense. In the case of SGML

parsers, the focus is on document portability, i.e., the same

document should not result in different interpretations when it

is parsed on different systems. This objective cannot be

completely achieved until parsers can be tested in order to

determine whether they conform to the relevant standards.

Standard test suites should be developed for SGML parsers to be

used by developers, users, or third-party testers; the test

suites should be considered as evolving rather than static as

they will be updated based on users* experience with parsers.

The existence and acceptance of these test suites should lead to

comparability and wide acceptance of test results produced by

different examiners. This document to defines a methodology for

developing conformance test suites.
2. Scope and Field of Application

This document defines a framework for the development of a test

suite for SGML parsers and describes:

- definitions

- an overview of testing

- difficulties associated with testing SGML parsers

- approaches to testing

- organization of the test suite

- test procedures

NOTE: Unless explicitly stated otherwise, the term parser

(as used in this document) will mean a validating SGML

parser as defined in 6.3 of the SGML CIS. Although the

standard also defines a conforming parser in section 6.3 of

the SGML DIS, there is no requirement that it perform output

of any kind and consequently its results cannot be

validated.

The test methods described in this document address only the

functional capacity of the parser - other features of an SGML

system, such as user interface, performance, parser design, etc.

are not considered.

Additionally, it should be recognized that "complete validation,

implying absolute correctness, is presently infeasible with any

sizeable program (DEUT82)." Only a small subset of the possible

test cases can actually be presented to the validating parser.

This limitation is not unique to the problem of validating SGML

parsers but is characteristic of software testing in general;

all one can do is submit a representative subset of the typically

infinite number of possible inputs to the system under

investigation and determine whether or not the results are in

accord with the specifications for that system.
3. Definitions

3.1 Reference Model Definitions

This document is, in part, based upon the concepts developed in

the ISO/DIS, Information Processing - Text and Office Systems - Standard Generalized Marloip Language fSGML) . November, 1985 and

makes reference to the following terms defined in that standard

attribute definition

CDATA

connector

content model

element declaration

entity declaration

exceptions

exclusions

external identifier

feature

general entity

inclusions

NDATA

notation declaration

occurrence indicator

parameter entity

parser

Generally speaking, a parser is a program used to determine

the underlying structure and content of some input object

(file, document, etc.) More formally (in an SGML context),

a parser checks that the tokens appearing in the input

document occur in patterns that are permitted (by the rales

of SGML and the description given by the document architect

in the document type definition) and makes explicit the

hierarchical structure of the incoming token stream by

identifying which parts should be grouped together,

public identifier

ranked element

RCDATA

SGML declaration

system identifier

validating parser
4 . Overview of Testing

Testing is a primary tool of software quality assurance and, in a

broad context, encompasses not just the execution of the rests

but also the design of test cases. The ideal goal would be to

state, that after successful completion of the test suite, a

software product is free from errors. This will not be possible

in the general case and the best we can do is give the user

confidence that the product is likely to perform as described.

Although testing and debugging are often used interchangeably, we

shall distinguish them by stating that the purpose of testing is

to show the existence of errors while the purpose of debugging is

to find the error or misconception and effect the appropriate

corrections. Some of the characteristics of testing are:

1. Testing uses predefined inputs and expects a predictable

set of outcomes. The only uncertainty is whether or not the

software will execute the test correctly.

2. Testing is a demonstration of an error condition or the

apparent correct processing of a document.

3 . Testing can be designed and accomplished with ignorance

of the internal program design.

4. Testing will involve treating the parser as a black box

CO which we provide a set of known inputs and from which we

will take the output and compare it against the expected

result.
5. Motivation for Developing Validation Procedures

The primary purpose of conformance testing is to establish

whether the implementation being tested conforms to the

specifications of the standard. We expect other benefits to

derive from this:

1. It is generally agreed that the SGML standard is

difficult to read and interpret - having a way to test thei

interpretations should provide a positive influence to

developers of SGML parsers.

2. The fact that a parser has successfully completed a

standard set of tests will improve its acceptability to

users and give them confidence that they may process their

important documents without misinterpretation.

3 . As a result one 1 and 2 above , we expect that the

acceptance of SGML as a standard will accelerate.
6. Difficulties Associated with Testing SGML Parsers

The testing of SGML parsers presents a particularly challenging

situation because:

1. Parser output is loosely defined in the standard; also,

the parser will be incapaible of helping to diagnose its own

mistakes (as contrasted to a compiler or interpreter which

could perform some process and compare the outcome - in some

cases - with a constant known value.)

2 . Only minimal output is required by the parser - the

parser is required only to report whether or not an error

was encountered; no standard reporting form is required.

Therefore, much of our evaluation of a parser's correct or

incorrect handling of some function will be by inference,

e.g., we cannot know that a parser has correctly interpreted

an attribute value but we will infer that it has properly

recognized the attribute value if it reports no error for a

correct value and does report an error for incorrect values.

3. The tests cannot be modeled from the parser design

because that will be unknown to the persons conducting the

tests

.

4. Various levels of implementation are likely since there

are. several functions in the standard which may not be

useful to most users. The tests should be structured so

that failure to process some rarely used function of the

language will not disqualify a parser from further

evaluation.

5. There is no requirement that an SGML parser continue

after encountering an error, therefore, the number of

exception test documents will be relatively large.

6. There are parts of the standard for which validation may

not be possible, e.g., a validating parser which is not

associated with any sort of formatting output process may

fail to recognize 'record ends' which are caused by markup.

7. Finally, as with any complex computer application,

complete validation is a goal that may never be attained. A

failed test shows that a parser implementation does not

conform to *the standard; a successfully completed test shows

only that it mav conform. The completion of a series of

well constructed tests establishes confidence that the

software will perform as intended.

It is also important to keep in mind that this document addresses

testing parsers for conformance, not testing documents for

conformance - the distinction is important. In the former.
conformance is a matter of syntax; if a document has been

constructed according to the rules of SGML, it is compliant.

Furthermore, we can determine a document’s conformance or

nonconformance by inspection.

In contrast to document conformance which is described

structurally, parser conformance is described functionally. The

essential requirement for a parser is that it accept as input,

any document and inform the user if it cannot determine its

underlying structure and content in accordance with the rules of

SGML.
7 . Approaches to Testing

Testing techniques are as varied as programs are varied and there

is no single best method. Instead, some combination is usually

most effective. A few of the primary approaches are described

below:

7 . 1 Path Testing

A path, as used in this approach, is some executable sequence of

instructions through a routine. Path testing involves choosing

input data such that enough paths are generated so that:

1. Every instruction in the routine is exercised at least

once.

2. Every decision (branch or case statement) has been taken

in each possible direction at least once (BEIZ84)

.

Path testing is highly regarded as the corner stone of testing;

however, to know which paths to test requires knowledge of the

parser's internal design which will generally be unavailable to

the tester. Also, since each parser will be implemented

differently, we would be forced to treat each one individually.

For these reasons, path testing - despite its great value - cannot be used in developing validation procedures for SGML

parsers and will not be further considered.

7 . 2 Transaction Flow Testing

Transaction flow testing provides another approach. From the

user's point of view, a transaction is simply a unit of work - from a functional point of view, a transaction is a sequence of

operations beginning with an input and resulting in one or more

outputs. At the completion of a transaction, it is no longer in

the system (except perhaps for some historical record) . Examples

of transactions are inquiries into reservation systems,

withdrawals from automatic teller machines, etc. Although there

are no clear counterparts to transaction processing in parsing an

SGML document, we can consider some functions (e.g., defining

entity references, defining content models, opening files

associated with external entities) as transactions even though we

may only be able to infer that they were processed correctly or

not based on some later event, e.g., we will not know whether a

content model in the document type definition was processed

correctly until we encounter the element in the document) . This

modified form of transaction flow testing will be used frequently

in developing the validation suite.

7 . 3 Syntax Checking

In syntax testing, the object under test is treated as a black
box which should accept valid inputs and reject invalid ones.

The emphasis is not on what the program or system does with the

inputs (and in the case of a parser we do not know with

confidence what it does with the inputs) but rather on whether or

not it correctly distinguishes valid from invalid inputs. This

type of testing is highly applicable to SGML parsers (indeed, it

forms the basis for defining validating parsers) and we will

exploit it as much as possible. Syntax testing is used to

demonstrate the following:

1. The system does not fail when subjected to bad inputs.

2. The system rejects all bad inputs and accepts all good

inputs

.

3. The system correctly process valid inputs.

7.3.1 Categories of Syntax Errors

(BEIZ83) defines eight categories of syntax errors:

1. High-level syntax errors: the strings have violations

of the topmost level in a top-down 3NF syntax specification.

2. Intermediate-level syntax errors: syntax errors at any

level other than the top or bottom.

3 . Field-syntax errors : Syntax errors associated with an

individual field where a field is defined as a string of

characters that has no subsidiary syntax specification other

than the identification of characters that compose it. A

field is the lowest level at which it is productive to think

in terms of syntax testing.

4. Delimiter errors: Violation of the rules governing the

placement and the type of characters that must appear as

separators between fields.

5. Field-value errors: Not really syntax errors, but

errors associated with the contents of a field.

6. Syntax-context errors: When the syntax of one field

depends on values of other fields, there is a possibility of

an interaction between a field value error and a syntax

error. For example, when the contents of a control field

dictate the syntax of subsequent fields.

7. Field-value correlation errors: Then contents of two or

more fields are correlated by a functional relation between

them. There is not full freedom in choosing their values.

The value of one field is restricted by another field’s

values.

8. State-dependency errors: The permissible syntax and/or

field values is conditional on the state of the system or

the routine. For example, a command used for startup may

not be allowed when the system is running.

7.3.2 Test Case Design
The basic strategy will be to create one error at a time while

keeping all other parts of the input statement correct. A

logical next step would be to consider double errors, triple

errors, etc. but the number of test cases would increase

exponentially so this is not feasible. Another and perhaps more

viable approach would be to select compound cases that are likely

to be reveal vulnerability in the parser but without knowledge of

the parser design this becomes almost impossible. Initially,

therefore, we will

test single error cases only. If experience reveals particularly

troublesome combinations, they may be incorporated later.

7. 3. 2.1 Top, Intermediate, and Field-Level Syntax Errors

Again (BEIZ82) offers some help in selecting test cases; assume

the topmost syntax level is defined as:

item := a I b 1 (c & d)

1. Do it wrong! Use an element which is correct at some

lower syntax level but not the current one.

2. Invalid combination! For example, from the above

definition use (c & b) rather than (c & d)

.

3. Don't do enough! Use (c) instead of (c & d)

.

4. Don’t do anything! Many systems fail when the input is

null; also, other problems (apparently unrelated) may be

revealed.

5. Do too much! Use (a & b) instead of just (a).

Concentrate on only one level at a time, trying to keep the

levels above and below as correct as possible.

7 . 3 . 2 .

2

Delimiter Errors

Delimiters are used to separate fields or parameters and the

problems associated with them may provide a rich source of test

cases. Some cases to include would be (BEIZ33):

1. Missing Delimiter! This causes the apparent merging of

two fields.

2. Wrong Delimiter! For example, use single quote for a

parameter separator, etc.

3. Not a Delimiter! Use some character or string which is

not a delimiter where a delimiter should exist.

4 . Too Many delimiters ! Perhaps the system becomes

confused.

5. Paired Delimiters! There are lots of possibilities here

including nesting, unpaired delimiters, and compound errors

such as ((()(())) . 6. Tolerant Delimiters! The delimiter may be optional or

more than one form may be acceptable.
7. 3. 2.

3

Field-Value Errors

In some cases, values are associated with fields; and the

possible entries for these values should be checked.

1.

Boundary Values! Good choices would include minimum -

1. minimum, minimum -r i, a reasonable value, maximum - 1,

maximum, maximum + 1, very much below minimum, very much

above maximum.

2. Excluded Values! Test for values which should be

excluded (if any)

.

3. Troublesome values! For numeric values check for values

surrounding powers of 2.

4. Type Changes and Conversions! If a field value should

be encoded as a string of ASCII digits, put in some

nondigit, are leading +/- signs allowed, etc.

7 . 3 . 2 .

4

Context-Dependent Syntax Errors

Sometimes variations of syntax may be allowed depending on

context; in the case of SGML, a good example would be a

contextually required start tag.

7. 3. 2.

5

Correlated Field Values

7 . 3 . 2 .

6

State-Dependency Errors

The format of a statement may be acceptable at one time but not

another depending on the system’s state. In the case of SGML

parsers, it might be permissible for a paragraph to occur inside

a chapter, but not inside a figure.

7 . 4 Logic Based Testing

This approach to testing assumes that the tester has access, to

the rules that formed the specification - usually something like

a decision table. The idea is that the same rules that were used

for the design may also be used for testing. Generally, this

information does not exist in any usable form for SGML parsers so

we will discount the technique from further consideration.
3 . Organization of the Test Suite

The following are some general guidelines that should be kept in

mind in designing the test suite.

8 . 1 Avoiding Reliance on Untested Functions

One of the significant problems confronting the test designer is

to find some organizing principle, i.e., a natural way of

sequencing the tests. One such approach would be to test the

functions in the order in which they appear in the standard; the

fundamental problem with this strategy is that the organization

of the standard does not lend itself to the bottom up testing

required to logically test a parser. A function cannot be

effectively used in testing another related function unless it

has previously been tested, e.g., a comment within a declaration

cannot be used until it is known that the parser will recognize a

comment and the resolution of an entity cannot be tested until ir

is known that the parser can process an entity declaration.

Using this approach lessens the possibility that the function

being tested could wrongly pass the test because of a flaw in the

implementation of a function whose validity is being assumed.

Also, if an error were reported by the parser, it would not be

clear whether the true cause of the failure was the function

under test or one of the untested functions being used.

8.2 Test All Individual Functions

« The test suite Will be subdivided into test groups with each

group primarily constructed to test the general ability of a

parser to correctly process functions of the standard. Test

groups are in turn subdivided into test subgroups which test a

parser's capacity to handle subsets of the function being tested.

The test subgroups are built from the actual test cases which

test the parser's capacity to handle specific instances of a

function.

The scheme of testing only one function per group also helps to

minimize the total number of tests since it eliminates the

extreme growth in the number of tests which would result from

testing all possible combinations. This approach is not without

problems since it is likely there will be some level of

interdependence between the processing of various functions.

Where this is recognized, special test groups will exist to

specifically test function combinations.

8.3 Minimize the Number of Tests

Ultimately, the input to any process must be viewed as a bit

stream, therefore a process which accepts a two byte (assuming a

byte is 8 bits) input could have 65536 distinct input

possibilities. If a process accepts four byte inputs and
requires 100 microseconds to test each input, it would require

almost 120 hours to check all inputs. Obviously this is not a

reasonable for systems like SGML parsers where the inputs may be

several orders of magnitude more complex. We must therefore

carefully choose a very finite subset of the possible set of test

cases and use this for our test suite.

8.4 Make the Tests Easy to Use and Their Results Easy to

Interpret

It should be accepted that the tests will be executed in

different environments by persons whose primary concern is

determining the conformance of a parser, not in trying to

understand how to perform the tests. Also, the tests should be

structured, as much as possible, so that the results are easy to

understand and interpret.
9. Test Procedures

The main focus of conformance testing will center on 'live'

processing of a test document (s) by the parser being tested,

i.e., documents - conforming and/or non-conforming - are given to

the parser and a verdict is determined for its behavior. If the

document is conforming, the parser should report no errors; if

the document is non-conforming, the parser should note an error.

An observer will analyze the outcome and if it is as expected

will consider the test successfully completed, else he will

consider it failed.

The testing will be organized in accordance with section 8.1 of

this document, i.e., a bottom-up ordering will be followed. This

implies that a complete document cannot be tested until it is

known that a document type definition can be correctly processed.

Since the document type definition is built from subordinate

components, it is necessary to test them individually before

testing entire type definitions. A logical ordering of the test

sequence for these components is:

Comments

SGML Declaration

Parameter Entity Declarations

General Entity Declarations

Content Model Declarations

Marked Section Declarations

Exceptions Declarations

Attribute Declarations

Content Declarations

Complete Document Type Definitions

After it is determined that the parser can successfully process

document type definitions, testing of complete documents can

follow. Following the same bottom-up approach as used for the

document type definition, testing would begin with the simplest

SGML docximent and proceed in a logical sequence to the more

complex up to the stated limits of the parser.
10. References

a. Information Processing - Text and Office Svstieins - Standard

Generalized Mar]cuD Language rSGML) . ISO/DIS 8879, November, 1985.

b . Revised Working Draft for OSI Conformance Testing Methodology

and Framework . ISO TC 97/SC 21/WG 1, November, 1935.

c. NBS Minimal BASIC Test Programs - Version 2 . User Manual

.

Volume 1 - Documentation . U.S. Department of Commerce, National

Bureau of Standards, November, 1980.

e. Characteristics of Software Quality . Boehm, Brown, Kaspar,

Lipow, Mac Leod, and Merritt, TRW Series of Software Technology,

1978.

f. Software System Testing and Quality Assurance . Beizer, Van

Nostrand Reinhold Electrical/ Computer Science and Engineering

Series, 1984.

g. Commuter Program Testing . ChandraseJcaran and Radicchi, NorthHoli and Publishing Company, 1981.

h. Software Testing Techniques . Beizer, Van Nostrand Reinhold

Electrical/ Computer Science and Engineering Series, 1983.

i. Principles of Compiler Design . Aho and Ullman, AddisonWesley Series in Computer Science and Information Processing,

1979.
.01

It «
1^.1 ’ OATMiJM^S - 9

t.i-W

At:nr.s% *yr*^

6

"'

*-.15

: 1 :*: i^jd'

J 3 ^ !>r ^’:: >

p» ' V ' ap.i^-i -CJi r '. gn.f , €* cu^c^rit,

' r.c .'- vk-.^

. dc '*.»: '3# aac

i S u ^

c5 * r »cnd r ;iann;'

‘. ^ac;. gr r ', ."-j

'- f D-2 . :

if't.xDjiTUB .\:, itmnt nt«rp- r^ -' '

’ , «--a , « . n ;

. a 'istpXlic;..cr A( 4

- ^ ' a-v\ .; ' r B »#»4.

' : A - -' f c - ,- c.; . ,

' iaa4i)

.

;o ;

- , i :

•• ‘^Wr. : - -2 CA 04 j«sg V, t'ifld

£> ' ' ^ ^'t^a , e r. c , )

•-' *:

1

‘ ata lOrp; '• r- ^ 19t C"

DATABASE MANAGEMENT l

. 4^t4 d-ic(>i on a r>: pmnt «n4 . LaipJLi#^

»ra ar<i stindarciji

'» ? ^^•pcs!t. t tj r^Ai»S '^roc ” report nr! r fra -if.-sr

moncni;

Plan tor ‘. ' v Sacabasn

laontftfr af^./ ^ plat) 3 C 9 i-^r.

i 'aiT.

.

— •> a' aiiaaco.-a ‘i:! y^ir

* ^ airtia * rac^r-«- cac . • -r is

,

Oavfi io;-

n«* . f

jr % -

I s ; IT _ . . ; >

' ;rar* o* -# »

II. 1 DATABASE MANAGEMENT SOFTWARE AND STANDARDS

SPECIFIC TASKS

FY 86

1. Assess DoO needs for database management standards:

a. Identify database characteristics in planned CALS applications (e.g., contractor design, manufacturing and

logistic databases, LSAR databases, reprocurement data).

b. Recommend a set of standards, methcdolog ies and tools

for DoD use in database design (including data modeling,

data dictionaries, standard query languages and architectures for distributed databases), and additional

software (language bindings, etc.) needed for CALS

applications.

c. Assess current, intermediate and long term capaoilities

to implement these standards to meet CALS distributed

database needs. Identify and prioritize critical RiD

issues

.

d. Recommend a strategy f,cr use of a data dictionary in

CALS planning.

e. Develop a plan to expedite the development and implementation of database management software and standards

for CALS based on the above findings.

Deliverables :

I — Report to CALS Steering Group on tasks a-d (preliminary^

report three months after go-ahead, final report at six

i months)

’ — Plan for the database stancards area (outline three

months after go-ahead, draft plan at six months, firm

plan at eight montns)

2. Accelerate cataoase standards aevelcpment and validation

efforts wnere neecec to meet CALS scnecu ie oojectives:

* a. Provide a m.ilestcne plan for gaining acceptance of

stancards reccmmencec in task 1 1 . i . i

->

b. Develoo a vai acnrcacn aia cirticnaries

c. Develop a data ticticr.ary snell

cemons tra t ions

.

r

d. Develoo oreliminarv ticnal soecificaticns for data

dictionary extensions to support neecs identified in

task II.I.l.o. Tnis might induce grapnics, ci

databases and cata mcdelin(

s c t- utec
De 1 i verables

“

Quarterly status reports and a final technical report

(eight months after go-ahead)

3. In support of tasks II. 1.1 and II. 1.2, evaluate DoD demonstration programs and, where necessary, conduct additional

experiments on NBS testbeds to resolve technical issues.

Deliverables ; — Quarterly status report to the CALS Steering Group “

Individual issue papers when evaluation of a specific

technical issue is completed (incrementally delivered

within eight months after go-ahead)

4. Evaluate Air Force experience in applying IDEFO/IDEFl functional analysis and data modeling techniques, and assess the

feasibility of applying this approach on a broad scale for

CALS applications. Compare with alternative approaches.

Deliverable t — Issue paper (six months after go-ahead)

As DoD needs are determined, via the initial task, adjustments

may have to be made to the remaining tasks. Tasks identified by

an asterisk (*) appear to be low priority for FY 86. These tasks

will be accomplished in FY 86 if possible. If not, they will De

deferred to FY 87.

Tentative FY 87/88 Tasks

FY 87 and 88 tasks will be firmed up in the tactical plan deliv

ered six months after FY 86 go-ahead. Tentative tasks include:

FY 87

1. Develop preliminary functional specifications for needed

programming language "bindings" to NDL and/or SQL as identified by Milestone 1.

2. Design validation methodology for NDL and/or SQL as identified by Milestone 1.

3. Complete one programming language "binding" to NDL and/or

SQL.

4. Demonstrate preliminary data dictionary validation suite on

data dictionary shell.

5. Prepare for CALS review a preliminary specif ication of data

dictionary extensions to support:

graphics

;

distriouted databases;

data modeling.
6. Provide data dictionary shell for use in CALS dataoase

design.

FY 88

7. Complete and demonstrate data dictionary validation suite.

8* Complete specifications for data dictionary extensions and

begin FIPS processing.

Complete and demonstrate NOL and/or SQL validation suite.

10. Submit recommendations to CALS on the applicability of

Remote Database Access Service and Protocol to CALS

requirements for distributed dataoase.

11. Demonstrate support of graphics by interim data dictionary.
! 3
I. DATABASE MANAGEMENT SUPPORT

This section contains a siimmary of the work accomplished on

Database Management Support, tasks II. 1.1, II. 1.2, II. 1.3, and

II. 1.4 for the FY 1986 NBS statement of work.

A. DATABASE MANAGEMENT SOFTWARE AND STANDARDS

1. ASSESS DOD NEEDS FOR DATABASE MANAGEMENT STANDARDS

In the task to assess the DoD needs for database management

standards, there are five specific subtasks. These s-ubtasks are:

(1) identify CALS database characteristics, (2) recommend

standards, methodologies, and tools, (3) assess standards

implementation capabilities, (4) recommend data dictionary

strategy, and (5) plan for standards implementation.

The Preliminary Report on Data Management Standards , dated June

20, 1986, provided as a separate report to last quarters report,

discussed this task. One of the major shortcomings of this

report was that it did not address the specific CALS

requirements. At that time, there had been insufficient^

information available to analyze the specific standards required’

for CALS. Because of the change in the focus of the CALS effort

for the remainder of .FY 1986, the tasking in the SOW did not

accurately reflect the work that .was done or the scheduled • deliverables. Consequently, in FY 1987 and FY 1988, the

assessment of DOD needs will be done as part of CALS Core

Specifications. The contents of the Preliminary Report on Data

Management Standards will be a part of the deliverable associated

with the development of the CALS Core Specification. Below is a

more detailed discussion of each subtask.

a. Identify CALS database characteristics (Subtask II. 1.1. a)

The original intent of this subtask was to identify the

database characteristics for each of the programs under the

CALS umbrella. There are 32 programs described in the CALS

draft plans prepared by each of the DoD services. NBS

started to dociiment all of these programs and included

documentation in the Preliminary Report on Data Management

Standards ; however, it proved to be impractical and

unnecessary for NBS to review all of the programs. Database

characteristics and data management requirements can be

determined from specific application areas discussed in the

NBS Point Paper. CALS Representative Systems . By

concentrating on application areas, NBS can determine the

commonality of systems and focus on the standards that are

appropriate for CALS. This direction will be continued in

the FY 1987/88 SOW. The work for this task will be a

function of the "Develop CALS Core Specifications'* task in

NBSs future effort.
b. Reconmiend standards, methodologies and tools (Subtaslc

II. 1.1. b)

The Preliminary Report on Data Management Standards

described the data management standards that are availcLble

for use in CALS . The June 8 6 CALS Workshop Report

identifies a preliminary finding of the standards required

for two application areas. Engineering Data Repository and

Printing and Publishing. In the vor3cshop, participants

identified a requirement for a Technical Data/Configuration

Management capability and a method for indexing technical

data which would aid users access to data in these and other

applications. Standards such as SQL or IRDS are standards

that should be evaluated for potential use in satisfying

this requirement. Using the NBS Point Paper. 'CALS

Representative Systems . and the CALS Framework Report (under

contract for Feb 87 deliverable) as a basis for identifying

CALS standards,. NBS will identify the standards applicaUsle

for each application area.

• c. Assess standards implementation (Subtask II. 1.1. c)

The Preliminary Report on Data Management Standards . Section

4.2, Research and Development, discusses some near term

issues and some of the research and development issues that

NBS and DOO must address. These will be explored in FY

1987.

d. Recommend a strategy for use of a. data dictionary in CALS

planning. (Subtask II. 1.1. d)

Some preliminary discussion on these topics is in the

Preliminary Report on Data Management Standards . Section 5,

Strategy for Use of a Data Dictionary. This subtask must be

coordinated with the efforts associated with the contract

for the CALS Framework and incorporated into the CALS

Framework Report .

e. Plans for standards implementation (Subtask II. 1.1. e)

An outline was submitted in the last quarterly report and

the FY 87 SOW addresses this subtask.

2. ACCELERATE DATABASE MANAGEMENT STANDARDS EFFORT

The goal of this task (II. 1.2) is to develop a plan and

methodology for accelerating data dictionary and database

standards development and validation efforts where they are

needed to meet CALS scheduled objectives. Since this task is

dependent upon the subtask to assess CALS needs for standards

(subtask II. 1.1. c) which is not yet complete, the work on this

task will be deferred until FY 37.
One significant event that occurred during this quarter was the

vote by OSI TC97/SC21/WG3 IUDS Rapporteur Group to register the

ANSI X3H4 IRDS Command Language and Panel Interface Document as a

Draft Proposal (DP) International Standard (IS) . There had been

strong opposition to the U.S. position on the proposal; however,

through outstanding efforts and persuasion by the U.S. delegates

it was finally approved as a DP IS. If this document had not been

approved, there would have been an estimated 9-18 month delay in

progressing the IRDS through the international standards process.

To support the joint DOD/NBS CALS effort, NBS issued a contract

to Dr. Henry C. Lefkovits, the principal contributor to the IRDS

Specification, to assist NBS and X3H4 in accelerating progression

of the IRDS to a DP IS.

3. EVALUATE DOD DEMONSTRATION PROGRAMS

The goal of this task (II. 1.3) is to evaluate DOD demonstration

progrcuns in support of tasks II. 1.1 and II. 1.2. Because these

two prior tasks will be part of the FY 1937 effort, this task

will be accomplished in conjunction with other FY 1987/38 tasks.

4 . EVALUATE IDEFO/IDEFl

The goal of this task (II. 1.4) is to evaluate Air Force

experience in applying IDEFO/IDEFl functional analysis and data

modeling techniques, amd assess the feasibility of applying this

approach on a broad scale for CALS applications. Because of the

change in the focus pf CALS for the future, nothing was done on

this task and it is being dropped from the planned future work

statement

.
o? qooia suaarroqqeR SOKI %Z,

T»»d am aSMluiatn .^tdastwca , te»piags^^nl.-4gSM

a pn

yyt .fittidKhsi -M -iflpqiw#!-*-—

U.aii»iM3fc»3«U

icjtt-.iciia . stind'XC'i* ^ucb 'va jq?. .W Ittot ^3t^#TWu^^»d^

iJt, ^ I . ^ ^ ^ .. mtmrnP't' ,^'^~tT‘S a|»55

thiA

nodi H AVitittilt#* : C.OV pri*:- it. \ \ : '^»m ^n .

. «i.. r«<juirat,*i>t, rTfiffTKim irnrrnflBT'THial^

nol3»i*i4imib 4mO

^ ,*il2iX-.l^^bA«iallaXd3H;tRAAA4*j^Or€5#SS[fJfci^*ttj^¥'

Rj(saq BB\rsei TI a#d3o tDiv irol33m/t«es b^dMlic^a^^^ •“

, :Ti/V''-«-

rnUa^

»*««»v«;.<*5

jACT. atMg;aSToSa-.^ ;^

t

Arts aAJtoi^ASxiqqA B4a^

rt^ •BriAiio

aSio**'»«WW=l

ncanob «»w pofctUoo

b*nr«**tB47

.*luSi»i

•S's^

•««

^f^P"****

^ol BO*-; 5p *x»oo5 ^

pla#U»inq. (Sut«3ic rnt.i.i.4) .3ti»m»jasm

prcliMtiiMur'.'' 4iAcuSAicn cyn -n^a«; tropic*' im in

gMlijiuaua^ Qc . .JiitoJjBc nc gtAno^gla # s#ct40i!^ a . ^

$':r*cacr/ Cair:ll^ii a Oatji Picncntry, tJils; oubcaak iruat (^^if zod!T^ AjiiLnad . vl th trh# offarea . tsac *: i ata*-'. ^ i th tba* comunct

tox T2:m^ *C3^ framavnjrJt w^- u%Qvrfp-^Tn:!^<!L intc tih#

ttaatvoits.

PlBrm fcnp'^^'^4a*da Iwpiaaian^a^an (fujbtMk Ii-X.l.a) a

Xn‘ outlJUDA via a\ih:» I -tad in *>.« Xaat ejUartariy raparc

tn«' ft t7 dOV' Addraaaarti tfubnaak*

a.- Aocict^a^a i sxtMksm

rna qoftl tbU t;a€>- ,,(!-• t< , 4cv«lop 4 plan aild

£AtbO)iol'0^ rcr 9,rr.a4 dat.^ dtatiov.ar/ * tiatabaaa

•taryiarda and validation vdara- tiiay atsii

MadPd to, waar OJL3 ar!ii»julcd obj < . §i inca tbi* taak la

dapif«imt“ upon tha i-ooraak to aaswa :At^ n^oacla for atandarda

(aubtifX XX»X» wtiion ia not /at tha vork on thlaa

'1 /:a dafarrad until ft «7 . * **
COMPUTER AIDED LOGISTICS SUPPORT (CALS)

DATA MANAGEMENT STANDARDS

PRELIMINARY REPORT

Prepared For

Working Group on Specifications and Standards

Prepared By

Patricia Konig

Frank Spielman

Joan Sullivan

National Bureau of Standards

Institute for Computer Sciences and Technology

June 20 , 1986
St*, j5 ,' V|W..^?J _

• f» ’ - tf l.;v " • ,

i* '^ t C

m

•/''fY

^*J

1

{^AO) 20ITSID0J OSO.XA ftSTU^Z^fCO •

^ 'T ' - ' i’ll

' I

*Jvf»

*

* * j(

. V‘\i’'<-fe*.'., ^ "'j*

'

''?^

1

-

' ^

r r

‘

' T

,r , .l'--'^

-“ • B •. .

- ‘

' * * -3

: *-« • * ^ t

ZQRAV^dATB T^iZI130AWUi AtAO^

s > -?s

:S t -iftgM*!

nciiti»lq£‘ Anrv’

nftvilix;E rtAoC

»^jUt>ff^c "4o L'6#ii-^a XBnoiafc*vi

' "t*!*

^ * •* ‘ '

I'.idfJI* Ji ^-* ; . C'

<• ‘ti

- _ A*. . .
TABLE OF CONTENTS

INTRODUCTION 1

DATABASE CHARACTERISTICS 1

TECHNOLOGY VIEWS .... 1

FUNCTIONAL VIEWS 4

DISCUSSION OF THE VIEWS 4

PHYSICAL CHARACTERISTICS 5

DATA MANAGEMENT STANDARDS, METHODOLOGIES , AND TOOLS .... 6

DATA MANAGEMENT STANDARDS 6

DATABASE STRUCTURES AND LANGUAGES STANDARDS ... 7

DBMS BACKGROUND 7

DBMS BENEFITS 8

DBMS ENVIRONMENT 8

NDL APPLICABILITY 9

NDL SPECIFICATION 10

SQL APPLICABILITY 10

SQL SPECIFICATION 11

NDL/SQL USAGE 11

STANDARD FOR MANAGING DATA DESCRIPTIONS 12

IRDS STANDARD BACKGROUND 12

PROPOSED IRDS STANDARD 14

DATA INTERCHANGE 15

. DATA DESCRIPTIVE FILE (DDF) 16

ABSTRACT SYNTAX NOTATION. ONE (ASN.l) .... 16

METHODOLOGIES 17

DATA MODELING 17

GUIDE ON LOGICAL DATABASE DESIGN 18

DATA MODELING TECHNIQUES 19

TOOLS 19

ASSESSMENT OF STANDARDS FOR CALS 21

DDF/ASN.l 21

RESEARCH AND DEVELOPMENT ISSUES 21

DISTRIBUTED DATABASE ENVIRONMENT 21

GRAPHICS AND THE IRDS 22

DATA MODELING AND THE IRDS 22

CALS PROGRAMS AND STANDARDS 22

STRATEGY FOR USE OF A DATA DICTIONARY 3 2

IRDS BENEFITS 3 2

PLANNING PROCESS 32

DESIGN AND IMPLEMENTATION OF SYSTEMS 33

LOGICAL INTEGRATION TOOL 33

IMPACT OF CHANGE TOOL 3 4

ARCHITECTURE OF MULTI-LEVEL IRDS 3 4

IRDS STATUS 3 4

RECOMMENDATIONS 35

1
; -aviam tz

1

C 1

i

_

I

c o

1

m
COMPUTER AIDED LOGISTICS SUPPORT (CALS)

DATA MANAGEMENT STANDARDS

PRELIMINARY REPORT

1 . INTRODUCTION

This preliminary report is an interim deliverable for task II,

Database Management Support, of the National Bureau of Standards

(NBS) proposal. The report discusses four specific tasks: 1)

database characteristics, 2) data management standards,

methodologies, and tools, 3) data management issues, and 4)

strategy for use of a data dictionary in CALS.

For the short period of time that NBS has been working on the

CALS effort, there has not been sufficient time to adequately

analyze the requirements in enough depth to recommend the

standards needed to support CALS. Consequently, the emphasis on

this preliminary report is on the existing data management

standards and where they can be use in the existing CALS

applications. Future activity and reports will focus on the

standards needed to support the common DOD-wide requirements for

CALS. NBS will then be able to determine the appropriateness of

the existing standards, the standards which need to be enhanced,

and/or any new or DOD tailored" standards required for CALS.

2. DATABASE CHARACTERISTICS

There are two major methods of grouping the CALS programs/ systems

described in the Service Implementation Plans. First, there are

the technical data representations and secondly there is the

grouping by functional area. Each of these views is described

below.

2.1. TECHNOLOGY VIEWS

Future CALS systems focus on the four basic automation

capabilities depicted in Figure 1. This figure and supporting

material is based on information obtained from the "U.S. Air

Force Plan for Implementation of CALS.” Each of these areas has

tended to develop as a separate island of technology, not well

connected to the others. There is a very large infrastructure of

large-scale, batch processing and communication oriented systems

together with the related human investments and administrative

and technical procedures necessary to operate them. The scale

and complexity of the systems, the resources necessary to make

significant change, and the rapid change of the underlying

technology all represent major challenges. Accordingly, special

emphasis must be given in the CALS program to the technology and

standards activities so that CALS systems can evolve as the

technology changes. Existing standards and protocols must be

1
enhanced or new ones developed to support the interchange of data

within and between these four islands of automation.

The four technical views depicted in figure 1 are: Image, Text,

Alphanumeric, and Communications. The communications view is

being addressed in other CALS initiatives and thus is not a part

of this NBS/DoD effort. The image view is really a graphics

representation of a part or component of a weapon system. The

text view is considered to be long textual material such as a

report or manual. The alphanumeric view is highly structured

data that would be found in an inventory database.

2
FIGURE 1 BASIC CALS TECHNOLOGIES
2 . 2 . FUNCTIONAL VIEWS

The functional area or view groups the programs into three basic

categories: Product Data, Technical Support Data, and Logistic

Support Data. Each of these functional views is described in

more detail below.

The Product Data is the totality of data elements which

completely define the product for all applications over its

expected life cycle. This includes the data about the

engineering drawings and the semantic description of these

drawings, such as tolerance levels, material composition,

geometry, topology, attributes, and features necessary to

completely define a component part or an assembly of parts.

This data is image or graphics oriented with suppgrting

semantic descriptions and is increasingly developed through

the use of CAD/CAE systems. The semantic description is

often referred to as text but in reality this data may be

more structured and therefore appropriately stored in a

structured file or database.

The Technical Support Data consists of data that is used to

develop and deliver technical and operational manuals. It

is largely textual (free form) data, however it usually will

include some drawings for illustration purposes.

The Logistics Support Data consists of the data needed to

supply and maintain the weapon systems in an .operational

readiness state. Logistics support generally include

elements such as training, supply, support equipment, and

maintenance. This data is primarily structured and is

sometimes referred to as alphanumeric data. There are

several existing automated systems that support this area.

2.3. DISCUSSION OF THE VIEWS

Some of the CALS programs may primarily support only one of the

major functional areas but still require the use of several or

all of the technical views. The relationship between these two

views is described below.

For the Product Definition Data, there are essentially two areas

that are being automated: Engineering Repositories and CAD/ CAM

data. The engineering repositories are in the process of

automating the storage and retrieval of the engineering drawings.

Although the drawings are or may be the result of CAD/ CAM

systems, there is a requirement to use a structured database for

maintaining an on-line index to the drawings. For example, the

Army and Air Force DSREDS/EDCARS system is using IBM’s IMS

Database Management System (DBMS) to maintain and retrieve index

data about the drawings. Section 4 discusses the future use of

standard database and data dictionary systems in supporting CALS

.

4
For the Technical Support Data, there are also two areas where

standards may be used to enhance projects such as ATOS, 600S, and

NAPPS. Although the data is largely textual, there appears to be

a need to include certain logistics support data related to

component parts as well as index data for the large textual

files. Also, there appears to be a requirement to interface

these automated systems with other logistics support systems.

The use of database and/or data dictionary standards can help

facilitate this interface.

The Logistics Support Data is a prime candidate for evolving

database and data dictionary standards to support projects such

as UDB. Since the data is highly structured, these standards

should be evaluated for applicability to enhance the access to

and interchange of logistics data. A standard data dictionary

would greatly facilitate a user in locating logistics data in a

distributed environment. It also would provide assistance in

locating parts when specific information such as part number,

nomenclature, etc. , is not known.

2.4. PHYSICAL CHARACTERISTICS

This section will include a description of the physical

characteristics of the data required for each of the CALS

programs. NBS hopes to obtain more information about the

physical characteristics through additional visits to CALS

related installations and/or CALS workshops*. Some of the areas

to be covered in this section of the final report include:

o Types of data — textual, image, structured data (i.e.,

stock number, indexes) ; identify type of data required for

input, storage, and output

o Distributed or centralized data

o Update or query driven

o On-line versus batch updates and queries

o Indexing and cross referencing requirements for a specific

system and for interface support to other systems

o Volume of storage required

o Interfaces to other systems for data sharing or interchange

o Use of, or plans to use, standards (local, service, ANSI,

ISO, etc.) for data dictionaries, database management

systems or data interchange

5
o Name of any current data dictionary and/or database

management systems

o Security requirements

o Special disaster recovery requirements

3. DATA MANAGEMENT STANDARDS, METHODOLOGIES, AND TOOLS

There are several standards available or being developed which

can support the management of CALS data. In addition, there are

different methodologies and tools that should be evaluated for

use by the CALS programs. The data management standards,

methodologies, and tools are described in the following

paragraphs

.

3.1. DATA MANAGEMENT STANDARDS

Rapid increases in the costs associated with software development

and maintenance are driving organizations to alternative methods

of data management arid applications development, including

commercially available software, DBMSs, and application

generators. Consequently, the .advantages of standards for

software facilities and interfaces are beginning to be

recognized, in much the same manner as in the computer

communications field.

Users of sophisticated data management software need to export

their data to powerful graphics and other software systems.

Organizations who employ independent data dictionary systems need

to control data used by a DBMS, computer programs, and so-called

"fourth generation languages.” Those who purchase data

management technology expect these expensive software facilities

to support constantly changing requirements. Just as for

hardware systems, the days of user dependence on one vendor for

all of their software needs are technically and economically

impractical. The overall cost of managing data can be decreased

through the use of data management standards by: (1) aiding the

transport of personnel skills between organizations and

information systems therefore increasing productivity and (2)

more effectively interchanging data between systems.

CALS’ objectives include access to data at various nodes of a

distributed, heterogeneous database. The users on a network

should be required to know at most two database languages (a

local and a global language) . Most users should be able to work

with at most two simple schemas (local and part of the global

schema) ; users requiring more flexibility should be able to

explore the global schema, subject to security constraints, using

menus or other aids.

6
Data management standards provide a foundation for achieving the

objectives outlined above. There are existing standards related

to data interchange; but at present, there are no existing

international, national, or Federal database management software

standards. However, proposals are currently under review within

the American National Standards Institute (ANSI) and the

International Organization for Standardization (ISO) technical

committees. These proposals address four critical areas for

standards: (1) data structures and languages; (2) dictionaries

for managing and controlling complex data descriptions; (3) data

interchange; and (4) distributed data environment.

3.1.1. DATABASE STRUCTURES AND LANGUAGES STANDARDS

Over the last few years, considerable research and development

has been done on different database models including network,

hierarchical, inverted files, and relational models. Proposals

have been developed to specify database languages for the network

and relational data models. The background, benefits,

environment and standards relating to database management systems

are discussed in this section.

3. 1.1.1. DBMS BACKGROUND

The late 1960 's and 1970 's brought a flurry of database research.

Charles W. Bachman is widely recognized as one of the early

developers of the network approach to data 'management. This

approach provides a flexible scheme for linking together records

of different types using a pointer-chain structure. In 1971, the

Data Base Task Group of the CODASYL COBOL Committee proposed

network database languages for schema and subschema data

descriptions as well as for data manipulation. The Accredited

Standards Committee X3H2 adopted these proposals in 1978 as a

basis for development of a standard language for network

structured databases.

Hierarchical systems evolved independently in the 1960 's so that

currently there are many different versions in the marketplace.

Since the hierarchical model is a special case of the network

model, there is no separate standardization effort for a

hierarchical database language.

End-user oriented DBMS's, characterized by an inverted file

access technique, proliferated in the 1970 's. However, due to

inconsistent data structures and lack of a common data

manipulation strategy, there has been no attempt at

standardization

.

In 1970, E. F. Codd wrote the seminal paper that defined the

concepts of normalization and joins for relational tables. This

paper created a lot of interest in various high level query and

manipulation languages based on predicate calculus. Structured

7
Query Language (SQL) using the relational model was proposed in

1974. Over the next five years, IBM built and evaluated a

prototype implementation called System R. The technology

developed in that prototype was implemented in 1980 as SQL/DS and

then in 1983 as DB2 . The SQL database approach was widely

emulated by hardware and software vendors. In 1982, the scope of

work for X3H2 was expanded to include a standard for relational

database management systems.

3 . 1 . 1 . 2 . DBMS BENEFITS

The purpose of database language standards is to promote

portability of database definitions and database application

programs between different installations. Additional objectives

are:

- to encourage more effective utilization and management of

data by users (both end-users and programmers) by ensuring

that skills acquired on one job are transportable to other

j obs

,

- to ensure that there will be a pool of trained personnel

available to work on new development projects as well as to

maintain existing systems,

- to reduce the cost of software development by achieving

increased programmer productivity through • the use of

database technology employing standard structures and

operations, standard data types, standard constraints, and

standard interfaces to programming languages,

- to protect the software assets of the organizations by

ensuring to the maximum extent possible that database

management systems standards are technically sound and that

subsequent revisions are compatible with the installed .base.

3 . 1 . 1 . 3 . DBMS ENVIRONMENT

The DBMS approach to computer systems is an organized effort to

share structured data across a variety of applications. The data

typically consists of a large number of named data elements (such

as numbers and short textual fields) . Data elements are grouped

into various record types, with related data elements being

grouped together. Many interactive users, as well as batch

programs, access the data and modify the data concurrently. As

soon as one authorized user changes the values in the database,

all the authorized users can view the new data. Redundant data

is kept to a minimum. Redundant data often results in

out-of-date and inconsistent data for applications which use the

data but are not responsible for creating it.

8
Of course, the DBMS software has security features to prevent

unauthorized individuals from viewing or updating the data. The

DBMS also has strategies for allowing many users to update data

concurrently without causing confusion and corrupting the

database. The DBMS enforces integrity constraints and will not

allow certain invalid data values to be entered into the

database. The DBMS has utilities to restore the data (almost

completely to its original state) when the computer goes down in

the middle of heavy updating or when a disk is damaged and

becomes un-readable.

In addition, the DBMS is a productivity tool. The DBMS allows

the end-user to obtain reports without writing a program. -The

DBMS provides an interface to programming languages such as

COBOL. This allows the programmer to simplify his program by

factoring out most of the logic which deals with data access.

This logic, coded in a procedural style, is replaced with

requests for database services which are coded in a more

efficient, less error-prone, non-procedural style. In fact, the

DBMS is the major component in an integrated set of productivity

tools managed by a dictionary. The dictionary (the subject of a

separate standard) is an essential part of the DBMS, yet it

performs many other functions as well.

Each DBMS vendor offers a different mix of productivity tools,

and perhaps a different database -language. When a user needs to

share data or programs with other users or when he has to convert

his system from one vendor’s computer to another vendor-'

s

computer, the greatest expenses are incurred in converting the

data, converting the application programs (written in COBOL,

FORTRAN, etc.), and retraining personnel. Current standards

activities for dictionary and database languages focus on the

last two concerns.

There are two standards for database languages which assume

different underlying data models and are best suited for

different types of applications. In many cases, an application

could be created using either model. The two standards are the

Network Data Language (NDL) and the Structured Query Language

(SQL) , respectively. The database language specifications for

NDL and SQL are expected to become ANSI standards X3. 133-1986 and

X3. 135-1986 respectively. The final ballot closes on June 16,

1986. Both NDL and SQL are being processed by ISO as Draft

International Standards (DIS) and by NBS as Federal Information

Processing Standards (FIPS)

.

3. 1.1. 4. NDL APPLICABILITY

The network model is appropriate for highly structured

applications requiring rapid access along predefined paths. The

network model is desirable for transaction-oriented processing,

where a small portion of a very large database is accessed in

9
real time, and data from several related records musr be combined

to perform the function.

An example of access along a predefined path would be the

function of locating a book in a library. From a subject

descriptor (e.g. "optical disk”) , several titles are located.

For each acceptable title, the call number of the book is

located. For each call number, the locations of copies of the

book are determined. If the book is available now, a check-out

procedure is followed. If not, perhaps a reservation procedure

is followed. This sequence of events happens over and over, and

it would be important in a large on-line system that the data

access be as efficient as possible.

3.1. 1.5. NDL SPECIFICATION

The NDL is a specification for the logical data structures and

basic operations of the network model. The network data model

contains two basic data structures: the record and the set. The

record is the basic unit of data manipulation. Records are

stored, erased, found, modified, and connected to and

disconnected from other records. The set is the basic unit of

navigation. A user is able to move directly from -one record to

another along logical set access paths defined by the database

schema. The navigation path has to be determined during the

design of the database. Because of this, ad hoc queries

(requiring data from records which are not - connected by a set

relationship) may be very inefficient.

The NDL is a specification for interfacing DBMS software to

standard programming languages. The NDL is a programming

language intended for use by applications programmers who have

been trained to use the network model. Despite its complexity,

the network model has payoffs in the areas of performance and

enforcement of inter-record integrity constraints. A network

model DBMS will probably have a user-friendly query langauge, but

it will not be in the style of NDL.

The NDL standard has two levels of conformance, as well as the

possibility of functional conformance (with vendor-supplied

syntax) . NBS recommends, in the Federal Information Processing

Standard (FIPS) for NDL, that only Level 2 (the full standard) be

used. The NDL standard specifies interfaces to four standard

programming languages — COBOL, FORTRAN, Pascal, and PL/I.

3. 1.1. 6. SQL APPLICABILITY

The relational model is appropriate for applications requiring

flexibility in the data structures and access paths of the

database. The relational data model is desirable where there is

a substantial need for ad hoc data manipulation by end-users who

are not computer professionals, in addition to the need for

10
access by large operational systems. Prototyping and decision

support systems can take advantage of the flexibility of the

relational model. However, performance is still a problem,

although recent releases of several products offer substantial

gains in performance. The use of a database machine especially

designed for database operations may solve performance problems.

3. 1.1. 7. SQL SPECIFICATION

The SQL is a specification for the logical data structures and

basic operations of a relational data model. The primary data

structure of the relational model is a table. A table is defined

in terms of rows and columns. A row is a non-empty sequence of

values (a record) . A column is an unordered collection of values

(all the values of a given data element) . There is no predefined

navigation that the user has to follow to find the desired data.

The user can obtain data from any number of tables by joining

them together at the time he is retrieving the data. Thus, the

relational model is considered to be more dynamic and flexible.

The SQL standard also specifies interfaces between the DBMS

software and standard programming languages. SQL is

programmer-friendly, since it provides a high-level,

nonprocedural way to create, access and modify data from within a

standard programming language. In addition, the same language

can be executed interactively to obtain ad hoc reports. Because

end-users -are comfortable thinking of their data as rows and

columns . in tables, and because the data manipulation language of

SQL is English-like, SQL can be used successfully by

non-programmers without extensive training.

The SQL standard has two levels of conformance; the FIPS

recommendation is again the Level 2 (full standard) . SQL

specifies interfaces to four programming languages — COBOL,

FORTRAN, Pascal, and PL/I. In addition, conformance to SQL may

be claimed for implementations which process data manipulation

statements directly.

X3H2 is continuing the development of additional SQL features.

Among the expected features are interfaces to programming

languages Ada and C, referential integrity (inter-record

integrity constraints) , date/time data types, browsing

capabilities, etc.

3. 1.1. 8. NDL/SQL USAGE

The structures and operations specified by NDL and SQL are

typical of existing capabilities in a wide variety of database

management system products and are expected to be fully supported

by vendors in off-the-shelf products by April 1988 (the end of

the transition to the FIPS) . These specifications should be used

as a starting point in the design and implementation of

11
appropriate (or applicable) CALS systems. They should also be

considered during development of standard interfaces to other

standard products such as data dictionary, graphics, etc.

3.1.2. STANDARD FOR MANAGING DATA DESCRIPTIONS

In recent years, the concept of Information Resources Management

(IRM) has gained popularity. This philosophy recognizes that

information and all aspects of its production, dissemination,

control and cost should be treated as an enterprise resource,

just like money, real property, and people. Thus, the need to

manage and control the totality of the enterprise's information

resources was recognized. In order to support this need, the

concept of an Information Resource Dictionary System (IRDS) has

evolved. The IRDS will serve as a tool to help manage and model

the enterprise's information environment. Managing . this

environment requires the capability to document an enterprise's

information environment, to maintain an inventory of all

information entities, to support the operational aspects of the

information environment, to illustrate the interrelationship of

infoirmation entities, and to document the location of the

entities in the information environment.

The draft IRDS Standard contains the specifications for a

software package that can be used to manage an enterprise's

information environment. The IRDS Specifications are a draft

proposed ’American National Standard (dpANS) , a draft proposed

U.S. Federal Information Processing Standard (FIPS), and a

Working Document of the International Organization for

Standardization (ISO). NBSIR 85-3164, A Technical Overview of

the Information Resource Dictionary/ System , provides a technical

overview of the computer software specifications for an

Information Resource Dictionary System (IRDS) . It summarizes the

data architecture and the software functions and processes of the

IRDS.

3. 1.2.1. IRDS STANDARD BACKGROUND

In 1980, both ANSI and NBS of the United States Department of

Commerce initiated efforts to develop standards for dictionary

software. The ANSI effort began with the approval by the

American National Standards Committee for Information Systems

(X3) of a project to develop a standard for an "Information

Resource Dictionary System" (IRDS) . This resulted in the July

1980 convening of Technical Committee X3H4 responsible for

developing the standard for an IRDS.

In 1980, the NBS initiated an effort to develop a Federal

Information Processing Standard (FIPS) for Data Dictionary

Systems. Since that time, NBS has actively pursued a standard

IRDS through a series of events which are summarized as follows:

12
Prepared and disseminated the Prospectus for Data Dictionary

System Standard in 1980 which discussed the use of data

dictionary systems and described plans for developing a

FIPS.

Conducted four Data Base Directions workshops that

investigated Information Resource Management, Database, and

Data Dictionary related issues.

Conducted interviews with U.S. Federal agency personnel to

identify requirements for a Data Dictionary standard and

published the Federal Requirements for a Federal Information

Processing Standard Data Dictionary Svstem . Conducted a series of six workshops for representatives of

more that fifty U.S. Federal agencies to obtain feedback on

evolving Data Dictionary Specifications.

Prepared and disseminated an interim publication. Functional

Specifications for A Federal Information Processing Standard

Data Dictionary Svstem . for review and comment early in

1983; NBS received and analyzed comments from over 100 U.S.

Federal Government agencies.

Prepared and disseminated the draft Specifications for the

proposed Federal Information Processing Standard for Data

Dictionary Systems in August 1983.

Sponsored two workshops for vendors to review the

Specifications as they evolved. Vendors representing

seventeen of Data Dictionary Systems participated in the

workshops

.

Disseminated the interim publications and draft

Specifications to more than 200 private industry

organizations, universities, and state and local governments

in the U.S. and organizations in foreign countries.

Although ANSI X3H4 and NBS used different titles (i.e.,

"Information Resource Dictionary Systems" and "Federal

Information Processing Standard for Data Dictionary Systems")

,

the two groups had identical goals and a similar development

approach.

The two efforts came together in September 1983 when X3H4 voted

to adopt the August 1983 version of the draft Federal Information

Processing Standard for Data Dictionary Systems as its Base

Document. Since that time, the Base Document has evolved to its

present form as a draft proposed American National Standard

(dpANS) and a draft proposed FIPS for an IRDS.

13
The dpANS and the FIPS IRDS underwent public review and Federal

agency review in the latter part of 1985. Accredited Standards

Committee X3H4 made changes to the IRDS specifications, based on

the public and Federal review comments, during the first four

months of 1986. Another public review period, of the recent

changes, will take place June 2 - September 2, 1986. NBS expects

that the IRDS, number X3.138, will become an American National

Standard and a FIPS in early 1987.

In January 1984, the ISO Technical Committee 97 approved Work

Item 97.21.6 for IRDS. The Work Item is assigned to Subcommittee

21, Working Group 3 (TC97/SC21/WG3 ) for the purposes of

progressing it to become a future International Standard.

As a result of the joint DoD/NBS CALS effort, NBS will issue a

contract to Dr. Henry C. Lefkovits, the principal contributor to

the IRDS Specification, to assist NBS and X3H4 in formulating a

U.S. position that will help accelerate progression of the IRDS

to a Draft Proposed (DP) International Standard. The

recommendation to progress the IRDS to DP status will be voted

upon at the September 15-19, 1986 meeting of TC97/SC21/WG3

.

3. 1.2. 2. PROPOSED IRDS STANDARD

The IRDS Specifications contain the most commonly used facilities

of existing data dictionary systems and ^ represent a

state-of-the-art level of technology in dictionary systems. The

proposed . base level IRDS Standard includes specifications for a

"Core” dictionary system plus specifications for optional

"Modules'*. Although the IRDS Modules interface with the Core,

they are independent of one another. Organizations, therefore,

need to acquire only those modules that supporr their

requirements. After this base level standard is finalized,

development of additional modules will begin.

The core IRDS contains the basic capabilities that organizations

generally need. These core specifications are intended for

implementation on large microprocessors and small minicomputers

as well as large computers. The five optional modules in the

IRDS, that provide additional facilities, contain specifications

for: Basic Functional Schema; IRDS Security; Extensible Life

Cycle Phase; Procedure Facility; and Application Program

Interface.

To provide additional flexibility in the use of the core IRDS,

the specifications allow for the capability to customize or

extend the types of data that can be stored in the dictionary.

Organizations can use this capability to describe unique

resources and define organization specific system development

methodologies

.

14
The core IRDS contains two user interfaces: a menu-driven

"Panel” interface and a "Cominand Language" interface. The Panel

interface is designed to support interactive processing,

especially by inexperienced dictionary system users. This

interface leads users down a structured path of screens (panels)

that result in the execution of dictionary system functions.

Thus, non-technical staff as well as technical staff will be able

to execute certain core IRDS functions without having to

understand or use the more complex syntax of the Command Language

interface. The Command Language interface may be used in either

a batch or interactive mode. Because each of the user interfaces

will be similar in all IRDS implementations, individuals will be

able to use different IRDS systems without extensive retraining.

A vendor is in compliance with the core standard and three of the

five modules if only one of the user interfaces is provided. Two

of the modules, the Procedure Facility and the Application

Program Interface require the Command Language. If both user

interfaces are provided, both must comply with the standard.

The IRDS Specifications include an IRD to IRD Interface Facility

which provides a controlled method of moving data from one

standard dictionary to another standard dictionary. Organizations

using the standard IRDS could, for example, extract data from

decentralized dictionaries and add it to a central dictionary

that focused on organization-wide data management. The specified

IRD to IRD Interface supports this transportability of data even

in the case where the standard IRD systems are developed by

different vendors and are resident on different hardware systems

at different locations.

3.1.3. DATA INTERCHANGE

Data interchange standards have been developed to provide a

mechanism for data structures, structured database and files, to

be easily moved from one computer system to another, independent

of vendor or model. Data structures to be interchanged can vary

significantly in complexity and size. There is a need for a

common method to accomplish these interchanges. It is also

desirable that any medium (such as a communication line, a

magnetic tape, a disk pack, a flexible disk, etc.) can be used

for the physical interchange. If possible, all information

necessary to successfully recreate the structure in the target

system should be contained within the information transported.

To meet these needs, two standards have been developed which are:

1) Specification for a Data Descriptive File (DDF) for

Information Interchange, ANSI/ISO 8211, and 2) Abstract Syntax

Notation. 1, ISO Draft International Standard (DIS) 3824/8825.

15
3. 1.3.1. DATA DESCRIPTIVE FILE (DDF)

The DDF standard establishes media and machine independent

formats and data record formats for interchanging information

between computing systems. The standard is intended for use with

physical recorded media as well as with communications media.

The contents in the user data structure can be of any

internationally recognized character set and coding and are

interchanged in a transparent fashion. The intermediate

stmcture through which the information passes is designed for

interchange purposes only and is not intended to be used for

general processing.

The approach used for the standard was to define an interchange

format into which the sender's information is mapped and conveyed

to the receiver's system. Upon receipt of the information ‘ in the

interchange format it is then mapped into the receiver's format

without loss of structure and content. The standard specifies a

method to describe a robust interchange structure which can

accept most user data structures.

Most data structures in common use can be described and

interchanged using this standard. The structures within the

interchange file can be of the following forms: elementary data,

vectors, arrays, and hierarchies. The elementary data may be

character strings, bit strings, or various numeric forms. User

file structures such as sequential, hierarchical, relational and

indexed can be converted into the. interchange structure. NetWork

structures can be interchanged but additional pre-processing and

post-processing is necessary to preserve logical linkages.

The standard provides for three interchange levels from which the

users may choose, based on the complexity of their data

structures. The first interchange level supports multiple fields

containing simple, unstructured character strings. The second

level supports fields containing structured data and a variety of

data types. The third level supports hierarchical data

structures

.

3. 1.3. 2. ABSTRACT SYNTAX NOTATION. ONE (ASN.l)

ASN.l is an ISO Draft International Standard (DIS) , ISO DIS

3324/8825. It is more general than the DDF interchange forms in

that it is a "language" for defining general data structures

rather than a syntax for specifying columns and row occurrences

of an underlying tabular structure. ASN.l allows for the

interchange of any data structure that the user specifies. The

specification for the language syntax is separate from the basic

encoding rules. The language syntax, ISO DIS 3824, provides the

specifications that a user must use to define the data structure.

The basic encoding rules, ISO DIS 8825, specify the encoding

methodology for the data contained in the data structure. Using

16
this approach, information can be exchanged in two parts. The

first part is a character string that defines a specific data

structure, and the second part defines a string of octal numbers

that is an encoding of the values in the defined data structure.

The interchange of any data structure defined by the ASN.l syntax

is accomplished using three elements: Type, Length, and Value.

The Type is a bit sequence that identifies a data type previously

defined by the language syntax. The Length is an integer that

declares the length in bytes of a data occurrence. The Value is

the actual encoding of the data occurrence. Any data structure

definable via the ANS . 1 syntax can then be encoded as a nested

hierarchy of type/length/value triples.

The ISO ASN.l DIS uses the CCITT X.409 Message Handling Facility

notation. However, the ASN.l provides additional alternatives to

the language and syntax notation that are not available in the

X.409 standard.

3.2. METHODOLOGIES

CALS will require the use of several different methodologies.

There must be methodologies to support the way that the

information systems are to be constructed and later maintained.

The life cycles of the information systems must be established

and integrated with weapon system life cycle management. The

’Configuration of information systems also must be managed. The

data dictionary , ultimately the standard IRDS , is the tool that

will facilitate the management of these methodologies.

3.2.1. DATA MODELING

Data Modeling is the process of constructing a logical

representation of data and the associations among data. The data

model can be used to represent data structures throughout an

organization, or can represent a single logical database

structure. It describes the data structure independent of the

targeted hardware or software environment. The data model of an

organization is frequently referred to as the organization’s

information model or business systems model. A person or group

of people responsible for constructing a data model must analyze

the information requirements, develop diagrams and charts, and

coordinate systems development with the end-users, database

administration, and data processing staff.

There are numerous data modeling methodologies that are

available. Computer support for data modeling is almost

mandatory, given the size and complexity of the data model and

the various external views, as well as the frequent changes

resulting from the new requirements which are folded into the

model on a continuing basis. There is a real need for a

consistent approach and notation, as well as standard automated

17
support tools and interchange formats. Standards for data

modeling should include data modeling methodology, IGES, SGI4L,

IRDS, SQL and possibly NDL. NBS has written a guide on logical

database design (data modeling) which describes a generic

methodology for building a data model. The Guide and more

specific data modeling techniques are discussed below.

3. 2. 1.1. GUIDE ON LOGICAL DATABASE DESIGN

NBS Special Publication 500-122, Guide on Logical Database

Design , discusses an iterative methodology for Logical Database

Design. The guide describes the design methodology for

determining the hardware-independent, software-independent

structure for an organization's data requirements. The objective

is to decrease the effort required to maintain organizations'

information processing systems.

3 . 2 . 1 . 1 . 1 . BACKGROUND

Logical Database Design (LDD) is the process of determining the

fundamental data structure needed to manage an organization's

information resource. LDD provides a structure that determines

the way that data is collected, stored, and protected from

undesired access and modification. Since data collection,

storage, and protection are costly, and since restructuring data

generally requires expensive ^ revisions to programs, it is

important that the LDD be of high quality.

A high quality, LDD will be; (1) internally consistent, to reduce

the chances of contradictory results from different information

systems; (2) complete, to ensure that known information

requirements can be satisfied and known constraints can be

enforced; and (3) robust, to allow adaptation of data structures

in response to foreseeable changes in the information

requirements. To fulfill these considerations, a LDD should be:

(1) independent of any particular application, so that all

applications can be satisfied; and (2) independent of any

particular hardware or software environment, so that the data

structure can be supported in any environment. A good LDD will

ensure that modularity, efficiency, consistency, and integrity

are supported in the subsequent operational database,

3. 2. 1.1. 2. LDD METHODOLOGY:

The Logical Database Design (LDD) methodology described in the

Guide includes four phases: Local Information-flow Modeling,

Global Information-flow Modeling, Conceptual Schema Design, and

External Schema Modeling. These phases are intended: (1) to

make maximum use of available information and user expertise,

including the use of a previous Needs Analysis and (2) to prepare

a firm foundation for physical database design and system

implementation. The methodology recommends analysis from

18
different points of view—organization, function, and event—in

order to ensure that the logical database design accurately

reflects the requirements of the entire population of future

users. The methodology also recommends use of a data dictionary

system, preferably a standard IRDS, in order to conveniently and

accurately handle the volume and complexity of analysis and

design documentation. The report places the methodology in the

context of the complete system life cycle.

3. 2. 1.2. DATA MODELING TECHNIQUES

CALS is currently using data modeling methodologies to suppori:

the CAD/CAM area. For example, the Air Force is using IDEFl in

the IDS program. IDEFl is a top-down approach using the Entity

Relationship technique. The NBS AMRF is using another technique

called SAM*. NIAM is another technique which is a bottom-up

approach to data modeling. A description and discussion of these

methodologies will be included in the final report.

3.3. TOOLS

In the arena of data management tools, . there are several

commercially available tools that can be used by CALS. These

tools can be grouped into Database Management Systems (DBMS)

,

Data Dictionary Systems, and Data Modeling. In the discussion on

these tools, some vendors and commercial products are listed.

The inclusion or omission of a particular company or product does

not imply either endorsement or criticism by the NBS.

NBS has worked with most of the vendors cited in the following

paragraphs both on the relevant Accredited Standards Committees

and by conducting vendor workshops. The forthcoming NDL, SQL,

and IRDS standards reflect a technical consensus of the major

vendors. None of the vendors have yet made formal announcements

that they intend to conform to the standards. However, several

vendors have told NBS confidentially that they plan to either

change their existing system or develop a new system in order to

conform, principally to the SQL and IRDS standards. Some vendors

also are developing conversion software that will help their

existing customers migrate from the current system to the

standard data dictionary/database system. NBS will provide

additional information on this subject in the Plan to Expedite

the Development and Implementation of Data Management Standards . There are many commercially available DBMSs on the market. Many

of the vendors support the relational model, especially in the

microcomputer environment. Most of the vendors of these products

will partially support SQL. Most packages will not run on both a

micro or mainframe; however, ORACLE is one example of a package

that will run on both microcomputers and mainframe computers.

Other products which run under UNIX operating systems will run on

either mainframe computers or microcomputers operating under a

19

m
UNIX system. There are vendors that support the network data

model; however these systems primarily run on mainframe

computers. Some mainframe DBMS software packages described in

the Auerbach Data Base Management publication include:

Vendor Product

Cincom Systems , Inc

Applied Data Research, Inc

Cincom Systems, Inc

IBM Corp

Computer Corp of America

Cincom Systems, Inc

Infodata Systems, Inc

Burroughs

Oracle Corp

IBM Corp

Relational Technology, Inc

Mathematica Products Group

Software AG

IBM Corp

TOTAL

ADR/DATACOM/DB

TIS

IMS/VS

Model 204

ULTRA

INQUIRE

DMS II

ORACLE

SQL/DS

INGRES

RAMIS II

ADABAS

ADF-II

There are several data dictionary systems on the market. Some

come with DBMS packages while others are stand alone or

independent systems. Some vendors even offer products that

support an integrated environment, where the data dictionary,

DBMS, and other functions communicate with each other. Some

packages include:

Vendor

Applied Data Research, Inc

Cincom Systems , Inc

Computer Associates International, Inc

Computer Corp of America

Cullinet Software, Inc

D&B Computing Services

Infodata Systems, Inc

Information Builders, Inc

IBM Corp

Manager Software Products

(MS?) , Inc

Martin Marietta Data Systems

M. Bryce & Associates, Inc

Oracle Corp

SAS Institute, Inc

Software A.G. of N.A. , Inc

TSI International

Uccel Corp

Product

Datadictionary

TIS Directory

Integrated Data Dictionary

Dictionary/ 2 04

Integrated Data Dictionary

Nomad2 Data Dictionary

Edict

Focus Data Dictionary

DB/DC Data Dictionary

Datamanager

RAMASTSR

Information Resource Manager

Integrated Data Dictionary

Integrated Data Dictionary

Predict

Data Catalogue II

UCC Ten Data Dictionary

20
The above list of vendors was extracted from a report. Data

Dictionaries: Knowledae-Bases for the Future , prepared by

International Data Corporation (IDC)

.

Some vendors offer products that support data modeling. The data

modeling support ideally should be integrated with a data

dictionary system. Some of the vendors that support data

modeling with their data dictionary systems include MSP ' s DESIGNMANAGER and Data Catalogue II ' s FACET.

4. ASSESSMENT OF STANDARDS FOR CALS

The data management standards must be assessed in terms of

current, intermediate and long term capabilities in meeting CALS

objectives. Some of the issues involving standards and the CALS

effort are addressed below.

4.1. DDF/ASN.l

There are some issues that may impact the near term

implementation or selection of standards related to CALS

projects. One of the issues that has a near term impact is in

the area of data interchange, primarily for structured data.

That is, should a DDF or an ASN.l be used for data interchange?

If both data interchange standards are used in CALS, what impact

will this have? In the IRDS specification, the data- interchange

between IRDSs must be done using the' DDF standard. However, the

interchange of engineering data, as specified by NBS ' Automated

Manufacturing Research Facility (AMRF) effort, is done using

ASN.l.

Further analysis is required to determine if both should be used

in the respective areas or whether only one should be used.

Assessments on the use of data interchange standards such as DDF

or ASN.l are currently not explicitly included in the NBS/CALS

statement of work.

4.2. RESEARCH AND DEVELOPMENT ISSUES

There are several research and development issues that NBS/CALS

must address. The issues identified to date are: (1)

Distributed databases and IRDS, (2) Integration of Graphics

standards with the IRDS standard, and (3) Data Modeling support

by the IRDS.

4.2.1. DISTRIBUTED DATABASE ENVIRONMENT

The overall objective of CALS is to be able to access data from

various nodes of a distributed, heterogeneous environment. In

other words, a user logged onto a system using a remote terminal

could first determine what data is available and secondly could

21
then access the data without being concerned abour where that

data is located or the characteristics of that data.

First of all, a strategy for the use of a data dictionary or IRDS

needs additional evaluation, research, and the subsequent

development of another IRDS module. The existing IRDS will

provide the CALS users with the necessary knowledge to determine

what data is available and where it is located. The strategy for

using the IRDS is discussed in the next section. Specifications

for supporting database management systems in a distributed

environment also need to be developed.

Additional evaluation and research is needed in the area of

updating and retrieval of distributed data. Within ISO, the

Remote Data Access (RDA) Rapporteur Group of TC97/SC21/WG3 , is

using, as their base document, the Technical Report, European

Computer Manufacturers Association (ECMA) TR/30. This report is

a specification for a Remote Data Access Service and Protocol

(RDASP) . It defines: (1) a database model, (2) operations on

the database model, and (3) the protocol to support the

operations service and mapping to the underlying presentation

service. This specification is targeted at database systems that

support the Relational Model (SQL) . This group initiated work on

the ISO standard in late 1985 and additional development is

needed. Through the CALS effort, DoD could have a significant

impact on the content of the future standard.

4.2.2. GRAPHICS AND THE IRDS

The CALS effort is heavily reliant upon graphics support,

especially in the area of product data definition and CAD/ CAE.

With the data dictionary or IRDS being the overall knowledge base

for knowing what data is available and where it is located, the

CALS IRDS must support graphics . There needs to be a

specification for an IRDS optional module to support graphics

data types and an interface to provide data definitions to a

standard graphics system.

4.2.3. DATA MODELING AND THE IRDS

CALS is currently using data modeling methodologies to support

the CAD/CAM area. For example, the Air Force's IDS is using

IDEFl. The NBS AMRF is using another technique called SAM*.

Specifications for an IRDS optional module is needed to provide

appropriate analyses and reports for CALS data modeling.

4.3. CALS PROGRAMS AND STANDARDS

Each of the CALS programs have associated with it data which must

be processed. This data is categorized into a functional view

and one or more of the technical views. There are standards that

may be appropriate for the different CALS programs. Each CALS

22
program that was reviewed during the two trips is briefly

described below along with identification of the functional and

technical view most appropriate for that program. The

descriptions of the goals and objectives came from the

implementation plans of each respective service. The NBS

comments are general notes. This section will be expanded in the

final report after additional technical review and analysis.

Project Title : Automated Technical Order System (ATOS)

Goals and Objectives: ATOS is being implemented to improve

generation, storage, and distribution time associated with

AF TO's. A major goal is to significantly reduce the cost

of AF Technical Order acquisition and management.

Functional View: Technical Support

Technical View: Image and Text

NBS Comments: There probably will be a need for an index to

the ATOS data. If so, either IRDS and/or SQL standards

should be appropriate. Additional information and analysis

is needed to determine the extent to which a part of the

Technical Order and Change Order data is ’’structured" versus

textual data. If part of the data is structured, then the

NDL or SQL standards should be appropriate.

Project Title : Engineering Data Computer Assisted Retrieval

System (EDCARS)

Goals and Objectives: The purpose of EDCARS is to make

significant improvements in the quality, retrievability , and

cost of Engineering Data.

Functional View: Product Definition Data

Technical View: Image

NBS Comments: The IBM’s IMS database management system is

being used to develop a "central index" or directory to the

1.5 million drawings stored on optical disk storage. For

compatibility across the services, either the IRDS or

SQL/NDL standard should be considered.

Project Title : Integrated Design Support System (IDS)

Goals and Objectives: The IDS objective is to apply

advanced information management technology to integrate

engineering data into what will appear to the user to be a

"single" data base. IDS, therefore, will mesh with the

Integrated Computer Aided Manufacturing (ICAM) program,

ATOS, EDCARS, UDB, IMIS and LIMSS.

23
Functional View: Integrated management view

Technical View: Image, Text, and Alphanumeric

NBS Comments: A database of commonly used parts is being

used to create the illustrations for the technical orders.

This database of drawing information could be indexed and

managed by the IRDS, SQL, or possibly NDL.

Project Title : Integrated Maintenance Information System (IMIS)

Goals and Objectives: To promote effective aircraft

maintenance by enhancing capabilities of base level

maintenance technicians through tailoring information to

support specific needs. IMIS will provide a single

interface to all required information and will supplement

on-aircraft diagnostics to provide full-fault isolation

capabilities

.

Functional View: Logistics Support

Technical View: Image, Text, and Alphanumeric

NBS Comments: The Air Force is reviewing the content and

format of the Technical Orders. There are plans to have

’’automatic'* cross-referencing/ indexing to maintenance

information. The IRDS or SQL standard should be appropriate

to store and retrieve the results. More information is

needed on Technical Order and maintenance data to determine

if the IRDS or SQL standard is appropriate for these

categories of data.

Project Title : Geometric Modeling Applications Interface (GMAP)

Goals and Objectives: The GMAP program will enable the

digital communication of product definition data describing

air-cooled jet engine turbine blades and disks throughout

the entire product life cycle including engineering

analyses, manufacturing, logistics, and depot support. GMAP

objectives include: to create a definition and model of

engine blade and disk product data; to survey the

state-of-the-art geometric modeling systems and application;

to define the minimum requirements of a geometric modeling

system; and, to demonstrate the integration of a prime

contractor with its vendors and Air Force Logistics depots.

Functional View: Product Definition Data

Technical View: Image

24
NBS Coiments: The IRDS appears appropriate for the

Conceptual Schema required by GMAP. More information is

needed about the "information classes" of entities/ features

to determine if any of the IRDS, SQL, or NDL standards are

appropriate. In any case, the IDEFl* ER model is being used

and the IRDS would be appropriate for supporting that data

modeling environment.

Project Title ; Unified Data Base for Acquisition Logistics (UDB)

Goals and Objectives; The objective of the UDB is to

develop, demonstrate, and evaluate a logistics information

database system which will assist weapon system designers

and logisticians in incorporating logistics considerations

into the early design of weapon systems. The UDB will

provide logisticians with a flexible, efficient database

application system designed to ease the burden of

documenting iterative LSA tasks.

Functional View; Logistics Support

Technical View; Alphanumeric

NBS Comments; The Air Force is currently using Cullinet’s

IDMS database management system and the IDD data dictionary.

Therefore, the IRDS and either the NDL or SQL standard would

be appropriate for compatibility and exchange of data with

other systems. There is a need for a graphics interface to

IRDS and the appropriate database standard.

Project Title ; Product Definition Data Interface (PDDI)

Goals and Objectives; The PDDI program will establish a

digital interface between engineering and manufacturing

which replaces the engineering part drawing. PDDI

objectives are; to evaluate the Initial Graphics Exchange

Specification (IGES) ; to specify manufacturing information

needs from engineering; to create a prototype interface to

exchange product definition data between dissimilar systems

in a factory, and to demonstrate the program in a production

environment with in-house manufacturing systems and

commercial CAD/ CAM Systems. PDDI seeks to lower the costs

of creating, managing and communicating part descriptions

for aircraft systems by allowing the data to be transmitted

in a standard, public domain format.

Functional View; Product Definition Data

Technical View; Image

NBS Comments: The IRDS appears appropriate for the

Conceptual Schema required by PDDI. More information is

25
needed about the "information classes" of entities/features

to determine if any of the IRDS, SQL, or NDL standards are

appropriate. In any case, the IDEFl* ER model is being used

and the IRDS would be appropriate for supporting the data

modeling environment.

Project Title ; Integrated Information Support System (IISS)

Goals and Objectives: To establish and operate a test bed

to validate the concept of Integrated Applications supported

by an Integrated Information Support System (IISS) in a

heterogenous computer and data base environment. In

addition, the project is using a set of interim standards

and procedures to guide the enhanced design of the IISS.

The set of requirements established from 1984 prototype and

1986 production implementation designs will be the basis for

enhancements to the IISS. The test bed will serve as a

technology transfer vehicle, training facility and a central

development site. The test bed realizing the full benefits

will also serve as a facility to assist the DoD Community in

achieving these benefits faster and with less risk.

Functional View: Integrated Management View

Technical View: Image, Text, and Alphanumeric

NES Comments: IRDS; SQL, and probably NDL are all

applicable. General Dynamics is currently using 300 IMS

databases on the shop floor. They are currently using a

"sophisticated" data dictionary system with the IDEFl* model

"sitting on top." The neutral data manipulation language is

SQL based.

Project Title : ADP System for Technical Data Management and

Engineering (MASTER)

Goals and Objectives: MASTER is a system to support repair

parts procurement. MASTER provides an automated system for

gathering, updating and storing technical information to be

used for the development of requirements packages for repair

parts acquisition. MASTER provides listings of item

configuration documentation, i.e., specification lists,

drawing lists, packaging data sheets, engineering change

proposals (ECP's) etc., and its condition status. In

addition, MASTER provides a code to relate the status of

data contained on the listing to the type of procurement the

technical data will or will not support without further

review or documentation updates. Data for MASTER is derived

from the Technical Data/Configuration Management System

(TD/CMS) , Budget Stratification System, manual input, and

contractor provided part number data.

26
Functional View: Logistic Support

Technical View: Alphanumeric

NBS Comments: The data supporting this project is stored

in computerized files. There is a requirement to maintain a

part number to document and cross-reference parts listings.

In the future, this system is scheduled to be redesigned.

At that time, the IRDS, SQL, and NDL standards should be

considered.

Project Title : Automated Publications Production System (APPS)

Goals and Objectives: Provides a Research and Development

tool in automated publishing technology to interface

contractors and MSC's, and utilize consolidated government

data bases for increased publication production

productivity

.

Functional View: Technical Support

Technical View: Text and Image

NBS Comments: There probably will be a need for an index

to technical data. The IRDS and/or SQL standard would be

appropriate. Additional information and analysis is needed

to determine the extent to which the technical data is

structured versus text. NDL or SQL would be appropriate for

any structured data.

Project Title : Digital Storage and Retrieval Engineering Data

System (DSREDS)

Goals and Objectives: The DSREDS program will provide

engineering drawings and related data in an easily used

electronic form for developers/producers of Army materiel

and for input to other systems needing this type of

information. Goals include yearly cost savings of 21. 5M;

reduction in administrative lead time and drawing revision

costs; standardized system with capacity to support through

the 90 's.

Functional View: Product Definition Data

Technical View: Image

NBS Comments: See EDCARS

Project Title : Electronic Maintenance Publications System (EMPS)

Goals and Objectives: The Electronic Maintenance

Publications System is a program designed to evaluate the

27
concept of paperless technical publications by (i) obtaining

RAM data on, and user response to, paperless technical

publications through limited fielding of EMPS , (2) learning

to prepare electronic technical publications and (3)

collecting cost-effectiveness data.

Functional View: Logistics Support

Technical View: Image, Text, and Alphanumeric

NBS Comments: This system appears to require all three

views of the technical data: Image, Text, and Alphanumeric.

It definitely requires Image and Text data. There probably

will be a need for an index to the technical data. If so,

the IRDS and/or SQL standard would be appropriate. In

addition, the technical data also contains information about

part numbers. This information must be obtained or passed

to other systems containing logistics support data. This

data is structured and can be contained in a structured

database. The SQL or NDL standard would be appropriate for

this type of data.

Project Title : Personal Electronic Aid for Maintenance (PEAM)

Goals and Objectives: This is a joint effort with the Army

to develop test and evaluate an authoring and electronic

portable field maintenance system. The Navy project is

focused on the extensive use of graphics displays . as

troubleshooting aides for use by the maintenance technician.

The system is being designed to provide the technician with

a checklist of maintenance actions and step-by-step

procedures in combined text and graphics format.

Functional View: Logistics Support

Technical View: Image and Text

NBS Comments: The IRDS, SQL, or NDL standard could be used

in conjunction with the authorizing system to facilitate the

associated logistics functions. Additionally, SQL may be an

applicable tool for use by the maintenance technicians, even

though a porrable computer would not be large enough to

support a full function DBMS.

Project Title : Computer-Based Aide for Troubleshooting (CBAT)

Goals and Objectives: The increasing sophistication of

modern Navy weapon systems has resulted in an exponential

growth in the technical information required for support.

This phenomenal growth often does not include the additional

documentation required to support maintenance of the

advanced electronic circuitry beyond the point where the

28
automatic test equipment (ATE) and built- in-test (BIT) leave

off. Complete reliance on ATE and BIT forces the

technician, when ATE and BIT fail, to fault isolate without

any additional technical information. While the amount of

data is, in itself, a problem, complexity in the

presentation of information aggravates it. Specifically, it

is the user’s access to an interaction with the technical

information that is formidable.

The objective of this project is to define, describe, and

evaluate the technical information variables that contribute

to effective maintenance performance by: (1) development of

a technology base for technical informiation design and

delivery, and (2) design, development, test, and

implementation of an intelligent user defined technical

information system.

Functional View: Logistics Support

Technical View: Image and Alphanumeric

NBS Comments: CBAT is similar to PEAM insofar as it needs

support for both authoring and electronic delivery of

information. The IRDS, SQL, and/or NDL should be

considered.

Project Title : Navy Integrated CAD-CAM

Goals and Objectives: This project will establish hardware

and software system specifications, develop program

documentation and execute consolidated acquisition and

integrated installation of CAD-CAM systems at principal

engineering and industrial activities performing

design/maintenance of ships, systems and facilities.

Functional View: Product Definition Data

Technical View: Image

NBS Comments: The indexes which accompany the CAD/ CAM

drawings are not automated. The use of a DBMS to manage

these indexes would be a step in the right direction;

however, a better solution would be a DBMS integrated with

the CAD-CAM software, so that selected text embedded in the

drawings is automatically indexed, and so that all text is

accessible via full-text search. The IRDS, SQL and NDL

standards should be reviewed for applicability.

Project Title : Computer-Aided Integrated Logistic Life Cycle

Support (Computer Aided Logistical Support Analysis) (CALSA)

29
Goals and Objectives: Apply RAM across the spectrum of

logistic support analysis and the logisricai support

analysis record over the life cycle of the acquisition. To

provide front end and supportability inputs and

considerations to the design and engineering process for the

acquisition process.

Using the government owned CALSA (with the MK 50 Lightweight

Torpedo Program as a testbed) , the first steps have been to

record with current primary emphasis on the timely spare

provisioning process, reviews and audits.

Follow-on efforts will integrate RAM/CAD on an interactive

basis utilizing existent databases for corporate memory to

provide front end inputs to the design and engineering

process

.

Functional View: Logistics Support

Technical View: Image and Alphanumeric

NBS Comments: The CALSA project should consider using an

IRDS to support a user community encyclopedia of acronyms

and definitions and to integrate access to a database of

logistical support analysis records. SQL should be

considered for most of the ad hoc reporting requirements.

Project Title : Engineering Drawing Automated Storage and

Retrieval Equipment (EDASRE)

Goals and Objectives: The DLA Engineering Drawing

Automated Storage and Retrieval Equipment (EDASRE) project

is directed toward automating four technical data

repositories to support information requests and

reprocurement actions. The repositories include the Defense

Electronics Supply Center (DESC) , Defense General Supply

Center (DGSC) , Defense Industrial Supply Center (DISC) , and

Defense Construction Supply Center (DCSC) . Repository

functions of each of the Supply Centers are established

under DoDI 5010.12, Technical Data Management Program. The

DLA EDASRE program is comprised of two phases. The first

phase provides DLA with an interim capability to fully

automate processing of aperture card files at the four

technical data repositories, thus eliminating the need to

manually store and retrieve aperture cards in response to

customer requests for technical information.

Phase 2 of the EDASRE program will incorporate DLA planning

to transition from Phase 1 interim automated aperture card

systems into DSREDS/EDCARS digital storage and retrieval

environment for the processing of engineering drawings and

reprocurement bidset packages. It is the DLA's intent upon

30
completion of the EDASRE Phase 2 planning to acquire digital

capability through any existing DoD contract that may be

used as a means for acquisition. Otherwise, DLA will look

toward the DSRED/EDCARS experience in defining digital

processing requirements and acquisition criteria before

taking any competitive procurement action.

Functional View: Product Definition Data

Technical View: Image

NBS Comments: In planning for automating the drawing

repositories, there is a need to develop a "central index"

or directory to all of the engineering drawings. The IRDS

or SQL/NDL standard should be considered.

Project Title : Modernized Parts Control Automated Support System

(MPCASS)

Goals and Objectives: The Defense Logistics Agency Parts

Control Automated Support System (PCASS) currently has many

manual functions involved in the administration and

performance of the DoD Parts Control Program, DoDI 4120.19,

MIL-STD 965. This program supports Military Parts Control

Advisory Group (MPCAG) operations. The MPCAGs are located

at four different Defense Supply Centers (DSCs) , which

evaluate and make recommendations on parts proposed for use

in systems being developed by the DoD and other Federal

agencies. The MPCAG *s responsibilities are to promote

standardization through the use of military specification

parts

.

Objectives

1. Provide an on-line database to replace PCASS sequential

tape files, allowing near-real-time processing and ad hoc

query capability for the military services and industry.

2. Provide for almost 100% growth to 1,000 contracts

supported per year, with improved response time.

3. Automate the remaining manual/paper reference files,

including status of Mil/Spec standard preparation (over

1,200 per year) and Qualified Products Lists (over 200

lists)

.

4. Provide telecommunications for system input/output, and

for interface with reference files in other DoD and industry

ADP systems.

Functional View: Logistics Support

31
Technical View: Alphanumeric

NBS Comments: The IRDS and either NDL or SQL would be

appropriate to enhance compatibility and exchange of data

with other systems.

5. STRATEGY FOR USE OF A DATA DICTIONARY

The Data Dictionary or Information Resource Dictionary System

(IRDS) will be a valuable support tool for CALS. The benefits of

an IRDS and its use in CALS are discussed in the following

paragraphs

.

5.1. IRDS BENEFITS

A preliminary cost-benefit overview prepared for ICST estimates

that the U. S. Federal Government could realize over $120 million

(in constant 1983 dollars) in benefits by the early 1990 *s from

use of a standard IRDS. Opportunities identified for cost

reduction and avoidance included the following:

Improved identification of existing, valuable information

resources that can be used by others in the same

organization or shared with other organizations

Reductions of unnecessary development of computer programs

when suitable programs already exist

Simplified software and data conversion through the

provision of consistent documentation

Increased portability of acquired skills resulting in

reduced personnel training costs

5.2. USE OF IRDS IN CALS

In the arena of information systems management for CALS, the IRDS

can be used in the planning process, the design and

implementation of information systems, the integration effort,

and the assessment of impact of change.

5.2.1. PLANNING PROCESS

The IRDS can be used in the planning process for documenting and

tracking CALS systems and associated funding requirements,

contract awards, and implementation status. The IRDS can serve

as the focal point for basic knowledge about all the CALS

systems. It can contain some of the basic funding requirements

about information systems, although more specific funding

information may be contained within the Planning, Programming,

Budgeting System (PPBS) . The IRDS can interface with zhe PPBS

for more specific budget information. Likewise, general

32
information about contract awards can be maintained in the IRDS

and the IRDS can interface with other systems to obtain more

specific contract information. The information on implementation

schedules can be maintained in the same fashion. More specific

schedules would be obtained from a project management system.

5.2.2. DESIGN AND IMPLEMENTATION OF SYSTEMS

The IRDS can be used during the analysis, design, development,

implementation, operation, and maintenance of CALS information

systems. Each of these areas is discussed below.

During the analysis phase, the IRDS can be used to analyze

and document the overall information needs and the data

requirements. The strategies of CALS management can be

translated into logistics functions that are needed and then

into actual application systems. The data requirements can

be translated into data models to support the logistics

functions

.

During the design phase, the logistics functions can be

further defined in terms of more detailed and specific

events that must occur. The data models can then be

expanded to include the data elements required to support a

CALS system

.

During the development phase, the IRDS can be used to

support the development of screens, reports, and other

inputs, programs, and outputs. The physical database can be

created from the previously created data model.

At implementation time, the IRDS can be used to integrate

the installation of a specific CALS system with other CALS

systems

.

Once systems become operational, it is possible that the

IRDS can be used in an active capacity. Some commercially

available data dictionaries actively interface with other

software, resulting in an integrated environment. In the

long run, this is a desirable objective to pursue.

The IRDS can also be used as a tool for the maintenance of

CALS systems. This is discussed further in a later section

on impact of change.

5.2.3. LOGICAL INTEGRATION TOOL

The IRDS can serve as a logical integration tool for integrating

life cycle, configuration, and project management functions

related to CALS information systems. The IRDS can be used to

verify that specific items completed in one life cycle phase are

adequately documented and consistent before moving into the next

33
phase. In addition, the IRDS can aid the management of

information systems configuration to ensure that systems are

configured properly to accomplish established goals and

objectives. The IRDS can also assist information system project

managers in integrating their projects with other projects.

5.2.4. IMPACT OF CHANGE TOOL

The IRDS can also be used to aid management in assessing the

impact of change to information systems. An IRDS containing all

of the interrelationships of data and how it is used in the

information systems can provide a detailed analysis on the impact

a proposed change will have on any or all of the information

systems. For example, the IRDS could be queried to determine the

impact of changing a zip code from five characters to nine

characters or the length of a part number. The IRDS would report

on the programs and databases that would have to be changed.

This capability can improve considerably an organization's

ability to estimate the time and cost of proposed systems

development or change. It will more thoroughly ensure that a

given change to an item will be changed in all programs and

systems using that item.

5.3. ARCHITECTURE OF MULTI-LEVEL IRDS

In the strategy for implementing the IRDS in CALS, there must be

an architecture of multi-ievel IRDSs. The size of the CALS

effort is too 'large to expect a single IRDS to contain all the

CALS information resources. Therefore, there must be a multitiered IRDS approach. Each tier would contain the information

appropriate for a specific level. For example, OSD might have an

IRDS that contains global CALS information; each service could

have a service CALS IRDS containing information global to the

respective service; and then at the lowest level there could be

an IRDS that would be an integral part of a specific CALS

information system.

5.4. IRDS STATUS

As specified in an earlier section, the IRDS is a draft standard

specification for a data dictionary system. NBS expects that the

IRDS will be an American National and Federal Information

Processing Standard by early 1987. Until the IRDS becomes an

approved standard, CALS may want to start with a commercially

available system for CALS management purposes and then migrate to

IRDS standard implementations. It is likely that computer tools

will be available to automatically perform this migration.

34
6 . RECOMMENDATIONS

To ensure that standards used in CALS are appropriate and

available when required, NBS recoimends the following actions be

taken.

The CALS Working Group on Standards and Specifications work with

NBS to select a limited number of "representative" programs

representing the three major categories of data: Image, Text, and

Alphanumeric. These programs should also represent the three

functional areas; product data, technical support data and

logistics support data. The goal is to select three to six

programs for in-depth analysis. NBS then can review other CALS

programs in a more general manner to determine if the conclusions

from the in-depth analysis are accurate for CALS in general.

Specific technical issues that NBS must address appear in Section

2.4, Physical Characteristics. Specifically, NBS must perform

more analysis on;

Existing and planned databases to determine which of the

database standards, SQL or NDL, are most appropriate.

The indexes/directories in CALS systems to choose between

SQL and IRDS as the preferred standard.

The DDF and ASN.l standards be considered as possible

alternatives for the interchange of data commonly contained"

within structured files or databases. For more information, see

Section 4.1, DDF/ASN.l.

NBS complete the assessment of CALS needs and expand this report

in the following areas;

The data modeling methodology and tools required to support

CALS (Sections 3.2 and 3.3) and the need for IRDS to support

data modeling (Section 4.2.3).

The requirement for distributed DBMS and IRDS to all CALS

users access to the widely dispersed CALS data (Section

4.2.1)

.

The support a DBMS in a CALS environment needs from an IRDS

(Section 4.2)

The support an IRDS should provide for graphics standards

(Section 4.2.2)

Strategy for using a data dictionary, or IRDS (Section 5)

.

DoD/CALS and NBS determine the need for an IRDS User Manual.

Such a document would address the types of data that users need

in an IRDS to; provide the necessary knowledge to obtain access

35
to CALS data; plan CALS information processing activities; assess

the impact of proposed changes and subsequently manage required

changes; determine problems that can occur if certain features of

the standard are misused; etc,

DoD/CALS review Section 4.2, Research and Development Issues, in

preparation for discussions of priorities with NBS.

36
Ir '^'^' ' '• <1 ,

. '. . 1... '..*“ r-fi-T f ..

' T’>'.'. *'*•. :;20 'r-vCT^Wll v.VUvu-

. corj.-: JU^ CAt:^.

: Ot ,u pro-’jriiii'' vi'-.t tJtifc , ’# ''’“ '““'“i-’-s: "» -; av;i: - - r. '

iii:'<i!»a«rtc I*

. r, . 'ftpd in3f«aa- ri^ptlremeat , oi ~r

JfB:'. vtth t‘

t;..- vo.i.’!" :.t

i,i .j r’^.rC ' ***'-

: a 1

.

fii

-.«aZ -ths^? * liauiTad .:nh^T

fcr '.aday«i«

n

' tumi

rut vitiLi: "1^

" " pr* ?ri;^.c ttat ilt®

J \r7. AXt FWO" Id DL4S

CONCEPT PAPER

•»>or r.: . at IfJSvV drafts , 4;;l .’.air" C c ar*a . OT r ^

• ftTOdil )Z & pciXSp-. •, 1 . • IS, tlxia viev 7f eavi-T

'

• tjat . ewi a»er " :

• ' * d

^lan; : ^n\w < Zfti v-H c

rwa VI, L

Z'Mt^ ,bd d ^'-r oviev o:f

tto t —

IlIP'O , ^ w^»JS a*

*f view rT

ii«TV1.0t/DlA -0'

[1^2^ lirrXZig ». A» j IF"

«eat : 3 ; :V-

»tiO Aidjr. a d€|^lca#rt -fcr. »e;or

it

dALS

^

'^M.E e::vi '’cta«f,at

.

:n:.wl r. Jett 2}

\u ^oriAS*

w - ^ t.‘

' j'At: ' 'j'^

\.'»-

'• • ^ r o b w i-t

IMjr appiio

•TL - jt)ec I , : r

.J ts

IX^

^S:.:':.S Vi

CALS REPRESENTATIVE SYSTEMS

CONCEPT PAPER

1. In its initial quarterly report, NBS recommended that DOD

wort with. NBS to select a limited nimber of "representative"

prograjns which would represent the overall CALS initiative.

These programs should represent the major components or

application areas comprising CALS. Further in-depth analysis

could be performed on these programs with the output being a

generic model describing each application area. Each generic

model would identify the common "core" characteristics and

requirements of the Services, DLA, and industry, and would

provide NBS with the information needed to identify standards

that would apply, or to enhance or tailor those already

identified.

2. It is essential that a limited number of representative

programs be selected for analysis because of the large number of

CALS related program initiatives within the DOD components.

There are 82 CALS programs that are described in the plans

prepared by the Army, Navy, Air Force, amd DLA. It would be both

impractical eind unnecessary for NBS to review all of them,

particularly in light of the initial on-site visits and workshops

conducted by NBS during FY 1986. NBS feels a better approach is

to group the programs into categories representing major CALS

application areas. Selecting one or two representative programs

in each application area will simplify the analysis process.

Generic models would then be developed for each application area,

based on in-depth review of the selected programs, and the

results incorporated into the CALS Framework and Development

Plan. These models would also become test cases to validate the

construct describing a CALS architecture.

3 . One possible view of the CALS environment , based on our

review of the Service/DLA implementation plans, consists of siz

major application areas, as depicted in Figure 1. Because there

are overlaps among these application areas, as well as different

perspectives, this view of the environment should be integrated

with others that are emerging (e.g., the DoD CALS Implementation

Plan) to produce a common description of the CALS environment.

The siz application areas are: i) Product Definition Data; 2)

Engineering Data Repository Systems; 3) Automated Authoring,

Publishing, and Printing Systems; 4) Technical Data/Configuration

Management; 5) Technical Information Delivery, Maintenance, and

Diagnostic Aids; and 6) Maintenance Information Systems.

Overlaps depicted by the shaded intersections represent the

sharing of data and/or functionality.

4. Each of the siz application areas is described in the

following paragraphs.

^ Note: This tater reflects changes suggested by OASD cn

Dec 1, 1986.
a. Product Definition Data is the totality of data elements

which completely define a product for all applications over its

expected life cycle. This includes the data adDout the

engineering drawings and the semantic description of these

drawings, such as tolerance levels, material composition,

geometry, topology, attributes, ajid features necessary to

completely define a component part or an assembly of parts. Any

programs involving the Computer Aided Design (CAD), Computer

Aided Majiufacturing (CAM), or Computer Integrated Manufacturing

(CIM) are included in this application area.

b. Engineering Data Repository Systems provide the support for

storing, retrieving, and transmitting digitized engineering data.

The goal is to provide a cost-effective, high-technology system

needed for handling and managing the engineering drawings and

related information required by engineering and technical

personnel.

c. Automated Authoring, Publishing, aind Printing Systems provide

the capability to create, publish and print technical material.

Included in this application area is the capability to print upon

demand, distribute technical materiELl in paper form to the users,

and process changes to the technical material. It does not

include the delivery of the material to the maintenEince personnel

in electronic form because this is included in another

application area (described in the next paragraph).

d. Technical Information Delivery, Maintenance, and Diagnostic

Aid Systems will deliver technical documentation to maintenance

technicians in electronic form. It is a "job aid" field

maintenance system which uses graphics displays as troubleshooting aides to provide the technician with a checklist of

maintenance actions and the step-by-step procedures for

diagnostic analysis of problems. This application area is

treated separately from the prior one because of the additional

considerations for on-line interaction and for interfacing with

other logistics systems.

e. Technical Data/Configuration Management supports the

integration and management of all the automated technical

information within each services programs. The Army has a batch

oriented TD/CMS system that can serve as a basis for determining

the requirements in this area.

f. Maintenance Information Systems support the automation of

parts supplies, maintenance accounting, repairables transaction

and status accounting.

5. The view of the CALS environment described above should be

integrated with others that are emerging to help develop and

refine the common “core" requirements for building a CALS

Framework. From this CALS Framework, NES can then continue

identifying the standards that will be required to support CALS.
Technical

Data/ I ' J co

4-)

A o> CO

fO c *o O) c sz

OJ OJ c 3 E •M •r— 4-> CO or O) fO CO c E

C3 E o •f“ •r" (U

fO o r“ L. 4-> C c 4-> 4-> Q- CO o rO 3 3 3 >T o s: «!C < a. oQ 00

Figure 1

CALS

ENVIRONMENT
1
NBS»114A (REV. 2-80

U.S. DEPT. OF COMM.

BIBLIOGRAPHIC DATA

SHEET (See instructions)

1. PUBLICATION OR

REPORT NO.

NBSIR 87-3566

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

4. TITLE AND SUBTITLE

FINAL NBS REPORT FOR CALS, FY86

5. AUTHOR(S)

Edited by Sharon J. Kemmerer

6. PERFORMING ORGANIZATION (If joint or other than NBS, see instructions) 7. Contract/Grant No. national bureau of standards

DEPARTMENT OF COMMERCE 8. Type of Report & Period Covered

WASHINGTON, D.C. 20234

Final, FY86

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

Office of Assistant Secretary of Defense (A&L)/WSIG

Department of Defense, Pentagon

Washington, DC 20301-8000

10. SUPPLEMENTARY NOTES

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

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

bibliography or literature survey, mention it here)

The overall objective of the DoD Computer Aided Logistic Support (CALS) Program

is to integrate the design, manufacturing, and logistic functions through the

efficient application of computer and communications technology. DoD requires

functional and interface standards and procedures that will enable the digital

interchange of data in weapon system and automated system contracts, that will

be common to all Services and DLA. This FY86 Final Report provides NBS

recommendations for standards usage to support the interchange of CALS digitized

technical information in four major areas: product data, graphics, database

management, and text.

12. KEY WORDS (Six to twelve entries; alphabeti cal order; capitalize only proper names; and separate key words by semicolon s) CALS; CGM; DoD; graphics; database management; IGES; IRDS; logistics; NDL; product

data; SGML; SQL; text

13. AVAILABILITY

1 ^1 Unlimited

1 1 For Official Distribution. Do Not Release to NTIS

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

20402.

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

14. NO. OF

PRINTED PAGES

15. Price

USCOMM-DC 6043-P80
!!

II

I'l

1
I

1

I

I

;1(

>

1


I

!

t