Implementation of STEP-Based Product Data Exchange and Sharing

(1)

http://cer.sagepub.com

Concurrent Engineering

DOI: 10.1177/1063293X0000800106

2000; 8; 50

Concurrent Engineering

Shen-Chou Yeh and Chun-Fong You

Implementation of STEP-Based Product Data Exchange and Sharing

http://cer.sagepub.com/cgi/content/abstract/8/1/50

The online version of this article can be found at:

Published by:

http://www.sagepublications.com

can be found at: Concurrent Engineering

Additional services and information for

http://cer.sagepub.com/cgi/alerts Email Alerts: http://cer.sagepub.com/subscriptions Subscriptions: http://www.sagepub.com/journalsReprints.nav Reprints: http://www.sagepub.com/journalsPermissions.nav Permissions:

at NATIONAL TAIWAN UNIV LIB on August 25, 2008

http://cer.sagepub.com

(2)

50

CONCURRENT ENGINEERING: Research and

_Applications

Implementation

of

STEP-Based Product Data

_Exchange

and

_Sharing

Shen-Chou Yeh and

Chun-Fong

You

1 Department

of Mechanical

_Engineering,

National Taiwan

_{University, Taipei,}

Taiwan,

ROC Received 13

_September

1999;

accepted

in revised form 14 November 1999

Abstract: Product data _exchangeand _sharingis an _importantissue for miscellaneous information systems. STEP-based product data exchange and _sharing_providesa useful mechanism for implementing concurrent engineering and promoting the realization of CALS’ en-vironment. This paper implements a _pilot_systemfor STEP-based PDE (Product Data Exchange) system based on the _requirementof

product data _exchangebetween and within enterprises. The system incorporates engineering information in the _designand

manufactur-ing stages and guarantees the _consistencyof the _productdata _exchangeand sharing. Complete development processes of systems, in-cluding AAM _{(Application Activity Model),}ARM _(ApplicationReference _Model),and AIM _{(Application Interpretation Model),}are illustrated

herein. AAM _utilizingBPR _(BusinessProcess _{Reengineering) approach}is employed to _developARM, which is then mapped to AIM mod-els from part 41, part 42, part 44, AP 203, AP 214 in STEP The system’s database is based on the _integratedAIM models in STEP to as-sure the capability for product data exchange and sharing. The kernel data structure is a combination of _engineeringinformation and product-oriented definitions. The data from miscellaneous information systems, such as CAD/CAM, MRP/MRPII, ERP, and PDM, in the

de-sign and manufacturing phase of a _product’slife _cyclecan be exchanged using this _system.This paper also employs STEP to _present an _integrated_{product-oriented}data structure to manage engineering information from different information systems.

Key Words: product data exchange, product data sharing, product data management, concurrent _engineering,STEP

1. Introduction

Product data

_exchange

and

_sharing

must assure the

interoperation

of

_product

data from miscellaneous informa-tion _systems

_by

either

_defining

standardized data models for

representing

product

data

_ll-4

or

_implementing

_system

ar-chitecture for

_reducing

the barrier of

_product

data

_exchange

and

_sharing

_[5-8].

STEP standard

_provides

a robust data

structure for the

_exchange

of

_product

data models

_{[9,1 OJ.}

However,

no information

_system

_currently

has the

_capability

to

_flexihly

_{manage STEP-based}

_product

data from

miscella-neous information systems. The data sources of different

product

information within STEP-based

_product

data mod-els are defined to

_integrate

the information.

This

_project

aims to define the

_project

data models

_using

EXPRESS

_language

and _setupthe STEP-based

_product

data

repository

for

_product

data _managementand

_exchange

for automobile

_{manufacturing}

industries and their first-tiered

suppliers.

The STEP-based

_product

data

_{representation}

as

il-lustrated in

_Figure

_may

come from miscellaneous ilfolma-tion systems, such as

CAD/CAM,

MRP/MRPII, ERP, and

PDM.

_Although

additional information from one _systemcan

be attached and

_implemented,

STEP cannot

_incorporate

pieces

of information from miscellaneous _systems.The

re-pository accomplished

in this _papercan

_{alllalgalllate}

the data

based on STEP and a real STEP-based data

_repository

to

achieve

_product

data

_integration.

Distinct

_{methodologies}

for

product

data

_exchange

and

_{sharing, including}

_{part 21,}

SDAI,

COM, and

CORBA,

are discussed in the next section.

1.1 Review of the

_Implementing

_Conceptual

_Layer

Object-oriented language

with UML

(Unified

_Modeling

Language)

modeling methodology

is

_proposed

to

_equip

the STEP-based

_repository

_system

with EXPRESS data

models,

since EXPRESS

_language

lacks the I/O

_capability

_for

pro-gramming j

1 I J.

Object-oriented modeling language

also has the benefit of

_being

robust,

flexible, extensible, direct,

and reusable. The conventional means of

_establishing

a

STEP-based _systemis to use EXPRESS

_language

to model the

con-ceptual

models, and then construct the

_application

_{layer by}

object-oriented

and EXPRESS-C

_languages

as

_depicted

in

Figure

2. The

_conceptual

data models are translated into an

RDBMS (Relational DataBase

_Management

_System),

merged

into an ODBMS

_{(Object-oriented}

DataBase

Man-agement

System),

or

_{managed by}

an EXPRESS model

man-agement

system, to construct the

_{physical layer}

_{of the}

sys-tem.

1.2 The

_Physical

_Layer

The

_physical

_layer

in

_{Figure 2}

contains the kernel database and network communication media structure. The ODBMS

1

Author to whom correspondence should be addressed.

(3)

Figure 1. STEP-based _productdata representation.

provides

better _storageof information within the STEP-based system than the

object-oriented conceptual

data mod-els because the latter affects the construction of the database schema. Best results can be obtained

_by

emptoying

the

RDBMS after

_{object-oriented modeling}

because it is

com-patible

with relational databases and it will

_guarantee

the ef-fectiveness of the

_legacy

_systemsdata retrieval. The

com-plexity

of the information to be stored is

_key

to

_choosing

between the ODBMS or the RDBMS as the former is suitable

four

_complexly

related data, such as the PDM and CAD/CAM

system, while the latter is suitable for

_{large quantities}

of data.

The main concern that must be addressed when

_adopting

RDBMS as the kernel of STEP-based _systemis the

integra-tion

_{of legacy}

data. It is best achieved

_by

ODBC

_(Open

Data-Base

_{Connectivity)}

because it can

_{incorporate legacy}

data

_by

merging

the schema

_{of legacy}

data into the STEP-based

sys-tem

[ 12 J.

On the other

hand,

if the ODBC driver of an

ODBMS is used. the data

_residing

on ODBMS can also be

shared

_by

the RDBMS.

The

_{physical layer}

of the STEP-based PDMS should be

equipped

with a data

_exchange,

an external shared

database,

or a distributed database method to secure

_product

data

exchange

and

_sharing.

The data

_exchange

method enables

product

data within a PDMS to be

_exchanged

as

_physical

files

_expressed

in a

plain

text

_{[ 13].}

This method

_easily

fa-cilitates

_{setting specifications, conducting}

tests and diverse

system

applications.

The

_externally

shared database method

accesses a common database between

companies

on a

contract basis. Data are

_copied

from the PDMS of the

compa-nies into the common database. The distributed data-base method distributes the

_product

_{data among the PDMS} of

_companies

that can

_concurrently

share access

_[

1-~-16].

The

_virtually

shared database method may be the

ulti-mate in

_product

data

_sharing

intended to create a concurrent

working

environment because

_although

the data are

physi-cally

shared on internet network, the database functions as a

single

unit.

The construction of a STEP-based distributed database

management system is illustrated in

_Figure

3. The left side indicates the

_generation

of the internal

_{representation}

of EX-PRESS codes, such as the

_migrated

data models in Section 2.

This can be used to construct the

_{database, generate}

_parser codes, and

_implement

C++ codes. The C++ codes are

com-piled

by

an ODBMS to add the _managementfunctions into

original

C++ codes. At the same time, a schema

dictionary

Figure 2. Approach for establishing a STEP-based _system.

(4)

52

Figure 3. Approach for constructing STEP-based distributed _management_system.

and its related codes are

_generated

and

_{managed by}

the

ODBMS. The shared database environment is achieved with the ODBC driver

_provided

_by

ODBMS

_{[ 17,18].}

Figure

4

_presents

three mechanisms of network communi-cation,

_including

an ODBC mechanism, a database

commu-nication mechanism, and a CORBA/COM mechanism, with

their

_operation

methods, that can all work within a

STEP-based PDMS. The ODBC mechanism comhines all informa-tion from the different systems into the unified data schema. Database communication relies on the ODBMS, while the

most

_{popular approach}

is the use o1- TCP/IP

_protocol

to ad-dress the PDMS server side. The CORBA/COM mechanism

allows the distributed

_objects

to communicate with each dis-tribute the information of PDMS.

1.3 Review of

_{Implementation}

of

Application Layer

The

_application

_layer

must connect the

_operations

of the

physiral layer

to the

_{conceptual layer.}

The effectiveness of data _managementand

_{compatibility}

with STEP are

_always

opposite,

because the

_{implementation}

_{of STEP-based}

sys-tem

_using

ARM or AIM indicates two different

_approaches

119].

_gradually

solve

Figure 4. Three mechanisms of network communication.

(5)

this

phenomenon,

so that

_{prototyping applications}

can be

r-~rpidly

developed

and

_easily

connected to the _target data-base. The

application

or

presentation layer

is formed

by

ref-erencing

models in the

_{conceptual layer}

to meet diverse

re-quirements.

A flexible

_modeling

and better communication interface are the

_major

issues for a STEP-based PDMS.

They

should be considered to

_adopt

different

_requirements

from distinct ventures. It

_emphasizes

how to

_{flexibly synchronize}

the

conceptual

models and the data structure and how to

es-tahlish a network communication interface. Communication

interfacing

is

_important

for a distributed PDMS to meet the need of

managing

and

_sharing

information. Since the STEP-based system is an

object-oriented

_system,most communica-tion interface relies on Java,

CORBA,

or DCOM to achieve the distributed environment.

STEP utilizes SDAI to

_integrate

the _system

_{by sharing}

the AIM

_product

data of information _systemssuch as CAD

sys-tem, PDMS, etc.

~?0,? 1 ~.

The SDAI can be

_regarded

as an

API

_{(Application Programming}

Interface) to store and share the

_product

data

_independent

of the

_{system’s physical layer.}

The SDAI should not be used

_during

the

_practical

utilization stage since it is

_merely

an interface to

_operate

the database of EXPRESS

language.

The STEP-based data based on _the

ap-plication

object

level is

_managed

_by

_using

HLDAI

_(High

Level Data Access Interface) that is a

_{user-friendly}

interface

with an

_application

view. A STEP

engineer

can access the STEP database without an SDAI or AIM

_by

using

the

HLDAI

_(High

Level Data Access

Interface).

A STEP

engi-neer shall construct the STEP data

_exchange

_system

accord-ing

to its kernel data schema that is a data structure definition of information

_systems.

2.

_System

Architecture

The bolder lines in

_{Figure 2}

indicate the

_methodology

ap-plied

to

_develop

the STEP-based

_repository

_systemin this paper. The

integrated product

data models in STEP are

cre-ated

_by

a UML

modeling

tool that _generates

programmable

C++ codes and is translated into an

object-oriented

database,

POET. The

_generated

C++ codes are used to

_develop

_the

ap-plications

in the

_presentation

_layer,

while the

_{object-oriented}

database is

_ready

for

_storing

the instances of the data models.

Any

change

in the

_conceptual

models will

_immediately

after the data models in the

_physical

_layer.

An 00 _management mechanism, such as an OODBMS or serialization

mecha-nism of

_{object-oriented}

_language,

is used to

_develop

STEP-based PDMS to

_accomplish

the _managementof STEP-based

information,

rather than

_using

SDAI or HLDAI.

A STEP-based

_product

data

_repository

is

_developed

to ful-fill the

_requirements

of

_product

data

_management,

_exchange,.

and

_sharing.

The

_product

information models follow

ISO-10303,

STEP standard, while data

_{exchange, sharing,}

and management

methodology

follow the

_{methodologies}

de-fined in STEP. The

_repository

can

_exchange

_product

data and _{manage the CAD}models and technical information as

il-lustrated

in

_Figure

5. The functional _componentsinclude an

Internet-based

_exchange

_subsystem,

_{applications,}

utilities, and a

_repository

database with an access

_apparatus.

Defining

the

_product

data models

_using

STEP standard-izcs the information

_{representation}

to assure the

implemen-tation of information

_sharing.

The STEP files

_{export/import}

functions in the

_system

can be used to

_generate

the

_exchange

files. The

_accompanying

utilities and

_applications

can be

used to demonstrate the

_integration

and

_management

capa-bility

of STEP-based

_repository.

The hest

_possible

model of the STEP

_system

must be

cre-ated herein since the

_quality

of the models affects the

imple-mentation of the

_system.

A subset data models based on

AP2 14 is used as the kernel information models of the

infor-mation within the

_development

and

_{manufacturing}

_stages

in the

_target

_industry

_[22],

This section describes the

develop-ment of each task,

_{including modeling}

the information mold-els,

_developing

kernel database,

_developing

the

_{applications,}

and

_developing

the utilities. The

_{functionality}

and

imple-mentation

_{methodologies}

used in the

_pilot

_systemare

dis-cussed in detail.

2.1 Overall

_System

Architecture

The

_repository

_systemshould have the

_following

compo-nents to _manage

_product

information

_effectively,

database management system with database interface,

repository

sys-tem with access interface, utilities, and

_{applications,}

as

illus-trated in

_Figure

6.

The database interface

_provides

the

_registration

function, the

_manipulating

functions of

_application

interfaces and meta-data, and the

_managing

functions of user information

and database

_engine.

The

_repository

interface

_provides

the

vaulting, formatting,

and

_browsing

functions of all

_executing

threads. The utilities,

_including

_system

administration and functions _management,

_provide

and maintain information infrastructure and

_operations.

The user

_{registration,}

manage-ment, and verification are alsu

_supported

_by

the utilities. The

applications

provide

the end-user with a

_working

interface to

fulfill their

_{requirements.}

The

_imported

and

_exported

infor-mation follows the subset data models of AP214 in STEP

1231.

The information i*eti-leB-zil and

_exchange

of the

applica-tions in the _system,

_{including product}

information and CAD models, follows ISO-10303 Part 20 serials like Parts 2 and 22.

2.2

_Modeling

the Information Models

The

_conceptual

data models of the

_repository

system must

be modeled to define the data schema. The models include AAM, ARM, AIM, and other models with

_specific

program-ming language.

AAM is used to model the

_activity

models within

_design

and

_{manufacturing}

_stages

while the data

man-aged

within the

_activity

is modeled in ARM. ARM is then

mapped

onto the standardized data models in STEP. AIM is then translated into the models in C++ for

_{implementation}

by

the

_{object-oriented language.}

(6)

54

(7)

2.2.1

MODELING

CONCEPTUAL DATA

MODELS

The

_conceptual

data models of the

_repository

system in-ctude AAM, ARM, and AIM. All

_conceptual

data Illodelv of the tablcs and CAD models in thc

pilot

system are

repre-sented

using

EXPRESS

_language

and illustrated

_by

EX-PRESS-G.

Thc

_{aphlicatiun objects}

of CAD models and the

ten sets ot~ technical information,

including engineering

re-)ated documents, material,

_{specification. expressed}

with EX-PRESS models are defined and

_{represented by}

EXPRESS-G notation. The context of the

_conceptual

data models can be classified as the information models of CAD models and technical documents. The data models of CAD models in AIM follow AP?()3 in STEP, white the ones in the technical documents follow AP?()3, ? 1-t. and Part -t() serials _parts.The AAM

captures

the process information models in the

_design

and

_{manufacturing}

stages. AAM utiliies IDEFO

_modeling

nWhuUolo~~y.

The ARM

_employs

thc’ data modes in the ven-turc. and EXPRESS

_language

to model the information. The AIM. clcrived

_{hv mapping}

ARM with STEP standard,

reprc-,ent; STEP-based standardised

_industry

data models in this paper.

2.2.2 MIGRATE DATA MODELS FOR TECHNICAL INFORMATION AND CAD MODELS

Thc CAD _geometryinformation mode) _representsthe

product-oriented

data structure w

_presented

in

_Figure

I . The technical information, or

_{product-oriented}

data structure, is

represented by

miscellaneous industrial table sheets. An item view is used to combine the technical information w ith the CAD models so one can track the information

_through

the entire

_entity.

With this mechanism, we can reduce data

ex-change, reformatting,

data _management,

_{design history,}

doc-ument barriers

_{I ~41}

while

_implementing

concurrent

engi-ncerin~~.

2.2.3 IMPLEMENTATION MODELS

All

_{implementation}

models used to define the data models of the

_repository

and the

_applications

follows UML forOOA and OOD of the

_{applications.}

The Data Mudels (I.E. Static Modets) and

_Sequence

Muclels ( I.E.

_Dynamic

Modeb) of thc

applications

are used to _{manage the data}structure and

oper-ating

procedures.

Since the

_conceptual

data models

_of

prod-uct information are

_specified

_by

EXPRESS

_language

and EXPRESS-G

_graphical

notation, the EXPRESS

_language

is translated into C++ format tor use as thc reference models for the data schema of the

_repository

_system.

2.3

_Developing

Database

The database interface of the

_repository

_system_manages thc database

_according

to

_conceptual

models. The informa-tion

_technology

will not be restricted

_{by specified}

methods since the

_applications

arc not

_directly

connected to a database Illanagement

system.

Thc

_relationship

of all

_objects

with a

list of functions and attributes of classes can be obtained

us-ing

UML

_{modeling language}

to

_specify

the API. The API oC

the

_repository

comes from the database API. which is

speci-t’icd

_by

UML. EXPRESS-C models and

IDL (Interface

Defi-nition

_Language)

can also be used to handle

_objects

within the CORBA architecture. The

_applications

of the

_repository

system use

_conceptual

models to access the information stored in the database

_through

a set of interfaces. The

appli-cation interfaces can he from the lowest level API, which is the kernel

_application

interface, to the

_highest

level

_API,

which is the

_{application-oriented}

API. The

application-ori-ented API can use the information models to _mapthe

corre-sponding

instance to find

_{the necessary}

information. The API can he classified into four kinds of API: Kernel AP1.

Dictionary

API, Classification API. and

_Object

API. The relational database _{management system}is used

_by

the

repository

system as the kernel database. A DDL

_(Data

De-scription Language)

is

_generated

and used to _setupthe table schema and data schema of the RDBMS. The

_applications

can access information of the tablc; or CAD models

_through

the RDBMS. With the EXPRESS-tl)-DDL translator. the EXPRESS

_language

can be translatcd into the

_{corresponding}

DDL. The definition and

_relationship

between

_objects

can be

mapped

into the

_{corresponding}

data schema. Therefore, the

generated

DDL can be used _{to get}the definition and

relation-ship

of the

_{object-oriented}

models in the RDBMS.

The database access

_operations

of the

_applications

use the

ODBC

_Bridge

of the RDBMS to communicate with the data-base. These access

_operations

_{encapsulWe corresponding}

SQL

statements. For

_example,

the &dquo;Add New&dquo;

_operation

will I

encapsulate

thc INSERT statement

_{of SQL.}

while the &dquo;Edit&dquo;

operations

will

_encapsulate

the UPDATE statement

_{of SQL.}

All of these

_operations

will be

_packaged

as a set of API. ODBC is used as the standard access interface of database

to

_amalgamate

with other RDBMS. The

_applications

Litilize the ODBC

_Bridge

of the RDBMS to send

_SQL

statement to

easily

access the

_object

information of the database

_through

ODBC interface. The

_applications

can use the same API to

access data from distinct database to

_amalgamate

different RDBMS. even ODBMS with an ODBC

_bridge.

2.4

_{Developing Applications}

The

_{configuration}

management,

engineering

data

man-agement. geometry, and

_{ordering applications}

are all

devel-oped according

to the AAM models advanced herein. The

configuration

management

application

can be used to

man-age the

product configuration

data of the

_repository.

The

content of the

_{con figuration}

data consists of the

_product

defi-nition as Wc’ll W

_{engineering change}

_request,

_suggestion,

and

engineering change

issue. The

_engineering

data

_applications

can be used to _{manage the}

_{repository’s engineering}

data, such as material _managementand test

_report.

The

_geometry

application

is used to

_display

and render the 3D CAD model of the

_product,

while the

_{ordering application}

can he used to

manage the data from the

purchase

department.

The

_upplications

use kernel API

_{encapsulating}

the

_SQL

of the database to access the kernel database. The API ot’the

(8)

56

Figure 7. _{Functionality}of the _repositorysystem.

pository

accesses the kernel database because the API is

packaged

as the API of the

repository.

The

export/import

subsystem

translates information from/to the

_repository

with

a STEP-based

_approach.

The

_subsystem

can be a stand-alone

application

or a module of an

_application.

It can be classified

as an

_{export/import subsystem}

or a CAD roodel

export/im-port

subsystem dcpending

on its function. The

_major

func-tionality

of the

_subsystem

is

_translating

the information of the tables or CAD models to and from

_{part 21}

formats.

The browser and editor are the fundamental

function-alities for each

_application

of the

_repository

_system,aa illus-trated in

_Figure

7. The

_application

instances of the

_physical

objects

and the

_relationship

between these

_objects

are

dis-played

with different views. The structural browser and

edi-tor divide the

_graphical

user interface into two

_partitions:

a

rapid display

of the information items on the left, and the content of the item selected on the

_right.

Different form views _{with proper controls}should be used to

_display

its in-formation for distinct

_applications

of the tables. A browser for CAD models is also an

_important

issue for

_application.

A browser for AP203 CC6 is

_developed

to solve the inconsis-tency for STEP 1 iles of distinct CAD systems. An

_integrating

system is also

_developed

to move the information from the

CAD

_systems

and the

_repository

_system. 2.5 Utilities

The _system

administration,

_application

management, and

auxiliary

tool utilities can be used to

_{help develop}

and main-tain all information in the

_repository

_system.

The

_major

func-tions include:

1. To

_generate

_{and manage the}

_product

data models of the

repository

system

2. To _generateand _{manage the data schema in}the

_repository

system

3. To record the user’s information for

_managing

the user’s

privilege

4. To translate information from and to _properformat, such

as EXPRESS to C++ codes, and translation between CAD _systems

The

_exchange

_utility

is

_developed

in Java to secure _usage across distinct

_platforms

between industries to transfer

_part

2 1-iles. The

_exchanger

can monitor the _progressof files and

examine the

_completeness

of the

_exchange

files. It can be

used in either server or client modes for

_switching

the roles for

_{application requirement.}

The transaction information could also be saved to trace the user’s

_login.

The translators used in this

_{paper adopt}

one of the UG and CATIA

_systems

to

avoid the information loss.

3.

_{Implementation}

The

_repository

_system

is tested in two

_{manufacturing}

in-dustries.

industry

A and

_industry

B, to

_verify

the

_system

ar-chitecture.

_Industry

A has the entire

_repository

system, while

industry

B, the first-tiered

_supplier

of

_industry

A,

has just

the

applications

and

_exchanger.

The

_procedures

are discussed

separately

because the

_processing

of tables and CAD models

are not the same.

’rhe CAD translators used for the test are UG and CATIA

translators, which are the

_major

CAD _systemsused in the two

industries. The

_operating

_systemused forthe UG translator is Microsoft NT 4.0, while the one used for the CATIA

transla-tor is the IBM RS6000 UNIX. Both of these CAD translators

can translate the native CAD models into standard formats

based on AP203 and AP214. The translators for AP203 and IGES 5.3 of the two CAD _systemsare used to translate solid and surface CAD models to

_verify

the CAD models transla-tion

_by

STEP and IGES. The

_exchanger

_utility

runs on both

(9)

PC Windows NT 4.0 and IBM RS6000 UNIX environments because of the

system

environments of the industries. The

application

scenario is the

_co-design

situation between these

two

industries.

Industry

A

employs

a

_{conceptual design}

or

engineering

change

case, and then transfer related

infoma-tion.

including

CAD models and related technical informa-tion. to

_industry

B.

_Industry

B evaluates the

conceptual

de-sign

or

engineering change

and then transfers their

designs

or

suggestions

for that case. The same _{process is}

_repeated

as the

final

_design

is

_approved

and the

_{manufacturing}

and

_ordering

information is readied for

_production.

The screen

_dumps

for

the

_{developed repository}

systems

and

_exchanger

are

illus-trated in

_Figure

8. 3.1 Scenario 1

Industry

A translates the

_engineering

data and CAD mod-els of a

_product

and then sends them to

_industry

B.

Applica-tion A includes

_{configuration}

_management,

_engineering

data,

_geometry,

and

_{ordering applications}

as illustrated in

Figure

9. Each

_application

has its

_{corresponding conceptual}

data models

_using

EXPRESS,

formed

_by

a serial of process

from AAM to

_{implementable}

models in Section 2.2. The fi-nal models are translated and built into the Oracle databases

of the

_repository

_system.

The databases utilize the data

struc-ture, schema, and definition of the

_migrated

data models to

assure data

_consistency.

The

_applications

of the

_repository

can then be

_developed

based on these databases.

Geometry

information is included in the

_product

informa-tion, since the

_product

information is linked and

_{managed by}

PDMS. The

_{part 21}

files of the CAD models are

_generated

from the translator of UG and CATIA. The

_part

21 files in

in-dustry

A are

_{generated by}

the translator of the UG

_System.

A STEP CAD model viewer for AP203 is

_developed

to render the 3D models to browse the CAD models in _part21 formats. The

_part

21 files are

_parsed

and stored in the

corresponding

tables of the databases in

_repository

to store the

_geometry

in-formation in

_part

21 tiles. Both of these

_operations

are

sup-Figure 8. Screen dumps for the _{developed repository}_system.

(10)

58

Figure 9. _Working_processof the applications of the repository system.

ported

in

_application

A since the source of the

_geometry

in-formation can be

_{part ?}

1 files in the

_directory

of the disk or

databases in the

_repository.

3.2 Scenario 2

Industry

B receives the

_engineering

data and CAD models of a

_product,

and then sends back the

_design

information

af-ter

_design

or

_{redesign. Application}

B consists of the

configu-ration _management,

_engineering

_{data, geometry,}and

order-ing applications

of

_industry

B, as illustrated in

_Figure

9.

Although

industry

B has no data

_repository,

the information

exchange

and

_management

can also be

_{accomplished by}

us-ing

part 21

_exchange

files.

_Application

B

_imports

and

ex-ports the

part 21

files of the

_engineering

data and CAD mod-els from

_industry

A. Since the

_conceptual

data models of each table are

_pre-knmvn

to these ten sets of

_{applications,}

the

data from

_application

A can be received and

_{interpreted by}

application

B

_{directly by mapping}

the same

_migrated

mod-els. This

_procedure

is also

_applied

to the data

_exchange

of CAD models from

_application

A.

New

_{part ?}

1 files of the CAD _{models from the CATIA}

sys-tem are

_generated

and then

_passed

to

_industry

A

_through

the

exchanger

after the

_redesign

or

_{engineering change}

of the CAD files. The STEP viewer is used to browse the

_{part 21}

I files of the CAD models in

_application

A as in scenario l. The

_{part ?}

1 files of the CAD models are

_{generated by}

the translator of CATIA

_system.

4. Conclusion

Product data

_exchange

and

_sharing

mechanism can be

ac-complished

based on the

_repository

_system.

_Figure

10

illus-Figure

10. Product data _exchangeand sharing mechanisms for STEP-based _repository

(11)

trates the summary

of applicable methodology

of the STEP-based

repository

system. R 1 and R2 are the full set of the

re-pository

system,

while A I and A2 _representthe

_application

of the

repository

system without a

_repository

database. The data

exchange

and

_sharing

scenarios can be R-R,

R-A,

or

A-A. The data

_exchange

and

_sharing

mechanism are listed in

Figure

I ():

_{part 2).}

SDAI with

_accessing

database

functional-ity,

ODBC,

_accessing

API of DBMS, COM or CORBA. The

mechanism

using

part

21 relies on the

_quality

and

_flexibility

of

import/export

functional module to assure the

_quality

of

the data

_exchange

and

_sharing.

The mechanism

_using

SDAI relies on the

flexibility

of information models

_management

and translation to assure the

_quality

of the data

_exchange

and

sharing.

The mechanism that

_employs

ODBC relies on the translation and

_consistency

of information models from the

object-oriented

data structure and relational data structure to

assure the

_quality

of the data

_exchange

and

_sharing.

The

mechanism that

_manipulates

the API of DBMS relies on the

flexibility

of information models _managementand transla-tion. The mechanism

_using

COM or CORBA relies on the

development

of services on distributed environment to as-sure the

_quality

of the data

_exchange

and

sharing.

These

mechanisms co-exist to

_accomplish

the data

_exchange

and

sharing

between and within industries.

The data

_repository

_developed

herein is used to _setupthe management system for technical document and CAD mod-els. The information

_exchange

and

_sharing

_{is easy}to _process

because the information

_{representation}

and _managementis based on standardized

_product

data models. The interna-tional standard, STEP, secures the

_{implementation}

and

ex-tensibility

of the

_repository

_system.The _system

_integration

of miscellaneous _systems,such as MRP, MRPII, PDMS, ERP, can be ensured with the standardized data models. The same

_application

will be extended to other areas of the

manu-facturing

industries to

_organize

their virtual

_enterprise

envi-ronment and _promotetheir

_{productivity.}

References

1. _{K. Hodota, "Product and information}

_life-cycle

with

_product

configuration

database system on Internet," in 21st

Century

Commerce & CALS EXPO International

Conference

’97, 1997.

2. A.

_McKay,

F. Erens, and M. S. Bloor,

"Relating product

defi-nition and

_product

_variety,"

Research in

_{Engineering Design,}

vol. 2, pp. 63-80, 1996.

3. O. A. Suarez, J. L. A. Foronda, and F. M. Abreu, "Standard based framework for the

_development

of

_{manufacturing}

con-trol

_system,"

International Journal

_{of Computer Integrated}

Manufacturing

System,

vol.

11,

pp.

401-415,

1998.

4. J. K. Wu, T. H. Liu, and G. W. Fischer, "An

_integrated

PDES/STEP based information model for CAE and CAM

ap-plications,"

in The Second International

_Conference

on

Auto-mation

_Technology,

1992, pp. 179-187.

5. Y. M. Chen and Y. T. Hsiao, "A collaborative data

manage-ment framework for concurrent

_product

_{and process}

develop-ment," International Journal

of Computer

Integrated

Manu-facturing System,

vol. 10, pp.

446-469, 1997.

6. R. Jordim-Goncalves et al.,

"Implementation

of _computer

inte-grated

manufacturing

systems

using

SIP: CIM case studies

us-ing

a STEP

_approach,"

_{of Computer}

In-tegrated Manufacturing System,

vol. 10, pp.

172-180,

1997. 7. Y. V. R.

_Reddy

et al.,

"Computer

support for concurrent

engi-neering," Computer,

vol. 26, pp.

12-16,

1993.

8. G. L. Smith and J. C.

_{Muller, "PreAmp—a pre-competitive}

project

in

_{intelligent manufacturing technology:}

an

architec-ture to demonstrate concurrent

_engineering

and information

sharing,"

Concurrent

Engineering :

Research and

Applica-tions, vol. 2, pp. 107-115, 1994.

9. F. Chaxel, E.

_Bajic

and J. Richard, "Mobile databases nodes for

_{manufacturing}

information management: a STEP _based

ap-proach,"

The International Journal

_of

Advanced

Manufac-turing Technology,

pp. 125-133, 1997.

10. I.

_Bailey,

P.

_Spiby,

and J.

Vuoskoski,

"Pilot

_{implementation}

of process

plant lifecycle

functional data

_{exchange conforming}

to

STEP AP-221, Part 2:

_Logical

&

_physical

data models," ES-PRIT-IV,

PIPPIN,

1997.

11. P.

_Spiby

and D. _Sanderson,"Introduction to EXPRESS 2," ISO SC4/WG10 Document N58, June 1998.

12. L.

_{Bernosky, "Turning legacy}

data into

_enterprise

informa-tion," in 21st

Century

Commerce & CALSEXPO International

Conference

’97, 1997.

13. D. An et al., "A

_product

data

_{exchange integrated}

structure

us-ing

PDES/STEP for automated

_{manufacturing application,"}

Computers

Industry Engineering,

vol. 29, pp.

711-715, 1995.

14. Y. Tanaka et al., "Product data

_sharing

_{among distributed} het-erogeneous PDMs," in CALS EXPO ’97 International, 1997. 15. S. D. Urban et al., "A

heterogeneous,

active database

architec-ture for

_engineering

data

_management,"

of Computer

Integrated

Manufacturing System,

vol. 7, pp. 276-293, 1994.

16. S. D. Urban, J. J. _Shan,and M. T.

_Rogers,

_"Engineering

data

management

archieving

integration through

database

technol-ogy," Computing

& Control

Engineering

Journal, pp.

119-126, 1993.

17. D. L.

_Spooner,

"An

_{object-oriented}

_product

database

_using

ROSE,"

Journal

_of

_Intelligent

_{Manufacturing,}

vol. 5, pp. 13-21,1994.

18. S. K. Ke and S. C. Yeh, "The

_pilot

_systemfor STEP-based

product

data

_exchange,"

in CALS/EC EXPO ’98

_Japan,

_pp. 197-206, 1998.

19. S. Rahimifard and S. T. Newman, "A

_methodology

to

_develop

EXPRESS data models," International Journal

of Computer

Integrated

Manufacturing System,

vol. 9, pp. 61-72, 1996. 20. R. N.

_Botting

and A. N. Godwin,

"Analysis

of the STEP

stan-dard data access interface

_using

formal methods,"

Computer

Standards &

_Interfaces,

vol. 17, pp. 437-455, 1995.

21. A. Goh et al, "A

study

of SDAI

_{implementation}

on

object-ori-ented databases,"

Computer

Standards &

Interfaces,

vol. 16,

pp. 33-43, 1994.

22. H. Scheder,

"Requirements

of car manufacturers for

_product

data _managementin an extended

_enterprise,"

STEP-Forum

97,

1997.

23. ISO, 1997, ISO 10303-214 CDII—Core Data for Automotive Mechanical

_Design

Processes, 1997.

24. B.

_Prasad,

Concurrent

_engineering

fundamentals, Vol. 2,

Inte-grated product

development, Upper

Saddle

_River,

N.J., Prentice Hall PTR,

1996-1997,

pp. 367-375.

(12)

60

Chun-Fong

You

Chun-Fong

You,

Associate Pro-fessor in the

_Department

of Me-chanical

_Engineering,

_{NTU, got}his Master’s and Ph.D

_degrees

from Cranfield Institute of

_Technology,

UK. His

_{professional specialties}

in-clude Solid Model

_Systems,

Com-putatioilal

Geometry

and the

Inte-gration

of CAD/CAM.

Shen-Chou Yeh

Shen-Chou Yeh received his Master’s

_degree

in Mechanical

En-gineering

from NSYSU. He is

cur-rently

a Ph.D student at the NTU

working

in the area of

_product

data

exchange,

sharing,

and

manage-ment

_using

STEP. His research

in-terest is in the

_enabling

_technologies

for STEP-based information

_system

and

_developing

and

_implementing

STEP-based

_{manufacturing}

indus-try standard in Taiwan.