An extensible AE&C database model

Computers them. Engng, Vol. 13, No. 7, pp. 753-766, 1989 Printed in Great Britain. All rights reserved

cimi354/89 s3.00+0.00 Copyright 8 I989 Pergamon Press plc

AN EXTENSIBLE AE&C DATABASE MODEL

M. R.BLAHA GE Corporate Research and Development, P.O. Box 8, Schenectady, NY 12301, U.S.A.

and

N.L. EASTMAN and M. M.HALL Calma Company, San Diego, CA 92121, U.S.A.

(Receiued 4 April 1988; final revision received 5 December 1988; receivedfor publication 18 January 1989)

Abstract-Database management technology can improve the quality and reduce the cost of process design and project management. This is accomplished by letting the computer handle the rote work of translating and transmitting data between programs. Engineers concentrate on the quality of the underlying design. This paper partially addresses the issue of how chemical engineering programs go about using a database.

I. INTRODUCTION

Computer programs are an indispensable part of modem plant design and construction, boosting the productivity and quality of engineering work. But the success of engineering computing has spawned a secondary problem. Up to 60% of an engineer’s time is now spent on handling program data (Cherry et al., 1982; James, 1985). Each application is an “island of automation” which does not communicate or cooperate with other applications. Integration of these stand-alone programs would further increase the effectiveness and productivity of process and project engineers (Motard et al., 1983; Motard, 1988; Patakas er al., 1988). Let the computer manage the details of storing information and provide the correct format for each program.

The computer science solution to this engineering problem is a data base management system (DBMS). A DBMS is a computer program for managing a permanent repository of data, called a database. The database is stored in one or more files and is shared by many users and many application programs. Current DBMS are business-oriented and do not fully satisfy engineering needs (Buchmann, 1984; Gadient, 1985; Powell and Linton, 1983; Vernadat and Henneker, 1985). But there has been substantial progress in engineering DBMS research (Lorie and Plouffe, 1983; Snodgrass, 1987; Stonebraker and Rowe, 1986) and the engineering community can look forward to more. The awareness of special engineering requirements and the emergence of better DBMS standards (Date, 1987) are encouraging signs.

IBM’s Lorie and Plouffe (1983) succinctly sum- marize the motivation for using a database. “First, designs are increasing in both size and complexity with the result that the management of the data is

becoming a major problem for some design systems. Second, the state of the art in database systems has evolved . . .”

Other disciplines are also recognizing the need for proper data management. Chu et al. (1983) describe a Bell Laboratories’ project for integrating VLSI design software. They view a database as “an effective way to ensure compatibility of tools and consistency of design.” A database-driven system can easily assimilate new tools. Only one database interface must be written for a new tool, and then all the other integrated programs can benefit.

This paper lays the foundation for applying database technology to process and project engineering with an AE&C data model. The term “AELC!” is an acronym for “architecture, engineering and construction” and is commonly used to refer to the chemical processing and allied industries. A data model defines the structure of a database and is the first step towards using a database in an application. This data model does not encompass the full scope of process and project engineering, but it is a useful starting point and can be readily extended. This data model is part of an ongoing effort by Calma to integrate its software.

2. OVERVIEW

Figure 1 presents an overview of this paper’s AE&C data model. The focus of the model is the “plant”. A plant is a manufacturing facility with some combination of equipment and piping. A plant can be a refinery, ship or electric power installation. A plant can be used for continuous or batch processing. For now, please approach Fig. 1 intuitively. Section 3 will formally define the methodology.

753

754 M. R. BLAHA et al.

Fig. I. Overview of AE&C data model

Plant data divides into four major areas: equipment, piping, diagram and simulation. A small amount of information (not shown in Fig. 1) inter- relates the areas. Plant data is organized by function and not by program. Thus an application program may store information in several areas. For example, a P&ID program would store equipment. piping and diagram data. The modular structure of the data model facilitates addition of new functionality and integration of new programs.

The equipment and piping areas form the core of the model and directly relate to the physical plant. The equipment model stores details for each piece of equipment, such as design conditions, physical geometry, materials of construction, location, weight and cost. There are many different types of equipment and much data for each type. The piping model stores the piping layout, i.e. the design specifications, connectivity and location for each elbow, pipe, tee, reducer and other components. The information in the equipment and piping areas is of sufficient detail for constructing data sheets.

The diagram model is a view of the physical plant. The diagram model is a “view” because it stores both meaningful and trivial information. Connectivity and process control settings are important data. The precise location of symbols on a sheet is superfluous. The diagram model includes PFDs (process flow diagrams), P&IDS (process and instrumentation diagrams) and 3-D piping drawings. These drawings refer to the equipment and piping areas. For instance, when one places a symbol on a diagram, the database must remember that the symbol corresponds to a piece of equipment.

The simulation segment of the AE&C data model stores another view of the plant--a mathematical model. This area stores physical properties, process simulator input and output and process economics. Once again, there are references to the physical equipment and physical piping. The simulation model

in this paper is intended for continuous processing; a different simulation model would be required for batch processing. The simulation model in this paper lacks the parameter of time that batch processing associates with stream composition, pressure and temperature and equipment operating conditions.

Sections 447 will further explain the data model, but first, Section 3 will digress and review the modeling methodology.

3. A BRIEF REVIEW OF THE OBJECT MODELING TECHNIQUE (OMT)

3.1. Why an objeci -oriented data model?

Modern software engineering emphasizes that one should consider the complexities of a problem before committing to computer code. In other words, one should thoroughly design a program before beginning implementation. This rule also applies to the task of using a DBMS.

DBMS have a special data definition language (DDL) for defining database structure. For small applications. like those found in textbooks, it is reasonable to directly write DDL code. Most real problems are large and complex and require a more formal design, i.e. a data model. The DDL is at too low a level for conceptual thinking. Ideally, one would like a graphical data model. People can absorb information more efficiently when it is presented in graphical form. The data model must easily trans- form into DDL statements.

When beginning work on the AE&C data model, the authors had no bias towards any specific data modeling approach. The authors considered several options and ultimately decided to adopt the Object Modeling Technique (OMT) developed by Loomis et al. (1987). Non-DBMS AE&C experts were able to understand OMT diagrams after a few hours of explanation. OMT diagrams proved to be a valuable tool for stimulating and documenting design discus- sions. The OMT encourages the kind of evolutionary development that often occurs with complex engineering problems. Figure 2 shows a small OMT diagram and the corresponding DBMS DDL code.

This paper will limit its review of the OMT to the essentials. This paper will confine its attention to relational DBMS and exclude hierarchical and net- work DBMS. Relationa DBMS have a better theoretical foundation and are gaining wide acceptance. A relational database is perceived by the user as a collection of tables. Each table has a specific number of columns called attributes and an arbitrary number of rows.

3.2. Objects

OMT diagrams deal with objects and relationships. Webster’s dictionary defines an object as “a thing that may be seen, touched, or thought about.” An object is a concept, abstraction or thing with crisp boundaries and meaning for the problem at hand.

Extensible AE%C database model 755

Tables are populored by application p~Og?Yl*

L

DDL code

Cnsate table Utility (utility_lD ID not null.

utility_name cbar(40) not nd, Primary key (udlity_lD))

CITZSIC table Utility_consumption (.equip_ID m MI null.

utility_lD ID ML null. quanrity real, Rimary lrey (cqtip_ID))

wip-m ! cost 1 weight

Populated tables

Fig. 2. The data modeling process

Purification feed pump, reactor feed preheater, and the most recent simulation run are objects. A group of similar objects form an object class. Pump, heat exchanger and simulation run are object classes. OMT diagrams denote classes with heavy line boxes. Objects and classes are described by fields, such as cost, discharge pressure and diameter. Equipment and Utility at the top of Fig. 2 are examples of object classes. Class names are shown in the top of the box; field names are listed in the bottom.

3.3. Relationships

A relationship is a logical binding between objects. There are three types of relationships: association, aggregation and generalization. The OMT indicates a relationship with lines between object classes.

Special symbols at the ends of a relationship line indicate how many objects of one class relate to each object of another class. This is called the multiplicity of the relationship. A small solid circle means many. Many, in this context, is zero or more. A small hollow circle means zero or one. A straight line ending without a symbol denotes exactly one. Thus a many- to-many relationship, like that in Fig. 2, has a solid circle on each end of the relationship line.

Association is the most general type of relationship. An association relates two or more independent objects. Utility consumption in Fig. 2 is an association. Each piece of equipment consumes many utilities. Each utility is consumed by many pieces of equipment. Equipment and utility are distinct classes that interact. A heat exchanger may consume steam and produce condensate. Steam is consumed by many exchangers, perhaps a reactor, and live steam distil- lation columns. Associations may have properties, which are circled.

The top part of Fig. 2 describes database structure; the bottom part of Fig. 2 contains data. When defining database structure, one states that equipment and utility have a many-to-many association called utility consumption that is described by quan- tity consumed. Application programs load the actual data. For example, the purification feed pump costs $10,000 and weighs 250 lb. The reactor feed preheater costs $30,000 and weighs 5000 lb. Condensate has units of gal min-‘. The bottom table contains in- stances of utility consumption. The reactor feed preheater (4906) consumes 10 MB. t.u. h-l of 50 lb steam (0123). The reactor feed preheater produces 20 gal min-’ of condensate (6292).

756

Fig. 3. Aggregation relationships

Aggregation combines low-level objects into composite objects. Aggregation is often referred to as an assembly-component or “a-part-of” relationship. Aggregation often occurs in bill-of-materials or parts explosion type of problems. As shown in Fig. 3, a frame is a part of a motor; a shaft is a part of a motor; and many bearings are a part of a motor. Arrows point towards the composite object.

Generalization provides hierarchical structure for classes. Generalization partitions a class into mutu- ally exclusive subclasses. The triangle in Fig. 4 is the QMT symbol for generalization. In this example, a piece of equipment may be a pump or a tank. The equipment object class stores general information. Pump and tank store specific information. Each pump has a name, cost, weight, suction pressure, discharge pressure and flowrate. Generalization may have an arbitrary number of levels. Thus one may further refine pump into centrifugal pump, dia- phragm pump and plunger pump. Each level of a generalization represents one aspect of the same object. An object simultaneously exists at each level of a generalization hierarchy. The equipment type field next to the generalization triangle is the discriminator field which indicates the appropriate subclass for each superclass object.

There is one more concept to introduce- guaiijication. Qualification is a special attribute which

equipment type

Fig. 4. Generalization relationship.

(a)

NOT QUALIFIED

adds information about the many end of an aggregation or association. Qualification reduces the multiplicity of the many end of a relationship. In Fig. 5a a plant has many pieces of equipment. Figure 5b adds the fact that the pieces of equipment are distinguished by name. “Equipment name” in the small box is the qualification field. Both Figs 5a and b can store and retrieve equipment data. The qualified form captures more semantics and highlights the navigation.

3.4. Converting OMT diagrams into DBMS com-

The following principles guide conversion of OMT diagrams into DBMS DDL commands. Figure 2 and Section 8 provide examples. For a comprehensive explanation, please see Blaha et al. (1988). Remember that there will always be some exceptions to these rules.

I.

2.

3.

4.

Create a table for each class. Object fields become table attributes. Each class must have some combination of fields, such as a name or location, through which the user can find an object. Define an ID (an integer) as the primary key for every class table. A primary key uniquely identifies each row in a table and has special theoretical meaning. Do not create a table for generalization relationships. The generalization discriminator becomes part of the superclass table. The discriminator assigns a subclass table to each superclass row. The superclass and subclasses share a common primary key. Create a table for all aggregations and associations with many-to-many multiplicity. For other aggregations and associations, creating a table is optional and a matter of taste. Relation- ship properties become table attributes.

(b)

QUALIFIED

Fig. 5. Aggregation relationships.

Extensible AE&C database model 757

This paper observes the following convention. A relationship is named, if and only if it maps to an explicit DBMS table. Choose some combination of participating object IDS as the primary key of each relationship table. The precise combination depends on multiplicity. Add comments, enclosed in angle brackets < >, to express information which is awkward with OMT syntax. Add DBMS details that OMT diagrams may not specify, such as data type. Add DBMS statements to tune performance, such as indexing and hashing.

At the time this work was performed, the authors manually converted OMT diagrams into DDL commands. Since that time, Premerlani (1988) has automated the conversion process. The input to the conversion software is OMT diagrams; the output is DDL statements. Primitive objects (circles, boxes and text) are drawn with an ordinary graphics editor. The graphics editor dumps drawings in an ASCII markup language that the conversion software then reads. The software has several intermediate iayers and eventually builds up to the OMT abstraction of classes and relationships. Thus OMT diagrams represent not only a valuable design documentation, but a live, active form of database structure. Operations on OMT diagrams directly correspond to operations on the database structure.

4. EQUIPMENT MODEL

Figure 6a provides the context for equipment. The highest level object is a site. A site consists of many plants which are distinguished by name, such as ethylene plant or acrylonitrile plant. A plant sub- divides into sections. Each section has a primary function, such as feed pretreatment, waste-water cleanup or purification. If a section default material of construction is specified, it overrides the plant default. Similarly, an equipment specification would override the section default. Each section has many pieces of equipment. Equipment has nozzles that can connect to piping. A site supplies basic utilities like steam, electricity and condensate that equipment may consume. (Negative consumption is permissible.) People approve equipment designs.

A large design cannot fit all classes and relationships on a single piece of paper. So one needs a mechanism for decomposing large OMT designs into multiple sheets of paper. One approach is to put part of the complete design on each piece of paper. Each relationship appears on a single page; classes may appear on multiple pages. Duplicate class boxes bind together the separate pieces of paper. An ellipse next to a class box indicates that the class is duplicated on other pages. Figures 6-9 use ellipses to relate equipment, piping, diagram and simulation data to each other.

Figure 6b stores equipment details. The equipment object class contains general information. The generalization subclasses store specifics for each type of equipment. Figure 6b lists some heat exchanger fields. The full model would have more types of equipment and additional fields.

This data model accommodates both standard and custom equipment. Most equipment is standardized. The basic design of pumps, heat exchangers and tanks do not vary from one process to another. Each standard equipment type has its own subclass table.

A small, but critical, portion of the equipment in a plant is custom designed. This type of information does not easily fit into rigid, predefined tables. For example, chemical reactor design may vary radically from one process to another. The Mist equipment table captures custom equipment data as (equipment, property name, value> triplets. Equipment properties are defined once per plant, for reasons of efficiency and security. Equipment properties may be defined at any time during the lifetime of the database.

Another benefit of automated data management vs the conventional paper-based approach is that one can readily manage meta-data, or data about data. For each piece of data, the model tracks the source, timestamp and confidence level.

The last major contribution of Fig. 6b is units of measurement. Conventional DBMS ignore units of measurement. This data model circumvents this limitation. Each type of equipment and each plant has a set of units. Thus, heat exchanger tube length may be in feet and heat exchanger tube diameter may be in inches. This approach stores plant data in consistent units, despite differences between the various application programs. This approach does not consume much database space, since units are defined at the plant level. A U.S. plant can use Imperial units; and another designed in Europe can use metric units.

5. PIPING MODEL

Figure 7a summarizes piping structure. A site has many dedicated piping systems, such as styrene process organics, 250 lb steam and waste-water. Piping systems and plants have a many-to-many relationship which is captured indirectly through the site. A piping system, such as steam, may pass through many plant boundaries. Plants require multiple services. A piping system is built from piping components. Some components are preassembled into spools. Other components are installed at the construction site. Each piping component and spool belong to exactly one plant. (The piping between plant boundaries is arbi- trarily assigned to the “utility plant”.) One may associate a piping component with a particular section or sections of a plant.

Piping components have pipe nodes for connection to another pipe node or equipment nozzle. A straight

._

She

site

nam

a bc

attt

n ne

ma

Pma

tunc

tion

1 7

de&l

ma

ll Of

con

stnlc

1 equ

ipm

ent

nam

e ]

MIS

C

equip

ment

3 Ivaiw

i%;:

data

sou

rce

times

tam

p co

nfid

ence

level

suda

ce

area

tu

be dh

eter

hI

be te

llgtti

tu

be pr

essu

re

shel

l pres

sure

Fig.

6a.

AE&

C da

ta m

odel

---e

quip

men

t mod

el

< For wch Eq

uipment and H~cxhngerfield sloie I metl.&a

a ICh

nCC

10 aa

la so

urce

tiSI

, limeslamp,

and

c~lfi

&ncc

te

vct. ,>

Fig.

6b.

AE&

C da

ta m

odel

-equ

ipm

ent m

odel

.

Extensible AE&C database model

Fig,

8a. A

EW

C data

m~e

l~ag

ram

m

odel

, Fi

g. 8b

. AE

&C

data

mod

el-d

iagr

am mod

el,


unit

op ty

pe

P--

l uo

heat

‘R

ex;J

U c

0eHi

cien

l su

ff ace

are

a

I UO

heat

ex

chan

ger

u co

eniiie

til su

dace

area

tu

$ fg

sish&

ll

shei

pres

sure

tu

ba pl

essu

re

shel

l pres

s drop

lub

e pr

ess

drop

du

ty.

coox

&w&e

r fk

‘

< ,’

Only

1 un

it opem

km @

t er

chm

ngc)

is s

hown

in th

is d

iapa

m.

in p

mcu

ce ab

out 5

0 ur

u~ op

era~

~aor

woul

d be

requ

ired.

>

Fig.

9b.

AE&

C da

ta m

odel

--si

mul

atio

n mod

el.

Fin g

Stre

am

?

< Ea

ch co

mpo

und f

or S

wam

com

pxiti

on m

usk b

e m

Sim

ulat

ion c

ompo

und li

st.

Each

phas

e for

Sm

xm @

se m

ust b

e in

Sim

ulab

ph

ase h

st

>

Fig.

9~.

AE&

C da

ta m

odel

-sim

ulat

ion

mod

el.

7


pipe has two nodes, one at either end. A tee has three nodes. People approve piping component designs.

Figure 7b models piping component details. The piping component object class contains general information. Elbow, pipe, tee and reducer store specific information. This model accommodates unusual piping component designs, with a miscellaneous subclass. Miscellaneous data decomposes into <piping component, property name, value> triplets. Miscel- laneous properties are defined once per plant. For each detail, the model stores meta-data: source, timestamp and confidence level.

6. DIAGRAM MODEL

Until now, this paper’s discussion of the AE&C data model has been general in nature and not influenced by any one software package. The diagram model is less general and reflects a bias towards the architecture of Calma’s products.

Figure 8a defines icons. An icon is a picture that represents a piece of equipment or a piping component. Icons group into libraries; a diagram may use several libraries. Pipelines connect to icons at discrete locations called connect nodes. When the user draws a pipeline, the end tends to snap towards the nearest connect node.

Figure 8b documents diagram structure. A plant has many P&IDS, PFDs and 3-D piping diagrams. Diagrams are composed of sheets and pipelines. A sheet corresponds to one piece of output paper. People must officially approve diagrams and sheets. A pipeline is a series of icons that denote piping components. Diameter, schedule and material of construction are not necessarily uniform for a pipeline. Pipeline breakdown divides a pipeline into pieces with uniform properties. Sheet and pipeline have a many-to-many relationship. A sheet contains many pipelines. A pipeline can span multiple sheets. Each sheet has many symbols which are also represented by icons.

Figure 8c relates diagram primitives to each other and the physical plant. Symbols have a many-to- many relationship with themselves. For instance, a temperature controller may bypass flow around a heat exchanger. A symbol usually represents one piece of equipment, but there are exceptions. A graphic-only symbol does not represent any piece of equipment. Some diagrams, especially PFDs, do not show all equipment. A symbol’s connect nodes are associated with pipeline breakdowns. Pipeline breakdowns and their implied direction of fluid flow are indicated with a sequence number. Pipeline breakdowns are placed on sheets. A pipeline breakdown may connect to another pipeline breakdown on a sheet (the diamond indicates a ternary relationship). Pipeline breakdowns represent physical piping components.

7. SIMULATION MODEL

The simulation model in Fig. 9 must be tailored for each process simulator. Most missing details concern thermodynamics, unit operations and the parameter of time for batch processing. This model deliberately avoids simulator history. Simulator history is too voluminous and too transient to store in a database and should be stored in a sequential file. One may opt to store history file names in the database.

Figure 9a summarizes simulation structure. A plant is the subject of many simulation runs. Simu- lations runs deal with unit operations and streams. Each stream flows into and out of one unit operation. Each simulation run has a list of legal phases and compounds. These master lists constrain stream com- positions. People officially approve the results of simulation runs.

Figure 9b models unit operations. The unit operations class stores general informtion. Subclasses store details for common unit operations. A miscellaneous subclass handles unusual or custom pro- grammed unit operations. A master list of properties and units of measurement are defined at the plant level. Unit operations may be explicitly assigned a piece of equipment. Unit operations have less meta- data than equipment and piping components. Each parameter is merely noted to be a user input or calculated output.

