NBS

PUBLICATIONS

NRRIR 86-3476

A 1 1 1 2 L 1 L 5 L 4

NATL INST OF STANDARDS & TECH RI.C.

All 10261 6564

Palmer, Mark E/The current ability of th QC100 .U56 NO. 86-3476 1986 V19 C.1 NBS-P

rrent Ability of the

cture, Engineering, and

Construction Industry to Exchange

CAD Data Sets Digitally

Mark E. Palmer

U.S. DEPARTMENT OF COMMERCE

National Bureau of Standards

National Engineering Laboratory

Center for Building Technology

Gaithersburg, MD 20899

October 1986

Final Report

Prepared for: QC al Civil Engineering Laboratory

100 Hueneme, CA

.056

#86-3476

1986

C.2

NBS

RESEARCH

INFORMATION CENTER NBSIR 86-3476

THE CURRENT ABILITY OF THE

ARCHITECTURE, ENGINEERING, AND

CONSTRUCTION INDUSTRY TO EXCHANGE

CAD DATA SETS DIGITALLY

Mark E. Palmer

U.S. DEPARTMENT OF COMMERCE

National Bureau of Standards

National Engineering Laboratory

Center for Building Technology

Gaithersburg, MD 20899

October 1986

Final Report

Prepared for: Naval Civil Engineering Laboratory

Port Hueneme, CA

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

NATIONAL BUREAU OF STANDARDS, Ernest Ambler, Director

ABSTRACT

As the Architecture, Engineering, and Construction (AEC)

industry continues to expand its use of computer-aided design

(CAD) systems, the communication of project information among

professionals and clients becomes more complex. The current

ability of this industry to exchange CAD information digitally

has been assessed through discussions with AEC CAD users and

consultants, site visits to CAD installations, and reviews of CAD

software and translator documentation. CAD systems from

different vendors are generally incompatible, and this limits or

prevents the flow of information between project participants.

The information that is currently being exchanged between

different CAD systems is primarily graphics, 2-D drawings with no

attached databases. The received data sets are usually only used

as reference outlines for new work and are not intended for

revision. The principal conclusions and recommendations of this

report are as follows:

1. In order to take full advantage of CAD and to maximize the

utilization of digital project information, the AEC industry

requires a dependable method for digital data exchanges.

2 . The current generation of translator tools is inadequate for

comprehensive AEC CAD operations. Incomplete translators,

insufficient documentation, and differing interpretations of

specifications have prevented accurate and complete data set

exchanges

.

3. There is a critical need for a public program to validate

translator software, to identify problems in current

implementations, and to develop guidelines for the use of

computer data exchange standards.

KEY WORDS: AEC CAD; CAD data exchange; computer-aided design;

computer integrated construction; construction

documentation; data exchange standards; data

translators; digital data interchange; IGES

;

intermediate data exchange formats; validation of

translators

.

ii

CONTENTS

PAGE

Abstract ii

1. Introduction 1

1.1 The Importance of AEC CAD Information

Exchanges 1

1.2 Current AEC CAD Information Exchanges 2

2 . Current AEC CAD Systems 5

2 . 1 The Range of Systems Used in AEC

Organizations 6

2.2 Data Set Translation Methods 7

2 . 3 Existing Intermediate Data Exchange Formats .... 9

3. Types of AEC CAD Data Set Exchanges 12

3 . 1 The Use of Translators and Intermediate

Formats 13

4. The Current Ability of the AEC Industry to Exchange

CAD Data Sets 17

4 . 1 Types of Information Being Exchanged

Digitally 18

4.2 Data Exchange Problems and Issues 19

5. Summary and Recommendations 24

5.1 Key Issues 24

5.2 Recommendations 2 6

6. References 27

Appendix A AEC CAD Data Exchange Questions 2 8

iii
« '
1 . Introduction

Architecture, Engineering, and Construction (AEC) firms are

striving to increase their efficiency and to improve their

projects by incorporating computer-aided design (CAD) systems.

The percentage of A/E firms using CAD has been steadily

increasing during this decade. Recent surveys of design firms

report that 40 percent of the responding firms currently have CAD

capabilities, compared to 15 percent in 1984. At least 80 percent

of all AEC firms are predicted to have CAD systems by 1987 [1],

The use of computers in these organizations has been evolving

from separate computer-aided drafting, engineering, and project

management applications toward integrated CAD systems, which

address the full range of AEC operations. The common, critical

component of all of these systems is the information that they

manage. The usefulness of CAD systems is directly affected by

how successfully this information can be exchanged between

different systems and the various project participants.

The purpose of this document is to provide an assessment of the

AEC industry's current ability to exchange CAD data sets

digitally and to present recommendations for future action. This

assessment was produced through discussions with AEC CAD users,

consultants, and vendors, site visits to CAD installations, and

reviews of CAD software and translator documentation. Many of

the discussions were conducted over the telephone, and all of

them were structured upon a broad list of "AEC CAD Data Exchange

Questions" (included in this report as Appendix A) . During the period of April - July 1986, 82 AEC CAD professionals

were contacted for their responses to these questions and for any

other pertinent information that they chose to contribute. These

contacts included representatives of 34 AEC organizations with

varying amounts of CAD experience, 16 AEC CAD vendors, 7 AEC CAD

consultants, and 6 CAD service bureaus. The findings and

recommendations of this report were then reviewed by a panel of

currently practicing AEC CAD professionals.

1.1 The Importance of AEC CAD Information Exchanges

In most large AEC projects, each participating organization

operates independently, exchanging information with the other

professionals in the form of drawings, schedules, and

specifications. In order to fully exploit the potential gains

offered by CAD, these professionals must be able to exchange this

information in digital form. Currently, the primary deterrent to

1
AEC digital data exchanges is the limited capability to

communicate data between CAD systems from different vendors.

Many private sector, municipal, and military projects involve

several AEC contractors, each of whom may have a different CAD

system. As of April 1986, there were 58 different CAD systems

being offered for AEC operations [2], and other CAD vendors are

preparing to introduce more systems this year. Although there

are annual discussions at CAD conferences on the impending

shakeout of vendors, the AEC CAD market continues to expand,

mature, and diversify.

The increasing use of CAD systems is bringing fundamental changes

in the operations of AEC offices and in the delivery of services

and projects. The effectiveness of the design and construction

process is, in part, determined by the manner in which

information is exchanged and manipulated. In order to

successfully integrate CAD systems, AEC organizations and

owner/clients will have to develop a strategic conceptual

framework, an industry-wide descriptive interchange language, and

comprehensive operational procedures for exchanging CAD data

sets .

1.2 Current AEC CAD Information Exchanges

With the increasing use of computers in the design and

construction process, there is a growing demand for the exchange

of information in digital form, i.e., as data sets. Many clients

are requesting the delivery of both conventional paper, project

documentation (drawings, schedules, etc.) and the digital files.

Some clients are accepting the delivery of just the project's

digital data sets, in a specified format.

Many organizations have identified facilities management as an

essential AEC service which should use these new tools. Some

owner/clients have extended their specifications for the delivery

of project data sets to include the "as-built" data. These

updated data sets are intended to be used as the base

documentation for facilities management operations.

Unfortunately, the extra costs of such requests have caused most

owners to remove this requirement.

Additionally, since very few project owner organizations have CAD

systems on which to use the data sets, CAD data may only be used

during the design process. Due to this short-term perspective as

to the value of the CAD data, there is no investment in

developing data sets which can be exchanged throughout the 1 i 1

e

cycle of a project.

CAD systems produce drawings and other forms of project

2
information quite efficiently, but unfortunately it is still

difficult to transfer this graphic and non-graphic data from one

CAD system to another. Most CAD systems are incompatible with

one another since they use different data representations and

formats. Although there are procedures for exchanging graphics,

currently there is no way to guarantee that the graphic data can

be manipulated on the receiving system or that the non-graphic

data will retain their meaning.

At present, there have only been very limited CAD data set

exchanges within the AEC industry. The majority of these

exchanges have been between professionals who are using the same

kind of CAD system (i.e., within a homogeneous environment), and

the translated data sets are primarily used only for

reference/background information or as supplementary archival

documentation (and not as the master document)

.

Additionally, the flow of information has only been in one

direction. The capability for bidirectional exchanges of CAD

data sets is only being exercised within the larger A/E firms

which work in homogeneous CAD environments. The AEC industry is

just beginning to examine how to use CAD for the iterative

refining, or cycling, of design solutions among all of the

project participants, regardless of the differences in CAD tools.

The initial strategy for receiving CAD data sets, on the part of

the large owner/clients, has been to require their projects to be

designed on the same kind of CAD system as they use in-house and

to specify the delivery of the project CAD data set in that

system's format. During the past two years, the limitations of

this strategy have been recognized, and the requirements have

been expanded to encourage a broader range of A/E firms to

participate. The more recent construction project specifications

allow the use of subcontractors and service bureaus to translate

the original CAD data sets into the required format, either by

direct translators or via a neutral format (specifically the

Initial Graphics Exchange Specification, IGES)

.

In order to transfer data sets stored in one CAD system into a different CAD system, a specified language and format for the

exchange must be agreed upon by the developers and users of both

systems. In the case of homogeneous exchanges (between the same

kind of systems) , this process is basically a direct transfer of

files, in their native format, with no requirement for

translation. As long as the representational conventions of the

data sets (i.e., assignment of layers, symbol definitions,

drafting standards, etc.) are commonly defined for both systems,

this type of exchange is usually successful within homogeneous

environments

.

The broader range of possible data set exchange problems occurs

within heterogeneous environments (i.e., different CAD systems

3
exchanging data) . Since each system uses its own concepts,

terminology, and encoding schemes, the original data sets can not

be directly used by the application programs in the receiving

system. Therefore, the original data sets must be translated

into the format of the receiving system.

The primary constraint to current CAD data set exchanges is that

there has not been a comprehensive and acceptable (dependable and

verifiable) method for the digital exchange of information

between different AEC CAD systems. Successful AEC CAD

information exchanges will require a documented taxonomy of

modeling concepts and a protocol to communicate each concept.

4
2 . Current AEC CAD Systems

There are numerous CAD systems available to AEC organizations,

ranging from simple drafting aids to integrated (a common

database management system supports all intradiscipl inary and

interdisciplinary functions) multi-user systems which address

numerous aspects of an AEC project. These systems can generally

be classified as 2-D drafting systems, 2-D drafting systems with

database management capabilities, or as 3-D modeling systems,

which include a database management system (DBMS)

.

Many AEC firms initiated their use of CAD with microcomputer

drafting applications. During the past two years, the

capabilities and the cost-effectiveness of these packages have

significantly increased. Currently there is a sizeable market

for add-on packages which provide libraries of symbols and which

expand the basic drafting operations with specialized functions

(such as automatic dimensioning or the insertion of doors and

windows)

.

In the AEC CAD arena there is a growing appreciation and demand

for database management functionality. A critical aspect of any

construction project is the management of information, and CAD

technology can provide powerful tools for controlling the

relationships between graphics and data. The addition of

database management systems may allow the users to make quantity

takeoffs, to compile listings of components, and to perform

facilities management functions.

However, the capabilities of a drafting-based DBMS are limited by

the functionality of a 2-D system. Since the same information

may be represented on different drawings, there will often be

redundant descriptions of a building. This redundancy leads to

problems in maintaining the consistency and the accuracy of the

data attached to the graphics. This fact enforces the convention

of considering 2-D drawings as "reports" extracted from an

integrated, 3-D building description.

A 3-D modeling system maintains a three-dimensional description

of a building, which provides the basis for the integration of

AEC CAD operations. These systems use wire-frame, surface, or

solid modeling methods (some systems will allow the user to

select the specific method) and usually provide common access to

a consistent, central database.

Wire-frame models describe objects as a series of vertices

connected by edges and provide the most rudimentary 3-D

description of a building. Surface models extend the wire-frame

to include closed polygons as the faces of 3-D objects and allow

properties to be attached to the faces. The most complete

representation is provided by solid modeling, which describes a

5
building as an assemblage of solids (with attached properties)

and voids. The development of a full 3-D model of a building and

all of its systems can be difficult and time-consuming, and the

information required for such a representation can exceed the

normal scope of services provided by an A/E firm.

Due to the large number and variety of components in a building,

solid modeling is considered too computationally intensive for

efficient AEC production of drawings and project documentation.

The current focus in advanced AEC CAD organizations is to develop

the capabilities of their surface modeling CAD systems into fully

integrated design and management tools.

Numerous AEC firms first implemented CAD in order to automate

portions of their drafting tasks. Yet, after the first year or

two of automated drafting and an increase in computer literacy,

many firms have become dissatisfied with this limited use of CAD.

An increasing percentage of current AEC CAD users are

investigating the integration of CAD within all of their firms'

operations. This integrated use of CAD resources may include

project management, engineering and design, drafting and

documentation production, operational control, and strategic

planning.

Four key elements have been advancing the integrated use of CAD:

the continuing decrease in the price-performance ratio of AEC CAD

systems, greater emphasis on 3-D modeling, more comprehensive

implementations of DBMS's for developing computerized project

databases, and the development of , local area networks (LANs).

The combination of comprehensive DBMS's and the use of LANs

promotes dynamic interference checking, more timely design

reviews, and the reduction of errors and field rework.

2.1 The Range of Systems Used in AEC Organizations

The AEC industry in the United States is extremely fragmented,

and most firms are subject to sizeable fluctuations in work loads

and types of projects. With individual disciplines having

differing requirements, no CAD system has yet fulfilled all of

the requirements for every type of AEC firm.

The simplest way in which individual AEC firms have implemented

CAD is to use the same system for all of their CAD functions.

This is the strategy that many small and mid-size (less than 100

employees) firms have adopted during the past two years, and it

has proven particularly successful when the application program:

of the selected CAD system can support the majority of the firm's

requirements

.

Unfortunately, most of the larger firms have not had the luxury

6
to choose that implementation strategy. Many of the larger firms

began investing (both resources and databases) in CAD five to ten

years ago, when AEC CAD systems were primarily extensions of

mechanical and electronic engineering CAD/CAM systems. In many

cases, their use of CAD has evolved out of a series of separate

decisions. As new projects or work loads were initiated,

specific applications programs, sometimes from different CAD

vendors, were selected to support the tasks of individual

divisions or to fulfill the requirements of the project.

This scenario has progressed in two different directions. In

some large firms, multiple systems are used throughout the

organization, and the CAD managers allocate their computing

resources based on project priorities, requests from division

managers, contracted specifications for deliverables, and the

optimization of resources.

The other way in which multiple CAD systems are being used within

a single firm is that each system is dedicated to the operations

of a specific division (or divisions) . This strategy has usually

been adopted because, over the years, individual divisions have

selected different systems which best suited the way in which

they were currently doing their work.

Some of the larger AEC firms in the United States are using as

many as five different CAD systems for in-house operations, and

some of those firms have only recently decided to centralize the

management of their CAD operations. AEC organizations which use

multiple CAD systems are faced with significant challenges,

ranging from the management of multiple versions of company

standards to the monitoring the internal exchange of data sets

between incompatible CAD systems.

2 . 2 Data Set Translation Methods

Central to the coordinated use of multiple CAD systems and to the

successful exchange of CAD data sets is the development of

dependable data set translation methods. There are basically two

ways to transfer data between incompatible CAD systems: direct

translation and translation via an intermediate format.

A direct translator is a software program which converts data

sets from their original format into the specific format of a receiving system. Although direct translators can be an

efficient way to exchange data sets between two systems, they do

not provide a viable strategy for exchanging data sets between

multiple systems.

The writing of direct translators requires a complete

understanding of the internal data format used by both the

7
sending and the receiving system. This information is usually

proprietary, and is subject to periodic revisions. With each new

revision to either of the two systems, the direct translator must

be revised. Additionally, this strategy reguires an excessive

number of translators to support data exchanges between multiple

systems. With "n" CAD systems, there must be n x (n-1) one-way,

direct translators.

One informative example of the limitations of direct translators

is the experience of the U.S. Army Corps of Engineers. The Corps

has maintained both neutral and direct translators to support the

CAD operations of their Huntsville Division. After incurring

excessive development and maintenance costs to implement a direct

translator, the Corps concluded that it was "impractical to

maintain a direct translator as a custom implementation" and that

"neither vendors nor the Government can afford to maintain a direct translator for every combination of equipment. " [3]

The use of neutral translators is intended to resolve these

limitations. A neutral translator is based on the concept of an

intermediate format and utilizes two programs (a preprocessor and

a postprocessor) to perform the translation. The preprocessor

reads the format of system A and writes into the intermediate

format, and the postprocessor reads the intermediate format and

writes the output into the format of system B.

There are several advantages to this process. First, the writing

of either program only requires an understanding of the internal

data format of one system. Second, there is only the need for 2n

programs (one-way translators) for "n" CAD systems, rather than

n x (n-1) one-way translators. Whenever a CAD system is revised

only two programs have to be updated, instead of all direct

translators that work with that system.

A key problem of neutral translators is the difficulty of

establishing an intermediate format which supports the features

of all of the CAD systems and the requirements of all of the

users. Consequently, any intermediate format must represent a compromise between many systems and approaches, and the

intermediate format may not accommodate all of the information in

an originating system.

The use of an intermediate format can reduce the users' risks of

vendor dependence and can allow greater flexibility in the

utilization of CAD resources. In order for an intermediate

format to provide this foundation for data exchanges,

specification must be precise and unambiguous, and the CAD

vendors (software developers) must interpret and implement the

specification uniformly.

Many of the problems with the current generation of neutral

translator software are caused by dissimilar interpretations of

8
the same specification. A critical component in the successful

use of an intermediate format is the establishment of methods for

validating translators' conformance to a clear and precise

specification.

2.3 Existing Intermediate Data Exchange Formats

Currently, there are four intermediate data exchange formats

available for AEC CAD communications: the Initial Graphics

Exchange Specification (IGES) , the CalComp 900-Series plot file

formats, the AutoCAD DXF file format, and the Intergraph Standard

Interchange Format (ISIF) 1 . IGES is the only one of these four

formats that is maintained by a national committee.

Each of these formats are being used for specific types of AEC

applications. In addition to these public intermediate formats,

some of the larger AEC firms have established their own "neutral

file primitives" and database structures for the internal

exchange of project data.

The Initial Graphics Exchange Specification grew out of the work

done by the Boeing Corp. , the General Electric Corp., the NASAsponsored Integrated Program for Aerospace Vehicle Design (IPAD)

,

and the U.S. Air Force Integrated Computer-Aided Manufacturing

(ICAM) program. Each of these organizations had identified the

lack of a standard for the exchange of CAD graphics as a critical

roadblock to moving toward computer integrated operations.

IGES is an intermediate format for the exchange and archiving of

product description data sets. This format was designed

initially for the exchange of the drawings of manufactured parts

and has been extended to include finite element models, 3-D wireframes, and process plant flowsheet drawings. The user of one

CAD system translates his system's data sets into the IGES format

using a preprocessor. The user of a different CAD system

translates the resulting IGES-formatted files into his system's

format using a postprocessor.

An additional goal of the IGES effort has been the use of this

format as an archival file format. Since vendor products are

continuously evolving, CAD users are frequently confronted with

the decision of upgrading their system to the latest version to

1 Certain commercial equipment, software, or materials are

identified in this paper in order to adequately specify existing

CAD software and data exchange formats. Such identification does

not imply recommendations or endorsement by the National Bureau

of Standards, nor does it imply that the software or equipment

are necessarily the best available for the purpose.

9
take advantage of new capabilities while risking the integrity of

archived databases. This issue of establishing a reasonable

approach for storing neutral archival files in a database

management system has not been resolved. At present, "the issue

of archival in a neutral format to avoid data loss due to system

updates has taken a very secondary role." [4]

In early 1980, the National Bureau of Standards published IGES,

Version 1.0, and in 1981, this version was approved as an ANSI

standard. Version 2.0 was published in February 1983, and

Version 3.0 was published in April 1986. IGES "will not solve

all the information needs of CAD/CAM systems, and it will need

further extension beyond its current definition. However, IGES

goes a long way toward alleviating the current data exchange

problems, and is a significant response to today's needs." [5]

The IGES standard is more complex than the other formats, and it

can represent sophisticated data structures, such as networks,

connectivity, and 3-D surfaces. Although IGES was initially

designed to support CAD/ CAM and printed circuit board technology,

Version 3.0 has been developed to support a broader set of

applications, including AEC.

In February 1984, the IGES/AEC Committee was established to

ensure that the IGES standard and the next generation of data

exchange specifications, PDES (Product Data Exchange

Specification) , facilitate the electronic exchange and archiving

of AEC projects. This committee proposes and implements specific

IGES enhancements for improving data set exchanges among AEC CAD

users (extensions are currently being developed for incorporation

into Version 4.0). The second goal of this committee is to

inform the AEC community of the need for consensus data exchange

standards and to maintain effective liaison with that community

and the CAD vendors.

The CalComp plot file formats were developed by the CalComp Corp.

to support the CalComp 900 Series on-line and magnetic tape

controllers for pen plotters. These are procedural files which

contain the commands for controlling the movement of the pens in

the plotter. Since all geometric elements are processed as 2-D

chains of vectors, all symbols and text lose their meaning.

The AutoCAD DXF format was developed to support the 2-D graphics

generated by Autodesk's drafting software and is being used for

transferring drawings to CAD systems. AutoCAD was introduced in

November 1982 as a CAD software package for personal computers.

10
ISIF was developed by the Intergraph Corp. and is widely used for

exchanging drawings generated on Intergraph systems. This format

is designed to work with the files generated by the Interactive

Graphics Design Software (IGDS) and by the Data Management and

Retrieval System (DMRS) , the hierarchical attribute database. It

can be used to exchange 2-D or 3-D graphics and associated

databases

.

11
3. Types of AEG CAD Data Set Exchanges

Data set exchanges between professionals in the AEC industry may

occur for a variety of applications and often within diverse CAD

environments. These exchanges may include drawings, equipment

schedules, bills of materials, numerical analyses, administrative

information, and 3-D models, and they may happen both within an

organization (intra-organizational) and between organizations

(inter-organizational)

.

While AEC CAD users want to exchange drawings with symbols and

dimensions, CAD systems provide the facilities to create,

manipulate, and exchange specific types of data. The types of

data to be exchanged between these systems are:

* geometry (lines, surfaces, etc.) and location

* annotation (text, dimensions, etc.)

* topology and structure (means of representing and

presenting information)

* associativity (logical relationships among data)

* property (information attached to data)

Combinations of these data types are used to digitally represent

drawings and AEC project information in the CAD systems.

The elementary classification of CAD data set exchanges is based

on the types of CAD environments employed, homogeneous or

heterogeneous. A homogeneous CAD environment includes only one

kind of CAD system. All data sets are written in the same format

and are directly readable by all of the communicating

workstations. A heterogeneous environment includes more than one

kind of CAD system, and consequently, the data sets written by

one CAD system must be translated in order to be read by a different system.

The homogeneous CAD environment provides the most direct and the

least error-prone facilities for data set exchanges. As long as

comprehensive CAD operating procedures (such as the assignment of

layers for specific types of information and the coordinated use

of symbols) are implemented and enforced, there can be extensive,

bidirectional exchanges of CAD information. These may include

the selective transmission of portions of CAD projects or the

transfer of a complete project data set.

Comparatively, there are far more problems with the heterogeneous

CAD environment. Since the systems are structured differently,

all graphic and non-graphic data must be mapped from the storage

files of the originating system to those of the receiving system.

These mapping procedures must resolve such basic software

differences as conversions from 3-D to 2-D, different line and

font styles, and differences in the assignment of layers.

12
In heterogeneous environments, each time a CAD data set is

translated between systems, some information may be lost. This

becomes especially detrimental when subcontractors are providing

portions of the project design and there is a need for

bidirectional exchanges of data sets. The common way to work

around this problem is to digitally exchange only those types of

information common to both systems, using predetermined entities

and modeling conventions and to exchange the rest of the required

information on paper.

3 . 1 The Use of Translators and Intermediate Formats

Although vendors and users recognize the need for dependable

information transfers between CAD systems, they have not always

agreed upon the solution. "The amount of work necessary to meet

IGES is extensive, and the resources the vendor is willing to

divert to this activity are often inadequate for the task. New

hardware or additional software features are perceived as adding

more to the sales potential of a product line than drawing

portability. But in fact this strategy results in reduction in

the use of and the market for CAD in the construction industry.

The unrestricted exchange of electronic information is in the

best interest of the construction industry and the CAD vendors."

[ 6 ] Initially the larger vendors only promoted in-bound direct

translators (into their systems' format), for obvious marketing

reasons. Some vendors considered out-bound translators (from

their native format to any other format) to be comparable to

putting "a six inch drain line into 'their' customer base". Due

to the costs of supporting the development of an intermediate

exchange standard, such as IGES, many vendors initially resisted

this solution to CAD data exchange requirements.

Most large AEC CAD users agree on the limitations of only having

direct translators. Although a direct translator can provide an

efficient way to transfer data sets between two particular CAD

systems, it does not provide a viable strategy for exchanging

data sets among multiple systems.

During the past four years there has been increasing pressure by

AEC CAD users for the development of a comprehensive intermediate

exchange format. This pressure has been exerted in various ways.

Most federal agencies and many AEC organizations are requiring

extensive IGES capabilities in their future CAD procurements, and

an increasing number of RFPs (request for proposal) for AEC

projects are specifying the delivery of project documentation in

IGES format.

13
For an intermediate format to be successful, it must be

sufficiently powerful to express all the information in the

originating system, without the receiver having to know the

original (internal) file structure. No intermediate format has

as of yet been fully successful in supporting the data set

exchange requirements of all AEC CAD users.

The early versions of IGES (Ver. 1.0 and 2.0) were inadequate for

the data set exchange requirements of the AEC industry, produced

excessively large files, and did not address the archival

requirements. Although IGES is intended to serve as an archival

format, the primary focus of the IGES effort has been on

successful system to system communications using IGES translator

implementations . Initially, many of the vendors only implemented a small

percentage of the specification (although they would advertise

IGES capabilities) and did not provide adequate documentation or

software tools for diagnosing translation problems. These

limitations frustrated many AEC CAD users and gave IGES a poor

reputation.

A key AEC example of this situation is the limited implementation

of the subfigure entity in most vendor provided IGES translators.

Each element of data in an IGES file is an entity, and the

subfigure entity is a collection of entities which can be used in

multiple instances.

AEC project definitions contain a large number of repetitive

elements which results in frequent instancing of the same symbol

(i.e., subfigure entity). The use of the subfigure entity

provides a way to retain the intelligence of the symbols,

replicates what A/Es do in practice, and reduces the IGES file

size. This is a crucial issue for construction industry firms

that need to exchange detailed drawings, and yet many vendor

provided IGES translators still do not support the subfigure

entity.

During the past five years (since becoming an ANSI standard)

,

IGES has added increasingly sophisticated capabilities and has

gained extensive support. Some of these enhancements have added

to the complexity and ambiguity of the specification, and this

has increased the difficulty of using IGES effectively.

The quality of IGES translators has significantly improved during

1986, and the Version 3.0 document has resolved some of the

earlier problems in the specification. This new version enhances

the user defined MACRO'S so as to better represent standard part

libraries and defines a new extension for External Reference

Files. Additionally, the new version allows the use of the

Compressed ASCII Format as a means of reducing the IGES file size

to one third of its previous size.

14
Still, for IGES to be completely successful, the vendors must

implement the specification uniformly. "Interpretations of the

specification can be different because there are ambiguities.

It's difficult to tell whose fault it is (when there is a problem

in an IGES translation)." [7]

Of the 58 CAD systems currently available for AEC operations, 44,

over 75 percent, report to support IGES capabilities [2].

Additionally, "Several companies with extensive in-house CAD/CAM

systems and proprietary software, including John Deere, Ford

Motor Company, General Electric, General Motors, Lockheed, Martin

Marietta, Structural Dynamics Research, and Westinghouse are

writing their own IGES translators." [8]

Many large organizations have established IGES as part of their

mid-term digital exchange strategy. Critical to the most recent

gains in the acceptance/implementation of IGES are the various

efforts undertaken by DoE, DoD, and each of the individual forces

(Air Force, Army, and Navy) to adopt IGES as part of their

transition to an "integrated mode of operation".

The Department of Defense has established the CALS (Computer

Aided Logistic Support) program in order to increase the

effectiveness of its communications and data processing systems

and to move DoD into highly automated operations. "A key element

in this program is the development of DoD specifications for

digital delivery by industry of engineering drawings,

illustrations for technical publications, and future product

definition data using the Initial Graphics Exchange Specification

(IGES) and the Product Data Exchange Specification (PDES) . " Office of the Under Secretary of Defense, September 1985 [9]

The CalComp plot file formats and ISIF were the first

intermediate formats to receive general acceptance in the AEC

industry, and each has supported specific CAD tasks. The CalComp

formats were originally designed to only support the transfer of

graphic information and has primarily been used for graphic

plotters. The development of ISIF grew out of Intergraph's

applications software, which initially supported cartography,

petrophysical exploration, and utilities.

ISIF was designed to be "format-free" so as to facilitate user

editing. The CERL technical report on graphics translators

(November 1984) states, "This capability has a price. First, the

non-graphic information that can be associated with the graphics

has limitations. Also, there is no ability to provide

backpointers in the data. In the hierarchical DBMS that

Intergraph currently markets, this is not a problem. However, in

the network DBMS soon to be offered, the backpointers would be

lost. ... Currently, the backpointers may be of little use in

some drafting systems; this will soon be a very important feature

15
in design systems and advanced drafting systems as well." [3]

Intergraph has continued to improve the software tools which use

this format, and ISIF is being used for a significant portion of

current AEC data set exchanges.

Although IGES does have limitations, an increasing percentage of

AEC CAD users are integrating IGES into their data set exchange

operations. If the AEC CAD vendors commit themselves to

providing comprehensive implementations of the IGES specification

and if the quality of the translation software tools (and

documentation) improves significantly, IGES will offer a viable

digital exchange mechanism for current AEC CAD operations.

16
4. The Current Ability of the AEC Industry to Exchange CAD

Data Sets

The AEC industry has only recently embraced CAD technology as a

primary medium for producing future projects, and most firms are

still investigating the issues of exchanging CAD data. Many AEC

organizations have only recently started to define and document

their CAD data set exchange requirements and procedures.

There is a general consensus in the AEC industry that in order to

fully implement the capabilities of CAD technology, a dependable

method of data set exchange must be established. Fortunately,

numerous groups are working on these issues, and some resolutions

are being formulated. These efforts include task groups within

corporations, professional societies (ASCE, ASHRAE, ASME, IES,

and AIA) , federal organizations (DoC, DoD, DoE, DoT, FAA, U.S.

Naval Facilities Engineering Command, and U.S. Army Corps of

Engineers) , and within large public works projects.

Currently, very few construction projects are completely designed

on CAD. The percentage of a project that is done on a CAD system

is determined by numerous factors, including the optimization of

CAD resources within the firm and the cost-effectiveness of the

CAD utilization. Many times CAD drawings/files grow so large

that they become unmanageable, and therefore, it is cheaper to

manually finish the last 5 percent of a project's drawings and

hard copy documentation.

The issues of coordinating the use and control of conventional

hard copy with CAD databases are still unresolved in most AEC

organizations. Some firms are now developing "transition

strategies" for evolving toward integrated, CAD based operations.

Most firms recognize that comprehensive management and archival

procedures will be needed so as to ensure successful data set

exchanges and comprehensive transfers of project deliverables.

Until recently, most AEC CAD systems supported very limited data

set translation capabilities. Some A/E firms have concluded that

the current generation of translation software tools are either

insufficient for their requirements or just not reliable. This

has caused numerous A/Es to digitize or re-enter data into a different format rather than risk the expenses of translating.

An increasing number of AEC clients are requiring the delivery of

CAD data sets in a specified format, in addition to conventional

drawings. Many AEC firms are sending CAD data sets to project

participants, both by using the same kind of CAD systems and by

using direct translators. A few AEC organizations have recently,

successfully implemented IGES capabilities for exchanging limited

subsets of project databases. Each of these IGES implementations

have required cycles of start-up testing and the "tailoring" of

17
the IGES translators to the requirements of the specific

projects, so as to maximize the amount of data that can be

transferred.

4.1 Types of Information Being Exchanged Digitally

The information that is being exchanged between dissimilar CAD

systems is primarily graphics, 2-D drawings with no attached

databases. This may include geometry (points, lines, arcs,

etc.), annotation (text, dimensions, etc), associativity (logical

relationships among geometry entities) , and display information

(line weight, font, etc.). The most common uses of AEC CAD data

set translations are for transferring reference outlines and

title blocks between project participants, for the delivery of

the project documentation to the client, and for transferring

mapping and finite element modeling (FEM) information.

The acquisition of topological and topographic information has

become an important element in the use of CAD in civil

engineering and cartography. With the ongoing advances in

photogrammetry and digital mapping systems, there is an

increasing use of translators to port digitized terrain models

into CAD systems (as base documentation for civil engineering

projects)

.

Some AECs are experimenting with exchanging existing hard copy

drawings by using digital imaging scanners. This procedure

converts a raster image into vectors which can then be translated

into IGES or into the native format of some CAD systems.

Although there is strong interest in exchanging complete CAD

models and their attached databases, successful exchanges of

graphic and non-graphic data have only occurred in homogeneous

environments. These exchanges have included 2-D drawings, bills

of materials, material standards, and schedules. Although the

current IGES specification can transfer drawings to different CAD

systems, it is inadequate for transferring much of the

intelligence behind those drawings.

The AEC industry is in the transition to CAD-based operations,

and most firms are still examining their options for transferring

information between CAD systems. The most extensive interchanges

of AEC CAD data sets have occurred in homogenous environments,

and these exchanges have included 2-D drawings, networks, and

attached databases (bills of materials, schedules, etc.). Except

for some recent RFPs ' qualification procedures and the testing of

translators, almost all AEC CAD data set exchanges have been in

only one direction. As of yet, there have not been requirements

for the cycling or iterative exchanges of AEC CAD data sets.

18
4 . 2 Data Exchange Problems and Issues

As long as the representational conventions of the data sets

(modeling conventions) are commonly defined for both systems and

transmission protocols are established, homogeneous data set

exchanges will have minimal problems. Comparatively, the

exchange of information between dissimilar AEC CAD systems (i.e.,

within heterogeneous environments) involves several potential

problem areas.

With just drafting systems, these problems include differences in

functionality and terminology (levels/layers or drawing/view)

,

entity mismatches, conflicting model sizes and scales, and

incompatible line styles, fonts, and symbols. The data

translation problems become far more complex when exchanging

information between 3-D modeling and engineering software

systems

.

The principal cause for these problems is differences in the

logical structure of the CAD systems (such as subfigure and

connectivity definitions) . Most early CAD systems were

computerized drafting systems which only produced 2-D drawings.

The more advanced CAD systems now work with 3-D models of

building projects, from which 2-D drawings can be extracted. A

2-D system will never be able to accurately receive or manipulate

a 3-D model. A 3-D system can receive a 2-D drawing and extend

it into the third dimension by adding a "z" coordinate, but that

extension will only create a subset of any complex 3-D model.

Other types of structural differences between CAD systems are

their use of attached databases and the structure of the data

components. Each CAD system employs a different database

management strategy for managing the non-graphic data (product

specifications, responsibility assignments, procurement dates,

etc.) that are attached to the graphics. All of these factors

can make the exchange of CAD data sets between different systems

extremely problematic. When these problems are combined with a lack of common modeling conventions, it is extremely difficult to

exchange useful information.

Generally, there has been marginal success with heterogeneous

exchanges via an intermediate format. The received data sets are

usually used as reference outlines for new work and are not

intended for revision. Some common problems are:

* problems with units of resolution, scale, and

positional units; e.g., match lines do not match-up on

segmented drawings.

19
* entity, symbol, and subfigure mismatches; e.g.,

parts of drawings are missing, title blocks, text, and

dimensions are incorrectly positioned.

* crosshatching, certain line styles, and most line

font patterns are not successfully translated; so A/E's

avoid putting section details or material information

into their CAD data sets.

In most cases, translated data sets have to be edited in order to

make them "visually equivalent" on the receiving system.

As of yet, there are very few methods for monitoring the quality

of data set exchanges and for ensuring that the data were

translated correctly. A common complaint by CAD users is that

many of the translator programs do not output any messages as to

individual entity translation problems and that most translators

do not generate a translation error log during execution. A

translator program should at least tell the user what entities

could not be translated.

An important tool for improving the quality of data set exchanges

is the monitoring and documenting of problems and successes.

Some firms have begun to record this type of information, and

many AEC organizations have initiated new programs to test and

refine their data set exchange capabilities. Yet, an overriding

factor in construction projects is expedience, and the demands

for completing a job can cause some of these quality assurance

procedures to be short-circuited.

Data set verification procedures should ensure numerical accuracy

and the usability of the translated data. The method used by most

AECs is to do a visual comparison between the received "digital

drawings" and the original hard copy drawings. This is usually

accomplished by plotting the translated data sets and overlaying

the plot on top of the original.

Even if a visual inspection is successful, this does not ensure

that the translated data sets are "functionally equivalent" on

the receiving system. One example of the potential for

functional degradation is when subfigures are translated into

separate vectors such that the subfigures can no longer be

manipulated as single entities on the receiving systems. Any

comprehensive measure of successful data set translation must

include methods to assess the degree to which the received data

sets can be revised in an effective manner on the receiving

system.

Currently, most AEC firms have limited management and control

procedures for the exchange of CAD data sets or for the

coordination of CAD data sets with conventional hard copy

drawings. The management of CAD data set exchanges requires

20
controls on the libraries of CAD reference plans and symbols and

should include comprehensive archiving procedures. Most firms

have minimal controls on reference libraries, and in some

projects, there are multiple sources for the "master documents"

being referenced by project participants.

A critical CAD issue that has not been resolved within most AEC

organizations is the requirement for archiving the design

documents, the CAD digital files, and the audit trails of design

responsibility. Additionally, the issue of archival in a neutral

format to avoid data loss due to system updates has not been

resolved. "Interface difficulties also need to be anticipated

when records from the CAD system are archived, because future use

may be on a different system." [10]

The assignment of responsibility for A/E design decisions usually

includes a professional stamp with a dated signature. The signed

design document has traditionally become the legal record for all

potential liability concerns. With the increasing use of CAD

data sets as the primary repository of design decisions, AEC

archival procedures must be revaluated so as to digitally include

the audit trails of responsible individuals and all other

information necessary for legal considerations.

With conventional CAD data storage (magnetic tape and disk)

,

there is no easy way to guarantee that the digitally encoded

design documents, with the approval signatures, cannot be altered

at a later date. Due to this limitation, most organizations are

archiving duplicate design documentation, both the digital data

sets and the signed hard copy (usually on microfilm) . In

addition to the costs of this duplication, such procedures may

lead to inconsistencies in project documentation and redundant

version controls.

CAD data set translation can be full of problems, and no one

wants to take the responsibility for the translated data. Many

service bureaus are avoiding translation jobs until they are

confident as to the reliability of the software tools. There are

numerous examples of AEC firms giving-up on translating data sets

and choosing to manually re-input the data.

Additionally, the early translators had marginal capabilities,

which did not fully support the requirements of the AEC industry.

These translators were expensive to maintain and to operate

(excessive file sizes and run times) . The documentation on many

translators is still limited. At best, the documentation shows

how to run the translator, but not how to analyze the translation

problems. Very few translators provide comprehensive error

recovery capabilities or diagnostic transaction reporting.

Another limitation on AEC CAD data set exchanges is the ambiguity

and the flexibility of the current IGES specification. Since the

21
vendors do not interpret the specification uniformly, there are

incompatibilities in the mappings between the preprocessor of one

vendor and the postprocessor of a different vendor. AEC firms

(except for the larger) do not have a budget for verifying

translators or to custom build translating and archiving

utilities. In order to effectively exploit the capabilities of

CAD, the AEC industry requires a dependable method of data set

exchange and reliable translation tools.

The AEC industry, having recently adopted CAD as a primary tool,

is now confronting the issues of compatible data formats. Many

AEC firms recognize the importance of transferring "intelligence"

with the graphics and are expanding their CAD capabilities to

support the exchange of project models with their attached

databases. Across the full range of large construction projects,

from major public works projects to corporate facilities, there

is growing interest in full, project life cycle exchange

capabilities.

An increasing number of clients are requesting the delivery of

their projects' documents in a specified data format so that they

can use them for facilities management on the in-house CAD

system. Major public works projects are currently deciding how

to specify the format for the intermediate transfer of CAD data

sets among subcontractors. The Federal Aviation Administration

(FAA) has decided to require airports to furnish them with

airport layout plans in IGES format by 1987.

An interesting aspect of the "Mobilization Plan" for the Boston

Harbor Tunnel project is that the primary AEC contractors are

also examining how to get the state to accept the data sets as

the deliverable master document. Another major project which is

also in the midst of establishing the format for AEC CAD data set

exchanges is the Orlando International Airport. This project is

intended to establish the data set exchange and archival

procedures for supporting operations for the rest of the century.

As part of this increasing understanding of the importance of

data set exchanges, numerous corporations and government agencies

have decided to adopt IGES. Key reasons for these decisions are

that IGES allows AEC firms far more flexibility in how they use

their CAD resources and that it provides clients more flexibility

in selecting AEC contractors. The CERL Technical Report on

graphics translators concludes that "a translator format is

needed that can support both current drafting systems and future

modeling systems. To date, IGES is the only format that provides

that capability. ... Only IGES has the technical capability to

capture the building and site "model" and further, it has the

largest following in the industry as a whole. Therefore, it is

expected to have the best chance of meeting the AEC community':'

future needs." [3]

22
Management at many AEC firms have decided that IGES has matured

into a viable standard for their projects, and some are defining

an application subset of IGES for their types of work. Recent

RFPs for large international projects have included IGES test

cases as part of the qualification criteria, and some major AECs,

who have decided to integrate their multiple CAD operations, have

selected IGES for some internal data set exchanges.

During the past year, there have been significant improvements in

the quality of IGES processors and in the support by the vendors.

The vendors now recognize that working together to establish data

communication standards serves their strategic interests.

"Giving up proprietary secrets may be the price, but the

