добавить свой файл
1 2 3 ... 27 28
§ Validation, conformance, and interoperability testing.

§ Developing information technology (IT) tools that support the implementation of IT standards.

§ Disseminating information about the standards.

§ Developing a programmatic thrust in information technology metrology for manufacturing.

A further objective of this document is to inform the reader about the importance of standards in facilitating the

ability of companies to manufacture and use their products. As the world moves into the twenty-first century, new

manufacturing technologies are needed to improve productivity and competitiveness. In this information and

computer age, companies exchange and share information across the country and the world. This capability is

needed to manufacture complex products, such as automobiles, airplanes, ships, and buildings, which are produced

today. To meet production deadlines, computer-aided design and manufacturing tools are used to move products

from concept, through design, prototype, manufacture, testing, and support that is required by the customer. This

information exchange process must be accelerated if it is to be useful. Today, existing products and technologies

are often replaced before their useful life has expired. This is driven, in part, by the competitive nature of the

manufacturing marketplace.

In this age of agile manufacturing, concurrent engineering, and teaming, the ability to share product data information

quickly and efficiently among a variety of different computing environments is critical to any collaborative effort.

Such collaboration needs to take into account efforts either within a company or across different companies

cooperating in normal business and commerce. The representation of product data in digital form is a technology

that is basic to both a company's internal plans for integration and its external relationships with the world. Product

data exchange is the essential component to implement the standards and technologies required to make the

collaboration applicable for manufacturing.

NIST has taken a lead position in developing STEP because of its historical mission to promote U.S. economic

growth. NIST has done its best by working with industry to develop and apply technology, measurements, and

standards. Specifically in the last few years, the NIST laboratories have increased their efforts to address the


infrastructural needs of the information technology and manufacturing industries. STEP is an ideal example of a set

of standards that integrates both industries. NIST recognizes that developing standards such as STEP must be

accomplished in the international arena because of the ever-increasing worldwide economic dependencies.

From its start, the STEP project benefited from a large number of experts that brought with them a wide range of

knowledge and skills. One commonality was the enthusiasm, dedication, and hard work that all put into the effort.

When the committee started, few if any of the team had any significant experience in developing standards. In one

sense, this was an impediment since much time was spent learning the intricacies of the ISO process. But in another

sense it was a major benefit since the secretariat and the technical team was unfettered with how things were

typically done in other standards committees. The STEP effort pioneered several accomplishments. STEP was the

first ISO standard to:

§ Use formal information modeling techniques in its development.

§ Publish a standard for an information modeling language.

§ Include digital information in its normative form.

§ Include a specification for conformance testing.

This work traces the history of the development of STEP. Successes, setbacks, and outstanding issues are discussed.

Ultimately, NIST believes STEP is succeeding, both as a technical solution to the problem of product data exchange

and as a contribution to the standards development process.


In Chapter 3 the reader will be introduced to a group of individuals from the PDES/STEP community, known as the

Ad Hoc Complainers and Gripers Committee [1]. As part of their argument for a particular approach to integrate

the many standard parts of STEP, they made an analogy. This same analogy aptly describes the approach taken for

this document:

“The development of PDES1 can be likened to editing a book by several authors, for example a

book resulting from a conference. The book could be put together by:

1. The editors merely collect all the presented papers into one volume.

2. The editors select a subset of the presented papers and publish these as one volume.

3. The editors decide on an outline of each chapter to be written, request the authors to write

their chapter following the outline, and publish the resulting collection.

4. The editors decide on a theme for the book and prepare an outline for each chapter;

commission authors to write their chapters following the outline; edit the chapters to remove

inconsistencies between chapters, to provide adequate cross-reference between chapters, to

fill in any missing ideas and to provide a consistent “style;” and finally publish the result.”

To learn what scenario was recommended by the Complainers and Gripers Committee for STEP integration, the

reader needs to wait until Chapter 3; however, for the purpose of compiling this document, the editor has attempted

to pursue scenario 4. Appendix D, About the Authors, allows the reader to identify the contributors by chapter, to

directly target any questions that may arise from the reading. The Editor attempted to preserve as much of the

authors’ technical and historical opinions as possible; however, to move toward a work that integrates as scenario

4 suggests, some of the authors’ opinions associated with a particular chapter may no longer reflect the authors’

original intent.

1 PDES is an earlier acronym for the STEP standardization work carried out in the United States. Today, PDES

stands for Product Data Exchange using STEP.



In the past, companies conducted business mostly using their internal, proprietary formats. As we move into a

global marketplace, we are beginning to see a dramatic paradigm shift toward open international standards. Figure

1-1 shows a view of these trends. Standards are no longer trailing technology and are no longer an after-the-fact

documentation exercise. Standards provide a critical foundation in achieving effective and efficient communication

within and among companies.

The processes of developing standards and the way we describe products have come a long way. An attempt to

parallel the technology growth with the standardization is not a trivial exercise. You will read in later chapters how

STEP development was, and still is, an experiment in parallel standardization with progressing technology.

Figure 1-1: Movement toward International Standards (contributed by PDES, Inc.)

The potential impact of STEP is enormous and its effect is just beginning to be seen around the world. With more

than 50 production implementations in the U.S. and Europe, STEP is already reducing lifecycle costs and product

time to market, as well as providing increased flexibility and agility. A few examples include:

· Lockheed Martin’s F-22 program has shown consistent savings using STEP: 50% process saving for

composites, and projected 27% savings on tool design for CAD/CAM systems.

· Boeing, in its 767 and 777 programs, has shown a 75% time savings in processing designs from engine

suppliers using STEP.

· Boeing, in its C-17 program, has reduced the time to transfer bill of material data from weeks to minutes using

STEP [2].

NIST hopes this text will capture both the pain and the gain required to get where we are today in informationmanaged

product data exchange.


The remainder of this document is broken into four primary sections:

§ Chapters 2 and 3 provide the basis for understanding product data exchange standards and the

developmental history of STEP.

§ Chapters 4 through 8 focus on aspects believed to be technical innovations for developing STEP and

perhaps for contributing to the promotion of information technology into sectors such as manufacturing,

electronics, and process plants. These chapters also provide more technical depth specific to ISO 10303


§ Chapter 9 reviews the international standards development organization (SDO) responsible for STEP and

associated standards development tools.

§ Chapter 10 presents a look to the future: what lies ahead as impacted by what went before. Chapter 11

reflects on the past and NIST’s involvement in the making of STEP.

The document concludes with glossaries of acronyms and terms, additional references that offer background reading

for some of the chapters, a brief biography on each author, an index, and a bibliography of chapter citations.

The following provides a brief overview of each chapter.

Chapter 2 covers the history of product data exchange standards that lead up to the initial investments in STEP.

Chapter 3 characterizes the phases of development that occurred during the process of reaching consensus on an

international standard for product data exchange. The focus of development shifted a number of times before the

architecture of STEP emerged. This chapter addresses the shifts, the technical implications, and the ultimate

decisions that led to STEP as we know it today.

Chapter 4 provides an overview of the STEP architectural components and methodology and describes the

requirements addressed by the STEP architecture and the governing principles of that architecture. Now that the

Initial Release of STEP has been an international standard for several years, some of the perceived problems with

the current architecture are also discussed.

Chapter 5 views modeling as crucial to the success of STEP; however, modeling is a very complex area and

continually under study. The abundance of conflicting requirements and different proposals, each with different

paths, helped to shape EXPRESS, the modeling language that was created for and used by STEP. Ultimately,

SC4's2 ideas came to encompass both compromise and innovation in the difficult area of modeling. Chapter 5 then

elaborates on EXPRESS as one of the cornerstones of STEP. It considers how the SC4 community has benefited

from developing EXPRESS and the limits to which EXPRESS can meet the needs of automatic code generation and

model validation.

Chapter 6 focuses on sharing data and implementing the standard versus modeling the information. Particular

emphasis is given to the Standard Data Access Interface (SDAI), ISO 10303-22, the data sharing interface standard

of STEP.

Chapter 7 explains the purpose and principles of the application protocol (AP) methodology and gives background

on the decision to add APs to the STEP architecture. This chapter also provides a summary of the mechanisms for

planning and managing AP projects and some of the lessons learned from the AP methodology.

Chapter 8 introduces the methods, tools, and integration of standards-based products as achieved through testing.

The two primary approaches for achieving systems integration are conformance testing and interoperability testing.

This chapter discusses the purpose of testing and describes the relationship between conformance and

interoperability testing in the context of STEP.

2 ISO TC 184/SC4: Technical Committee 184 on Industrial automation and systems integration, Subcommittee 4 on

Industrial data.


Chapter 9 covers the methods, manpower, materials, and tools that contribute to the standardization process of STEP

within the international standardization community. One should approach this chapter with the understanding and

appreciation that EVERYTHING surrounding the standardization of STEP is huge in magnitude and done with a

respect for complexity. Because typical ISO standards are shorter in length and smaller in scope, and most ISO

subcommittees meet with less frequency and with a smaller number of technical experts, SC4 has had to find

innovative ways to handle its standardization process.

Chapter 10 presents a vision of the future of STEP -- how it will impact industry and government beyond the year

2000. It includes both development and implementation perspectives, as well as thoughts on future product

direction. It also describes how STEP will interface with related groups and standards in the future.

Chapter 11 is simply the epilogue. It summarizes the magnitude of the STEP effort, and NIST’s role in that effort.


This document assumes a basic understanding of the standards development process. The intended audience for this

document is standards developers. These developers may or may not have a basic understanding of STEP or of

product data exchange. Specifically, some of the audiences who may be considered prospective readers include:

§ ISO TC 184/SC4 liaison organizations.

§ ISO/IEC technical committee liaisons to SC4.

§ ISO TC 184/SC4 technical experts and their managers.

§ IPO technical experts and their managers.

§ US PRO members.

§ U.S. industry associations and other candidate liaisons to SC4.

§ Information technology vendors.

§ International CALS community.

§ STEP Centers around the world.

§ Other national government agencies interested in product data standardization.

This text may also be useful as a teaching aid to introduce product data concepts and standards at the college level.


Any mention of a product, company, or service in this document is not intended to imply recommendation or

endorsement by the National Institute of Standards and Technology. This document is richer from drawing upon

specific examples and from other literary works, other organizations’ participation, and other product data tools and

services. The reader should assume all references are to enhance the material presented, and to put in context

NIST’s role in standardizing product data exchange.






“Before the dawn of the industrial revolution, engineering work was defined by a physical model of a product to be

reproduced. For example, a worker manufacturing a rifle barrel would ensure that the dimensions of the barrel

corresponded to a model barrel by using calipers to transfer measurements from one to the other. This method

reinforced the concept of workers manufacturing specific product types rather than generic components of larger


In 1801, Gaspard Monge wrote ‘La Geometrie Descriptive’ as the first treatise on modern

engineering drawings. This included the theory of projecting views of an object onto

three planes and the addition of size specifications to the shape descriptions. With the

mechanical drawing, an objective standard of performance for workmanship was possible

and thus the model could be eliminated. The drawing enabled the practice of designing a

product with interchangeable parts to be created. Operations could then be performed

using contractors that could manufacture different pieces to be assembled. This

capability led to the fragmentation of the manufacturing process that exists to this day.

The mechanical drawing concept has lasted for almost 200 years. As described above,

the manufacturing process for developing quality products was interwoven with the

method for describing the products. The drawing became the output of the design

process and the input into the manufacturing process. Drawings were converted into

process plans, which were converted into programs or procedures for the manufacturing

operations. Thus, every process has its own view of the product data. These dissimilar

views have made it difficult to feed back knowledge about different processes to the

designer. In today's industrial enterprises, the lifecycle processes for a product are no

longer all performed by the same group of people. In fact, the processes are distributed

through a network of factories.

As we move into the twenty-first century, new manufacturing technologies are needed to

improve productivity and competitiveness. In this information and computer age,

companies exchange and share information across the country. This capability is needed

for manufacturing the complex products such as automobiles, airplanes, ships, and

buildings that are produced today. There is a special consideration for accelerating this

information exchange process since the existing products and technologies are often

replaced before their useful life has expired as manufacturers compete in the marketplace.

To meet production deadlines, computer-aided design tools are used to move products

from concept, through design, prototype, manufacture, test and, ultimately the support

that is required by the customer [4].”

The representation of product data has evolved slowly over these same 200 years (see Figure 2-1). Before 1800, a

tangible physical model of a product defined product descriptions. The invention of the engineering drawings in the

early 1800s led to more precise product descriptions. This precision increased productivity sixfold over using a

physical model to define a product.


Figure 2-1: Evolution of Product Definition Capabilities

Drawings created with Computer-Aided Design (CAD) tools represented tremendous productivity gains over paper

drawings, such as ease to revise and archive. CAD tools also opened new opportunities, such as enabling

manufacturing instructions to be derived automatically and executed directly from the drawing. Nevertheless, as

computer design and manufacturing tools proliferated to meet increasingly complex and diverse engineering needs,

so did the formats each tool uses to capture and store product data. While paper drawings can be marked up by

anyone with a pencil, a product model that can not be interpreted by the necessary CAD tool is useless. For

organizations to share designs across various CAD and Computer-Aided Manufacturing (CAM) tools, they must be

formatted in a manner that the tool can recognize. This requirement is becoming increasingly important in an age

where large manufacturers often form joint ventures to address a business opportunity, and where partners in a

supply chain are being called upon to deliver an increasingly complex array of services.

Most companies find it difficult to enforce the use of a common set of CAD/CAM tools within their organization,

much less across (multiple) supply chains and among joint venture partners. Because of the lack of any common set

of tools, a common format for neutral file exchange is needed. It is exactly this common format, as well as data

access mechanisms that STEP hopes to provide. The cost benefits are suggested by the reduction in necessary

translators shown in Figure 2-2. The figure illustrates that by using a neutral file exchange, the number of translators

(for N systems) can be reduced from N2 to N. Using a neutral standard for transferring information across systems

drastically reduces the requirements for translators.


Figure 2-2: Efficiency of a Neutral Format for Data Exchange


The quest for a common output format among design automation tools did not start with STEP. STEP in many

ways can be seen as the culmination of various U.S. industry, government, and international efforts. For example, in

the 1970s the X3/SPARC Committee of the American National Standards Institute (ANSI) contributed the notion

that data should be described in a manner that was independent of particular uses or computer technologies. SPARC

proposed a three-schema methodology within which one basic conceptual information model could be realized in a

variety of computer technologies and presented to users through a variety of filters. These different views of the

same information were called conceptual, internal, and external views. (See Figure 2-3 [5].)

Efficiency of a Neutral Format for Data Exchange

By Direct Translators … By Neutral Format

Source: Department of Trade and Industry, “Product Data Exchange, An Introductory Guide,” Finallay Publications, UK.


Figure 2-3: Three-schema Methodology

The U.S. Air Force built upon the ANSI/X3/SPARC methodology by developing formal methods for information

modeling, as a part of its Integrated Computer Aided Manufacturing (ICAM) program. The intent of ICAM was to

develop new manufacturing automation technologies that could lower the overall cost of procurements. The

program determined that new systems engineering methodologies were needed for developing new technologies,

which implied new methods of defining requirements. This work resulted in a suite of formal methodologies:

IDEF0 for modeling activities, IDEF1 (later extended to IDEF1X) for modeling information, and IDEF2 for

modeling system dynamics. ICAM awarded a series of contracts that required the use of these new systems

engineering methodologies. Some of these contracts had direct impact on developing STEP. This held true for

other programs as well. The Integrated Programs for Aerospace-Vehicle Design (IPAD) project funded by NASA,

for example, had a geometry focus and is credited with being the first to make use of information modeling for

systems integration.

ICAM and its subsequent contracts, including the Product Definition Data Interface (PDDI) and Geometric

Modeling Application (GMAP) programs, contributed much to the tools and methodologies later applied to STEP.

Other efforts contributed to the formal description of the information needed to be shared among CAD systems. The

Computer-Aided Manufacturing - International (CAM-I) organization, through its Geometric Modeling Project

begun in the early 1970s, contributed significantly to the formal description of Boundary Representation (B-REP)

data. The result of the CAM-I funded work, which was a mathematical representation of standard geometry and

topology, was considered ahead of its time and clearly captured more information than the typical CAD systems of

the day could interpret. It was submitted to ANSI committee Y14.263 for standardization as a data exchange

mechanism. The CAM-I specification did not contain an exchange mechanism, but a foundational description of the

data that could be exchanged.

3 The ANSI Y14.26 committee name was Digital Representation for Communication of Product Definition Data.


2.2.1 The Birth of IGES

In 1979, events took place that catalyzed the CAD vendor and user community to create the first national standard

for CAD data exchange. CAD systems were less than ten years old, and there were only a handful of products with

any significant market penetration. Even at this early stage, users were overwhelmed by the inability to share data

among these tools and with their own internally-developed databases. In September 1979, frustration came to a

head at the two-day Air Force ICAM Industry Days Meeting [6]. On the first day, a representative from General

Electric (GE) challenged a panel of CAD vendors, which included ComputerVision, Applicon, and Gerber, in

essence, to stop blocking progress and work together to enable an exchange mechanism. While this need was

intuitive from a user’s perspective, this was a very threatening proposition to the CAD vendors— who feared that

sharing the structure of their databases publicly would be tantamount to giving away their competitive advantage. It

would have been easy to gloss over the challenge; after all, the major vendors all had at least token representation on

the ANSI committee responsible for CAD standards. Instead, the ComputerVision representative responded with a

challenge of his own: If Boeing and General Electric (and perhaps others) would contribute the CAD translators they

had already developed, the vendors would share their database structures.

What led to this offer was just the right mix of business motivation and hidden agendas. It just so happened that the

evening before the CAD panel, a CAD vendor representative was busily recruiting employees for his (unannounced)

new robotics company. In forming this company, he gained the user’s perspective: his product was going to need to

have access to CAD data! If he could set the wheels in motion for the CAD vendors to make their database

structures public, his new company would have a better chance at success; however, an exchange standard was also

in the CAD vendors’ best interest. The CAD vendors tried to differentiate themselves based on loyalty to their

customers; this also had the negative effect of dividing the end users into camps. There were large Navy contracts

looming on the horizon, and no vendor wanted to look unresponsive to customer requirements.

In the evening after the panel, several interested parties gathered in a smoke-filled room and asked themselves if a

common translator was really possible. The room had the right mix of people and ideas at the right time. This

included an Air Force ICAM, Navy, and NASA representative, each willing to fund $25,000 for such an effort. A

National Bureau of Standards (NBS)4 representative who, after a call to his boss at home for a sleepy approval, was

willing to champion it as chair and coordinator. The IGES Organization was formed by NBS in the spring of 1980.

With the fundamentals to a common translator decided, conversation turned to a name for this new translation

project. The group nixed the suggestion "Universal Translator" to avoid offending those within ANSI who might

have interpreted the project as a way to displace the years of effort already put towards a Y14 standard. A

minimalist approach was suggested:

I - Interim, to suggest that it would not replace ANSI’s work

G- Graphics, not geometry, to acknowledge that academics may come up with superior mathematical descriptions

E- Exchange, to suggest that it would not dictate how vendors must implement their internal databases

S- Specification, not to be as imposing as a standard

The panel reported on the second day, and the wheels were set in motion to create an “IGES.” Once the panel

admitted that a common translation mechanism was possible, it was impossible to stop the momentum of the

customers’ enthusiasm and expectations. Applicon and ComputerVision agreed to open up their internal databases,

GE offered its internal database structure, and Boeing supplied the structure of its Computer Integrated Information

Network (CIIN) database. Both GE and Boeing contributed their existing translators. A core team was formed

which included representatives from NBS (Roger Nagel), Boeing (Walter Braithwaite), and GE (Phil Kennicott).

Team members had worked closely with each of the vendors on internal integration projects. This prior experience

built the expertise and trust needed to craft a solution in a very short time, and neither vendor felt it gave an unfair

advantage to the other.

4 Department of Commerce’s National Bureau of Standards was renamed the National Institute of Standards and

Technology (NIST) by the Omnibus Trade and Competitiveness Act of 1988.


Soon after the ICAM Industry Days, NBS called an open meeting at the National Academy of Sciences (October 10,

1979). Around 200 people attended to herald the birth of IGES. There was an atmosphere of extraordinary

excitement, although not everyone was supportive. In addition, although it was hotly debated, the name was

accepted eventually with the minor change from “Interim” to “Initial.”

After two critical reviews, the IGES team released their first draft in 1980, containing geometry, graphical data, and

annotations. The IGES specification was brought to the ANSI Y14.26 committee for standardization, an action

which forced the committee to try to reconcile the very different views embodied by the IGES work and the CAM-I

boundary-representation description effort. When the first version of IGES was adopted as a standard (Y14.26M-

19815), it approved the IGES draft with the CAM-I work attached (but not integrated) as the fifth section, entitled

“Section five - Basic shape description.” Subsequent versions of ANSI Y14.26M omitted this fifth section .

Although it had funded the work, CAM-I recognized that Section five of IGES Version 1 was not compatible with

the shape description methods used in current CAD systems. CAM-I therefore developed an alternative

specification, resulting in the Experimental Boundary File (XBF) of 1982 [7]. This specification used the same

format and file structure as IGES, but allowed for the exchange of solid models many years before IGES itself

acquired that capability. The CAM-I XBF influenced various later efforts in solid model data exchange, and

ultimately affected the STEP part, ISO

10303-42 [8].

Work in CAM-I had started even earlier on

the Application Interface Specification

(AIS), a proposal for a standardized

programming interface to CAD modeling

systems. This proposal eventually spent the

period 1992-1994 as an ANSI Draft

Standard for Trial Use [9]. The AIS has

recently been released to the Parametrics

Group in ISO TC184/SC4/WG12 for

extension and updating as part of the new

parametric capability they are developing

for STEP (see Chapter 10).

Once the technical content of any standards

document has been agreed upon, most

people feel the job is done. Few realize

how much work goes into the final editing of the document. It is an exacting task requiring attention to a multitude

of small details. The sheer size of the IGES standard, for example, with its many figures and internal references

made the job of editing quite a nightmare. The product data community owes an enormous debt to people like Bob

Colsher, Joan Wellington, JC Kelly, Phil Kennicott, Dennette Harrod, Brad Smith, Gaylen Rinaudot, Kent Reed, and

others who dedicated themselves to final production of each edition of IGES. Each spent days, weeks, and months

of unreimbursed personal time laboriously editing and re-editing those chapters of text and figures.

2.2.2 Product Definition Data Interface (PDDI)

IGES provided a practical first solution for CAD data exchange, complete with an exchange file format. The speed

with which this first draft was developed was remarkable! It may have been due, in part, to the relatively limited

scope of the specification and the small size of the committee developing it. An additional contributor was the

contract requirement to publish a document within three months of the contract award. Once it fell under the

scrutiny of an ever-broadening community, weaknesses were identified that eventually justified embarking on a new

standard, which could break tradition with IGES. The Air Force ICAM program again made a significant

5 Since revised and republished as ANSI/US PRO/IPO 100.

Brad Smith recalls… When I think back on the early versions

of IGES, I remember one of those editing sessions. It was

Version 3.0. We were running late as usual, and I had

committed to be in London for an SC4 meeting. I had also just

taken delivery of the first laptop computer we ever had in our

group. I decided to take the master copy of the IGES

document with me, along with the laptop, so as to have the

editing done by the time I got back home. At the last minute, I

realized the laptop only ran on 115 VAC power, so I hit an

electronics store on the way to the airport. The first night in

the London hotel room, I felt rather smug as I settled into the

IGES editing after hooking up all the adapters, converters, and

cables. Unfortunately, I soon noticed the plastic case on the

new power converter had started to melt. Not wanting to stop,

I put the converter into the small room refrigerator, slammed

the door on the cords, and went on editing the document for

the next three days.


contribution to the evolution of product data exchange standards, this time through its Product Definition Data

Interface (PDDI) contract with McDonnell Aircraft Company. The purpose of PDDI was to develop a replacement

for blueprints as a communication mechanism between engineering and manufacturing. It sought to replace all

information found on a blueprint (more commonly known as an engineering drawing today). PDDI developed a set

of information models, a modeling language which contributed to EXPRESS [10], an exchange file format that

separated that data being exchanged from its definition, and a mechanism for applications to share data.

One of the tasks of this contract involved an evaluation of IGES in the context of its current implementations. This

resulted in a thorough report [11] and numerous constructive requests for changes to IGES. The evaluation activity

helped the community clearly define IGES’s shortcomings:

· Flavorings - IGES contained several ways to capture the same information, which made proper interpretation

largely dependent on the particular “flavor” of the pre- and post-processors.

· File size/Processing time - IGES was criticized heavily for requiring large files that took hours or even days to

parse with the average computing power available at the time.

· Loss of information during exchange - Information will inevitably be lost when information is passed between

two CAD systems with inherently different capabilities.

· Lack of discipline, architecture - There was a perception that IGES was developed without rigorous technical

discipline, and that formal information modeling would be useful.

· Upward compatibility - The need for generations of processors to parse files compliant with earlier versions of

IGES thwarted the breadth and rate of change in succeeding versions.

· Automated a paper system - IGES was seen as a method to exchange engineering drawings, but not capable of

capturing complete product data (including administrative information) to enable more sophisticated

automation which would reduce or eliminate human intervention to translate.

Although PDDI was a research effort from 1981-1987, it contributed understanding, mechanisms, and models to

what later evolved into STEP. It served as the “kick in the pants” for the IGES Organization to think “What’s

next?” Those from the PDDI team had the opportunity to make a real impact on future PDE standards.

Additional shortcomings in IGES were later identified in a paper by Peter Wilson:

• Subsetting - Vendors selected and implemented only portions of the whole of IGES, thus making exchange

between two systems impossible without prior agreement on what was to be exchanged.

• Processor testing - There was no mechanism for testing processors or resolving errors between two processors


There was a real, long-term problem with IGES that would be difficult to fix: IGES communicated the lines and

symbols appearing on an engineering drawing (except for some electrical concepts such as connectivity), but it

failed to communicate the meaning of the information the engineering drawing was created to convey. The PDDI

study revealed that product features must be transmitted with the geometry so that computer-based applications

could "understand" the engineering drawing. For example, an application looking at an IGES representation would

see merely a circle on a part. The desired result was to be able to distinguish whether that circle was a surface mark

or a hole.

2.2.3 Subsetting and Application Protocols

The use of formalized subsets of IGES entities offered one approach to improving the quality and predictability of

translations. NBS, under sponsorship from U.S. Department of Defense Computer-Aided Acquisition and Lifecycle

Support (CALS) Program, led the IGES Organization6 in building IGES subsets and applications for Defense. The

6 The work on IGES Version 1.0 required the creation of two committees – a Working Committee to extend the

capabilities of IGES and repair errors uncovered in that original version and a Steering Committee to oversee the


U.S. Department of Defense eventually stipulated IGES subsets for various application areas, such as technical

illustrations and electrical/electronic applications, within their CALS suite of military standards. Subsets allowed

IGES processors to be classified by the functionality that they could support entirely, and acted as a predefined

written agreement between a sending and receiving party.

STEP’s concept of application protocols (APs) grew from the lessons learned regarding IGES entity subsets and

early IGES Architecture, Engineering, and Construction (AEC) application protocol work done by NIST for the U.S.

Navy. Chapter 7 is devoted in more detail to the concepts and benefits afforded by STEP application protocols.


Several international efforts also contributed significantly to the evolution of product data exchange standards.

2.3.1 AECMA Report of Geometry Data Exchange Study Group

In 1977, the European aerospace industry recognized a major problem in exchanging shape representation on

collaborative projects. The European Association of Aerospace Industries (AECMA) developed a common

exchange format that allowed the collaborating companies to exchange simple surface geometry. The format was

used on a few occasions, but the advent of more complex surface types, integrated into vendor systems, caused it to

fall into disuse. Even so, there was good work done by AECMA. The United Kingdom contributed the AECMA

Report of the Geometry Data Exchange Study Group to the International Organization for Standardization (ISO)

effort for building an international product model data standard [13].

2.3.2 Flachenschnittstelle des Verbandes der deutschen Automobilindustrie (VDA-FS, VDA-IS)

The Germans standardized Flachenschnittstelle des Verbandes der deutschen Automobilindustrie (VDA-FS), which

addressed the exchange of free form surfaces and free form curves needed by the automotive industry. VDA-FS

was based on IGES but offered a competing exchange file format to that of IGES. The VDA was created in 1982 to

increase the efficiency of the design process and usefulness of CAD/CAM systems. The Germans brought VDA-FS

to the international table to contribute toward the international product model data standardization effort [14].

The German automotive industry, through VDA-IS (IS-IGES Subset), defined subsets of annotation entities that

were relevant for various applications in automobile manufacturing. These subsets were created so that compliance

could be tested. The particular data exchange requirements met by these subsets included: drawing information,

two- and three-dimensional geometry, and analytic and free-form surfaces [15].

2.3.3 Standard d’Echange et de Transfert (SET)

The French Standard d’Echange et de Transfert (SET) project started at Aerospatiale in 1983. Aerospatiale needed a

common database capability across its different CAD systems. They did a formal test of IGES and found it did not

work. To be a little more precise, they tested the first beta IGES implementations from two vendors which,

according to documentation, had implemented only points, lines, arcs, and text notes. (A major amount of

information on an engineering drawing would of course be lost even if these few entities had been implemented

completely and correctly!) From this test, Aerospatiale concluded that it was the IGES specification that did not

work. The result was a French effort to write a specification, standardize it, implement it, test it, and support its use

in production. Designed to address the difficulties using IGES, the primary industrial drivers of SET were

automotive and aerospace industries. The standard represents the results of the requirement to exchange data

operation. The Working Committee had two major subcommittees: an Edit Committee and a Test, Evaluate, and

Support Committee. Together the Working and Steering Committees were referred to as the IGES Organization.


between different CAD/CAM systems, and from the need to archive these data. Version 1.1 of SET was put on the

international table to contribute toward the international product model standard. It contained:

<< предыдущая страница   следующая страница >>