# Presentation: 449468

## “The Challenge of AP-Interoperability within STEP”

***“******The Challenge of AP-Interoperability within STEP”***

***Dipl.-Inform. Günter Staub***Institut für Rechneranwendung in Planung und Konstruktion (RPK)Prof. Dr.-Ing. Dr. h.c. H. GrabowskiUniversität Karlsruhe (TH)Kaiserstraße 12, D-76131 Karlsruhe, Germanyphone: ++49 721 608-4156e-mail: staub@rpk.mach.uni-karlsruhe.de

**AP212/214 Harmonization Project Report**
*WG10 Workshop on “Architectures for Industrial Data”*
*NIST, Gaithersburg, MD, USA, 7.-9. Jan. 1997*

**Notes:**
1
This presentation is about the AP212/214 interoperability project called "Harmonisation ..."
I want to give an overview of the project as well as a report on the current state of the project.
The goals of this presentation are as follows
to inform WG10 about the work
to make WG10 aware of the importance of interoperability in industry
to point out the current problems in STEP that hinders interoperability, and 
to describe possible solution approaches
The project based on the results of an analysis project in German industry
electromechanical product development
project sponsored by the STEP/PDMI
national project
focuses on product data management and implementation
project duration: 04/96 - 12/96

## Content

**Motivation and Project Objectives**
**Harmonization Approach**
**Status & Further Work**
**Problems & Recommendations**

## Motivation and Goals

**Computer-aided development of electromechanical products too inefficient**
- large amount of paper-based information exchange
- partial, proprietary solutions for E-CAD/M-CAD integration available in some companies
- no standards-based, bi-directional data communication between E-CAD and M-CAD systems available
**Objective**
- enable an efficient realization of computer supported process chains for the integrated development of electromechanical products
- ensure interoperability between the APs for
*“**Electrotechnical Design and Installation”* (AP212) and
*“**Core Data for Automotive Mechanical Design Processes”* (AP214)
- 	to allow the co-operative use of both APs in an electromechanical design context

## AP212/214 Interoperability

**step**
**file**

**step**
**data**
**base**

- data formatdata interchange implies a requirement for a data format that can be parsed syntactically by the recipient of the data
- data semanticsboth IT applications must understand the data

*read/write*

*read/write*

**AP-interoperability is the ability to exchange interpretable data between two (or more) IT applications which are based on different APs, i.e., to have a meaningful communication between ****IT applications**

**AP212 based IT**
**Application**
- (e.g., Mentor Graphics)

**AP214 based IT**
**Application**
- (e.g., CATIA)

**Notes:**
15
Computer applications
handles data/information
have an internal representation (e.g., B-Rep vs. CSG, relational vs. object-oriented, etc.)
provide a functionality (functions to model the shape vs. functions to perform a FE-analysis)
support enterprise functions (e.g., planning, design, work-preparation, etc.)
Combination
different computer applications with different internal representation may be used to support the same enterprise function (e.g., CATIA, ProEngineer)
one computer application can support different enterprise functions (e.g., a CAD-system can be used to model the shape of a preliminary design and to model the detailed design)
different computer applications with different representations and different functionality may support the same enterprise function (e.g., product development)

## General Approach – Requirements driven AP Harmonization

**identify the information**
**requirements for the development **
**of electromechanical products**

**map the information requirements****onto the APs 212 and 214**

**harmonize common**
**ARM areas**

**harmonize common**
**AIM areas**

**1**

**2**

**5**

**3**

- information
- requirements

- Units of Functionality,
- Application Objects

- harmonized
- ARMs

- interoperable AP212/214
- implementations

- harmonized
- AIMs

**4**

**implement the APs**

## Step 1 – IndustrialRequirements Analysis

**Goal**
- capture the information requirements for the integrated, computer-aided development of electromechanical products
**Procedure**
- analysis of typical development processes within ProSTEP member companies
**Delphi AS **(wiring system for cars)**,**
**Mercedes Benz **(process chain optimization: integration of electric/electronic - computer supported methods and tools)
**Siemens** (“Kernspin-Tomograph”)
**Result**
- documentation of the information requirements in form of detailed interview protocols and minutes
- interviews independent of STEP (AP212 and AP214), i.e. in the terminology of the domain expert

## Step 2 – Mapping onto AP212 and AP214

**Goal**
- translate the information requirements for the development of electromechanical products into terms of AP212 and AP214
**Procedure**
- separate meetings with an AP expert
- mapping of the information requirements onto the APs 212 and 214
- out of scope / in scope
- identification of the corresponding ARM elements (UoFs, AOs) of AP212 and AP214
- identification of “overlapping areas” and relationships between both APs
**Result**
- AP212 and AP214 view of the information requirements
- “cross-AP” information requirements

## Step 3 – ARM Harmonization

**Goal**
- express information requirements common to both APs in the same way in order to ensure an identical interpretation process
**Procedure**
- ARM harmonization meetings
- “delta-slides”, showing commonalties and pointing out differences
- solution proposals for harmonized ARMs
- documentation of the agreed solutions for AP interoperability
**Result**
- harmonized ARMs of both APs in the identified areas
- bi-directional mapping of “semantic counterparts”
- issues against both APs (including proposed solutions)

## Strategy for ReachingAP Interoperability

*AP212*
***ARM***

*AP212*
***AIM***

*AP214*
***ARM***

*AP214*
***AIM***

***AP212***
***mapping table***

**3**

**1, 2**

**4, 5**

***AP214***
***mapping***
***table***

- 1.	identification of semantic counterparts on the ARM-level
- 2.	specification of a formal, bi-directional mapping on the ARM-level
- 3.	follow the mapping-table entries of both APs
- 4.	specification of a formal, bi-directional mapping on the AIM-level
- 5.	implement the AIM-level mapping specification for AIM data exchange

**3**

*ARMs (and AIMs) are specified*
*at the same abstraction level*
*using the same specification language (EXPRESS)*

## Further Work

**AIM harmonization (Step 4)**
- based on Mapping Table harmonization
- interoperability tests based on AIM population
**Issue resolution**
- incorporation of AP-interoperability related CD issues (internal)
- review of AP-interoperability relevant issues (external)
**Development of a “core model” for AP212/214 interoperability**
**Investigation on necessary modifications of STEP implementation forms**
- data exchange for multiple APs using ISO 10303-21
- refinement of domain equivalence construct in ISO 10303-22

## Problems

**both APs are still under development**
- different time schedules and individual delays
- AP212: out for CD I ballot   –   AP214: preparation for CD II ballot
- sometimes: “shooting at moving targets”
**amended IRs**
- not clear if AP212 is allowed to use the amendments
- worst case: same requirements maps to different IRs
**both APs have a large audience**
- ... contradicting requirements in both APs may appear
**harmonization will not always result in identical/similar structures**
- converters, translators, etc. still necessary
- going from the ARMs to the AIMs even increases the complexity of the problem

## General Problems (1)

**AP-interoperability is **_**not**_** a “built-in feature” of STEP**
- each AP is developed to exchange/store data for _one_ application domain
- no monitoring enforces AP teams to investigate the relationship of the owned AP to any other AP
- lack of resources, interest, will ?
- no guidelines for AP-interoperability available
- no focus on AP-interoperability within
- STEP architecture and methodology
- AP development process
- STEP description methods and implementation forms
- AIM is understood (users, vendors, ...) to provide the commonalty between APs - but it does this only in a limited way. The ARM-interpretation process is a crucial point

## General Problems (2)

**No concept of CCs for AP interoperability in STEP**
- AP-specific CCs will lead to additional implementation problems
**No “AICs” at the ARM level**
**No bi-directional ARM-AIM mapping (“mapping tables”)**
**The commonality between APs is not visible**
- publish AIMs of APs as IR subset + AP-specific specialisations
**AP-interoperability comes not for free**
- additional effort and resources needed by AP teams for discussions, meetings, rework and modification of parts of the AP, ...
- additional person outside the AP teams necessary (“mediator”)
**Funding mechanism drives AP projects**
- 1st. priority: bring in their own requirements and finish their "own" AP
- ?th. priority: interoperability requirements

## Recommendations

**Migration from a “single AP-centred” STEP architecture and methodology to an “interoperability-centred”**
- interoperability should be one central requirement for and design principle of the “new architecture”
**Move form “monolithic AP-approach” to a more modular approach with well-defined “interfaces”**
- “configuration” of APs rather than development from scratch
- “less freedom for individualism - more focus on commonality”
**Future description and implementation forms to support “plug & play” interoperability**
- less effort for generating interoperable solutions
**“****New architecture” should allow/enforce a high degree of automation for the AP-development, i.e., shorten the time to market for APs**