potential is so enormous that there should be plenty of

opportunity for all." [11]

All of these factors, along with the increasing participation of

users and vendors in the IGES committees, are providing a viable

framework for the continued improvement of IGES. As more AEC

organizations develop comprehensive IGES implementation

strategies and with the continued improvement of the

specification and of the translator software, IGES should provide

a good foundation for the majority of the current digital data

set exchange requirements within the AEC industry.

23
5 . Summary and Recommendations

This assessment of the current ability of the AEC industry to

exchange CAD data sets has identified numerous issues which

must be resolved so as to ensure successful data set exchanges

and the comprehensive archiving of AEC projects. In order to

take full advantage of CAD and to maximize the utilization of

digital project information, the AEC industry requires a dependable method for digital data exchanges.

It is important to understand that, at present, the successful

transfer of CAD drawings between multiple, dissimilar systems has

a significant price. This price is the time spent to understand

each system's operations, the time spent to understand the system

vendor's implementation of the translation software, the time

spent to understand the error messages' meanings and their

consequences, and the resources required to test and validate the

translators and the data set translations.

5 . 1 Key Issues

* The current generation of translator software tools is

inadequate for comprehensive AEC CAD data set exchanges.

Incomplete translators, erroneous processors, and differing

interpretations of IGES have prevented accurate data set

exchanges. Translator programs should include editing, analysis,

and transaction reporting capabilities. Their documentation

should show how to run the translator and how to analyze

translation problems.

* The terminology of each CAD system and of the intermediate

exchange format may be different, or there may be common

terms which are used to convey different information. Data

set exchanges will often fail when these inconsistencies are

not resolved. The language and format of the data exchange (such

as IGES) should be clearly defined prior to any data set

exchange

.

* The use of symbols and libraries. Some CAD systems store

the complete description of a symbol at each instance, and other

systems encode a pointer to a permanent library in which the

complete description is stored. In the latter case, a timestamped version of the symbol library will have to accompany all

exchanged data sets. User defined associativities, properties,

and entities should be included in data set exchanges so as to

minimize misinterpretation.

24
* Entity mismatches between CAD systems and intermediate

formats. CAD users can expect a mismatch of CAD systems'

capabilities and data entities. A native entity may have no

direct equivalent in another CAD system (or multiple possible

representations in IGES) and may be translated into less

sophisticated data elements. This can result in inconsistent,

inaccurate, or inefficient translations. It is advisable that

the sender and the receiver establish common modeling conventions

for encoding CAD information.

* The extra requirements for the configuration management of

multi-system interaction. This issue has been avoided in much of

the AEC industry; specifically by using direct translators for

the one-way transfer of data sets. Key concerns are: the use of

libraries of master specifications and details; defining common

entities and functionality; and the exchange and control of the

definitions of symbols.

* The limitations of IGES, in performance, ambiguity,

complexity, and capabilities. Early versions required excessive

resources, both in actual processing time and in storage costs.

IGES is continuously evolving, and Version 4.0 is currently being

developed. AEC organizations must understand the capabilities

and the limitations of IGES.

* Professional liability ramifications of digital exchanges;

who assumes responsibility for the accuracy and completeness of

the translated data sets. This issue is not resolved in the AEC

industry. At present, all AEC firms consider CAD data sets as

supplementary documentation, with the traditional hard copy

drawings being the "master documents". Translated CAD data sets

must be reviewed, just as conventional drawings are inspected

prior to being stamped and delivered.

25
5 . 2 Recommendations

* AEC organizations should establish standardized operating

procedures which coordinate the use of CAD and manual

documentation / drawings. Few firms have fully resolved these

issues. Some key concerns are: predefined project modeling

conventions (operations, sheet layout, layer assignments) ; single

source of standard symbols; change control and problem resolution

procedures; the ability to segment files for efficient updating,

and comprehensive data set archival procedures.

* AEC organizations should document the complete data flow in

exchanges (operator to operator, intended future uses of the

information, and archival requirements) . It is essential to

document what information needs to be exchanged and by what

means. Currently, very few AEC firms have documented data set

exchange procedures, translation audit-trails, or translation

start-up test plans. Each of these play a critical role in

ensuring the quality of the translations.

* Comprehensive data translation quality assurance programs

and evaluation criteria, for monitoring the quality of the

translated data (accuracy and functionality) , should be

developed. These should include translation start-up and testing

procedures. In most AEC operations, these do not exist.

* Recommended practices and guidelines for the use of IGES in

the AEC industry need to be established. These should include

translation verification procedures, a library of AEC benchmark

files, implementation guidelines, and archival strategies.

* Performance measures and detailed specifications for data

set translators must be developed. At present the users of CAD

translation software must test each program for the specifics of

the intended application. With functional measures and

specifications, the users could far more easily assess the

quality of the available translation packages.

* A public program to validate translator software and to

identify problems in current implementations must be established.

The quality of a data set exchange is dependent upon the

correctness and completeness of the translator implementations.

A public validation program would provide an uniform basis for

the objective evaluation of these products by the AEC industry

and would generate valuable feedback for improving the

translators and the application procedures.

26
6 . References

[1] Teicholz, E.; Southerton, A.; "PC CADD New 'Standards' are

Emerging," Architectural & Engineering Systems: 25;

January/February 1986.

[2] Raker, D. S.; "CADD Buyer's Guide," A/E Systems Report;

April 1986. 12 p.

[3] Golish, L. M. ; Emberley, L. W. ; "Graphics Translators for

Computer-Aided Drafting and Design: Interface Alternatives

for the A/E Community," U.S. Army Corps of Engineers

Technical Report P-85/03; November 1984. 27 p.

[4] Liewald, M. H. ; "A Generic Approach to Data Management

Utilizing IGES," IGES Symposium; March 15, 1984. 8 p.

[5] Kelly, J. C. ; Wolf, R. ; Kennicott, P. ; Nagel, R. N.

;

Wellington, J., ed. ; "A Technical Briefing on the Initial

Graphics Exchange Specification (IGES)," National Bureau of

Standards (U.S.) NBSIR 81-2297; July 1981. 127 p.

[6] Reinschmidt, K. F. ; Lersch, D. L. ; "Communicating computers

a must," Engineering News-Record: 62; September 29, 1983.

[7] Pittman, Jon; quoted by Post, N. M. ; "Computer users are

striving for compatibility," Engineering News-Record: 30-35;

May 29, 1986.

[8] Krouse, J. K. ; "Engineering Without Paper," High Technology:

38-46; March 1986.

[9] Shorey, R. R. ; Director, Weapons Support Improvement Group,

Department of Defense; Letter to the National Bureau of

Standards; September 30, 1985

[10] Hollingshead, M. ; "COGO Data Transfer with an IGES File,"

McDonnell Douglas Automation Company; November 1983. 12 p.

[11] Clancy, J. J. ; quoted by Barrett, C. N. ; "An Advocates View

of CIM," Computer Graphics World: 81-86; May 1986.

27
Appendix A

AEC CAD DATA EXCHANGE QUESTIONS

Name of Company

Type of Business No. of Empl .... Prof Disciplines No. of Offc .... Address

Telephone No.

Contact Name

1.1 Has your organization exchanged CAD data digitally with

other professionals?

1.2 For what types of projects?

1.3 What kinds of CAD systems have been used within your firm?

1.4 What types of information have been exchanged digitally?

- just drawings

- bill of materials

- drawings with databases

1.5 What were the disciplines of the parties exchanging data?

Your system: Rec. systems:

1.6 Could the transferred data be manipulated on the receiving

system?

1.7 Did you produce the transfer files or did you use a job shop

/ service bureau?

1.8 What interchange formats have been used and with which

systems?

IGES , Ver. ISIF

.... CalComp .... DXF

.... Other, specify

1.9 Which interchange formats are you currently using?

IGES, Ver.

.... Other, specify

What determined this selection?

1.10 What is your standard data format for internal usage?

28
2.1

How successful were the data exchanges in a homogeneous

environment?

- complete file dump or selective transmission

- difficulties and limitations

2.2

How successful were the data exchanges in a heterogeneous

environment; what is received, with what kind of

functionality?

- one-way transfer via direct translator

- one-way transfer via "neutral format"

- full-cycle, from sys A to sys B, and back to sys A

- graphic and non-graphic entities

- display information: line weight, fonts, etc.

- annotations: dimensions, text

- logical structure of the data: associativities,

subfigures, and properties (data attached to the

graphic constructions)

3 . 1 Does your company have documented operating procedures as

defined for CAD use?

3.2 Who is responsible for the accuracy and completeness of the

digitally translated drawings (or CAD model)?

3.3 How are the definitions of symbols, that are used in the CAD

drawings, stored and exchanged between systems?

- stored with the CAD drawings as a supplementary file

- stored by reference to an external 1 standards

library so that when the symbol is updated, any

future reproduction of a drawing containing a

reference to that symbol is also updated? (helpful

for maintaining company standards, but this procedure

may prevent the accurate reproduction of the archived

drawing)

3.4 Is this library of symbol definitions passed as a separate

file and then manually installed on the receiving system?

3.5 Have you examined the issues of archiving CAD data in a neutral format to avoid data loss due to system updates?

4.1 Are you currently using any direct conversion translators?

From whom? Who provides customer support for using the

software?

29
5.1 What have been your major problems in using IGES to transfer

data between different CAD systems?

- entity mismatches in dissimilar implementations

of IGES; specific entities not accurately processed

- organization of data : structure entities

- handling of size and scale, lines and text

- accuracy of placement

- imprecise values generated by translation matrix

- error recognition and recovery

5.2 Have you documented the errors and problems that have been

identified? Compiled a list of current fixes / resolutions?

5.3 To what degree do your IGES processors comply with Ver. 2.0?

5.4 What useful entities are not mapped into or out of the IGES

file by your current processors (pre and post)?

- geometry, annotations, connectivity

5.5 Is documentation developed to define common entities,

supported by both CAD systems, so as to avoid using

unsupported entities?

5.6 Do your IGES processors terminate upon encountering

unsupported or incorrect entities?

5.7 How extensively is the START section of your IGES files used

by the sender to insert messages to be read by the human

receiver?

- notes on matching levels, e.g., various types of

information be constrained to appear on fixed levels

5.8 Is there a summary report or translation log produced

by the IGES processors?

- an information message on the status of the process,

on the actions completed, and the errors identified

5.9 Do you have to edit any of the files (orig., IGES, or post-)

to obtain comparable (the intended) functionality on the

receiving system?

- are entities or attributes changed to accommodate the

'target' system

6.1 Have you developed any test case drawings for validating

your digital data exchanges?

6.2 Do you use any software tools for validating and diagnosing

IGES files or processors?

- conformance testing : to ensure that individual

entities and data items are accurately processed

- entity analysis and functional checking

30
6.3 Do you use full-cycle tests as a start-up procedure for new

projects using dissimilar CAD systems?

6 . 4 What are your methods of measuring and monitoring the

success of digital data transfers (e.g., 90 percent

complete)

?

- file verification methods

- graphical and functional checks

7 . 1 How do you evaluate translator software?

- required capabilities; acceptance criteria

- validation criteria; accuracy and functionality

- performance measurement (benchmark tests, test cases)

7.2 How would you describe the quality of current translator

software and of the supporting documentation?

7.3 Do you think there is a significant need to improve the

current generation of IGES processors?

7.4 Have you discussed these limitations with the vendors or

requested that they make improvements to their IGES

processors?

8.1 Do you plan to use any other translators within the next

2 years? If yes, please specify

8.2 Do you plan to expand your current levels of digital data

interchange during the next two years?

8.3 What do you consider to be the prime reasons for your

operation/development of interchange facilities?

. . .

.

To optimize existing

CAD resources

. ... To improve project team

coordination/commun

.

. . .

.

Other

. . .

.

In response to client

demands

. . .

.

To prepare for future

work/expand CAD resources

31

SBS-114A (REV. 2-80

r —

U.S. DEPT. OF COMM. 1 . BIBLIOGRAPHIC DATA

SHEET (See instructions)

4. TITLE AND SUBTITLE

PUBLICATION OR

REPORT NO.

2. Performing Organ. Report NoJ 3. Publication Date

The Current Ability of the Architecture, Engineering, and Construction Industry to

Exchange CAD Data Sets Digitally

5. AUTHOR(S)

Hark.E. Palmer

6. PERFORMING ORGANIZATION (If joint or other than NBS, see instructions) 7. Contract/Grant No. national bureau of standards N68305 86WR60132

DEPARTMENT OF COMMERCE S. Type of Report & Period Covered

WASHINGTON, D.C. 20234 Final

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

U.S. Navy/Naval Civil Engineering Laboratory

Maritime Road

Port Hueneme, CA 93043-5003

%

10. SUPPLEMENTARY NOTES

| | 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)

As the AEC industry continues to expand its use of CAD, the communication of project

information among professionals and clients becomes more complex. The current ability

of this industry to exchange CAD information digitally has been assessed through

discussions with AEC CAD users and consultants, site visits to CAD installations, and

reviews of CAD software and translator documentation. CAD systems from different

vendors are generally incompatible, and this limits or prevents the flow of information

between project participants. The information that is currently being exchanged between

different CAD systems is primarily graphics, 2-D drawings with no attached databases.

The received data sets are generally only used as reference outlines for new work and are not intended for revision. The principal conclusions and recommendations of this

report are as follows:

1 . In order to take fully advantage of CAD and to maximize the utilization of digital

project information, this industry requires a dependable method for the digital data

exchange

.

CONTINUED ON ATTACHED SHEET

12. KEY WORDS (Six to twelve entries; alphabetical order; capitalize only proper names; and separate key words by semicolon s) AEC CAD; CAD data exchange; computer-aided design; computer integrated construction;

construction documentation; data exchange standards; data translators; digital data

interchange; IGES; intermediate data exchange formats; validation of translators

13. AVAILABILITY

[Xj Unlimited

| | For Official Distribution. Do Not Release to NTIS

[~l 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
2. The current generation of translator tools is inadequate for comprehensive AEC CAD

operations. Incomplete translators, insufficient documentation, and differing

interpretations of specifications have prevented accurate and complete data set

exchanges

.

3. There is a critical need for a public program to validate translator software, to

identify problems in current implementations, and to develop guidelines for the use of

computer data exchange standards.