**STEP Application Protocol Implementation**

**by**

**Yuhwei Yang**

**P.D.I.T.**

**for**

**CIC Group, Building and Fire Research Laboratory**

**National Institute of Standards and Technology**

**October 1995**

The objective of this paper is to address the questions that have been
raised about how STEP is to be implemented, especially from the
perspective of the design intent of the STEP architecture and
development methods. Since there are a myriad of issues concerning "data
exchange", "data sharing", and the use of multiple Application Protocols
(APs) in a single implementation, this paper discusses STEP AP
implementation with its focus on addressing these issues. Many of the
existing STEP AP implementation projects currently, use the same
implementation approach and system architecture as the IGES
implementation. As a result, many implementation issues have been
identified by individuals that use the IGES implementation approach for
STEP. The differences between the nature of IGES and STEP specifications
require their implementation approaches to be different. These
differences are identified in this paper.

Many believe that data sharing is defined as the use of multiple APs in
a single implementation. As a result, some of the most popular proposed
solutions are focused on how to integrate APs into a single schema to
solve the data sharing issue. In fact, data sharing and integrating APs
are related but independent issues. The integration of APs involves
using multiple APs to satisfy a larger, and sometimes ad hoc application
context and data scope. The primary technical issue is the proper merge
of multiple AIM schema; a data semantic alignment issue. Data sharing is
an implementation objective that requires designing a system
architecture to satisfy a specific data sharing environment. The primary
technical issue is data access and management of the shared data
instances; an implementation issue. A single system architecture that
satisfies the data sharing implementation objective can apply regardless
of whether a single STEP AP or multiple APs are used as the standard
data definitions.

In order to effectively explain and examine the relationships among STEP
implementations in data exchange, data sharing, and the use of multiple
APs, they need to be defined and discussed separately.

The issues associated with implementation are separated into the
following four areas:

\(1\) Data exchange and data sharing implementation using Application
Protocols.

\(2\) Implementation using a single AP versus implementations using
multiple APs.

\(3\) Variations on STEP implementation approaches and system
architecture (There are many valid and useful STEP implementation
approaches. They can vary significantly depending on the implementation
objectives).

\(4\) Data exchange implementations based on STEP versus data exchange
based on IGES (they are fundamentally different).

This paper is organized into four sections to address these four points.

**1 Data Exchange and Data Sharing**

The development architecture and methods included in ISO 10303 are
designed to support the principle objective of the standard: the
specification of standardized descriptions of product data that are
suitable not only for neutral file exchange, but also provide a
[basis]{.underline} for implementing and sharing product databases.

It is generally accepted that there is a significant industrial
requirement for what is called "data sharing" and that "data sharing" is
different from or beyond "data exchange". In order to assess the nature
of support for these in ISO 10303, it is necessary to first establish
exactly what they mean and how they are different. The following simple
real-world analogies can be used to illustrate the concepts of data
exchange and data sharing.

**1.1 Data Exchange - An Example**

An account statement detailing a customer's banking activity is prepared
monthly by a bank and sent to a customer via the US Postal Service. The
customer receives the statement and uses the information to balance his
checkbook and track his financial position. A "data exchange" has taken
place (Figure 1-1).

![](media/image1.emf){width="6.495833333333334in"
height="2.8041666666666667in"}

Figure 1: Example - Data Exchange Scenario

Account information maintained by the bank has been transformed into a
form the customer can understand (a statement), the information has been
transported to the customer via an exchange mechanism (the US Postal
Service), and the customer has received and understood the information.
Such an exchange has the following characteristics:

-   [Initiated by data producer]{.underline}

    Typically, a data exchange occurs upon the initiation of the party
    who originally produces the information, in this case the bank.

-   [Transformation to neutral format]{.underline}

    The bank may choose among many different internal representations to
    effectively manage its account information. In order to communicate
    that information with the customer, however, a transformation must
    take place to convert the information into a form the customer can
    readily understand. In this scenario, the information to be
    exchanged includes not only the data (numbers representing dollar
    values), but also the *context* of that data. In this case, the
    context is represented by the column titles and descriptive text
    which accompany the numeric data on the statement. Without this
    contextual framework, the customer would have a difficult time
    understanding the information.

-   [Redundant copies of data]{.underline}

    Once the exchange has taken place, there are now two copies of the
    account information: the account information represented internally
    at the bank and the statement now in the possession of the customer.
    Presumably, the customer will use the account statement to maintain
    his own account information independent of the bank.

-   [Discrete event in time]{.underline}

    A data exchange occurs as a discrete event in time. Once the
    exchange has been accomplished, the information at the "sending"
    side (the bank) may change without notice to the "receiving" side
    (the customer). The information passed during the exchange is simply
    a snapshot of the data as it existed at the time of the exchange. If
    this new information is to be passed along to the customer, another
    data exchange must take place. Similarly, if the customer wishes to
    respond in some way to the account statement, the customer must
    initiate a new data exchange in which his response is sent to the
    bank.

**1.2 Data Exchange and ISO 10303**

In a modern computing environment, data exchange is commonly understood
to be the exchange of neutral format data files between computer
systems. A sending system translates data from its internal format and
encodes it into an established neutral format. This file is then
transferred to the receiving system where the data is translated into
the internal format of the receiving system.

The architectural components which comprise a data exchange
implementation include:

-   a sending system translator (pre-processor) to generate neutral data
    file

-   a transport mechanism for sending neutral files to the receiving
    system

-   a receiving system translator (post-processor) to convert data files
    to an internal format

There are many well understood transport mechanisms available for
distributing a data file, including electronic mail and File Transfer
Protocol (FTP).

In the banking analogy, the bank statement, including both the data and
the data context, represents the neutral data file. In traditional
computer-based data exchange, the neutral data file usually contains
only the data, not the context. The context of the data, or how the data
values relate to meaningful concepts, is often defined *implicitly* by
the data's location in the format file. Both the sending and receiving
systems depend on *a priori* knowledge of the file format and its
relationship to the data context. If this were true in the banking
analogy, the account statement would contain only numbers; the bank and
the customer would need to agree beforehand which numbers correspond to
which account categories (i.e. line 1 would contain the balance, line 2
would contain disbursals during the reporting period, etc.)

ISO 10303 supports data exchange through the STEP physical file format.
Each STEP application protocol provides an application interpreted model
(AIM) which serves as an explicit standardized data specification for an
established application context. It is the AIM which provides a
documented explanation of the context (scope) and meaning
(relationships) of the data to be exchanged. The AIM is used, along with
an encoding algorithm, to produce STEP physical files which contain both
the data and its associated context, thus enabling effective and
flexible communication between computing systems.

**1.3 Data Sharing - An Example**

Unlike data exchange, the definition of data sharing is not as easy to
agree on. This is true because there are many different implementation
objectives for data sharing and too many different ways that data
sharing implementations can be created. At an abstract level, data
sharing means data stored in one system can be shared by other systems.
Conceptually, a sharable data instance needs only to be stored once in a
single place and used for many purposes by many systems. The term
"share" means to use, own, or receive jointly; it is also defined as a
portion of a whole which is given or assigned. If we use these
definitions, data sharing is not the act of transferring a snapshot of
the data, but the joint use and ownership of the data.

Consider one example (as illustrated in Figure 1-2) of data sharing in
the context of the banking analogy presented above.

![](media/image2.emf){width="6.499305555555556in" height="2.78125in"}

Figure 2: Example - Data Sharing

Rather than mailing an account statement every month, the bank may
implement a touch-tone telephone system to pass along information to its
customers. A customer may call the bank and use the push-buttons on the
telephone to enter his or her account number and navigate menus to
access and update his or her account information. In this case, data
sharing has the following characteristics:

-   [Initiated by data receiver]{.underline}

    Typically, data sharing occurs upon the initiation of the party who
    desires/receives the information, in this case the customer who
    initiates the telephone call.

-   [Data on demand]{.underline}

    Because the telephone system provides the customer with the latest
    account information at the time of the phone call, the customer need
    only call at the time when the data is actually needed. In addition,
    the customer chooses the content of the information he or she wishes
    to receive by selectively navigating through the touch tone menu
    system.

-   [Context embedded in protocol]{.underline}

    The context of the information received by the customer is partly
    defined by the specific steps, or *protocol*, the customer uses in
    interacting with the phone system. For example, in response to the
    phone system's prompts, the customer may press "1" to receive
    checking account information and then press "2" to receive current
    balance or "3" to receive most recent check number that has been
    cashed. The actual context of the final numeric data received by the
    customer is defined by the series of steps taken to receive the
    data.

    Although the telephone banking system example helps to illustrate
    some of the characteristics of data sharing, there are additional
    characteristics which fall out of the scope of the example above:

-   [Single Data Instance]{.underline}

    In most data sharing systems, only one instance, or copy, of the
    data is maintained. Other interested parties may access the
    information as needs require, but only one copy is considered to be
    the updated, legitimate repository of the data.

-   [Read and Update]{.underline}

    Data sharing often encompasses more than just a retrieval of
    information. Facilities often exist which permit updating of the
    single data repository by multiple parties. In this perspective,
    data sharing is a "two-way" street which allows both information
    access as well as information updating.

**1.4 Data Sharing and ISO 10303**

The successful development of a data sharing implementation requires
that many different aspects of information technology be considered.
Among those, controlled data access is a key element. Data access is the
interface mechanism whereby a computer program can read or update the
selected data in a data store. In the data sharing scenario, some
portion of the database is intended to support joint usage and
ownership. To successfully share data, the data access mechanism must
allow multiple application systems to read, store, and manipulate the
shared data.

Traditionally, data sharing systems are implemented as client-server
systems, or more recently as server-server (federated) systems.
Therefore, multiple cooperating applications may have one or more data
stores that are controlled by server functions. There may be data stored
in these distributed data stores that are designated to be shared among
many application systems. As in the banking analogy above, the
communication protocols and implementation technologies required for
data sharing implementations are more complicated than those of data
exchange, and multiple data stores add to the complexity.

The information context for the shared data is embedded in each
application's knowledge (the application logic), their physical schemas,
and the steps required to access/update the shared data in the
distributed data stores. Effective data sharing requires a mapping of
these different data stores where shared data reside under a single data
specification that is understood by the cooperating applications.

ISO 10303 supports data sharing implementations via the AIM, conformance
classes, and data instantiation rules and constraints that are specified
in the mapping table. Collectively, these serve as the single data
specification for the application systems that need to share data.

Because ISO 10303 is being developed as a communication standard, it is
not intended to serve as an efficient and complete data structure for
storage implementation. However, AIM can provide the necessary
navigation paths for data access. Therefore, two mappings are required
from the AIM. One mapping is to a user's conceptual view of the
information (context), represented abstractly in an ARM. The other
mapping is to the physical databases where the shared data are stored.

The design of a data sharing implementation must consider the system
architecture and computing environments (e.g., hardware, software, and
development tools) of all application systems that need to share data.
The system design must address the unique interactions between the
control structure and the component systems. The design strategy varies
depending on the component systems, the computing environment, and
performance considerations. These design strategies are not specified as
and probably should not be a formal standard part of ISO 10303. Section
3 introduces a generic capability as a design strategy for both data
exchange and data sharing implementations of STEP APs.

**1.5 "Open Data" and ISO 10303**

Much has been written concerning the goal of "Open Systems". In the
1980's the trend toward open systems produced some successes in the area
of operating systems with the introduction of POSIX standards. These
standards identified a common set of interfaces to which compliant
operating systems must subscribe.

It has been theorized that an "open data" environment would provide
significant advantages for users of information-intensive systems. The
vision of an open data environment is to standardize on a single
conceptual representation of information and associated interface
mechanisms within an application domain. Application developers would be
required to write application software to conform to the representation
and interfaces defined in the standard. The goal of this environment
would be to allow a customer to "plug and play" competing applications
from different vendors without expending significant resources to
migrate the underlying application data form one format to another.

While the feasibility of such an approach requires significantly more
study, it is clear that ambitious goals of an open data environment
require a standardized data specification for information within an
application domain. It is hoped that the methods and approach of ISO
10303, built upon the concepts of standardized data specifications,
could be leveraged to supply the necessary data requirements for an open
data environment.

**2 Implementation using single or multiple Application Protocols**

The data exchange or data sharing implementation may use a single AP or
multiple APs. If the data specification that controls the communication
is a single schema (model), then there is no difference between data
exchange and data sharing implementation system architectures and
architectural components. The single schema may be the AIM of a single
AP or a consolidated schema that is made up of the merged AIMs of
several different APs. Figure 3 depicts the relationship between the
communication-controlling schema and the system architectures. The
details of the system architecture used in the diagram is discussed in
section 3; which is not the focus of discussion for this section.

It follows from this that using a single AP or using multiple APs is not
dependent upon the implementation objectives or transaction forms,
(e.g., data exchange or data sharing) or the characteristic of the
implementation (e.g., on-line access or the exchange of a physical
file). Rather, it is dependent upon the scope and application context of
the data required in the

![](media/image3.emf){width="6.493055555555555in" height="3.65in"}

**Figure 3: Relationship between System Architecture and schema**

implementation. Therefore, issues associated with using multiple APs are
entirely different issues than those associated with data exchange or
data sharing implementation architectures. *This does not mean that one
can not design a system architecture that can accommodate both
functions.*

This section addresses the issues and strategies associated with
implementations using a single AP or using multiple APs.

**2.1 Implementation using a Single Application Protocol**

When the use of a single AP for data exchange or data sharing is called
for, ISO 10303 specifies the conformance criteria and conformance
testing method. The conformance criteria for the implementation of a
single AP includes the conformance class, the data specification (i.e.,
the AIM), interpretation and mapping between ARM and AIM, and the
abstract test suite. A conforming implementation using a single AP must
be able to provide data instances that can satisfy:

-   the subset of AIM EXPRESS schema structure,definitions, and rules
    (Clause 5.2 of the AP document) that belongs to an AP specified
    conformance class (Clause 6 of the AP document);

-   the instantiation constraints and rules specified in the ARM to AIM
    mapping table (Clause 5.1 of the AP document); and

-   the abstract test suites (the APs corresponding 300-series Part).

**2.2 Implementation using Multiple Application Protocols**

The data exchange or data sharing implementation of multiple APs does
not require a different implementation system architecture than that of
a single AP. What it does require are:

-   established guidelines on if and how AIM schemas from different APs
    can be merged; and

-   definition of the criteria for a conforming implementation.

**2.2.1 Merging AIM Schemas**

Each AIM defines the usage (i.e., interpretation) of IR constructs in a
specialized context. For example, the IRs define an entity called
shape_aspect as an aspect of a product's entire shape (which is a kind
of property of a product). Under the context of an AP which is intended
to communicate the description of shape features of mechanical parts for
machining, the IR generic definition of shape_aspect is interpreted to
be a machining feature that has specific parametric descriptions. For
example, a chamfer is defined by a transition between two edges of a
surface with a flat cross section. Associated with the chamfer
shape_aspect there shall be an angle and an offset length between two
edges of a surface where the angle applies to specified.

The same IR shape_aspect entity, under the context of a different
application protocol, may have a different specialized meaning. For
example, for electrotechnical system design shape_aspect is used to
define the termination of a device that can be connected to the
termination of another device. The parametric shape description is not
relevant under this context, but rather its spatial location is
important design information.

For example, an implementation of the AP to communicate shape aspects to
support mechanical fabrication applications may only choose to use the
single AP that defines shape aspects under the context of machining
features. An implementation that is interested in consolidating the
usage of shape aspect from both the perspectives of machining features
and connectivity of device terminations would require merging these two
independently designed APs as a "composite " or "consolidated" schema
for a data store structure. Both sets of rules/constraints that govern
the instantiation of the shape_aspect entity in the consolidated schema
are valid, but they are valid on different sets of the population.

In order to merge two or more AIM schemas into one consolidated schema,
which is an expansion of the scope and context of each single AP, these
are some of the technical issues:

-   Alignment of application context

The fact that the same entity appears in multiple APs does not mean that
they can be merged or that it is meaningful to automatically merge them
into a single model. The relationships must be established between the
usages of that entity in each of the two APs. The relationship between
the two usages may be established by explicitly defining an interface
between them, or by using a similar method as the AICs.

> [Explicit interface definitions]{.underline}
>
> During the development of an AP, a potential expansion of scope may be
> explicitly identified for the purpose of leveraging other existing APs
> or future APs. For example, an AP that is focused on a specific
> domain, such as electrotechnical plant design, does not include a
> mechanical perspective of shape geometry for the devices. The AP may
> define another product_definition_context that is an additional but
> related application context, e.g., mechanical design. This common
> product_definition_context, enables the merging of the AIM schema with
> another AIM schema which contains mechanical design context and shape
> geometry information.
>
> This additional and explicit addition of an intended "interface"
> definition allows two or more APs to be merged at the product
> definition entity.
>
> There are only a few entities in the IR, based on the IRs data
> architecture, that make sense to be identified as potential interface
> definitions to allow two or more APs to be merged into a consolidated
> single schema. These candidate entities are: product_definition,
> shape_aspect, property_definition, and representation (this list is
> not intended to be complete).
>
> [Use of AIC strategy for merging multiple AIM schemas]{.underline}
>
> Two or more APs may have overlapping contexts and information
> requirements. The overlap may be addressed by an AIC. The AIC is used
> as a common definitional module for both APs; the AIMs include the
> same AIC schema. For example, Part 202 has a draughting application
> context and Part 204 has the mechanical design shape context which
> share the same usage of the IR definitions of presentation of visual
> styles of geometric objects.
>
> Each AIC schema is defined with a "root" entity which specifies the
> specific IR usage rules/ constraints within the context of the AIC
> scope. For example, Part 501 is an AIC for wireframe shape
> representation that are bounded by a set of connected edge sets. This
> AIC is defined with a root entity
> "edge_based_wireframe_shape_representation". This entity is declared
> as a subtype of IR resource entity shape_representation. Included in
> the entity definition, are a number of local rules that specify how
> the geometric entities are used within the context of this type of
> wireframe representation. Part 510 is an AIC for wireframe shape
> representations that are bounded geometrically. It has a root entity
> "geometrically_bounded_wireframe_shape_representation". Included in
> its definition is a set of different local rules which constrain the
> usage of some of the same geometric entities for their specific use in
> providing wireframe representations that are explicitly bounded by
> geometry.
>
> An AIM schema, such as AP 203, that incised both geometrically bounded
> wireframe representations and brep, can include both AIC 501 and 510.
> The using AIM schema will define the geometric entities once. The root
> entities for each AIC localize the constraints on the same entities,
> that may be in conflict with one. The AIC root entities are designed
> to specify the individual constraints on how the generic geometric
> entities are used and localize them within their own contexts.
>
> If an implementation intends to merge two or more AIM schemas, one
> approach may be to create a new schema which includes two or more AIM
> schemas in the same way an AIM schema includes AIC schemas. Using this
> method, one or more "root" entities should be defined for each of the
> AIM schema to convert the single AIMs global rules into local rules of
> the AIMs new root entities. This method manages the use of specific
> rules that each AIM may have, into a "global" context of the merged
> multiple AIM schema.
>
> The advantage of using this method is that it enables the use of
> multiple APs for a single implementation that contains sufficient
> information for an expanded implementation application context while
> maintaining the specific constraints and identity of each individual
> AP to accommodate conforming data.

-   Syntactic Issues

In addition to the contextual/semantic issues of merging AIM schemas,
there are a number of syntactic issues.

> [EXPRESS language]{.underline}
>
> In order to merge AIM schema, a few EXPRESS language issues may exist.
> For example, in a merged schema, each AIM schema name that is used as
> part of a EXPRESS fully qualified name (e.g., in domain rules) must be
> replaced by the merged schema name.
>
> [Part 21]{.underline}
>
> Within a Part 21 file, each instance has a unique instance identifier.
> Part 21 uses this instance identifier to reference in the instance.
> This design principle assumes that each instance is unique. The design
> does not offer the proper mechanism for references of common instance
> across files. If two files contain the same instance identifiers, one
> must be changed to avoid mis-referencing. If two AIM schemas are
> merged into a new schema, physical files that are based on each of the
> single AIM schemas, can not be merged effectively. Because common
> instances are not identifiable, the data referential integrity can not
> be maintained.

**2.2.2 Criteria for Conforming Implementations**

Two alternatives exist within the STEP architecture for addressing
implementations using multiple AIM schemas. One option is to provide
only guidelines on how it can be done. This alternative leaves open the
choices of the AIM schemas that are to be merged to each implementation;
each individual implementation makes decisions based on its specific
implementation objective. Using this alternative, there will be no
specific conformance criteria established for the merged schema. A
conforming data communication in the implementation using a consolidated
schema of multiple AIMs (regardless of whether it is data exchange or
data sharing) can only be based on the identified conformance criteria
for each individual AP.

The other alternative is to standardize the conformance criteria for
implementations of merged AIM schemas. The conformance classes defined
for each individual AP may require significant modification in order to
be useful for the merged AIM schemas. Consideration must be given to the
purpose of using multiple APs. The application context for
implementation does not necessarily demand the standardization of
another application protocol. Especially, if the application contexts
for implementations vary and are more ad hoc in nature. If STEP were to
define what it means to have a conforming implementation of multiple
APs, methods for the development of conformance classes and new abstract
test suites must be established.

All of the currently available STEP standards: EXPRESS language, Part 21
file format, conformance criteria, and conformance testing
specifications are designed to support the single AP implementation. If
STEP were to provide conformance criteria for implementations of
multiple APs, issues associated with EXPRESS language, Part 21, SDAI,
conformance classes, and conformance testing must also be addressed.

**3 System Architecture**

Based on the current design of the STEP architecture and method, the
implementation of STEP APs for both data exchange and data sharing
objectives, requires a generic system function. This generic system
function is a data management function as depicted in Figure 4. The data
management function is only one system component. The application logic
consists of all the application system algorithms and the user interface
functions. The focus of this discussion is only to define the generic
data management function and how it is used for various implementation
objectives.

The four key components for the generic data management function are:

\(1\) A [conceptual schema processor]{.underline} that provides the
capability to store, parse, and understand the conceptual schema.

\(2\) A [schema mapper]{.underline} which maps the conceptual schema
definitions and structure to a different schema (the physical schema)
that is locally used for the storage of data that supports the
application logic

\(3\) A [physical schema processor]{.underline} that provides the
capability to store, parse, and understand the physical schema that
describes the locally managed data.

\(4\) A [data access function]{.underline} which reads and writes to the
database or data, based on the physical schema.

![](media/image4.emf){width="4.392361111111111in"
height="1.5569444444444445in"}

Figure 4: Generic System Function

When a request to access data is received by the generic data management
function, the requester issues the request using the conceptual schema
definitions. This conceptual schema definition is received by the
conceptual schema processor to verify that the definition is valid. The
validated request is passed to the schema mapper to map to the physical
schema. The schema mapper then passes the request using the physical
schema definition to the physical schema processor. The physical schema
processor validates the request against the physical schema definition.
Once validated, the physical schema processor issues the request to the
data access processor. The data access processor is responsible for the
retrieval, update, parsing, generation, and/or storage of the physical
data.

Depending on the implementation objectives, this generic system function
can be invoked to serve a specific purpose. The data management function
may be used to manage data locally for an application system or to
communicate data in an interface function with another application
system. Different compositions of the generic data management functions
can be used to serve different implementation objectives; each one
serves a specific purpose. Whenever two or more generic data management
functions are used by a single application system, an additional schema
mapper is required to interface the conceptual schema processors. This
schema mapper maps from one conceptual schema to another.

**3.1 A System Architecture for Data Exchange Implementation Objective**

Figure 5 describes a system architecture for the implementation
objectives of data exchange between two application systems A and B. The
shaded areas represent uses of the generic data management functions.
The exchanged data is in Part 21 file format. The conceptual schema for
the data exchange is an AIM_X.

![](media/image5.emf){width="6.492361111111111in"
height="2.301388888888889in"}

Figure 5: System Architecture for Data Exchange Implementation

In this figure, the system architecture illustrates that two of the
generic data management functions are invoked by each of the application
systems A and B. One of them is labeled "data management function" which
manages the locally used data for the native application system. For
system A, the data access processor is a file manager while for system
B, it is a database manager. This indicates that system A stores its
data as data files. The data access processor for system A is a file
manager that manages the use of data from these data files. System B, on
the other hand stores its data in a DBMS managed database, and thus uses
a database manager to access the data.

The second generic data management function used in application system A
and B serves the data exchange function. For system A, this data
management function is a pre- processor translator function. This
function includes the AIM_X schema processor, which translates the local
application data into the AIM_X definitions. The schema mapper in the
pre-processor function maps the data into the part 21 file format. The
Part 21 formatter generates the data into a physical file for the
exchange. For system B, the second data management function is a
post-processor translator. The data access processor in this
post-processor is a Part 21 file parser that reads and parses the
exchange file data into a physical schema structure. The schema mapper
maps the physical data into the AIM_X schema definition. The AIM_X
schema processor than translates the data into the application system B
data schema definition.

**3.2 A System Architecture for Data Sharing Implementation Objective**

Figure 6 depicts a system architecture that satisfies a complex data
sharing implementation objective. Involved in this implementation are
four application systems: A, B, C, and D.

![](media/image6.emf){width="6.49375in" height="3.876388888888889in"}

Figure 6: System Architecture for Data Sharing Implementation Objectives

[Application system A]{.underline} is composed of three generic data
management functions. The bottom one in the diagram manages the data as
shared resources among application systems A, B, and C. The middle one
manages the proprietary database for the native application system A
locally. This indicates that application system A uses data from both
the shared data and the proprietary data. Both the shared data and the
proprietary data are stored in their physical schema (efficient
structure made to suit the specific storage and data access technology
used by the application system). These physical schema map to the
application A schema definition in order to support the data usage of
system A's application logic.

The third (at the top in the diagram) data management function is the
server function. The server function interfaces with all of its clients,
including other servers that are allowed to share the data from the
shared database. Within the server function is the AIM_X schema
processor, which enables multiple application systems to share data in
terms of the AIM_X schema as the definition for their communication
protocol.

This system architecture indicates that by using the proper data
management functions (such as the various schema processors and schema
mappers), the database storage structure−even for the shared data−does
not need to be and probably never should be the same schema definition
that is used for the data sharing communication objective; i.e., the
AIM_X schema.

Many of the enterprise data integration efforts, must deal with legacy
systems and legacy data. To install data sharing capability into an
environment of legacy systems, the system architecture illustrated in
Figure 6 provides a viable solution.

While data is shared among multiple systems using a data management
function that can (1) process the communication standard schema
definition, such as a STEP AIM schema; and (2) access the physical data
via the function provided by the schema mappers, the physical legacy
databases can remain intact to serve the legacy systems.

[Application system B]{.underline} is another server in this system
architecture. It invokes two distinct data management functions. One of
them manages the locally stored data that are to be shared in the entire
system environment through system B's server function; it is connected
to the server function of system A. Application system B does not manage
any data that is not shareable. All of the data managed locally by
system B are made available to all clients of system A, through the
server-to-server communication link.

[Application system C]{.underline} is a data browser. It has a client
function which, through the client-to-server communication link with
system A, accesses all shared data managed locally by system A and
system B. It also invokes another distinct data management function. The
client function requests data using the AIM_X definitions and context.
Locally, it converts the data into a context for user browsing purposes.
System C also shares data with system D. The second data management
function manages a Part 21 formatted file in working form. This data
management function can translate data between Part 21 file format and
the user browser application schema. This data management function also
shares the Part 21 data file with application system D.

[Application system D]{.underline} has a single data management function
because its application logic is designed to operate on AIM_X schema. It
co-owns the Part 21 file working form with system C.

The purpose of describing this complex system architecture is to make
the point that data sharing implementation objective can be satisfied by
various implementation system architectures. The one that is presented
here is a combination of client/server system architecture and federated
system architecture, which accommodates multiple servers. The shared
data is physically distributed between the two systems A and B, that
have server functions as an element of their data management functions.

Also illustrated is the data sharing implementation between application
systems C and D which shares data from a Part 21 file. This illustrates
a significant consideration that Part 21 file, although is recognized
traditionally as a data exchange implementation form, can also serve as
the data store for data sharing implementation objectives. Conversely, a
database implementation does not necessary mean it is a data sharing
implementation.

**4 IGES implementation vs. STEP implementation**

Almost all of the known STEP AP implementations are based on the IGES
implementation experience and approaches. Most of the issues raised by
the implementors reflect the assumption that STEP AP implementation is
like IGES implementation; focused on CAD system data translation and the
standard is a generic definition, open to user/vendor's interpretation.

IGES was developed during the era of industrial automation when
technology and applications were developed as point-solutions to
specific industrial problems and within narrowly defined domains. In
addition, Information Technology (IT) standards and the role/impact that
they have on application systems were not well understood - they were
not like other industrial standards in many respects. As a result of
this historical context, IGES was developed with a focus on an
important, valuable, and high-profile application domain: computer-aided
design (CAD) and the representation and exchange of geometric/graphical
data.

Although aspects are similar to the paradigm represented by IGES, the
implementation of STEP APs differs from the implementation of IGES in a
number of significant ways. Among these are:

-   Focus on effective communication of product information rather than
    CAD data format translation;

```{=html}
<!-- -->
```
-   Application context associated data;

```{=html}
<!-- -->
```
-   Explicit inclusion of information requirements as an element of the
    standard; and

```{=html}
<!-- -->
```
-   Specification of conformance classes for evaluation of
    implementations of the standard.

The design principles of ISO 10303 architecture and methodology is to
provide a standard that can be used for effective communication. To
achieve the goal of effective communication, the data specification
focuses on associating context to data. These tightly associated context
to data within the scope increases the so called "baggage" or "overhead"
to the specification.

For example, an engineering bill-of-material is different from the
specification of a manufacturing bill-of-material. STEP allows for the
differences, but relate them to the same product design
(product_definition_formation), but differentiate them by specifying the
context of the bill-of-material to be different life-cycle stages.

This design principle of the standard increases the size and structure
of the data definition as well as the exchanged data. The comparison and
relationship between IGES and STEP implementations need to understand
these fundamental principles. To compare IGES implementation and STEP
implementation using file size as a measuring criteria is missing the
entire design principle of STEP.

The following sections discuss these differences.

**4.1** **CAD system data format translation vs. product data semantic
translation**

IGES employs a very simple paradigm for conveying data from one system
to another: the translation of data from a native format into a neutral
(i.e., system independent) format that is subsequently read and
translated into the native format of a receiving system. The combination
of the data exchange paradigm, the historical context, and the
communication objective (i.e., geometric/graphical CAD data) result in a
standard that can be characterized as a CAD system

data format translation standard.

While useful within it\'s own limits, IGES is not well-suited to
technology and application evolution with respect to semantics and
application interoperability. The broader problem - of which IGES is a
specialized example - is effective communication of product data. IT
technology and applications moved and broadened in this direction -
applications became \"smarter\", technology became better
interconnected. The semantics conveyed by an IGES file was limited to/by
a vocabulary of about 80 entities, which were mostly geometric/graphical
in nature. The data exchange paradigm did not lend itself to
interoperability or data sharing.

An objective of the development of ISO 10303 was the separation of the
design (and associated issues) of implementation, e.g., the exchange
file data format, from the specification of the semantics of the data.
Instead of data format translation as a principle focus of the standard,
like IGES does, ISO 10303 focused on the semantics of the information to
be conveyed. The objective of ISO 10303 is the effective communication
of product data, i.e., the successful conveyance of meaning between two
agents. Unlike IGES, both the representation of the information and the
format of the data are elements of the standard that supports the
implementation of the standard, but not part of the data standard.

The result of these differences is that where an implementation of IGES
will focus on data translation and mapping to a native system format, an
implementation of ISO 10303 must focus on the interpretation and
understanding of the data before it is mapped to native data structures.
The implementation of ISO 10303 will rely heavily on the information
presented in the mapping table within an AP (Clause 5.1), for the
interpretation and understanding of the data. A much more complex
implementation process than the translation approach of IGES because
ISO 10303 is intended to addresses a much broader problem.

**4.2** **Data Scope**

As alluded to above, the data scope of ISO 10303 is much broader than
that of IGES. While it can be said that \"a picture is worth a thousand
words\", the overt data scope suggested by the 80 entity vocabulary of
the IGES is geometric/graphical information.

In the past ten years, the descriptive names applied to industrial
automation systems have changed from CAD/CAM to PIM - Product
Information Management; this evolution reflects the changing focus and
broader scope of IT technology and applications. The data scope of ISO
10303 reflects and embraces this trend; it is a *product data* exchange
standard. The geometric representation of a product\'s shape and the
graphical presentation of the geometric representation are just two
parts of a much broader data architecture represented by the Integrated
Resources (and part of every AIM). Applying context to all in-scope
data, each STEP application protocol demands a broader data scope than
that of traditional CAD systems.

The benefit of STEP cannot be realized if STEP implementations focuses
only on CAD system data format translation. In fact, if the
implementation objective is limited to exchange geometric and graphical
data from one CAD system to another. IGES is probably a better solution.

The effects of the data scope on the implementation of ISO 10303 is that
the software that processes ISO 10303 data will have two characteristics
not found in IGES implementations:

> 1\) It will have to *interpret* the data based on the context (or,
> more specifically, the mapping table) of an AP; because the same IR
> data structures used in different APs may have different
> interpretations. The software must \"know\" what AIM is being used to
> interpret the data and, thus, determine the appropriate mapping to
> native structures. Unlike IGES, the same structures won\'t always
> be/mean the same thing.
>
> 2\) It will have interfaces to or provide information to many
> different kinds of industrial automation systems within an enterprise.
> IGES translators typically have a single destination or \"target\"
> system into which the data is translated - a point-to-point
> perspective on the communication. Because of its data scope, ISO 10303
> processors will likely provide information to more than one
> application system. This characteristic demands the consideration of
> storing data in different repositories that can communicate or
> interface to one another or in a single repository that can facilitate
> the sharing of data by multiple applications.

**4.3.** **Requirements Mapping**

IGES addressed requirements, design, and solution all in one stroke.
Information communication and data exchange requirements were assumed
based on the extant CAD technology of the day. The result was a standard
that was driven by CAD technology and vendor requirements, where \"what
it is supposed to do\" is embedded in \"how it does it.\"

ISO 10303 emphasizes on being a user-driven standard. The development
process for APs in ISO 10303 explicitly addresses the information
requirements defined by the domain and experts for the chosen
application domain. These requirements are documented in the standard as
the application objects (Clause 4.2 and 4.3) and they are met through
interpretation process to use the Integrated Resources. This
interpretation process is documented in the mapping table; which
specifies the relationship between the requirements and the data
structures which satisfies those requirements.

Besides defining the context of an AP, the AAM, ARM, and information
requirements establish the *purpose* of the STEP AP. The AIM provides
the standard data definitions and structure as the mechanism for the
exchange/communication of data. The mapping table binds the mechanism to
the purpose.

The implementation of ISO 10303 differs from the implementation of IGES
in that a communication act (e.g., data exchange) is tied to ***a
specific purpose and specific domain information requirements***. IGES
specifies a collection of entities that may be used and interpreted for
any and many purposes; these purposes and interpretations are embedded
in translator software and, more importantly, are not part of the
standard but are part of the translator programmers vision of how the
standard will be used. The requirements for information communication
and data exchange are unspecified in IGES beyond the basic
geometric/graphical entity set. Because they are based on the AIM,
implementations of ISO 10303 bound to a specific set of information
requirements and a purpose.

**4.4** **Conformance Classes**

A very significant difference between the implementation of IGES and
ISO 10303 concerns the testing and evaluation of implementations for
conformance to the standard. IGES does not address conformance
requirements as part of the standard; testing procedures for IGES
implementations are external to the IGES standard. The architecture of
ISO 10303 explicitly includes conformance testing requirements as part
of the standard and explicitly specifies what it means to \"conform\" to
the standard. External testing procedures (e.g., IGES) do not carry the
force or impact that integral conformance testing approaches do (e.g.,
ISO 10303).

An IGES implementation may read or write some or all of the data in the
standard. There is no requirement, however, that an IGES implementation
support all or any predefined subset of the standard. IGES Testing
procedures test whether the implementation reads/writes the data
correctly, but do not address the completeness of the data.

ISO 10303 specifies a number of levels of conformance for each AP. A
conformance class specifies functional characteristics for a usage of
the AP, functional characteristics that must be met by an implementation
of the AP. These functional characteristics may be based on
differentiation between different kinds of geometric representations,
different kinds of product information, or different levels of detail of
the data contained in data file. In order to conform to ISO 10303, an
implementation must conform to at least one conformance class in an AP;
\"conformance\" means that the implementation can successfully and
correctly produce and read all of the information specified in the
conformance class.

unambiguous communication vs. open to interpretation