Figure 9c focuses on stream data. Each stream has aggregate properties like flowrate, temperature and pressure. The fractional composition of a stream, depending on numerical accuracy, may or may not add up to exactly 1.0. Each stream may have several phases. Each stream parameter is marked as input or output. Stream compounds and phases are con- strained by the master lists of Fig. 9a. Stream units are defined at the plant level.

8. MODEL IMPLEMENTATION

As of writing this paper, the authors have implemented only part of the AE&C data model. This section will briefly discuss the downstream steps required to convert the AE&C data model into a useful database supporting a host of applications.

8.1. Converting OMT diagrams into DBMS commands

Section 3.4 and Blaha et al. (1988) explain how to convert OMT diagrams into DBMS DDL statements. As an example, applying these rules to the OMT diagrams in Fig. 6 generates the DDL statements in Fig. 10. These DDL commands include extra details that OMT diagrams lack, like data type. Some DBMS do not support all these data types and would require changes. For example, an enum, or enumeration type, could be replaced with a character string and checking for legal values. DDL commands indicate whether nulls are permitted. “Null” means

Crat

e ta

ble S

ite

(site

_lD

ID

not n

ull,

site

_nam

e ch

ar(4

0) n

ut n

ull.

lwth

_eDm

e cw

40),

prim

ary

by

(WD)

)

Crea

te l&

k S

ectio

n (s

ect&

ID

ID

not n

ull.

pi&I

D ID

no

t nul

l, sl

ioe_

&¶ne

ch

w#o)

em

nul

l, pr

iw_f

!Jec

tion

dur(B

O),

&fau

it_m

atl_

of_a

xmuu

c en

urn.

pl

imar

y ke

y (S

ectio

n-~D

))

crea

le ta

ble E

gnip

arer

u (q

uipn

eol_

lD

ID

IIM n

ull,

S%tiL

ll_lD

ID

no

t nul

l, qu

i~el

lt_~

char

@)

not n

uU,

quip

inm

t_ty

pe

enur

e no

t nul

l, m

anuf

actu

ra c

her@

Q,

tight

rta

l M

et

inte

ger,

Prim

tuy

key

(qui

pmen

t_ID

))

Crea

te te

bk N

ozzl

e (n

ozzk

_ID

ID

not n

ull,

quip

nat_

m

ID

not n

dl.

llod_

rIam

e ch

ru(4

0) M

I nu

ll.

prim

ary

key

(noa

k_lD

))

Ovat

e te

ble

Ske_

utili

ties

(utii

ity_I

D ID

no

i nul

l, si

te_I

D m

llo

t null.

ut

ihty

_nam

e ch

ar(4

0) n

ot n

ull.

units

enm

n no

t nul

l, Pr

im81

~ ke

y (U

tility

JD))

crw

e lab

lc u

tiuty

_aM

smn~

(y

u~;D

m

m nu

k ID

Iy

)t nu

ll,

qua&

y re

al,

Prim

my

key

(equ

ipm

ent-I

D t

utili

ty_l

D))

crea

m

labk

use

r (w

r_lD

ID

nc4 n

ull

use_

nam

e ch

ar(4

0) n

ot n

ull.

Prim

ary

key

(use

r ID)

)

Cre

ate ca

ble

Equi

pmen

t_sp

prov

al

(qui

pmen

t_ID

ID

wt

nul

l, us

er_t

D ID

IY

H nu

ll,

lime i

he

Prim

ary k

ey (q

eipm

ent

ID t

use

r ID))

Fig.

iO

a. A

E&C

dat

a m

odel

-equ

ipm

ent

DD

L co

mm

ands

.

hue

tabk

Hea

t exch

ange

r (q

uipm

ent_

ID

m n

ut nu

tl,

wfa

ce_w

re

al.

tuk_

diir

nal,

tube

_kng

th

tui?

eJIrc

ssw

z ~l

LFfe

=e

nal

ntm

tber

_of_

nwzk

s in

tegc

& sh

ellJ

nat&

l cn

um.

tube

_mat

erip

I wm

m,

func

timal

_~~

mm

m,

cons

~tim

l_ty

pe

cJlm

n,

Prim

ary

key

(qui

pmen

t_lD

))

