NISTIR 88-3862

Information Resource

Dictionary System: An

Integration Mechanism

for Product Data

Exchange Specification

Howard Bloom, Cita Furlani, Mary Mitchell, Joan Tyler, and David Jefferson*

U.S. DEPARTMENT OF COMMERCE

National Institute of Standards and Technology

(Formerly National Bureau of Standards)

Center for Manufacturing Engineering

‘National Computer and Telecommunications Laboratory

Gaithersburg, MD 20899

October 1988

75 Years Stimulating America's Progress inj-m*
,
NISTIR 88-3862

Information Resource

Dictionary System: An

Integration Mechanism

for Product Data

Exchange Specification

Howard Bloom, Cita Furlani, Mary Mitchell, Joan Tyler, and David Jefferson*

U.S. DEPARTMENT OF COMMERCE

National Institute of Standards and Technology

(Formerly National Bureau of Standards)

Center for Manufacturing Engineering

‘National Computer and Telecommunications Laboratory

Gaithersburg, MD 20899

October 1988

National Bureau of Standards became the

National Institute of Standards and Technology

on August 23, 1988, when the Omnibus Trade and

Competitiveness Act was signed. NIST retains

all NBS functions. Its new programs will encourage

improved use of technology by U.S. industry.

U.S. DEPARTMENT OF COMMERCE

C. William Verity, Secretary

NATIONAL INSTITUTE OF STANDARDS

AND TECHNOLOGY

Ernest Ambler, Director

Information Resource Dictionary System:

an Integration Mechanism for

Product Data Exchange Specification

INTRODUCTION

This paper discusses the need for a mechanism that allows

various views of product data to interface with various

techniques for managing product data. The Information Resource

Dictionary System (IRDS) [ANSI Standard X3. 138-1988] is proposed

as an integration and configuration management mechanism for the

Product Data Exchange Specification (PDES)

BACKGROUND

The design of manufacturable products is an increasingly

complex process for industry. Advances in technology have

resulted in compartmentalized life-cycle product development

activities. This has led to the isolation of the product

designer from others participating in product development. Those

isolated from access to the designer are: (a) the sponsor who has

the need for the product, (b) the process planner who understands

how the product can be produced in the factory, (c) the

manufacturing manager who understands the operation and

performance of the shop floor equipment, (d) the quality

assurance inspector who understands how to measure the

functionality of the product, (e) the service engineer who is

responsible for repair and preventive maintenance of the product,

and (f) the reliability engineer who is responsible for tracking

the performance of the product over its lifetime.

At each stage of the life-cycle, important knowledge about

the product is acquired. Unfortunately, this information is

seldom available to staff working on other stages of product

development. Specifically, the designer may not understand the

impact of his design on the creation of a true ’world-class'

product — one built to minimum cost with highest quality and

greatest functionality, in the shortest time span. To integrate

the isolated activities of product development, more attention

needs to be paid to the information exchange that occurs during

the product life-cycle.

With sophisticated and ever evolving technologies, users of

product data are faced with the need to exchange information

across diverse and dissimilar systems. At the same time, these

users must maintain the various contexts within their organization and functional responsibility. ~ The - integration' of systems

as well as the integration of information within this technological heterogeneity is the "core" of the developing Product Data

1
Exchange Specification (PDES) . Recognition of the need to

organize the integration and exchange of this information has

resulted in a major effort within the PDES community to define an

architecture for this purpose.

TOPICAL MODELS

The PDES community has been seeking solutions to manage and

exchange information about products as opposed to the graphical

exchange of drawings of products. The IGES/PDES Organization,

the voluntary standards organization, has been developing the

product information descriptions (called conceptual models)

across a broad industrial base (e.g. mechanical, electrical,

etc.). These descriptions, some common to many industries and

some unique to particular industries, form a "core of

information" about products. As application activities are

defined, committees have been formed to formalize the necessary

information shared between product development activities. This

effort has resulted in conceptual models which provide the

framework for the product information to be exchanged.

When a consensus has been reached on an individual topical

model, the model is then voted out of committee as a draft

specification. The various models have then been considered for

integration, when they contain common information. The PDES

Integration Committee was formed to find the overlaps and

intersections between different applications. Identification of

the integration elements needed to connect individual application

models has resulted in a "core" model called the Integrated

Product Data Model (IPDM) . This model is used to describe how

the topical models can be merged into the complete PDES

conceptual model.

The urgency to produce a PDES standard that is useful to the

industrial community has forced the decision to define PDES as a

collection of versions. Each new version enhances the product

data definition available in the previous version. In addition,

each new version will expand the scope of PDES to incorporate

more life-cycle activities. As these versions are released, the

techniques for representing the conceptual models may vary

because of the new complexity and richness of the specified

information. In addition, only the later versions will specify

sufficient product data to allow database and knowledge base

implementations to be efficiently built.

A conceptual model contains the fundamental objects and

concepts managed by an enterprise. The conceptual model also

depicts the relationships among the fundamental data objects of

the enterprise. Fundamental data objects are combined to create

useful collections of data which are subsets of the conceptual

model, called external views. An "external view" consists of

2
user-specific data and the structural organization of that data.

The procedures for creating the collections are unique recipes or

instructions for manipulating the fundamental data. These

procedures require management in their own right. They are not

part of the conceptual model. The rules for deriving external

views are user-specific and unique to each application.

Since the conceptual model includes all the important facts

about an enterprise, it can be thought of as a detailed

"database" containing vital constructs which can be extracted and

viewed in various ways. Extracts can provide a mechanism to

validate the content and intent of the conceptual model.

Once the first sharable topical product models were

generated and integrated, the PDES group had to consider the

following technical issue. How could the product model be

represented in a totally unambiguous manner? The answer was to

represent the information using a database design technique

called "data modeling." The various PDES application

subcommittees then implemented the specific topical data model in

a variety of data modeling formats. This caused a problem at

integration, as different data modeling techniques were used by

different application subcommittees. As with all technologies,

there are a range of tools, each of which is best for solving

specific problems. Improved and extended data modeling

techniques, as well as the tools to implement them, will continue

to appear in the future. Because PDES will be an ever evolving

standard, it is appropriate to allow the different topical data

models to be defined using a variety of data modeling techniques.

To be able to tolerate and integrate multiple modeling

techniques, a mechanism is needed for transferring specific data

models between the competing data modeling techniques. An ideal

candidate for this mechanism is a "data dictionary system" that

can save the product data model in a neutral specification.

Using a data dictionary system as this mechanism, it is then

necessary to implement only one pair of translators for each data

modeling technique. This allows for the translation of one data

modeling representation into the neutral format, and the

translation of the neutral format back into another data model

representation. The data dictionary system also becomes an

effective and efficient configuration manager for the development

of the IPDM.

PRODUCT DATA MANAGEMENT

The IPDM, resulting from the integration of the merged

topical models, abstractly defines the way in which the product

data elements^ interrelate. -In addition,^the - "physical level"

defines the way the actual product data is represented, organized

and stored (such as on a disk or in memory) . [Figure 1] The PDES

3
community is currently defining levels of implementation for

PDES . These levels define the "road map" for how product lifecycle activities (e.g. design, process planning, etc.) will

interface to the PDES implementation.

This leads to the second major issue: the development of a

mechanism that can manage the enterprise data and data semantics

for use in PDES implementations. This information management

capability can be supported by a data dictionary system that has

adequate functionality. The data dictionary system must be able

to interact with a variety of data storage techniques, such as

relational databases, file systems, object oriented databases,

etc. The data dictionary system must be able to describe the

data structures (e.g. strings, numbers, dates, tables, geometric

entities) that exist in the product information representation

and be able to cross-reference the associations among these data

structures. This PDES information must then be accessible to the

life-cycle systems through a neutral language that may be dependent on the level of implementation but should not be dependent

on the actual system implementation (i.e., the language of a

given relational database management system (DBMS) or file

management system)

APPROACH

The storage and management of all the components of PDES

development information in one logical, standard, data dictionary

system is the cornerstone for automation and reusability in the

future. Such a data dictionary system is required to manage the

numerous PDES topical and application models, model integration,

the validation process and the necessary documentation.

The Information Resource Dictionary System (IRDS) standard

being developed by the American National Standards Institute

(ANSI) and the National Institute of Standards and Technology

(NIST) can meet this need. The IRDS can be used to identify and

control all of the "pieces" that make up PDES and to evaluate the

effect of needed changes that will occur as the PDES standard

emerges. With the use of the extensibility feature, the IRDS

provides a stable platform for development and maintenance even

when the underlying technology is changing. [Figure 2]

The IRDS can support system integration by merging development and maintenance tools into one environment. PDES development requires the use of data modeling tools, data dictionaries,

DBMS, and, eventually, knowledge base systems to support all its

functions. Commercial and public-domain products exist in all

these areas. They can be easily obtained, but not easily

interfaced. The IRDS* can provide the mechanism by**which these

tools can be interfaced and replaced as new technologies emerge.

4
The IRDS can support the 3 -schema architecture (i.e., the

external view of the user, the logical conceptual model, and the

physical or implementation view of the internal model) . [Figure

3] Another way to visualize the three-schema architecture is as

a 3-dimensional space, with the three axes representing use,

processing and universality. Each of the three schemas

external, internal and conceptual — can be represented as a

point in this space. The major component of each of the schema

points projects on a different axis: external projects on the use

axis, internal projects on the processing axis, and conceptual

projects on the universality axis.

This architecture permits the relationships between levels

to be independently defined, permitting some changes to be made

to the specifications at one level without affecting the specifications at the other levels. Major changes, such as expansion

of scope, discovery of additional relationships, etc., will

impact all levels. Therefore, it is important to know how each

level is with the other through cross-referencing relationships.

The IRDS is the only recognized information management standard

in this area.

The IRDS provides a basic Functional Schema which directly

supports much of the information that an organization needs to

keep about implemented software systems. For example, the

ability to describe the data elements that make up a record and

how records are organized into a file is part of the IRDS BAsic

Functional Schema. Further, the IRDS provides a general schema

extensibility mechanism for tailoring and adding types of

information resources that need to be managed within an

organization. Schema extensibility is provided since the IRDS

does not intend to describe all of the types of resources that

enterprises may need to manage with a data dictionary. What is

provided by the standard is a schema with a minimum set of

information resource types, to be used as an example, along with

building blocks for extending the schema to meet each

organization's needs. It is this extensibility feature which

makes the use of IRDS so attractive.

What are the major categories of product data information

resources that must be managed if the full potential of an

information resource dictionary is to be realized for PDES? PDES

information resources can be grouped into three categories:

1) implemented systems and data organizations,

2) conceptual models and business rules, and

3) data usage and external views of data.

If the data types provided by the IRDS Basic Functional

Schema are examined, most of -them fall within - the^fdrst category

of information resources. The IGES/PDES Organization has spent

almost all its effort defining the second category of resource

5
types. Major efforts are still needed in the third category to

define industry and activity specific views of PDES or application protocols.

To be a more complete and effective tool for the PDES

community, the IRDS schema structures must be modeled with an

Information Resource Dictionary (IRD) to store and access the

conceptual IPDM. The schema of this IRD must be extended to

capture and document the meaning of the entities, relationships

and attributes which comprise the integrated conceptual model.

Once a neutral conceptual model is developed, the IRDS can

be used to effect change control over existing applications and

databases. Currently, IRDS provides facilities for recording,

storing, and processing descriptions of data. It can create and

store schemas for all types of data management systems. Thus,

application programs will not need to incorporate the schemas

into their code; programs can obtain the necessary information

from the IRDS, resulting in a true data-driven system. The PDES

dictionary can also serve as the access control point for all

current models. The activities described below provide directions to pursue to support specific PDES needs. We are not

attempting to address more general problems.

ACTIVITIES

1. Build a schema for a PDES Information Resource Dictionary,

using the IRDS schema extensibility feature to support the

storage and management of the diverse conceptual models built by

the PDES committees.

The extensibility feature of IRDS will be used to define a

set of information resource types, called metatypes, which

correspond to each of the fundamental constructs found within

the conceptual modeling techniques used by PDES. This new

schema definition will allow IRDS to support the storage and

retrieval of conceptual models. Automatic dictionary loading

and version-controlled updates must be added to the existing

IRDS prototype to support management of the conceptual

models

2 . Extend the PDES Information Resource Dictionary schema to

support a full three-schema architecture, and populate the IRD

with PDES information.

Initially this repository will hold the conceptual models,

supporting entity definitions, and scoping statements, as

well as related, but unresolved, issues. The IRDS Basic

Functional Schema supports only information * describing the

internal schema, specifically physical databases and files,

computer hardware, and user profiles. Therefore, the PDES

6
IRD schema will be expanded to support a full three schema

dictionary. When application subsets, testing criteria, test

cases, and implementation guidelines are developed, the PDES

dictionary can then be populated with relevant information.

This will permit evaluation of the effects of changes and

expansions in the PDES standard. These resources can then be

brought into alignment with the standard.

3. Develop automated or assisted translation between diverse

data models and represent these data models in the IRDS

.

There are three types of data models being produced by PDES

activities. PDES Version I will contain both EXPRESS and

IDEF1X, two types of data models. In addition, some

committees are formalizing their work in NIAM, a third type.

A NIAM model must be translated into both IDEF1X and EXPRESS

before it can be incorporated into the PDES standard.

Equivalent concepts between these models must therefore be

identified and formally represented to ensure that the

different types -are consistent. Translating these data

models into the IRDS can provide PDES with a unified

representation of this information, and permit consistency

checking among the data models.

4. Interface the PDES Information Resource Dictionary to

available software.

The IRDS provides for integration between data modeling

tools, database and system design aids, and application

development. As the repository for dictionary metadata

describing functions, data, and objects that compose an

application, the IRDS becomes the key integration tool for

PDES application development. In addition, it provides the

IRDS Export/Import Facility to control moving IRD schema and

metadata definitions from one site to another. The IRDS

Export/Import Facility is currently under development at

NIST.

4.1 Utilize conceptual modeling tools.

These tools are used in the requirements analysis and system

design phases. They provide quality controls in the

definition of both data models and functional design. Most

will also generate a prototype database schema in one or more

relational data definition languages. Most also have an

interchange form. This interchange form is the most likely

method for interfacing these tools to the IRDS. No

standardization efforts are active within ANSI to develop a

standard conceptual modeling language that could be used for

this purpose.

7
4.2 Support IRDS information interchange with DBMS.

DBMS provide a general purpose capability for storing,

accessing, and managing actual instances of data. The

Structured Query Language (SQL) standard and the Network

Database Language (NDL) standard are expected to be the first

of the DBMS related standards to be interfaced to the IRDS

standard. Remote Data Access (RDA) , an International

Organization for Standardization (ISO) standards effort, is

not yet mature enough for an interface to IRDS to be

designed. RDA also supports less capability than a

distributed PDES database implementation needs. However, ISO

has done enough work in the distributed area to identify the

minimum information requirements that a data dictionary/directory must manage to support this distributed aspect. The

IRDS Service Interface, which is currently under review, is

an addendum to the IRDS standard that will support the use of

the IRDS in an active mode. The Services Interface is

expected to be formally accepted as part of the IRDS standard

in 1990-91.

5. Develop Relationships to Physical Design.

The PDES organization is not heavily concerned with how PDES

is physically implemented because many of these issues fall

under the domain of implementors. There are aspects of

physical design, however, that must be managed to maintain

consistent versions of PDES; PDES will produce an exchange

format and testing suites which must conform to the

conceptual models defined in the standard. Therefore the

elements of the conceptual models must be associated with

those of the exchange format and testing libraries. Further,

there must be an ability to document the decisions made in

the physical design of these modules and to detect changes

required to keep these modules consistent with newer versions

of PDES. These types of cross-referencing information can be

captured and stored in the IRDS.

8
GLOSSARY

Application Model

A data model which addresses the information requirements

for a specific industry or vital - business - objective such as

electrical design or structural analysis.

Conceptual Model

An abstraction of the real world that conveys the concepts,

meaning and semantics of information for an organization. It

forms the basis for a dialogue between systems and users and is

based on a common understanding of the information it represents.

Data Attributes

Properties of product data which describe the data objects.

Data Dictionary

A repository for data definitions, system documentation,

data representations, and requirements descriptions of

information managed within the automated or manual systems of an

organization. This resource is then available over the lifecycle of developing and existing systems.

Enterprise

May be a corporation, a unit or division of a corporation,

government unit, or group of cooperating organizations, etc.,

which is the source or owner of information.

External View

That set of information which is sufficient to support the

performance of a particular function or business objective.

Fundamental Constructs

Defines the basic constructs used to create the data model.

Each data model technique will have a set of primitive elements

that are used to formally describe an actual data model.

Heterogeneity

Use of dissimilar computer hardware and software in support

of a common objective.

9
Implementation Model

A design of the data organization for a system. For database

systems this would be a database schema in the definition

language of the database management system selected to implement

the system. For- applications, this would be * the data structures

in the computer language used to write the application and for

object oriented systems, this would be the object class

definitions

Integration

The process of merging together independently developed

models into a cohesive and consistent model which reflects a

common understanding of information resources used within an

enterprise.

IRD Data Layer

The layer of the information resource dictionary that

manages the actual descriptions of information resources.

IRD-IRD Interface Facility

A method of exchanging information resource dictionaries to

additional sites which may have processing responsibilities.

IRD Schema Description Layer

Provides the basic framework on which to build the types of

information resources to be managed within an information

resource dictionary.

IRD Schema Layer

Defines the types of information resources to be managed

within an information resource dictionary; these are called

metatypes

IRDS

The Information Resource Dictionary Standard is a draft

proposed ANSI and FIPS data dictionary standard.

Knowledge Base

A system which is capable of persistent data management and

can actively enforce the business rules defined against the data.

A knowledge base is capable of evaluating requested functions and

performing constraint checking on the data. -—• i

10
Level I Implementation

A passive file interchange implementation of PDES.

Level II Implementation

An active file interchange implementation of PDES.

Level III Implementation

A database implementation of PDES.

Level IV Implementation

A knowledge base implementation of PDES.

Life-Cycle

The distinct phases into which every system may be divided

such as requirements, design, implementation, production, and

maintenance. Each phase may require different support from the

data dictionary which is used to administrate it.

NDL

The Network Database Language is the ANSI standard for data

definition and access for network databases.

Physical Design

The process of evaluating an implementation model or design

and factoring in performance characteristics and data access to

optimize the design.

PDES

Product Data Exchange Specification is a developing standard

which will provide for the unambiguous interchange of life cycle

product data from concept, to engineering design, to manufacture,

and to support.

RDA

The Remote Data Access protocol is an ISO standards activity

which is developing a standard for distributed system access.

SQL

The Structured Query Language is the ANSI standard data

definition and access for relational databases.

11
Topical Model

A data model which incorporates the requirements of many

users into a data model of limited scope. The scope defines the

topic of the data model (e.g. geometry data model)

12
cn o

Figure
co J2 O <y

II

U)ommm o >

CD

O ~

s: >* o

-i o < c

a>E o fl>

"D co SH

Son

Q.

Q S
ENTERPRISE

STRUCTURE

0-0

u w u

eu < cu
NBS-T14A (rev. 2-bo

U.S. DEPT. OF COMM.

BIBLIOGRAPHIC DATA

SHEET (See instructions)

1. PUBLICATION OR

88-3862

2. Performing Organ. Report No. 3. Publication Date

OCTOBER 1988

4. TITLE AND SUBTITLE “ “

Information Resource Dictionary System Applications (IRDS) : An Integration

Mechanism for Product Data Exchange Specification (PDES)

5. author(S) Howard Bloom, Cita Furlani, Mary Mitchell, Joan Tyler, David Jefferson

6. PERFORMING ORGANIZATION (If joint or other than NBS, see in struction s) NATIONAL BUREAU OF STANDARDS

U.S. DEPARTMENT OF COMMERCE

GAITHERSBURG, MD 20899

7. Contract/Grant No.

8. Type of Report & Period Covered

9. SPONSORING ORGANIZATION NAME AND COMPLETE ADDRESS (Street. City. State, ZIP)

10.

SUPPLEMENTARY NOTES

| | Document describes a computer program; SF-185, FlPS Software Summary, is attached.

11.

ABSTRACT (A 200-word or less factual summary of most significant information. If document includes a significant

bibliography or literature survey, mention it here)

With sophisticated and ever evolving technologies, users are faced with the need to

exchange information across diverse and dissimilar systems. At the same time the users

must maintain the various contexts within their organization and functional responsibility. The integration of systems as well as the integration of information within

this technological heterogeneity is the "core" of product data exchange specification.

The need to organize the integration and exchange of this information has been

recognized.

A way to store and manage all the components of PDES development in one logical, standard, dictionary system is the cornerstone for automation and reusability in the future.

The complexity of the integration task, the validation process, the numerous topical

and application models, and the necessary documentation, require the use of a dictionary

tool to manage and track the model integration stage of the PDES life cycle. The

Information Resource Dictionary System (IRDS) standard being developed by ANSI and NEST

can> meet this need. The IRDS can be used to identify and control all of the "pieces"

that make up PDES and to evaluate the effect of needed changes that will occur as the

PDES standard emerges.

12.

KEY WORDS (Six to twelve entries; alphabetical order; capitalize only proper names; and separate key words by semicolons

)

CAD, Computer Integrated Manufacturing, conceptual models. Data Dictionary,

data modeling, factory automation, IRDS, PDES, product data, product data exchange

13.

AVAILABILITY 14. NO. OF

PRINTED PAGES

(_Xl Unlimited

f" 1 For Official Distribution. Do Not Release to NTIS

1 Order From Superintendent of Documents, U.S. Government Printing Office, Washington, D.C.

20402. 15. Price

FX! Order From National Technical Information Service (NTIS), Springfield, VA. 22161 $9.95

USCOMM-DC 6043-P80