§ 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
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
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.
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.
1.2 DOCUMENT APPROACH
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 . 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
“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
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’
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.
1.3 DOCUMENT CONTENT
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
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.
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
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
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
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
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
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.
1.5 DISCLAIMER FOR THIS DOCUMENT
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.
IN THE BEGINNING… THERE WAS PRODUCT DATA EXCHANGE
2.1 EVOLUTION OF PRODUCT INFORMATION SHARING
“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
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,
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 .”
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
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
2.2 EARLY CONTRIBUTING EFFORTS
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
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
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
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 . 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
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.
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.
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 . 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
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
Standard for Trial Use . 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
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 , an exchange file format that
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  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
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
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.
2.3 OTHER INTERNATIONAL PLAYERS
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 .
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
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 .
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 .
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
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: