1. INTRODUCTION

2. PROBLEMS FACED BY STEP

3. INTRODUCTION TO WORKING GROUP 10

4. DATA INTEGRATION

4.1 Principles for AP Framework Facilitating Data Reusability and Data Integration

4.1.1 Principles for AICs

4.1.2 Principles for AIRs, and GIRs

4.1.3 Integrated Industry Data Model 

4.2 Purpose of a Core Model

4.2.1 Application Requirement

4.2.2 Common Interpretation

4.2.3 Core Data

4.2.4 An AEC Ship Building Core Model

4.3 Other AP Framework approaches

4.4 Integration of Industrial Data for Exchange, Access, and Sharing Standard

4.4.1 Application Architecture 

4.4.1.1 Types of Layers

4.4.1.2 Types of Database

4.4.2 Examples of Use

5. STEP (ISO 10303) ARCHITECTURE

5.1 Usage of the integrated data model

5.1.1 Functional Context: Activity Models

5.1.2 Subject area Models

5.1.3 Integrated Industry Data Models

5.1.4 Integration rules

5.1.5 Communication constraints

5.1.6 Exchange Protocols

5.2 MAPPING

5.2.1 Role of Mapping in AP Interoperability

6. APPLICATION PROTOCOL INTEROPERABILITY

6.1 AP Interoperability in a file exchange environment

6.2 AP Modularization

6.3 AP and AM development process

7. CONCLUSION

8. REFERENCES

Figure 1: Common Interpretation

Figure 2: Core data

Figure 3: Common Framework

Figure 4: Axiomatic/Heuristic Approaches

Figure 5: combined approach

Figure 6: As-Is methodology

Figure 7:proposed approach

Figure 8:Outline Architecture to Support IIDEAS

Figure 9: Data and Application Architecture

Figure 10: High Level Architecture

Figure 11: Architectural overview

Figure 12: ANSI/SPARC Framework

Figure 13: STEP Adaptation of ANSI SPARC framework

Figure 14: Evolution of STEP framework

ABSTRACT

At their first meeting in Sydney, WG 10 discussed various issues that needed attention. Some of issues that dominated the discussions are listed below:

• AP interoperability,
• Requirements for STEP, P-Lib, MANDATE,
• STEP, P-LIB, MANDATE Architectures,
• ISO 10303 Architecture & Methodology Reference Manual,
• EXPRESS Edition 2,
• Applications Architecture,
• Requirements for Data Integration,
• Relationships to other data standards,
• Relationships to other language standards, and
• Parametrics^a.

This paper is subdivided into three parts, namely

• STEP architecture,
• Data sharing/Integration, and
• AP interoperability.

1. Architectural problems: These involve difficulties encountered in interpretation. Interpretation process has become cumbersome because of the big gap between the ARM and the AIM. The gaps between the AIM and the ARM are detailed below. The constraints on the application objects have often not been documented in the APs. Constraints are used in APs to instantiate the generic data models found in the Integrated Resources. For example, pipes are used when building a ship and when designing an HVAC system in a building or connection in a refinery. However, AP 217 (Ship piping) and AP 228 (Building services-HVAC) will most probably have different representations for "pipe." Although a pipe can be used in two different application contexts, a pipe is a pipe no matter where it is installed. If a "pipe" module existed, the two APs could each reference it instead of having to invent their own "pipe" representation ^b. At present, there is no mechanism present in the architecture which will enforce the kind of data model/representation sharing shown in the example. The interpretation process is not repeatable because too many concepts are mapped into the same construct in various APs. There are several areas that cause this problem. The first area is that much of the interpretation needed for ARM is costly and not needed. Further the AIMs are not user friendly. A second area that has problems is mapping. The mapping constructs described in the AIM do not map well to the constructs in the integrated resources (IR). At present, there are no computer sensible mapping tables. Thus, mapping has to be done manually, thus making the creation of Application Protocols a laborious process due to the level of detail involved. Further STEP does not have a two way mapping process between the ARM and the AIM^c.
2. STEP resources: There is no clear demarcation between business rules and definitional aspects. This is due to the lack of tractability of data (lack of meta data) to its context. EXPESS lacks formality in the sense that it places too many constraints on models and has a lot of non-implementable resources. The Integrated Resources are insufficiently general, in many areas, to allow application- specific domain models. The problems associated with this issue are an offshoot of the architectural problems discussed before^c.
3. AP interoperability: The constraints on application objects are numerous. This inhibits proper data sharing. There is a big gap between the ARM (that captures requirements) and the AIM (that is the final model that is to be implemented). There are too many unlike concepts that are mapped onto the same constructs in various APs. Lack of AP interoperability arises due to the lack of coordination between the AP builders^c.
4. Lack of integration with other standards: There is no integration of other standards with STEP to generate a file that covers both. Data constructs available in PLIB and MANDATE are not used in AP development. In general, there is a closed mentality between the various AP developers. This prevents STEP from sharing the data models developed by the various AP’s, which would be a vital step in addressing the problems of AP interoperability^c.
5. Organizational Issues: There is organizational structure that supports planning, personnel training, and documentation. It is indeed ironical that there is no proper documentation when STEP is supposed to be a documentation tool^c.

The functions of the Working Group 10 are enumerated below:

• It is to provide technical leadership across the standards that are developed under the aegis of TC184/SC4.
• It is to address the complications that arise out of the ISO 10303 architecture and implementation methodology.
• It has harmonize the architecture with progress made in the field of data sharing/Integration.
• It has to implement the necessary changes, when necessary, to enhance the architecture.
• It has to assess the possibility of integrating other standards (such as P-LIB, MANDATE, and EPISTLE, XML, and SGML) and STEP.

• Modeling at different levels of abstraction,
• Identification of interfaces.
• Managing change to model,
• Modeling of constraints, and
• Use of multiple modeling languages.

What is data reusability?

According to Yoshiaki Ishikawa^g data reusability can be explained as follows: "The creator of specific data, can define and/or instantiate the data contents, using terminology of his business function, discipline, or industrial sector specific terms, and can transfer the data to and /or can share with its user. The user of the specific data, can utilize the instantiated contents of the transferred/shared data for performing his activities, can define and/or add his own data as a creator, and can feedback comments and/or exchange requests to the original creator".

Data Reusability Requirements

The primary objective of STEP is to facilitate "exchange" and "integration" of data between dissimilar application systems through a neutral file format. For this to be feasible, the following are required:

• Equal Partnership Principle: An industrial firm can acquire product data according to its own industrial standard from other industrial firms and vice versa.
• Life Cycle Principle: Product data must be shared between application systems that are used during the various life cycle stages of the product.
• Discipline Instantiation Principle: Product data must be shared between dissimilar disciplines.
• AP interoperability: This is an important integration requirement to support data reusability requirements. AP interoperability can be defined as data, common for multiple APs, that are defined and instantiated as a single and unique data element in a shared database or file. The topic of AP interoperability will be discussed in a separate section in this paper.

The ISO 10303 standard has the following objectives:

1. to support the integration and storage of any industrial data from any source, and access to that data,
2. to provide a mechanism for the standardization of data models that are found useful to industry,
3. to develop standardized data models that are conceptual in nature to support the data requirements of a number of explicit data models to standardize a formal two way mapping between data models, to support either:

• the migration of data from one model to another, or
• the ability to be able to view the data in one data model from another to standardize ontologies for use within this standard, and other standards, e.g., STEP is to support the definition of common semantics.

1. to determine a satisfactory basis for identification that two pieces of data are about the same object,
2. to define an implementation form for a data store which supports a multi-user, multi-application Application Protocol that takes account of access control requirements, and a batch interface that can be used for the transfer of data from (at least) one conformant data store to another3.

Class: This specifies the "covering range" of the APs. Covering range in STEP context specifies the complete life cycle of the product.

Layer: This classifies the target industry under the specified class.

Group: This specifies the commonality of scope under the specified layer.
 
Class is subdivided into four categories, namely³

• Class-1: APs classified in this category have common business functions.
• Class-2: APs classified in this category have P-LIB and MLIB Access.
• Class-3: APs classified under this category have unique business functions.
• Class-4: APs classified in this category provide product life cycles that covers multiple business function.

Under Class-1:

• Layer-1: Product data library and documentation APs.

•      Layer-2: PLIB and MLIB APs.

• Layer-3: Business Function/ Discipline APs.
• Layer-4: Product/ Industry Specific APs.

• Layer-5: Product life cycle APs for Component Products.
• Layer-6: Product Life cycle APs for Assembly Products.
• Layer-7: Product life cycle APs for Operators.

4.1.3 Integrated Industry Data Model

Through its deliberations, the working group had come to the following consensus³:

• There is a need for integrated industry data models.
• There are many integrated industry data models per industry.
• An integrated industry data model can be used as a basis for data warehousing
• Data integration does not have to result in replacing the STEP generic product data model (GPDM) with a totally different architecture. Instead, the other standards within the SC4 can migrate towards the present architecture if it is modified appropriately. The modification process is currently under process.

• Enhancement of integrated resources through migration of subtypes from AIMs.
• Creation of AIMs to eliminate contradictory constraints.
• Use of "core models".

4.2 Purpose of a Core Model

At the ISO TC 184/SC4 meeting in Berlin in 1993, the building construction group within the WG3/T12 AEC ship building team commenced an application protocol planning project (APPP) with the objective of defining a framework for the development of application protocols suited to their needs and to determine the priority areas for the initial AP development^h. The APPP identified the need for a core capability, which would enable sharing of common data between the various disciplines operating in building construction. At the Greenville meeting in 1994, new work item proposals were made for a Building Construction Core Model (BCCM)^h. Development of the BCCM model was authorized in the Sydney meeting in 1995^h. The first paper of the AEC core model was presented in Dallas in January 1996^h.

4.2.1 Application Requirement

Application requirements identified within STEP normally fall within a specified scope or context. Because of the presence of this contextual nature in AP development, there is no formal mechanism that enables the exchange of information between the application protocols. The only way in which this can be done is by developing an AP whose context and scope overlaps domains.

4.2.2 Common Interpretation

The commonalties that exist between different APs are captured by the Application Interpreted Constructs (AICs) shown in the figure below. AICs deliver a single representation of a construct that is common to more than one AP. It does not facilitate exchange of information between those APs due to the absence of meta data. As the commonalties increase, so would the number of AICs. This would result in inefficient management of resources. Presently, AIC development tends to be undertaken after development of an ARM and occurs as a result of shared requirements being perceived. The AIC, as its name suggests, is an interpretation. That is, it is used as a part of an AIM. There is no requirement for any common model construction within the ARMs⁷ . 

4.2.3 Core Data

The building construction group proposed the concept of core data at the Davos meeting held during May ’93. At this meeting, the group identified that there are a number of disciplines that have their own application requirements. In addition, it was also realized that apart from the unique requirements, there is a set of information that needs to be exchanged between the disciplines as shown in Figure 2. This set of information is less deep for any given application than would be the case for an AP but it describes a means of exchanging data between application requirements. This set of information is referred to as core data. This is the concept on which the Building Construction Core model has developed. 
 

4.2.4 An AEC Ship Building Core Model

The AEC Core Model has been proposed as a framework for the development of APs using a Generic Entity Framework. The AEC model is a more generic form of the BCCM. 

4.2.5 Core Model Concepts The purpose of a core model is to provide a consistent basis for the development of data modelsⁱ. The purpose of a common data specification is to identify the information, which is common between the various APs that serve a particular industry. Thus, this common data is intended to inform one discipline of the proposals of another discipline in a form that is comprehensible. The important aspect of common data is that it should exchange only relevant information. This is an important difference between the underlying concepts that go into the development of STEP and other standards such as IGES and DXF in which the information transferred is far more than what is required.

The AEC core model provides three ideas for core models, namely 1. Interpretation of common requirement. 2. Specification of common data. 3. Development of a common framework.

These ideas are discussed in the following paragraphs.

Two methods of developing information models have been identified, namely top down and bottom up. These are also referred to as axiomatic and heuristic. The questions that arise with regard to these two methods are as follows:

• Are the methods exclusive?
• To what extent are the two methods exclusive?

Common requirements are determined in a similar manner to AICs. However, they are not AICs in a core model sense since this would imply they are common ARM developments. At present, there is no mechanism in the STEP architecture that provides for ARM harmonization. One of the theories that is proposed for harmonization is that an Application Resource Construct (ARC) equivalent to an AIC might be appropriate and it is on this basis that common requirements are further considered⁷. The ARC would be at the ARM level instead of the AIM level. Hence, the ARC would be an information model that connects the scope of different APs unlike the AIM, which is a common construct for the commonalties of different APs. 

Oehlmann^j refers to data sharing and conformance concepts as stated below: -

"The benefit of data sharing is the ability to maintain a single, consistent context during the product life cycle. Consequently, especially configuration management concepts and associations between different model domains (e.g. different systems) can be handled more effectively. The STEP methodology targeted towards data exchange and the interaction between homogeneous model domains (the AP concept) seems at least not "ideal" in this respect. Further, STEP enforces the identification of conformance classes within the standard, assuming that such classes can be identified beforehand, that their number is limited, and that the borders of such classes do not cut between entity references".

Thus, while core models based on common requirements use a bottom up approach, core models based on common data and common framework follow a top down approach. While a common framework sets the basis for consistent modeling, common data enables exchange of information between APs and common requirements provide the capability for reuse of model constructs. The combination of the three capabilities can result in a powerful core model that may satisfy the industry requirements⁷. The combined approach is shown below.

Note: No material could be found on how the combined approach functions.

4.3 Other AP Framework approaches

Another plausible approach that was investigated by WG10 is detailed below^k. The approach focuses on:

• Capturing and analyzing requirements for data exchange and sharing.
• Integrating industry data models to achieve "top-down" consistency across APs within an industry sector.
• Identifying constraints on data that are relevant to data exchange protocols.
• The figure shown below illustrates the STEP development method. A key aspect of this method is the fact two data models are defined: the ARM and the AIM. The procedures and practices used within SC4 support the "division of labor", with domain experts (within the AP team) being responsible for the development of the ARM, and a second group (comprising AP and Interpretation team members being responsible for development of the AIM^k. The purpose of this approach is to allow:
• Domain experts to focus on the requirements of their applications(s), describing these requirements in the terminology of their domain.
• STEP experts assist in the development of the AIM, through interpretation of the STEP Integrated Resources and reuse of AICs, and to produce a model that fulfils the requirements formalized in the ARM. The interpretation process ensures that the resulting AIM is consistent with that of other application protocols.
• Setting aside the redundancy of effort associated with modeling the domain of interest twice, one of the observed problems of this approach is that development of ARMs are subject to few if any data modeling standards, resulting in models that are of generally poor quality. This means that the AIM development phase embodies significant elements of analysis of the domain requirements^e.

The framework shown below exhibits a closer proximity between the AIM and the Application Activity Model (AAM), thus the context specificity of AIM for data exchange is increased, and the exchange specific elements of AIM will be clearly identified and the relationship between multiple AIMs and between AIMs and models intended for data integration can be understood.

The incorporation of the integrated data model as shown in the Figure 7 reduces the importance of ARMs. Hence independent data model development is greatly reduced. This results in a reduction of the costs associated with AP development. This does not mean that the ARM is functionally ineffective. The ARM will be used for collecting and analyzing data requirements only.

At present, there is no single architecture and methodology for the SC4 standards that fully supports life cycle integration as demanded by industryⁱ. Integration of the different standards developed by the working groups is considered as another solution to achieving data integrity. At present, the standards are very different in function; for example, STEP had been primarily created for data access, while PLIB was primarily designed for exchange of part libraries. 

4.4 Integration of Industrial Data for Exchange, Access, and Sharing Standard

One of the foundations on which the framework that facilitates data sharing is built on is the Integration of Industrial Data for Exchange, Access and Sharing Standard (IIDEAS) according to which, industrial data includes the following⁶:

• Product data,
• Management data,
• Process data,
• Activity data,
• Parts data.
• Financial data.
• Sales and Marketing data, and
• Summary data.

1. Support integration and storage of industrial data, and access to that data.
2. Provide a mechanism for standardization of data models that are found useful to the industry.
3. Develop standardized data models that are conceptual in nature to support the data requirements of a number of explicit data models to standardize a formal two way mapping between data models, to support either the migration of data from one model to another, or the ability to distinguish identical data present in data models of different APs.
4. Determine a satisfactory basis for determining/defining that two pieces of data are about the same object

Define an implementation form for a data store which supports a multi-user, multi- application AP that takes into account access control requirements, and a batch interface that can be used for the transfer of data from at least one conformant data store to another.

The figure shown below shows the IIDEAS framework. The area of interest with regard to AP interoperability is the Data and Applications Architecture. The other areas are outside the scope of the working of WG 10.

Three types of applications are recognized in the figure shown above:

1. Legacy applications. These are applications that have their own internal data structures developed to satisfy the requirements of the application without regard for data sharing. A legacy application can be fitted with a wrapper layer that redirects calls to its database⁶.
2. Object based applications. These are applications that have been designed to be able to share data, and perhaps behavior between applications within a domain through a domain model, e.g. design, maintenance. However, the same object might be viewed from more than one domain model, with different behavior or attributes⁶.
3. Generic applications. These are applications that are designed to work directly off a generic data model. Experience has shown that applications designed to work off a generic data model directly have better performance characteristics than traditional legacy or object based applications working off integrated data through a view or mapping. However, generic applications require a very different approach to application development⁶.
4. 4.4.1.1 Types of Layers

There are four layers each of which will have an AP and offer services. These are:

5. Business Object Layer. This layer presents to the user or user application the view of the world they wish to see, however specific or generic that may be⁶.
6. Data Integration Layer. This layer contains a data model designed to be able to integrate data from different sources, and services to integrate data from different sources. In principle, there is more than one data model that could be used as the data integration model. However, data will only be truly integrated if it is contained in a single data model⁶.
7. Data Storage Layer. This layer provides a physical storage model. Experimental work by WG 10 has shown that it is possible to develop storage models that are independent of the data model that the data is being stored against. This means that data and data models can be added to the constructs without having to change the implemented data structures⁶.
8. Meta Data Layer. This layer provides data models and services for managing the meta data; that is, the data about data models, mappings, data model languages, mapping languages etc. and the services to support them⁶.
9.  

4.4.1.2 Types of Database

Three types of database are shown:

10. Specific databases directly implement the requirements of a single application. Performance is good, but flexibility is poor⁶.
11. Generic databases can store a wide range of data with better flexibility than the specific database. Performance is sometimes poor when data has to be transformed into another format, but applications designed to work with a generic database perform well⁶.
12. Flexible databases. These can hold the same data according to different data models to give the best of both the above types of database with the minimum of disadvantages⁶.

It was unanimously decided by Working Group 10 that all future work with regard to the architecture of STEP would have the IIDEAS framework (described above) as a fundamental principle to build upon. The IIDEAS standard has enlisted a list of guidelines that would enable ISO 10303 architecture to better facilitate data sharing/exchange. These guidelines are as follows:

Data Integration

The prime objective of IIDEAS is to support the integration of data instances from different applications, which use defined data sets, according to different data models, into a single data set and a single data model. The data by this single conceptual model might then need to be viewed from a perspective defined by yet another data model. (Source and destination models are external models in ANSI/SPARC terms.)

To achieve data integration, a data model conceptual to the source data models needs to be developed, and then a formal two-way mapping is to be defined between the source and conceptual data models³ .

Industrial Data Models

Data models have to be documented precisely and clearly with no ambiguity. A data dictionary approach with language and graphic based representations is thus needed³. Appropriate constraints that are model specific need to be supported. The data models are to be accompanied by an activity model that the data model supports.

Conceptual Data Model

Here a conceptual data model is defined to mean a data model that fully satisfies the data requirements of two or more data models, though not necessarily the constraint or behavior requirements. It defines the relationship between two data models, rather than an absolute state. The external data models may be standardized either in a standard (not necessarily ISO) or within this standard. Development of a data model that is conceptual to all others is expected to be a technical objective³.

It is important to have a standardization process that supports incremental additions to the conceptual data models and ontologies. Fortunately, principles exist, which if applied, enable the development of conceptual data models that are stable, yet flexible to different usages of data, and extensible for additional data requirements⁶ .

Formal Mapping among Data Models

IIDEAS gives the basis for mapping data elements according to the external data model (which is situation specific)to and from the conceptual data model⁶.

Mapping involves:

• Mapping explicit context (domain specific) of data model to/from the explicit elements in the conceptual data model.
• Mapping the implicit elements in the external data model (APs) to/from the explicit elements in the conceptual data model (Integrated Resources)⁶.

Ontologies

In information technology, an ontology is the working model of entities and interactions in some particular domain of knowledge or practices, such as electronic commerce or "the activity of planning." In artificial intelligence, an ontology is, according to Tom Gruber, an AI specialist at Stanford University, "the specification of conceptualizations, used to help programs and humans share knowledge^l."

4.4.2 Examples of Use

Examples of the use of IIDEAS are taken from the process industry. They are currently being pursued in industry.

Example 1: Standardizing the integration of several APs

The design of a process plant involves a number of disciplines, and the hand over of the complete design data for a plant would involve the use of a number of APs, in particular: 221, 227, 231, 212, 225, 230. However, a plant owner does not want a number of separate files of data that have significant overlap in data content. A single integrated database is desired to act as a reference database to support operations and maintenance activities.

Using IIDEAS, a conceptual data model and set of ontologies can be developed from the APs involved. The APs can then be explicitly mapped to the conceptual model and ontologies. This mapping then enables integration of the data into a single physical database. This can be accessed by operations and maintenance applications by the data access interface to provide the necessary reference data. The operations and maintenance applications could also store the data through the data access interface, using a suitable data model for their needs, integrated with the model for plant design⁶
Example 2: Ensuring commonality between APs

AP221 has developed a set of standard classes of equipment that are commonly used in the process industry. AP227 wishes to use them in their AP as a way of achieving both utility and commonality. Rather than make a reference from one AP to another it is preferred to standardize the standard classes (ontology) externally, and make reference to them from both APs, so that the content of the ontology can be managed independently of the data models that use it. IIDEAS provides a place to do this⁶ .

This section has dealt with the use of IIDEAS approach as a guideline for developing STEP architecture to enable data integration. In addition, plausible approaches to developing data integration into the architecture have also been discussed. STEP can benefit from following the architecture proposed by IIDEAS.

In his paper, "Requirements on a Data Architecture for SC4" (ISO TC184/SC4/WG10 Architecture N136, 1997/12/19) including STEP, PLIB, MANDATE among others, Nigel Shaw provides the following guidelines for architecture development.

1. The data architecture should be produced and standardized in such a manner that it does not require repeated standardization excepting for the correction of errors.
2. During its development, it should be possible to use the architecture to give incremental results of value.
3. The process of development of the architecture should be manageable with clear measurable objectives.
4. The data architecture should be communicable to non-native English speakers. The data architecture shall be defined in a computer sensible fashion. The means of definition should support the creation of tools, which use the data architecture or enable its application.
5. The possibilities for variation in the use of the data architecture should be finite and documented. The necessary means, including terminology, shall be defined to enable use of the data architecture for storage and other models to be clearly distinguished from its use as data architecture.
6. The introduction of the architecture shall not force change on existing implementations.
7. Following the introduction of the architecture, it shall be possible for systems to migrate to its use without loss of information.

Fundamental Principles

During the Washington meeting following the Sydney meeting, Working Group 10 outlined the principles for STEP architecture³.

ISO 10303 is based on the following principles:

• ISO 10303 is a standard that provides architecture for product data.
• ISO 10303 (in theory) has to support the tractability of product data to its context. This facilitates data sharing.
• ISO 10303 provides semantics for product data. These semantics are constrained by specifications.
• ISO 10303 provides requirements for conformance testing of implementations.

• Application Protocols: These are data specifications that satisfy specific product needs of a given industrial application. Application protocols are data standards that apply constraints to the semantics of the integrated data models (integrated resources) for application specific purposes. In short, each application protocol is a partitioning that reflects the requirements and usage agreed upon by a specific industry³.
• Integrated Resources: These are generic data specifications that support consistent development of application protocols across many application areas. The integrated resources provide a basis for specifying semantics of all application protocols through an interpretation process. This enables a consistent relationship between the integrated resources (each considered to be a single integrated model) and all the application protocols. Application protocols formed on the basis of a single integrated model have overlapping data constructs. As a result of such architecture, it becomes possible for application systems that read data from one application protocol to read data from a different application protocol³.

This section discusses how the integrated data model (having a two way mapping between the conceptual and the domain specific data models) may be used to achieve data integration.

STEP uses Activity Models to identify the domain of interest and the scope of an Application Protocol being developed in that domain.

• The subject area models are based upon the integrated data model and thus to an extent are already "pre-integrated".
• As more subject area models are developed, there is a requirement for an integration process to ensure that there is no redundancy across subject area models, leading to the extension and enrichment of the discipline classification schemes within the integrated modelⁿ.
• The subject area models are not focused purely on data exchange requirements.

This data model should be suitable as the basis for a database design. This is because the subject area models are themselves consistent, and that suitable rules regarding the integration of the subject models have been developed. The first is true, as all the subject models have been developed using the integrated data model. The second will be true if the associations between the subject area models are maintained using the generic framework and templates. ISO 10303-214 (Automotive), the EPISTLE Core Model (Process Plant), and the POSC EPICENTRE model (E&P) are all examples of Integrated Industry Data Models.

The structure of the integrated model described above would require the presence of a deep structure that traces the data to its context. The ISO 10303 is based on architecture of three layers, namely the application layer, the logical layer, and the physical layer (referred to as the ANSI/SPARC architecture). The models that originated from this architecture are known as the Integrated Product Information Model (IPIM). IPIM has many deficiencies, namely ambiguity in its specifications, human interpretation dependencies, and inconsistency in conformance issues. These problems were also faced by other data exchange standards such as IGES. Hence, a proposal for initiating a deep- structure integration of the application area subject models was taken. This proposal calls for identifying a product and tracing it back to its meta-data. It also necessitated the specification of the characteristics of the product (property definition) and a formal description (representation). The integrated resource constructs that are built to fit the proposal result in a single deep-structure integrated model. The objective of creating this deep-structure model is to represent context dependant meaning (semantics) that can provide a basis for shareability of data.

A high level architecture that incorporates the deep structure concept described above requires the following:

Data specification Architecture: This provides extensible and generic data models.

1. Data Specification Languages: These are used for formally specifying data

models.

2. Data Access Architecture: These specify implementation requirements.
3. Conformance Testing methodology: These specify testing methods for the conformance of Application Protocols to the standards.

Within the SC4 standards, we observe common use of a data specification language (EXPRESS) and implementation methods (physical file, SDAI). However, each of the SC4 standards appears to employ a different data specification architecture: this is the root cause of issues related to "co-operative use" of these standards, since it prevents direct re-use of data specifications and therefore sharing of data instances. The conformance testing aspect of the architecture is mature only in the case of STEP and, through its basis in Application Protocols, is closely bound to the data specification architecture³ .

An integrated architectural model as shown in Figure 9 was developed by WG 10 following discussions held at Washington. An integrated data model supports all industrial data and their respective applications in an enterprise. Integrated data models can be characterized by:

• Ontological Elements: These are the fundamental specifications upon which specific data models are constructed.
• Rules and Constraints: These are combinations of ontological elements that are used for conveying specific semantics.
• Standard Data: These are used for supporting the definition of class libraries and semantics that are context specific.
• Subject Area Models: These are subsets of the integrated data model used for specific purposes.
• Data Models integrate the subject areas pertinent to a given industry or industry sectors ³.
• Exchange Protocols: These identify the communication constraints within a subject area model. This is done for the purpose of data exchange.

A meta-model is inherent in any approach that seeks to find a solution for product data communication or integration. The meta model determines the common underlying structure of the product data model. In STEP, the generic product data model (GPDM) represents these fundamentals. GPDM is the foundation upon which all integrated resources and subsequently all AIMs are constructed. GPDM ensures that all product information is related to an identified product and ultimately to an application context.

Generic Framework

The existence of a small, semantically rich data model that forms the basis for extension to cover the complete scope of interest is absolutely essential. Such a framework exists in STEP in the form of the "core" schemas of Parts 41 and 43. This approach fits well with "layering" approaches such as those used within the PISA project, i.e., within STEP the IRs are an instance of the Generic product data model (the most general of all the data models used in STEP), each AIM is an instance of the IRs, etc⁶.

Templates

Templates provide a data modeling style and content by applying Generic Frameworks to a particular situation. The STEP Integrated Resources are templates intended for re-use within Application Interpreted Models.

Representation

"Representation" is intended to draw a distinction between a thing and information about the thing.

Discipline Classification Schemes

The existence of fundamentals, frameworks, templates and representation capabilities is not sufficient to capture and fulfill requirements across a broad scope of industry needs. It is also necessary to identify and classify the types of objects (and therefore types of data) that are of interest to a particular industry or discipline need ².

Within STEP, such classification schemes exist:

• within the Integrated Resources (particularly the 100-series Application Resources),
• within AIMs and AICs.

• subtyping,
• constraints on data values.

Rules and constraints

The framework, template, and representation elements all enable the definition of very flexible, generic data models. However, in order to meet specific needs associated with usage of the data model, it is necessary to place constraints on many of the potential associations that exist within the model ⁷.

The key elements of the "integrated data model", depicted in Figure 9, exist in the SC4 standards, and are also common to many of the other initiatives that contribute to the long-term goals of SC4. At present, some of the key elements shown in Figure 9 are present only in the domain specific models and not at the conceptual level itself. The other standards also have to work towards satisfying the requirements needed for the integrated data model shown in Figure 9. The issues presented above are some of the drawbacks for standards such as EPISTLE and P-LIB, hence WG10 is in the process of initiating standards for data integration that are compatible with the current SC4 standards. The integration of these standards would lead to the development of "common resource" models for SC4 standards such as P-LIB, MANDATE, and STEP. It has been proven beyond doubt that there is a significant amount of disharmony among the use of standards that address the use and exchange of models in the development of information systems.

Some of the problems are⁷:

• Many incompatible standards are developed for a specific information system purpose.
• Total ignorance amongst standard developers about the progress of other standards.
• Industries cannot make effective use of products that conforms to standards, as there is no perspective that defines the relationship between the standard components.

• Many vendors use the EIA CDIF standard for exchanging files whilst STEP does its data modeling using EXPRESS.
• IRDS, PCTE, PLIB (Part Libraries) and BSR (Basic Semantic Repository) are independently developing standards that manage different aspects of systems.
• There has been no commitment to integrate the semantic aspects of the integration systems.
• STEP uses its own export/import product for data exchange and its own application programming interface, which is not in harmony to the database, access developed by WG3.

• Using SGML (presently XML) tagged texts within STEP.
• Referencing data into STEP from SGML.

• Satisfying STEP requirements using "expression_schema" from PLIB, and
• Insertion of library parts by referencing from PLIB.

Another direction in which WG10 has been progressing to develop the ISO 10303 architecture is by questioning the validity of AIM in the interoperability environment. At present, the Application Interpreted Model (AIM) is used for adding constraints to the general semantics present in the Integrated Resources for application specific purposes.

Some of the problems associated with using this approach are that AIMs do not provide the necessary data structure specification required for implementing the AP(s). Hence the industry’s need for interoperability is not satisfied. This problem arises due to the quality of the integrated resource models and their documentation and due to the low level understanding of IRs and the process by which they are used on AIMs. WG10 has been looking at the possibility of introducing "implementable ARMs" to address the problem of interoperability. Some of the problems that an implementable ARM may be intended to solve include:

• The interpretation steps in AP development process, which are undesirable because of ignorance amongst standard developers about the interpretation process.
• High cost associated with the integration process.
• ARMs are easier to understand and implement.
• STEP architecture is too complex.
• AIMs include IR constructs for which the application (for which the AIM

However, it has been felt that having implementable ARMs involve problems that affected other data exchange standards like IGES. It was also realized that implementable ARMs stem not from technical considerations but from a desire to evade the complexities involved in having the AIM interpretation process. The WG10 has the option of choosing a simple solution (ARM based implementation) or the complex solution (AIM interpretation) depending on the circumstances of application. The role of the ARM is to separate the specification of information requirements from the mechanism that conveys information. This is the fundamental principle that differentiates STEP from other data exchange standards such as IGES. If the ARM was to be used as an implementation tool, then this fundamental difference is compromised. Choosing between the two would depend on the requirement statements of ISO 10303. Some of the requirements are:

1. Standard must ensure unambiguous exchange of data.
2. Standards must specify data structures for exchanging data.
3. Standard must exchange product data throughout the life cycle of the product.
4. The standard is a single integrated model for exchanging product data³

From the above discussion, it can be seen that a lot is yet to be done to make ARM based implementation an effective way to achieve AP interoperability. Work on this front is at present progressing under the aegis of WG10. Alternative solutions to addressing AP interoperability have also been suggested. Some of them are:

• Improving the quality of documentation of Integrated Resources- this would facilitate proper semantic transfer for better usability.
• Developing and using dictionaries and other tools that facilitate repeatability of interpretation process.
• Revisions to the documentation format of application protocols.

• The mapping of data instances between the ARM and the AIM has to be clearly defined. The current problem with doing this is that descriptions and considerations are well defined only at the entity type level and not at the entity instance level.
• The mapping has to be done in a computer sensible language that can be powerful enough to be linked to STEP.
• There has to be a two way mapping between the AIM and the ARM so that any error that occurs in mapping the constructs can be realized.

 
A similar structure is followed in STEP with certain modifications. The STEP structure is shown below: 

Hence WG10 has proposed two way mapping amongst other things that would enable AP interoperability. Work on the two-way mapping is presently in progress³. 

What is AP interoperability?

According to Nigel Shaw, interoperability arises due to the following: " One is when the APs have intersecting areas of interest. Another is when we are planning resources that are common to multiple APs, but there is no clear boundary between APs, i.e., the schema is an integrated union of APs¹."

According to Felix Metzger "AP interoperability requires a modularization in which the APs can be individually implemented and tested, and then mixed and matched with some assurance that they would work together¹".

According to Matthew West, there are four aspects to an interoperable environment¹:

• Business Operations
• Buying
• Selling
• Making
• Maintaining
• Management Information
• Descriptions, Specifications, Representations.
• Business Structure
• Products
• Processes
• Assets
• Organizations.

Some of the problems related to the inability of STEP to facilitate data sharing are discussed below⁴:

• The ability of STEP to facilitate both data exchange and sharing is predicted on the fact that all implementations of STEP must be based on the STEP APs and that these APs are all derived from a common set of resource models. In the formation of an AP, an application process model is used to derive and scope an application data model, which is mapped into the STEP resource models with entity specializations and population constraints created to satisfy the intent of the application process model (L.J.Mckee, AP Interoperability Issues in STEP, October 7, 1994). The "pipe" example discussed earlier illustrates the point made in the previous sentence. Thus, each AP is created by an AP team that is generally not concerned with the working of other APs, as there is no requirement to do so. The results are data and data exchange problems caused by the entity specializations and constraints when APs need to be integrated. For example, PDES Inc. suggests that to overcome this problem, AP developers should look both into the data and schema of APs that are of concern to them.
• EXPRESS rules: The entities specified in an AP are generally constrained by attributes that are specific to the application purpose. This prevents a shared database because there might be other entities that are using the same entities but with constraints that are discipline specific. A solution for this problem is that the entities that are declared must be sub-typed and only the sub-typed entities can be constrained.

AP interoperability is possible when implementation systems are able to identify the schema constructs of all the APs that drive the particular application under consideration. As discussed before, in STEP there are two ways by which data can be shared by different applications, they are:

• Integrated resources, which is a generic data model, and
• Application Interpreted Constructs (AICs) which contain the commonalties between the different APs.

Some of the data sharing problems that WG10 unearthed are:

1. How do applications share data when the structure and meaning is exactly the same⁴: In this case, since the representation type entities are derived from AIC, the processor will have no trouble in realizing the data instances appropriately.
2. How does an application conforming to AP1 share data with another application conforming to AP2 if one AP has more generic scope than the other⁴: AP1 uses only the more generic subtype and AP2 uses the more specific subtype in order to specify the source of "Product_Definition_Formation". Furthermore, AP2 instructs the "Product_Definition_Formation" to say that the only type meaningful to the application developed for its context is one in which the source is specified⁴: Thus the application is prevented from seeing the subtype-super-type structure. Hence a data dictionary has to be built that understands the subtype-super-type structure. As STEP provides a common basis for all product data, APs can build upon the data dictionary.
3. How does an application conforming to conforming to AP1 share data with another application conforming to AP2 if they are different⁴ : The point here is to find out whether an application system can differentiate data depending on its context. This can be done provided the application system keeps track of the data dictionary that enables the product to be traced back to its context (meta data).

6.2 AP Modularization

The advent of the concept of interoperability has resulted in a new architecture being proposed. When the STEP structure was first developed, APs were made from generic resources (GIRs) and application resources (AIRs), where the latter supported groups of related applications. For the "initial release" AICs and conformance classes were added. Now, Application Modules (AMs) are seen as a combination of AP, AIC and Conformance Class concepts^o.

Some of the reasons for modularizing Application protocols are as follows:

• Cost of development of Application protocols.
• Potential reuse of application software.
• Industry need for implementation of multiple APs.
• Presence of duplication and repeated documentation in various APs.
• AP interoperability.

People from different fields concerned with product data have expectations on the new concept of modularization; some of them are listed below⁴:

• Improvement in the quality of application protocols.
• Interoperability of application protocols.
• Exchange of AP implementations through "plug and play".
• Extensions to APs without prohibitive costs.

• APs should be easy to implement.
• Code reusability: If one AP is included in the implementation of the other, than the codes used for building the APs should be as similar as possible.
• The APs should be easier to understand.
• There should be no redundant tests and implementations

• The complexity of AP development (especially ARM development) should be reduced.
• The standardization procedure should be faster and more efficient.
• Harmonization between the APs and between the standards.

• Reduction in marketing time.
• Reduction in development costs.

Application modules (AM) based development calls for use of the three-layer ANSI/SPARC structure for the implementation of the core model. The core model, independent resources, and the domain model make up the architecture of ISO 10303. The domain models can be taken as small APs whose scope depends on a particular application system, and is derived by the specialization of the core model.
 
An Application module (AM) has all the components of an existing AP except for the long form. The Long form is nothing but the addition of constraints to the AIM. This makes the AM inherently interoperable. Also an AM does not have AAM and conformance classes. Thus, an AM is a functionally complete set of requirements and constructs that can be implemented to support common application requirements just like an AIC. Unlike an AIC, an AM may be a common interpretation of IR constructs. Also, an instance of an IR entity in an AP through different AM’s may have different semantics based on the constraints imposed by the AM. An AM has abstract test suites whose implementations are testable. Like the AIC, the AP uses an AM in its entirety. Further an AM does not have a list of entities for which and AP must write a global rule as was required for an AIC. This means that implementations based on AM’s may not have an associated business. This is the fundamental difference between an AP and an AM. The EXPRESS schema written in an application module is compatible with the IR schemas. AM’s have unique schema name and need to have as few rules as possible to make it as shareable as possible. AM is designed to take advantage of EXPRESS 2 and EXPRESS X. Currently, the focus of WG10 in the area of interoperability has been in the field of Application Modules.

1. Felix, Metzger. "On the Usefulness Mapping Tables in APs." Online. Internet. 17 March 1999.
Available: http://www.nist.gov/sc4/wg_qc/wg10/current/n060/wg10n060.htm

2. Fowler, Julian. "Report to SC4: Sydney, March 24, 1995." Online. Internet.
17 March 1999.
Available: http://www.nist.gov/sc4/wg_qc/wg10/current/n006/wg10n006.htm

3. Fowler, Julian and West, Matthew. "The Nature of Industrial Data: Some Architectural Aspects and Issues for SC4." Online. Internet. 17 March 1999.
Available: http://www.nist.gov/sc4/wg_qc/wg10/current/n031/wg10n031.htm

4. Gilbert, Mitchell. "An Approach to AP Interoperability in a File Exchange Environment." Online. Internet. 17 March 1999.
Available: http://www.nist.gov/sc4/wg_qc/wg10/current/n011/wg10n011.htm

5. McKee, L.J. "AP Interoperability Issues in STEP." Online. Internet. 17 March 1999.
Available: http://www.mel.nist.gov/sc4/wg_qc/wg10/archive/wg10n012.htm

6. West, Matthew. "Integration of Industrial Data for Exchange, Access, and Sharing." Online. Internet. 17 March 1999.
Available: http://www.nist.gov/sc4/wg_qc/wg10/current/n071/wg10n071.htm

7. Wix, Jeff. "Purpose of a Core Model." Online. Internet. 17 March 1999.
Available: http://www.nist.gov/sc4/wg_qc/wg10/current/n057/wg10n057.ht

8. WG 10 Document List. Online. Internet. 17 March 1999.
Available: http://www.nist.gov/sc4/wg_qc/wg10/current/