Crea

te ta

bk H

E_da

ta_r

ourc

e (q

u@en

t_ID

ID

nm

nut

I. s~

_sou

rc~

m,

Tbw

ce

ID.

-uw

ce

ID,

Tp_s

oyre

e ID

, SP

_wGe

ID

, ~s

wco

ID,

SM_s

cmrc

e ID

, TM

_sam

ce

ID,

Prim

ary

key

(qui

pmen

t_ID

))

Crea

te t&

k HE

_tim

csia

mp

(qui

pmen

t_ID

ID

no

t nul

l, SA

._tim

rstm

np

time,

TD

_lim

ests

mP

lime.

TL

_tim

esla

mp tim

e.

Tp_t

imes

lam

p time,

SP

_ti~

tim

e,

Iwin

xsul

tnP

time,

SM

_tin

wunp

tim

e,

TWm

eswn

p tim

e,

hlna

ry

key

(q&n

exID

))

Crea

te te

ble

HE_c

onGd

we_l

evel

(q

uipm

en~l

D ID

no

t nul

l, SA

_con

lidcn

ee_k

vel

cnum

. TD

_cnn

fder

r_kv

eI

eeum

, TI

_ccm

l3kn

ce_k

vei

enum

, TP

_uM

tidew

_kve

l en

um,

SP_c

onf&

nce_

leve

l en

um,

NN_c

onfid

cncc

_kve

l en

um.

SM-rz

mwn

ee_k

vel

enui

n,

TM_m

nf~_

kvel

en

um,

Rim

my

key

kquk

imem

__lW

CIe

ate f

able

hQc_

quip

gmpe

ny

ilu&

m?m

_nam

c cl

mr(

40) m

?tnu

N

ueits

enu

m n

ot nu

ll.

Create

tebk

Mke

_qu@

-een

t (q

&y_;

iD

; z

e$

hlue

in

tega

, Rv

alue

rd

Cv

elue

ch

ar(g

@.

&tqh

Mac

e ID

, til

newl

p th

e.

di&x

e_kv

el

mm

m.

Rim

ary

key

(equ

ipm

aa_l

D +

pmpa

ry_m

))

crai

te

mbk

D43

ln_m

(d

eta_

.wce

_lD

ID

not n

ull,

data

_sHr

rce_

~ ch

ar(4

0) n

ot nu

ll.

date

tim

e,

prim

ioy

key

(dat

a_sw

oe_l

D)

Crea

te ta

ble H

eat_

exch

rmge

z_~i

ts

@la

nt_l

D ID

no

t nul

l, Ql

rhce

_~

muu

n no

t nul

l, tu

b@am

~ m

ulm

MIn

IIll,

tuae

_lee

gth

enum

not

md,

m

besr

snun

en

um n

otm

dl,

Fig.

lob.

AEX

C da

ta m

odel

-equ

ipm

ent D

DL

com

man

ds.

Extensible ABQC database model 765

that an attribute value is unknown or not applicable. “Not null” attributes must have a value for every row.

Even though Fig. 10 addresses more details than Fig. 6, it is still not comprehensive. Most DBMS implement a database as a collection of files. Figure 10 does not assign tables to files. Figure 10 also does not show secondary indexes. An index ensures the uniqueness of a combination of attributes and speeds some queries. One would build indexes on names and IDS in object tables and most object IDS in relationship tables.

Note that all internal object references are via ID. Users approach the database with names and navi- gate with IDS. Since the AEdcC data model is complex, and IDS are not intuitive, special software would have to assist users with interactive use.

8.2. Interfacing applications to the database tables

The DDL commands define database tables. AE&C applications populate the tables. Most applications would interact with a database through preprocessors-postprocessors or direct update. Figure 11 illustrates these two alternatives.

Preprocessors and postprocessors require no changes to underlying applications and are ideal for batch programs. The basic idea is simpie. Create a card image file from database input; run the application; analyze the output and store the results in the database. However, database interaction via intermediate files can be awkward.

Some applications may want to query the database and use the resuits to control their subsequent ex- ecution. The application directly calls the database

Input m Ap~licadon ------------1

t

Fig. 1 la. Preprocessor-postprocessor database interface.

hput IO Ap~liuticm _____-------

Output from Application ___---------

Fig. Ilb. Direct database interface.

and read/writes the desired data, but the increased power is accompanied by more programming complexity. A database has much more structure than a simple sequential file. A database is less flexible and slower than data structures in computer memory. The performance impact may be critical for real-time graphics or number-crunching applications.

Other types of database-application program interaction are possible. The design of the interface depends on the particular situation.

9. CONCLUSION

This paper presents a robust framework for AE&C data that can improve the effectiveness of engineering computation. This framework, or data model, en- ables the computer to mediate the flow of data between programs. The computer does the mindless unit conversions and data reformatting. As a result, the user sees an integrated suite of tools, rather than an awkward collection of programs. This data model is intuitive to noncomputer experts, practical to maintain and designed for further growth.

One important contribution of this data model is the distinction between oiews of the plant and the physical plant. Fundamental equipment and piping data is cleanly separated from computing artifacts.

This paper also presents a methodology for modeling engineering data. This is not the primary focus of this paper, but rather a side-effect. The authors endorse the approach of Loomis et al. (1987). Blaha et al. (1988) show how to extend their methodology for relational database design.

The authors have not fully implemented the AE&C data model, but are progressing towards that goal. The authors believe that this data model is a useful start.

AcknowLdgemenrs-The data model in this paper represents more than just the work of the authors. Henzer Chen, Bill Premerlani, Jim Rumbaugh, Dave Wakefield and Barbara Warthen contributed to and reviewed this work.

REFERENCES

Blaha M. R., W. J. Premerlani and J. E. Rumbaugh, Relational database design using an object-oriented methodology. Common. ACM, 31, 414427 (1988).

Buchmann A. P., Current trends in CAD database. In Computer Aided Design. Butterworths, London (1984).

Cherry D. H., J. C. Grogan, G. L. Knapp and F. A. Perris, Use of data bases in engineering design. Chem. Engng, Prog., May, pp. 59-67 (1982).

Chu K.. J. P. Fishbum, P. Honeyman and Y. E. Lien, Vdd-a VLSI design database system. 1983 Data Base Week: Engineering Design Applications, Proc. Ann1 Mtg, San Jose, California, May 23-26 (1983).

Date C. J., A Guide to the SQL Standard. Addison-Wesley, New York (1987).

Eastman C. M., Database facilities for engineering design. Proc. IEEE 69, 1249-1263 (1981).

766 M. R. BLAHA et a[.

Gadient A. J., Functional requirements for an electronic design automation environment integration framework. IEEE Compint-Computer Aided Technologies, Montreal, Canada, September (1985).

James A. J., Selection criteria for an integrated CAE system. Proc. PSE’85, Cambridge, U.K., March (1985).

Loomis M. E. S., A. V. S. Shah and J. E. Rumbaugh, An object modeling technique for conceptual design. European Conf. Object-Oriented Program. Paris, France, June 15-17 (1987).

Lorie R. and W. Plouffe, Complex objects and their use in design transactions. 1983 Data Base Week: Engineering Design Applications, Proc. Annl Mtg. San Jose, Califor- nia, May 23-26 (1983).

Motard R. L., Integrated computer-aided process engineering. PSE’88. Sydney, Australia, August (1988).

Motard R. L., M. R. Blaha and Y. Yamashita, Integrated design management for the process industries. AJChE Annl Mfg, Washington, D.C., November (1983).

Patakas D., J. Mehta and R. L. Motard, Data management in computer aided engineering. AfChE Spring Nat! Mtg, New Orleans, March (1988).

Powell M. L. and M. A. Linton, Database support for programming environments. 1983 Data J3a.w Week: Engineering Design .4pplications. Proc. Ann1 Mtg, San Jose, California, May 23~~26 (1983).

Premerlani W. J., GE-CR&D. Private Communication (1988).

Snodgrass R., A CM ?-runs

The Temporal Query Language, TQuel. Database Systems 12, 247-298 (1987).

Stonebraker M. and L. A. Rowe, The design of POSTGRES. ACM SIGMUD, Washington, D.C., May (1986).

Vernadat F. and W. H. Hcnnckcr, CAD/CAM database at NRC: from manufacturing cell database systems to engineering information systems. IEEE Compint---Computer Aided Technologies, Montreal. Canada, September (1985).

Documents

An extensible AE&C database model