§ Supplementary information about the data structures and concepts employed.
§ Provided rules and recommendations concerning specifications to ensure coherence in future developments
Association GOSET is an organization established by industry and government in France to support continued
development, maintenance, and implementation testing of SET. GOSET representatives are also active contributors
to developing STEP and testing services to conformance test ISO 10303 .
In 1984, the European Commission funded an ESPRIT project called CAD Interfaces (CAD*I), with twelve
participating organizations from six European countries. The project worked mainly in product model data
exchange and on data exchange for finite element analysis. As in STEP, the transfer of data was based on the use of
schemas defined formally using a data modeling language. In 1987, this project achieved the first ever transfer of
boundary-representation solid models between different CAD systems. CAD*I participants were involved in the
development of STEP from the beginning of the work of ISO TC184/SC4, and some of them are still active today.
Much of the shape modeling capability of STEP is based on CAD*I work , and the project also had a significant
influence on STEP developments in the finite element area.
2.3.5 Why Not Adopt IGES Worldwide?
The following realities became drivers for a common international standard:
· Global commerce and increased outsourcing making data exchange more critical.
· More complex products which require coordinating among multiple engineering disciplines.
· Multi-use software, e.g., design or engineering systems that apply to multiple industries and applications.
· Need for lifecycle support.
Moreover, these are the generalities. As cited
earlier, IGES as a world contender for
international standardization, also had many
2.4 THE PDES INITIATION
By 1984, many of these efforts had produced
enough results to be compared, and an
international community was preparing to
form a committee in hopes of creating a
common solution to CAD data exchange. In
May of 1984, a late night meeting of the IGES
Organization Edit Committee was held. The
outcome: Kal Brauner, the Boeing
representative was tasked to write a paper on
what the next generation of IGES might look
Larry O’Connell (then of Sandia Laboratories) recalls… I
remember the IGES quarterly meeting aboard the
landlocked Queen Mary liner near Long Beach, CA. Most of
us slept in staterooms aboard the elegant vessel and strolled
to the daily plenary session after power walking around the
ship and having breakfast on board. Much of the paneling
in the less pricey staterooms was bird's eye maple. At least
one of the plenary sessions was held in the grand ballroom
under massive crystal chandeliers. Many representatives
from across the Atlantic and some from across the Pacific
attended to give the conference a truly international flavor.
Brad Smith outlined his notion of what should be done to
expand the scope and vision of the next version of "the
standard." In the months that followed, a select few (guided
by Kal Brauner of Boeing) began defining the requirements
Queen Mary was a fitting setting for the launch of such a
like without the IGES constraint to provide upward compatibility for processors. This informal request was in
response to pressure from PDDI results and European efforts. The first Product Data Exchange Specification
(PDES) report was issued in July of 1984, and was followed by a second report in November of 1984. These reports
laid the groundwork for the PDES Initiation Effort, which, similar to PDDI, was considered a theoretical exercise at
building a standard based on a broader automation goal and the discipline of information modeling. The PDES
Initiation Effort used a simple machined part as its focus for both the “logical” information being captured and the
“physical” mechanisms of data exchange. It also included an Electrical Schematic Application model. The
Initiation task validated, through modeling, the concept that electrical connectivity and mechanical “joining” both
shared a common topological model structure.
Those individuals involved originally assumed that this next-generation standard would be IGES Version 3. Instead,
the work spawned a separate U.S. national effort known as PDES. PDES was eventually the specification for the
international effort led by ISO TC184/SC4 responsible for developing and standardizing STEP. Chapter 3 provides
more detail on PDES impact and this initiation effort.
2.5 HOW DID ELECTRICAL CONTENT FIND ITS WAY INTO STEP?
One might wonder how electrical content ended up in an ISO, rather than an International Electrotechnical
Commission (IEC) standard. As with STEP, the roots trace back to IGES. The original vision for IGES included
products. It was not until the second version of IGES that a very preliminary attempt was made to accommodate
electrical connectivity information. Under the leadership of the IGES Organization Electrical Applications
Subcommittee7, developers began using information modeling in 1983 to improve the quality of electrical constructs
in later versions of IGES.
Aside from the quality of the constructs, the EAC was concerned about overlap and duplication with other
standardization efforts. In late 1983, the EAC met with the Institute for Interconnecting and Packaging Electronic
Circuits (IPC) in an attempt to coordinate efforts. It was decided then that IPC would continue to focus on the
CAD-to-CAM interface and the IGES EAC would focus on the modeling and CAD to CAD issues. Members of the
EAC also heard of attempts by the silicon foundry to develop an interchange format for integrated circuit designs,
and many wondered if that effort would duplicate, complement, or conflict with what was being developed for
2.5.1 Harmonization Activities
In April of 1984, The Institute of Electrical and Electronics Engineers (IEEE) Standards Coordinating Committee
called a meeting that further drew the IGES Organization into a dialog with other standards efforts. Of particular
interest was closer coordination between IGES and the relatively new Electronic Design Information Format (EDIF)
effort. The EDIF representative at this meeting declined an offer of joint participation, for fear that standardization
activities might delay the EDIF development schedule— a factor that has continued to impede, from both the IGES
and EDIF sides, true coordination among related standards efforts. Other electrical standards represented included
IEEE Project Authorization Request (PAR) P1076, the Abbreviated Test Language for All Systems (ATLAS), and
the Tester Independent Support Software System (TISSS).
At about the same time, a representative from Westinghouse began reaching out to other related standardization
efforts across the Atlantic Ocean, and authored several related papers that were published by CAM-I. He developed
contacts that led to discussions between the IGES Organization EAC and the IEC TC3, Documentation and
Graphical Symbols. In particular, NBS along with other IGES officers attended a meeting of TC3 subcommittee
7 Later known as the Electrical Applications Committee (EAC).
Howard Bloom recalls… When I was asked
by the CALS program manager to lead the
harmonization effort, I had no realization of
the sensitivity of each of the standards
development organizations. I had to be
extremely careful at the early meetings with
the words that I used. One phrase that
might favor one specific standard sent the
consensus building activity “two steps
back.” It took hard work, keen listening
and great diplomacy to drive the activity
towards accepting HPS-100. I don’t think it
would have been possible if I had been from
any other organization other than NIST.
SC3B in Los Angeles. This later facilitated the involvement of TC3 in the ISO/IEC Joint Working Group within ISO
Many organizations, including ANSI, and numerous individuals tried to find ways to increase the awareness and
cooperation among related electrical standardization efforts with little measurable success. Each group working on
some aspect(s) of the standardization for electrical and electronic product data had a set of volunteers, their
sponsors, and a clientele to whom they felt they owed their scheduled deliverables. For the most part, no two efforts
were initiated with the same goal, but rather were extended into overlapping territory in response to the needs of
their users. Furthermore, some of the sanctioning standards bodies depended in some part for revenue from the sale
of standards documents. A certain amount of jealousy about a perceived hierarchy of organizations also hampered
some of the willingness of people at the working level to share results and efforts. The resulting array of conflicting
and overlapping standards prevented the market from supporting any cohesive standard interchange methodology,
and left much of the burden of data exchange on the shoulders of manufacturers who used electrical CAD systems.
In February of 1988, ANSI/ASME Y14.26 (the same committee that standardized IGES) raised the concern to ANSI
management in a letter which stated:
“… we are concerned that there are concurrent overlapping standards activities that are not
coordinated. Of particular concern are the Initial Graphics Exchange Specification (IGES)
Electrical Application subset, the Electronic Design Interchange Format (EDIF), the Institute for
Interconnecting and Packaging Electronic Circuits (IPC) 35X series of specifications and the
VHSIC Hardware Description Language (VHDL)… ”
While the standards cited were not the only efforts of concern, they were specifications which
ANSI itself had authorized and which the government called out in CALS military standards.
This letter led to a “Harmonization” meeting at EIA Headquarters in May, 1988. CAM-I’s
effort. Participants included Boeing, McDonnell Douglas, Allied Signal, Eastman Kodak,
Hewlett-Packard, Northrop, The Plessey Company, Westinghouse, and NIST. In February of
1989, the EIA issued results of an Evaluation Report entitled “Harmonizing CALS Product Data
The CALS/EIA Report found “… far more overlap
than… anticipated… EDIF overlaps one or more other
standards 78 times.” The Report offered a matrix showing
which lifecycle steps were captured by which of the four
ANSI standards, carved out a scope for each standard based
on this matrix, and declared harmonization effectively
accomplished. This proposed solution was rejected by
industry, as noted in CAM-I EAP R-90-EAP-01 which
criticized the Report’s conclusions. Milton Piatok of Boeing
summed up industry’s viewpoint in a letter to ANSI in 1989:
“An electronics company which performs all the
steps in the design process… using heterogeneous
computer systems, work stations, and factory NC
[numerical control] machinery and robots would
have to support all four standards… At worst, this
could mean not only having to implement the software to support each standard, but also having
translators between each pair. … Such an approach (if it were feasible) would be cumbersome,
error-prone, time-consuming, and costly.”
In November 1989, NIST accepted the leadership of the Harmonization effort, which was later formalized as the
Harmonization of Product Data Standards (HPS) organization under the Industrial Automation Planning Panel
(IAPP) of ANSI. The HPS established three councils, to which NIST continued to serve as the Secretariat: Business
McDonnell Douglas (now from NIST), led the Tools and Technology Council.
The major accomplishments of the HPS organization were to propose a methodology and a process for harmonizing
the four ANSI standards, and to publish the first version of a coordinated information model as ANSI/HPS-100
“HPS Information Federated Model Descriptions.”
Figure 2-4: The Operative Means to Harmonization
The HPS proposed the following process to guide harmonization, which reflects the group’s early belief that the four
standards would eventually be completely represented within STEP:
Process Guidance for Harmonization
Gather Models Gather verified conceptual models for the subject area of current focus from each of the
relevant standards organizations.
Federate Every element is added to federated model in data dictionary. Elements are classified.
Unique, identical, and conflicting coverage is identified. Conflicts are resolved by
creating generic elements that each conflicting element can be mapped to. Federated
model contains each conflicting element as well as resolving elements.
Test Define mapping between standards through the generic portion of the federated model.
Create test vehicles (test cases) for the subject area of interest in the original standards.
Sending Ö Federated Ö Generic Ö Federated Ö Receiving
Standard Model Portion of Model Standard
Format Federated Model Format
Compare before & after files of test vehicles document mappings.
Harmonize Derive harmonized model from tested, generic portion of federated model.
Submit portions of harmonized model as candidate application reference models
national standardization. Hold public review.
Integrate with STEP The portions of the harmonized model submitted for standardization within STEP will
Process Guidance for Harmonization
be integrated with STEP resource models in accordance with STEP procedure.
Develop APs, CDIMs Develop application protocol (AP) and context-driven information model (CDIM) for
subject area of interest. The AP will reference the mappings between the harmonized
model and each standard. Identify information voids that none of the standards cover.
Table 2-1: The Harmonization Process (V1.1)
Both the information model and the guidelines for harmonization, later referred to as the “federation” to reflect the
individual organizations’ priority of autonomy, aided the groundwork for continuing international collaboration.
The HPS was moved under the CIM Standards Board of ANSI and then deactivated as leadership in the area was
transferred to the international arena under IEC Technical Committee (TC) 93. Through its working groups, IEC
TC93 continues to develop a federated model to aid the interoperability of electrical information exchange
standards. NIST representatives continue to play an active leadership role within IEC TC93 to build supporting
electrical and electronic standards.
2.5.2 IGES Electrical Transition to STEP
To help interested manufacturers prepare their people for Computer Integrated Manufacturing using STEP, the EAC
released the Layered Electrical Product Application Protocol (LEP AP), which was referenced in IGES Version 5.3.
Initial EAC leadership to accomplish this release was from the Department of Energy Sandia Laboratories, and later
the IGES banner, plus many more working under various other banners. People working for and with the ANSI HPS
mentioned above provided significant contributions to the model. A notable monetary and morale boost for this
model came from the U.S. Naval Command, Control & Ocean Surveillance Center, Research Development Test &
Evaluation Division which contracted for developing the IGES Hybrid Microcircuit Application Protocol . This
IGES AP was the most immediate predecessor of the LEP STEP AP.
2.6 LEGACY TO STEP
Even before the ANSI/HPS-100 model emerged, the early efforts of the IGES EAC provided some valuable general
lessons learned about information modeling in a standard’s setting: