EKAMD--A Knowledge-Based Concurrent Engineering Support System

http://cer.sagepub.com/Concurrent Engineering

http://cer.sagepub.com/content/5/1/59The online version of this article can be found at:

DOI: 10.1177/1063293X9700500107

1997 5: 59Concurrent EngineeringChuan-Jun Su, Mitchell M. Tseng and Richard J. Mayer

A Knowledge-Based Concurrent Engineering Support System−−EKAMD

Published by:

http://www.sagepublications.com

can be found at:Concurrent EngineeringAdditional services and information for

http://cer.sagepub.com/cgi/alertsEmail Alerts:

http://cer.sagepub.com/subscriptionsSubscriptions:

http://www.sagepub.com/journalsReprints.navReprints:

http://www.sagepub.com/journalsPermissions.navPermissions:

http://cer.sagepub.com/content/5/1/59.refs.htmlCitations:

What is This?

- Mar 1, 1997Version of Record >>

at TRENT UNIV on October 10, 2014cer.sagepub.comDownloaded from at TRENT UNIV on October 10, 2014cer.sagepub.comDownloaded from

http://cer.sagepub.com/

http://cer.sagepub.com/content/5/1/59

http://www.sagepublications.com

http://cer.sagepub.com/cgi/alerts

http://cer.sagepub.com/subscriptions

http://www.sagepub.com/journalsReprints.nav

http://www.sagepub.com/journalsPermissions.nav

http://cer.sagepub.com/content/5/1/59.refs.html

http://cer.sagepub.com/content/5/1/59.full.pdf

http://online.sagepub.com/site/sphelp/vorhelp.xhtml



59

CONCURRENT ENGINEERING: Research and Applications

EKAMD—A Knowledge-Based Concurrent Engineering Support System

Chuan-Jun Su and Mitchell M. Tseng*

Department of Industrial Engineering and Engineering Management, The Hong Kong University of Science and Technology,Clear Water Bay, Kowloon, Hong Kong

Richard J. Mayer

Department of Industrial Engineering, Texas A & M University, College Station, TX 77843

Received 16 Apnl 1996, accepted m revIsed form 15 September 1996

Abstract: In the seventies and early eighties, there was a recognition of a crisis in industries relating to a slip in the industrial competitivenessand quality of products This recognition gave rise to an increase in investment in automation and modernization of manufacturing equipment,facilities, systems, organizations, and labor management In the nineties, a shift in focus to problems in worldwide competitive position forced therecognition that many of the previous problems were actually symptoms of deeper rooted issues addressing the entire corporation frommarketing and fiance through research, engineering, manufacture, and field support Among the key issues affecting the erosion of worldwidecompetitive position for industry are

1 Comparatively long lead times to take a concept to rate production2 Inability to assimilate research results into product or production technology3 Lack of a total systematic approach to quality management4 A retiring or otherwise lost knowledge base5 High rates of change in the product definition (and the production process) during build-up to rate production and upon any major product

or process change

The Engineering Knowledge Acquisition, Management, and Delivery system (EKAMD) is proposed as a part of the answer to the questionsWhy does it take so long to design/engineer/produce a product? Why are so many of the mistakes of the past repeated? The part of the problemthat EKAMD addresses is focused on the acquisition, management, and effective delivery of engineering knowledge, experience, and rationaleThe EKAMD can be thought of as an integrated concurrent engineering system which provides an environment including facilities for (1) designknowledge representation including shape-based representation, (2) advanced engineering modeling support, (3) knowledge configuration andversion management support, and (4) system Integration support In summary, this environment is intended to be used to support the rapid ex-perimentation, prototyping, and development of a new generation of integrated design, engineering, manufacturing, and maintenance decisionsupport applications to meet the challenges of concurrent engineering Most importantly, this architecture can enable the capture and deliveryto the engineer of product life cycle experience relative to manufacturability, reliability, and maintainability

1. Introduction

The complexity of today’s products requires the assemblyof large teams to accomplish concurrent or simultaneous en-gineering (CE) of a product through its life cycle. At pres-ent, these teams are used as the life cycle design and analy-sis information pipelines through which the emergingdesign is iterated until it satisfies the design requirements.The &dquo;To Be&dquo; situation emphasizes parallelism of tasks,driven by design ideas constrained by the life cycle implica-tions of those ideas. Initiatives toward concurrent engineer-ing must include many different organizations in design, en-gineering, manufacturing, and field support operating as avirtual design team. The key to successful CE application isthe capture of life cycle knowledge and timely effectivedelivery of that knowledge to the appropriate decision-making event. Much of the knowledge that is applied in or

*Author to whom correspondence should be addressed

communicated between these activities cannot be repre-sented in linguistic terms easily, as it is primarily shapebased or shape indexed. Shape- and feature-based knowl-edge refers to that engineering, manufacturing, and main-tenance knowledge associated with the geometric propertiesof the part. Because these shapes do not necessarily havenames, they cannot be represented in traditional knowledgerepresentation schemes. Nor do traditional literal patternmatching schemes work for purposes of knowledge retrievalor reasoning. The part representation used by conventionalCAD (including solid modeling) systems is incomplete interms of the semantic and qualitative part descriptionsneeded for concurrent engineering [1]. In addition, theclosed architectures of these CAD frameworks make

delivery of the life cycle knowledge to the decision-makingevent difhcult. However, for effective CE applications, wewould like to identify problem areas in a design and providerecommendations interactively during the design creationprocess. This problem of impoverished part representation

Volume 5 Number 1 March 1997

1063-293X/97/01 0059-18 $10.00/0@ 1997 Technomic Publishing Co., Inc.

at TRENT UNIV on October 10, 2014cer.sagepub.comDownloaded from


60

Figure 1. Concurrent engineering product life cycle.

also has inhibiting effects on the cost effective applicationsfor CAE. For example, a hole will be represented as a cylin-drical face connected to the faces around it in a solidmodeler. This representation is not suitable for grid refine-ment algorithms used in finite element analysis that need toknow that the hole is a stress raiser, and consequently needsa finer mesh, that the cylinder represents a hole that may bemapped by a process planning system to drilling, reaming,or boring operations, or that the hole presents problems tomanufacturing because of the way that it interacts with otherfeatures. We develop an approach to acquire the product lifecycle knowledge and build integrated applications with thereasoning mechanisms. The approach would provide thecapability to acquire &dquo;conditions on&dquo; or &dquo;contents of&dquo; designknowledge that contains arbitrary geometry structures (gen-eralized shapes).The concurrent engineering model of manufacture as

shown in Figure 1, emphasizes a parallel approach to partlife cycle engineering that is driven by design. In Variant/Generative Process planning and design by feature, we wereattempting to bridge the gap between Design and Manu-facturing because the life cycle process was assumed to beserial. This &dquo;traditional&dquo; approach to manufacturing isshown in Figure 2. In the concurrent engineering paradigmthe process is parallelized, so we must be able to assess theimpact of design decisions by delivering design knowledgeto all of the activities which influence the design, such asengineering analysis, productibility, assembly analysis, costanalysis, maintainability analysis, and use ability analysis,and then be able to communicate the results of these analy-ses back to the design activity. This means mapping infor-mation to and filtering out &dquo;detail&dquo; (often shape based) intoa form that is amenable to each one of these activities.

2. Shape Knowledge Acquisitionand Representation

The &dquo;featurization&dquo; of a part is an interpretation processthat occurs within a particular context. The same physicalphenomena (a part) will be partitioned and abstracted dif-ferently by different agents in different contexts [2,3]. Dif-ferent agents in different contexts are attuned to different

perceptions. This difference of attunement implies that dif-ferent signs are extracted from the same phenomena. Evenin simple natural language phenomena, where we mightsuppose that the exact same attunement to the words in asentence exists, the interpretation of a statement made withthat sentence will change from context to context. Attune-ment and interpretation are influenced by the acquiredknowledge of the agents in the context. The implications ofthis view of featurization as an interpretation process impactmany aspects of CE applications from the user interface tothe information integration mechanisms. For example, if

one accepts that expert performance in the complex do-mains of engineering and manufacturing requires expertiseacquired through experience and specialized training then itis unreasonable (and probably undesirable) to expect de-signers to effectively think in terms of manufacturingfeatures except in the most trivial cases.

2.1 I Shape Acquisition Strategy

We develop our shape acquisition strategy by classifyingthe approaches taken by prominent researchers in the fieldof feature recognition [4,5]. In our survey, we found that noconsensus exists on such fundamental issues as: (1) what isa form feature, (2) what is an appropriate mathematical

Figure 2. &dquo;Conventional&dquo; product life cycle.



61

definition of a form feature, and (3) does there exist acanonical set of form features? To illustrate these points, thefollowing definitions for form features have been proposedin the literature:

(a) A region that alters the convexity of a part [6,7](b) A region which has topological, geometric, or func-

tional significance in a particular domain [8,9](c) Recurring patterns of information related to a part’s

description, relating nominal size and shape, precision,and material [10]

(d) A higher level semantic description of a part in terms ofa specific domain [11]

(e) A single face or a set of contiguous faces called a faceset, and a set of characteristic patterns in topology andgeometry defines each shape feature [12,13]

(f) Regions of a part having some manufacturing sig-nificance in the context of machining [14]

(g) A specific geometric configuration formed on a sur-face, edge, or corner of a work piece, intended to

modify outward appearances or to assist in achieving agiven function [15]

(h) A geometric form or entity that is used in reasoning inone or more design or manufacturing activities [16]

After reading these definitions, the reader might bejustifiably perplexed by: (1) the apparent lack of consensuson these definitions of features, (2) the fact that all of themare true in one way or another, and (3) they are also

somewhat contradictory. The solution to this conundrum isthat the researchers were defining features for different pur-poses. Figure 3 shows a shape acquisition framework thatwe propose, which places these definitions in perspective.In Figure 3, the arrows to the left, top, right, and bottom ofeach box represent inputs, controls, outputs, and

mechanisms, respectively, used by the IDEFO functionmodeler [17]. Some of the definitions deal with the recogni-tion of geometric and topological patterns, others deal withmatching these patterns to prototypical shapes, while a thirdgroup deals with the interpretation of feature shapes using

Figure 3. A framework in which the feature definitions found m the literature are compatible.



62

Figure 4. Examples of nonmanifold topologies.

AI techniques. In our approach to this shape acquisitionproblem, the manner in which the acquisition is performedin each stage is controlled by a user selected frame of refer-ence. The geometric algorithms we have developed for

shape acquisition consist of (1) predicates such as coplanar,intersect, and convex, (2) derived properties such as area,perimeter, and volume, and (3) constructions such as con-vex hull, minimum enclosing box, and Boolean operations.Examples of the graph search algorithms that will be usedare articulation, biconnected and triconnected components,and depth first search [18]. The AI inferencing algorithmsthat have been modified for use with these geometricalgorithms are: abduction [19], truth maintenance, and con-straint propagation [20].

2.2 Shape-Based Knowledge Representation

During the development of our shape-based knowledgerepresentation scheme, some of the key questions we ad-dressed included: (1) How do we go about creating a repre-sentation for form features that allows us to map into thesedifferent frames of references? (2) Do we need to use a non-manifold topology to represent our part geometry in orderto keep our representation neutral [21], i.e., when we needmanifold topologies, why don’t we use a mapping function?(3) When we reason about shape, are we using an internal-ized (Naive) representation that is nonmanifold and non-Euclidian ? (4) How do we use this representation for

delivery of knowledge to and from CAD systems? We havedeveloped a representation for shape-based knowledge thatis outlined below. Note that we have explicitly included theconcept of dimensionality in granularity [22], so there is notalways a tidy substructure/superstructure or refinement rela-tion between granularities. This allows us to speak of anAffine granularity, a Cartesian granularity, or a manifoldgranularity of a part. An example of the nonmanifold topol-ogy of our scheme used to represent volumetric features isshown in Figure 4.There is strong evidence to suggest that form features of

mechanical parts are primitives in a language or representa-tion scheme that is used to describe shape in technologicalactivities such as design, manufacture, and logistics [8].How we define, extract, and interpret form features of amechanical part are strongly influenced by:

(a) The granularity in which we are viewing it(b) The directional and biasing systems of the primitive ob-

jects(c) The directional and biasing system of the viewer(d) The directional labels or projective prepositions used in

describing the form feature

In this work, we have identified that a shape-based knowl-edge representation should include (1) a unique identifier forspace description elements, (2) a frame of reference, (3) theability to describe relations about shape compositions, and(4) a set of logical constraints describing the shape type orshape composition. Our definition for a form feature repre-sentation is as follows: (Shape N F 7r C S)

where:

N is a feature-name,F is the frame of reference (FoR)7r is a set of primitive element specifications or feature

specificationsC is a set of constraints (geometric, topological, etc.,

relating elements of z in FoR F)

2.2.1 FRAME OF REFERENCE (FoR)It is important to establish a reference frame for the spa-

tial descriptions since (1) spatial prepositions used may beused in a deictic, intrinsic, or extrinsic manner [23], (2)relations are sensitive to the frame of reference’s granularity,and (3) all spatial metrics have to be declared relative tosome coordinate frame [22]. To permit reuse of frames ofreference, we allow the inheritance of reference frames. Ourdefinition for frame of reference is as follows:

Frame of Reference (FoR)An FoR is defined as (FoR N G D L S)



63

Figure 5. Illustration of the use of frame of reference

where:

N is the FoR NameG is the granularity of the FoRD is the direction and biasing system used in the Frame of

Reference. For example, a cartesian coordinate Frame,or a four-dimensional frame that includes x y z and time.

L is a set of directional labels used in the Frame of Refer-ence-for example Top, Bottom, Left, Right

S Inherited FoR’s

As an illustration, Figure 5 depicts the use of frame of refer-ence.

Various activities are attuned to different aspects of the

part model shown in Figure 6. The end-milling activity in-dividuates the part in terms of individual slots, the gang-milling activity individuates the part as a set of parallelslots, the heat-transfer analysis activity individuates the partin terms of fins, and the finite element analysis activity in-dividuates features that are stress raisers, such as concaveand convex edges.

Reference frames are composed of datums, direction

biases, directional labels, and distinguishability functions.Figure 7 shows an example of a reference frame, i.e., theuser’s view that employs a left/right handed, up/down, andfront/rear bias. This particular reference frame employs abox organizational framework for the datums. The box isactually a composition of six datums that are referenceplanes. Each reference plane is defined in the point-normalform. It is convenient to use the point-normal form, as thenormal, approach, and orthogonal vectors of the homoge-neous coordinate frame may be used as normal vectors for

the reference planes of the box datum. Note that referenceframes can be defined in terms of the user, a viewer of the

part, the part itself (intrinsic), or by virtue of the part’s mo-tion. Figure 8 illustrates the direction labels defined for aleft/right handedness biasing system. Figure 9 illustrates thespatial prepositions used for reference planes in an above/below biasing system. It is worth noting that the spatialprepositions of the box datum are actually defined in termsof the reference plane spatial prepositions. In order to showthis, some definition is necessary:

1. The methods Right-of and Left-of applied to a box

datum, pick out the right and left datums, respectively.2. The directional label On-inside positions two reference

planes such that they are coplanar and their normalvectors face in the same direction.

3. The directional label On-outside positions two referenceplanes such that they are coplanar and their normalvectors face in the opposite direction.

Armed with these definitions, it is easy to see that: (on-Right A B) is the same as: (Above (Right-of A)B), which isthe same as: (On-ourside (Right-of A) (Left-of B) ).

Thus, the more abstract spatial prepositions may bedefined in terms of the more primitive spatial prepositionsprovided by reference planes.

Figure 6. Reasoning about part geometry from different reference frames.



64



65

2.2.2 GRANULARITYDifferent grains may &dquo;smooth&dquo; objects, reduce &dquo;insignifi-

cant&dquo; objects to points, or map into spaces of differentdimensionalities [22]. Thus, spatial relations can be definedover entities in the abstraction spaces if they are indexedwith the granularity of that space. Each grain definitionmust include a set of primitive mapping functions such asindistinguishability, adjacency, and membership. Variousrelations may hold between grains, for example, we can saythat grain 1 refines grain 2 if grain 1 draws at least as manydistinctions as grain 2 does. A full theory of granularityshould allow an agent to abstract away irrelevant detail froma problem by moving to coarser granularity [22]. This isuseful, for example, in maintaining compatibility between apart’s design model, its finite element model, its manu-

facturing model, and its assembly model. Granularity is

very useful for dealing with time as either a discrete event,or an interval [24]. This allows us to compatibly representa machining process as an interval at one granularity, and asan instant at another granularity. Figure 10 shows an exam-ple of the use of granularity. Our definition for granularityis as follows: (Granularity N c3 S)

where:

N is Granularity specification namea Set of primitive mapping functions (e.g., adjacent, in,

same)S Set of Inherited Granularities

2.2.3 DIRECTIONAL AND BIASING SYSTEMSA space may include a metric that need not necessarily be

Granularity

Figure 10. An example of the use of granulanty.

cartesian, as we may define metrics on spaces that do nothave &dquo;straight line&dquo; concepts, or define only partial ordersover a range [22].

2.2.4 ARCHITECTUREFor a systematic description of the proposed shape ac-

quisition and application system, an IDEFO (activity/concept diagram) model was developed as shown in Figure11. The principal activities identified in the top level arethose of Knowledge Acquisition, Refinement, and Applica-tion. Figure 11 shows only the top level concepts for thismodel. The architecture must be capable of deliveringshape-based knowledge within CAD systems.

2.3 Container Objects

In this section, we demonstrate the applicability of com-posite objects as a knowledge representation technique forconcepting and describing shape, form, and function withina framework of experimentally derived description primi-tives.

2.3.1 BASIC CONCEPTS AND THEORYOF OPERATIONA composite object-oriented system extends the notion of

objects to make them recursive under composition. This en-ables the instantiation of a group of objects as an entity. Thisis useful when relative relationships between members ofthe group must be isomorphic for distinct instances in thegroup. A composite is defined by a template that describesthe sub-objects and their connections. These objects are cre-ated by an instantiation process and are describable in aclass inheritance network. One benefit of creating compos-ite object classes is the ability to make modified versions ofa template by making a new subclass which inherits theproperties of the superclass. Facilities for making compositeobjects are not common in object-oriented languages, butare fairly common in application languages, such as thosefor describing circuits and layout of computer hardware.

2.3.2 PRINCIPLES FOR COMPOSITE OBJECTS

Composite objects have the following features:

~ Composite objects are specified by a class containing adescription indicating the classes of the parts and the in-terconnections among the parts. The use of a class makesinstantiation uniform.

~ Instantiation creates instances corresponding to all of theparts in the description. The instantiation process mustkeep track of correspondence between the parts in the in-stantiated object. It fills in all of the connections betweenobjects. It must permit multiple distinct uses of identicalparts.

~ The instantiation process must be recursive to allow theuse of composite objects as parts. For programming con-venience, the system must either flag as an error the situ-



66

Figure 11. Shape-based reasoning/acquisition system architecture.

ation where a description specifies using a new instanceof itself as a part, or support &dquo;lazy instantiation.&dquo; A

description of a part which includes itself can result inthe instantiation of objects with an unbound size. Alter-natively, instantiating subparts on demand (lazy instantia-tion) would allow the use of potentially unbounded ob-jects, as the subparts are generated only on use.

· It must be possible to specialize a description by addingnew parts or substituting for existing parts. The descrip-tion language must allow specialization of composite ob-jects with a granularity of changes at the level of parts.

The following sections describe the basic requirementsfor the EKAMD container object system based on the abovegeneral theory of composite object operation.

2.3.3 BASIC REQUIREMENTS FORCONTAINER OBJECTSA container object-oriented system uses structural tem-

plates to describe container objects having a fixed set of

parts. Container objects are regular objects, created by aninstantiation process, and describable in a class inheritancenetwork. The benefit of creating container object classes is

the ability to make modified versions of a template by mak-ing a new subclass which inherits the properties of the superclass.

Container Object Templates. A container object is

described by creating a class whose metaclass is a tem-plate or itself has a superior that is a template. Any classwhose metaclass is a template or a subclass of a templateis called a template. The default values of the instancevariables of a template can point to other templates whichwill be treated as parameters and be recursively instan-tiated when the parent is instantiated. Instance variablesthat point to non-template classes or to default values aretreated as constants that are inherited by the instances.

Instantiation of Container Object Templates. The instan-tiation process will recurse on all the parameters of the

template. Every parameter is instantiated when it is firstencountered. Multiple references to the same parameterare replaced by pointers to the same instantiated instance.The instantiation of a template is isomorphic to the origi-nal template structure with constants inherited, and dis-tinct instances substituted for distinct templates (i.e.,parameters). If a container needs multiple distinct in-



67

stances, then multiple distinct templates are needed in thedescription.

Specializing Container Objects. Specialization of con-tainer object templates must be supported both at thedefinitional level and at the instantiation of a template.That is, the template class must also be a template allow-ing the construction by example of new template struc-tures.

Constrained, Conditional, and Iterative Templates. Theinstantiation of container objects having repetitive or con-ditional parts with the logic specified with IISyCL con-straints is supported by the EKAMD.

Defaulting of Attributes Values in Container Objects.When instantiating a container object, it would be ad-

vantageous for it to determine default attribute values that

satisfy the instantiation constraints. For example in

ICADTM, to make a table, the user only has to design oneleg, and the tabletop, and then specify that the table

should be on top of four of the legs. ICADTM automati-cally defaults the positions of the four legs to the cornersof the tabletop.

Lazy Instantiation and Demand Driven Control of Con-tainer Objects. A container object could be very large,for example, an instance of an F-16 fighter is composed ofthousands of parts. Each part has geometric models, aswell as design, test, manufacturing, assembly, mainte-nance, and vendor data attached to it. On referencing orcreating the F-16 instance, it would be advantageous if theentire F-16 were not instantiated, rather only those com-ponents of the container that we care to reference and theset of support objects needed to instantiate those sub-components so as to satisfy the instantiation constraints.Demand driven control means the system only performsthose calculations that are necessary to respond to a

query. This facilitates partial design and saves time duringdesign revisions.

Graphic Browser for Examining Objects. A hierarchicalorganizational structure manages the complexity in

design by breaking down the assembly into its componentparts. The designer must be able to create, edit, instan-tiate, and modify container object templates using a

graphical browser that displays user selected structureforming relations. The default relations displayed wouldbe the part-whole and inheritance relations.

Part-Whole Defaulting. When an object requires an attri-bute that does not appear in its definition, the object looksup the tree to its ancestors for the value. This mechanismis known as part-whole defaulting as attributes are auto-matically made available as default values to parts withinthe subtree of the part owning the attribute. Thus, only theattributes of the descendents that are different from theancestors need be defined. For example, if a table’s

material-type attribute is defined to be wood, it would

only be necessary to define the material type of thosecomponents of the table that are not made of wood such asnuts, screws, and bolts. For example, if we were to define

a house with a red terra-cotta tile roof, it would be un-

acceptable if we would have to set a color attribute oneach one of its tiles, while at the same time, we mightwant to be able to point to a tile and obtain its properties.

No Class vs. Instance Distinction. In many object-orientedsystems, a distinction is made between class and instance.Classes are generic objects, whereas instances are

specific. Generally, this means that classes are not firstclass objects. In ICAD, for example, the design languageis used to describe a class, which is the set of possible in-stances that may be created from a single definition, butclass descriptions cannot be created by the instantiationprocess. In the EKAMD container object system design,we are modeling our class structures after the schemastructures in frame systems. All operation types ap-

plicable to instances will be executable on classes.

2.3.4 GEOMETRY DRIVEN CONTAINEROBJECT SYSTEMContainer Objects Based on Partition Similarities. In

fleshing out a description using prototypes or building upa description using generic primitives and operations, theprocess will be recursive and will involve partitionings,features, arrangements, deformations, and functions for

specifying the components and their constraints and rela-tionships. There is a high degree of interdependence be-tween these terms, for example, a partition may be de-fined in terms of features, which are defined in terms of

partitions, arrangements, functions, and deformations. Adeformation may be described in terms of features.

Container Object-Based Partition Similarities. The

system supports the subdivision of the object in terms offeatures, arrangements, function, and deformation.

Container Object-Based Feature Similarities. The systemsupports the use of predefined feature descriptors to

describe the contents of a container object.Container Object-Based Arrangement Similarities. The

description of the spatial/functional patterns that exist be-tween the elements in a container object.

Container Object-Based Deformation Similarities. Thesystem supports the specialization of prototypical descrip-tions by describing incremental departures from the pro-totype in terms of form (bending, tapering, pinching) orbehavior. All object-oriented languages allow the alteringof behavior through the definition of class hierarchies andthe definition of methods.

Container Object-Based Function Similarities. The

description of the contents of a container in terms of thespecifications, environment, and purpose for which thecomponents are intended.

3. Advanced Engineering Modeling Support

One of the primary components in any design support orautomated &dquo;designer&dquo; system is the engineering analytic



68

model. One of the goals of a generalized architecture forbuilding expert systems to support the engineering life cyclewould be to also support the development/refinement of themodels of the physical systems or processes which are usedin that design process. A large part of engineering design in-volves the manipulation of models. Yet most computermodels today are coded in such a way as to be very resistantto change. Any changes to the existing models frequently re-quire extensive recoding of very old and largely undocu-mented code. New model developments are equally difficultbecause the engineer has no means of expressing the modelconcepts to a computer in a way natural to him. What isneeded is an intelligent model building system that knowsabout model concepts, solution technique types, and imple-mentation methods.The major modeling support utility provided by the

EKAMD is the constraint management [25]. Design is

constraint-oriented: much of the design process involves therecognition, formulation, and satisfaction of constraints.The CMS (Constraint Management System) can aid design-ers in identifying and exploring the boundaries of the designspace. It can help to determine which are the most impor-tant design parameters, specifications, and constraints andevaluate the global performance of the alternatives in orderto select the most appropriate ones for detailed analysis andrefinement. The main functionalities to be provided by theCMS component of the EKAMD include:

1. Causality and dependency determination via Bipartitematching

2. Strong component (simultaneous constraints) detection3. Consistency verification4. Explanation and qualitative reasoning5. Solution sequence generation6. Sensitivity analysis

Besides the engineering performance modeling support,the CMS was incorporated into the container object repre-sentation mechanism as described in the following section.

3.1 CMS in Containers

Composite objects, because of the ability to specify recur-sive template structures in their definitions, has a need forconstraint management capabilities. These capabilitieswould be used to ease the specification of the instantiationlogic as illustrated in the following example.ICAD has :trials, and :query-trials keywords within the

defpart macro, that define a list of possibilities for an attri-bute, and a test to determine which attribute is chosen. Eachpossibility is tested in left to right order, and the value of theattribute is the value of the first success. An example of theuse of :trials is where the analysis of a list of cataloguedparts might require the total mass of the object’s parent.Since the total mass depends on which cataloged part is

used, :trials is used to perform the analysis.The syntax of :trials is as follows:

: trials ([:trial-attribute-name (trial-test list-of-possibil-ities) ]

:trial-attribute-name is the name of an attribute trial-

test is an expression list-of-possibilities is the list ofvalues to be tried

When information about the table leg is required, thesystem has to calculate the leg type. The test uses :total-weight and :leg-strength which depends on the typeselected. We implemented a more flexible form of this typeof control structure using a primitive form of constraintmanager. The traditional type of searching is computa-tionally expensive as it does not use any searching strategy.As is shown in the following example, the user can intercedeby conditioning the search data where the cataloged data issorted in ascending horsepower before the search is at-

tempted.

Using a constraint management approach would allow thesystem to automatically compute a solution strategy basedon the &dquo;knowns and unknowns&dquo; of a particular design ses-sion. It would also simplify the container specification asless procedural specification for instantiation needs to besupplied.

4. Services for Evolution Managementwithin the EKAMD

In order to provide support for design engineers in thecontrol of the evolution of the design data, a design environ-ment must:

1. Manage and propagate constraints specified in the prod-uct needs analysis or in design goal specifications andenforce those constraints on the evolving solid models



69

2. Transparently control the configuration of the designartifacts

3. Support rapid browsing and modification of the aboveinformation about an evolving design

4. Support definition and management of perspectives5. Support definition and management of versioned objects6. Provide configuration decision management capabilities

Such capabilities are required if current &dquo;computer aideddrafting&dquo; (cad) and computer implemented engineeringanalysis programs are to be evolved into effective ComputerAided Design and Engineering (CAD/CAE) environments.Lack of computer support for determination of the effect of

changes (at a semantic level not just at an effected parts listlevel) causes poor disposition decisions that can result inmajor delays in a product program. Inability to enforce con-straints across multiple representations of design data, andpoor decisions often result in a requirement for a completereentry of the design data. This amplifies the negative im-pact of the poor cad interfaces. Configuration control is nor-mally manually performed, resulting in many man-hours re-quired to locate the current released design data for

modification.

4.1 I EKAMD Configuration Control andVersion Management

4.1.1 PRODUCT DATA EVOLUTION MANAGEMENTThe term product data refers to the public product defini-

tion artifacts that are managed by the system. If theEKAMD environment was used by an automobile manu-facturing organization, these artifacts would be such itemsas complete vehicle designs, radiators, tires, etc. Other in-formation maintained would be supporting data such as costanalysis reports, vehicle design requirements, etc. These

items would all have versions and most of them would be

composite objects. The default product data configurationmanagement services provided by the EKAMD would bebased on the &dquo;check-in/check-out&dquo; strategy, with public-level version control. This default was chosen because it

represents the approach most likely to be found in currentcorporations. As an example, consider a product that under-goes four phases in its life cycle. The first of these is an ini-tial design phase. During this phase, the product undergoesinitial development, testing, and refinement. While the

product is in this state, there will be frequent changes to theconfiguration and possibly parts of the design will remainundefined for a period of time. As this phase nears com-pletion, certain portions of the design may become immuneto changes. The phase ends sometime early in the productproduction phase. During the production phase, changesmay still be made to parts of the design; however, there willbe extremely stringent constraints on these changes. Thenext stage in the life cycle of the product comes when pro-duction of the product terminates. The product in this phasewill likely continue to be supported by the organization.

Once production of the product ends, the need for designchanges becomes less likely; therefore, change-control con-straints would force very high level approval for any designchange. At some point, the organization will no longer sup-port the product. This places the product design in the finalphase of its life cycle. The design data still needs to be main-tained because there is much usable information in the

design, and the organization would benefit by keeping thedesign available for review and copying. However,modifications will no longer be made to this particulardesign; it is frozen. These four phases that a product designgoes through are called states. We call these states develop-ment, production, support, and retired.The EKAMD environment provides functions which

allow an organization to define the descriptions for the ob-jects which exist in its product data databases. The objectscreated contain, in addition to the attributes that describethe product, version and state attributes. The functions pro-vided by EKAMD would be such functions as create ver-sioned-object. A versioned-object would inherit version andtime-stamp attributes. Simple versioned objects would

likely be non-composite objects or components of the prod-uct that are outsourced (i.e., components of a compositeproduct that are neither designed nor produced by the or-ganization). For an object that would pass through phases inits life cycle, the EKAMD environment must provide thefunction to create state-object. State-objects will likely becomposite objects. These would be product componentsproduced by the organization, but in particular, a productwhich is a composite object, such as a vehicle produced byan automobile manufacturer. A state-object would inheritversion, state, time-stamp attributes. The time-stamp attri-bute not previously mentioned would be a means of assist-ing in a merge operation that would be necessary when mul-tiple users are working on the same design. In order for anobject to be properly described, it will be necessary to in-

clude the ability to describe objects as component-parts(i.e., list of objects that are part of another object). Each ob-ject in a list of component-parts would have the componentobject in their is-a-component-of list. In addition to provid-ing a facility for defining objects, functions will be providedfor describing the states in which the organization’s productdata can exist. Functions will also be provided for definingwhat would constitute the termination of one state and the

start of the next. In addition to the above described version

management capabilities, additional functions to be pro-vided by the EKAMD environment include:

. problem report generation

. change request processing

. message passing

. status report generators

. status/state browsing facilities

Requirements for these and other configuration manage-ment functions require further definition and refinement.Controlled manipulation of the product data will be pro-



70

vided by the knowledge base which is described in the fol-lowing section.

4.1.2 KNOWLEDGE BASE EVOLUTION CONTROLIn addition to maintaining a database(s) of product data, a

set of life cycle engineering knowledge bases must also bemanaged. These knowledge bases can be thought of as data-bases that would be composed of the rules, constraints, poli-cies, and principles of life cycle engineering in the organi-zation. The knowledge base data will also have versions.These rules, constraints, policies, and principles of designinfluence the design process via the control points to whichthey are attached. Most importantly, the knowledge basemaintains an additional version management data type thatwe call a context. The context version management capabil-ity allows one to control the &dquo;applicability&dquo; of knowledgeand the validity of certain inferencing mechanisms. For ex-ample, the execution or application of a particular rule, orconstraint, etc., doesn’t always occur. For an illustration ofthis point, assume that the organization recently acquired anew cooling system analysis tool which requires more datathan the old. All new designs must use this tool. A contextwould then be defined to allow the inference that if the

released version of the vehicle is later than some date, thenthe new analysis tool has been used in its design process.The context would determine which set of rules, policies,constraints, and principles of design are applied in a givensituation.Items in the knowledge base will be treated as versioned-

objects and functions would be provided in the EKAMD en-vironment which allows a qualified user of the environmentto define objects of each of these types. The functions fordefining objects in the knowledge base are the keys to per-sonalizing the system for different organizations. They allowthe creation of versioned-objects in the knowledge base thatprovide for:1. User defined rules and organization policies. Rules can

be defined that limit user access to only certain applica-tions.

2. User defined constraints on objects in the product base.An example of a constraint could be projected produc-tion cost of object should not exceed x number of dol-lars.

3. User defined policies such as change request must be ap-proved by department manager, or change request re-quires approval by the division head.

4. User defined context. In the previous example of poli-cies, there appear to be two conflicting change requestpolicies; however, the context could be &dquo;apply the firstpolicy when the stage is development&dquo; and &dquo;apply thesecond when the stage is supported.&dquo; A context wouldalso be used to control such procedures as which analy-sis programs to use or whether certain data is stored in

a database or is calculated. Often the context will be

associated with the value of the time-stamp attribute in adesign object.

5. User defined principles of design.Sets of the objects in the knowledge base will be asso-

ciated with control-points. Because the objects in the knowl-edge base are separate entities, an object can be associatedwith multiple control-points. The definition of the control-points and the sets of objects to be associated with eachwould be defined by an authorized knowledge base manager.Definition of a control-point would be the equivalent to set-ting a flag on the entrance to or exit from a given functionor command. A context would be a means of attachingdifferent sets of objects to a control-point based on someuser defined situation. The context would also be used to en-

force the use of particular design and analysis tools based onsome user defined criteria.

In order for the objects in this knowledge base to be ofmaximum use, a command to the design system functionsand applications would go through a command interpreter.The actual commands would be called by the command in-terface rather than the user. For instance, the user wishes torun a cost analysis on a given design. The user would typea command such as cost design x. The command interfacewould:

1. Receive the command2. Check the version and state of design x3. Select the appropriate entry control-point(s) for the con-

text of the design4. Check the set of policies/constraints associated with the

entry control-point5. Execute the functions associated with the policies/

constraints

6. Initialize the appropriate costing application. The userwould a) perform the costing process and b) terminatethe process.

7. Select the appropriate exit control-point(s)8. Check the set of policies/constraints associated with the

exit control point9. Execute the functions associated with the policies/

constraints, sending any required messages, change ver-sions, or state of the design object, etc.

The previous section has not directly considered the

needs of the individual user of the system; it has been moreconcerned with the needs of the organization. However,proper handling of the organization’s needs for a productbase and a knowledge base requires that consideration begiven to the individual user of the system.

4.2 Personal Design History

The EKAMD supports the individual user in the defini-tion and use of personalized environments in which he/shecan define personalized interface presentations, rules, con-straints, etc. These would be attached to control-points in thesame manner that those in the knowledge base are attachedto control-points. Another area that needs to be considered



71

in a description of the individual user’s environment is theability of the user to experiment with the design of objectswithin his/her design domain without modification of thecommunity databases. For instance, consider the designerof an automobile. This individual needs the freedom to ex-

periment with vehicle body designs in order to developideas for future development. The user should be able tomake multiple changes to an object within his/her domain,but retain the ability to back out of those changes at will.The user’s domain would be defined by the role type that

he/she assumes. Role type is an aspect of access control,which is of vital importance in any multiuser system. Theinstallations will be allowed to define different role or user

types to which individual users can be assigned. Associatedwith each role type will be a set of allowable functions or

operations that users of that role type can execute or use.The system manager will assign each user to one or morerole types. A user can then login to the system, which wouldplace the user in their private environment. After login, theuser would select one of his/her role types to use. This pro-cedure provides the user with access to only those opera-tions that he/she would require. The environment was de-signed so that an individual does not have to terminate asession and reenter the system in order to change roles.However, for the purposes of security, when a user exits onerole type and starts another, the system would automaticallyclear the session (after prompting for the save operation).The user would then have a different set of commands avail-

able, some of which could be duplicates of the precedingset. With the definition of available functions for a role type,the objects in the product base that an individual is allowedto modify can be controlled. This restriction will provideextra protection for the product data. The engineeringdesign support environment will provide an exit-role com-mand in all role type descriptions. Ending a session wouldautomatically execute the exit-role command. If the func-tionality is available in a particular user’s role type, then theuser can define rules, constrains, control-points, etc., thatwould be applicable only in his/her environment. The cre-ation and use of these control-points and policy sets, etc., isidentical to those in the knowledge base; however, the use ofindividual control-points would be in addition to the or-ganizational defined rule sets and would not be allowed toinvalidate any requirement defined by them. Whether theuser is working on product data or experimenting with adesign that may eventually become product data, the objectsthat are created and manipulated within a user’s personal en-vironment require versioning. In the individual’s private en-vironment, the primary reason for versioning is to maintaina history for changes made to object with respect to otherobjects within _the design.The designer would make incremental changes to the ob-

ject of design with each change recorded as a version of thetotal object. The designer could browse these different ver-sions selecting any one for further refinement (each re-

finement would represent a change and thus another ver-

sion). Eventually, one version would prove to be acceptableand it would return to the product base where its inclusionwould produce a new version of the product. The private en-vironment could then be purged of the excess versions orthey could be retained for future reference. One facility thatwould have to be provided to the user would be a means oforganizing the personal environment.

In this section, we have presented an approach to evolu-tion management that is offered as one of the key integrationservices of the EKAMD. In the next section, the EKAMD

approach to integration services in general will be de-scribed.

5. Platform Architecture for System Integration

To provide the type of information and knowledge man-agement support and control required, a platform archi-tecture based on a services approach to integration wasdeveloped. This represents a new way of looking at the inte-gration problem. In essence what we are suggesting is thatrather than focusing on the construction of an &dquo;integratedsystem,&dquo; what should be focused on is the &dquo;integration ser-vices&dquo; that the EKAMD platform as well as the functionalapplications provide. In previous approaches to integratedsystems architectures, the burden was assumed to be on theplatform to provide the integration support desired. Theprevailing wisdom on achieving concurrent engineering in-tegration within an organization, is that it occur in three

ordered waves, namely:

(a) Data Integration(b) Application Integration(c) Function Integration

In order for this to occur, comprehensive standards haveto be set up a priori and be universally accepted by the or-ganization. Thus, applications would have to meet thesestandards before being accepted by the organization. Thesetraditional approaches have severe problems (which is prob-ably why after eleven years there are still no significant ap-plications of this approach). One of those problems is theneed to define a priori the comprehensive standards. Thispresumes that an organization (or a group of analysts withinthat organization) can foresee a) the integration services thatare required and b) the relative demands for those integra-tion services. Presuming that we could solve &dquo;a&dquo; with a yetto be discovered appropriate &dquo;crystal ball&dquo; without knowingthe answer to &dquo;b;’ the ISO style integration approaches forcean equivalence of integration support across all needs. Thisimplies a massive overhaul of existing legacy systems andunjustifiable modifications by vendors of their existingsystems to achieve even a minimal level of integration sup-port. Thus, this &dquo;socialistic&dquo; approach just won’t work. Whatis clearly needed is a &dquo;capitalistic&dquo; approach where such ser-vices can be incrementally introduced as user demand

forces suppliers of the needed services to emerge. The key



72

is the establishment of the appropriate guidelines and struc-tures for the service contact specification, service protocol,service advertisement, and contracting so that a) once theexpense of setting up a service has been incurred, that ser-vice is available to all subscribers and b) the service broker-age evolves in an organized fashion. Under the &dquo;services&dquo;

concept, the platform focuses on advertisement, specifica-tion, and facilitation of &dquo;integration services.&dquo; In the

simplest realization of this concept, an application (or user)could request information services. Such requests would beadvertised across the &dquo;services&dquo; network. Applicationscapable of responding to the services request would, basedon availability, bid to provide the service. In fact, many ofthe capabilities of the &dquo;Integration Mechanism&dquo; componentof the ISO genre of integrated architectures would be carriedover under the notion of a planner (or general/systems con-tractor). Such a mechanism would support the generation ofa &dquo;service request&dquo; plan (or proposal) which would essen-tially be a design of a means to service a complex (or un-usual) request by employment of a number of advertisedservices. An important characteristic of this approach is thatthe integration planner only need be involved with thosemore complex service requests. This is in contrast to theCDM (conceptual data model) processor approach of theISO. In fact, there would be nothing preventing applications(or users) from serving as their own general contractors(i.e., having a hard coded proposal as part of the applicationcode), running only the risk of not knowing the latest ser-vices available. It is our conviction that the integration of anengineering application into a concurrent engineering plat-form should be viewed as an opportunity to provide greaterfunctionality to the system by providing new services andresources. The opportunity to incorporate new services intoa system must be addressed at three classes of services,namely:

(a) Passive services {Data, Information, Knowledge}(b) Active services {Application, Function, Inference}(c) Control {Configuration, Versioning, Context}

As these classes do not have strict ordering, vendors mayuse their discretion to advertise services in terms of genericcapabilities that can be rendered by their applications. Thus,an object may issue a service request to a Service Integra-tion Manager (SIM) that will post the request(s) directly toblackboards, serviced by domain brokers. The brokers puttogether service package proposals by assembling resourcesand methods and costs by broadcasting requests to a net-work of applications in their domain. These domain broker-ages can include network service, data service, version con-trol negotiation, geometry, etc. The brokered service

package includes a time window in which the services canbe initiated. There are at least two varieties of bid and pro-posal support that must be provided by the SIM. The firstvariety is referred to as the verified sources variety thatwould be implemented in a fashion similar to the ISO CDMprocessing scheme using a directed message passing para-

digm. The second variety (referred to as &dquo;open bidding&dquo;)would employ a stock exchange (blackboard) style ap-proach. The SIM then selects a package from amongst theservice proposals based on criteria such as duration and costand initiates the service. Figure 12 displays the operation ofthe SIM.The Planner components of the SIM would be based on

the following three premises:. Knowledge Driven Service Support Planning. Description-Based Information and Knowledge Integra-

tion Mechanism. Object Level Life Cycle Data and Life Cycle Knowledge

Evolution Control

The first premise, Knowledge Driven Service SupportPlanning, is simply the requirement that the planning com-ponent of the integration services system have an under-standing of the processes that it will be planning services for(and with). The information integration component of thisknowledge base can be built up from a process modelingspecification by the managers and technical leaders at a site.This resulting knowledge can then be loaded into the systemplatform. With this knowledge, the system can provide theadministration of the design data development process (aswell as the life cycle engineering knowledge evolution pro-cess) that was described above. The knowledge base integra-tion component of the EKAMD is described in a similarfashion (IDEF3), but the source of these descriptions comesfrom the design experience and rationale capturemechanisms as well as from experience captured from themanufacturing, maintenance, and operations personnel.

Figure 12. Service mtegration manager.



73

Figure 13. Multi-schema architecture approach

The second premise is that the system must have de-

scription-based integration service mechanisms. Informa-tion integration is necessary to provide complete and ac-curate access to (and control of) the life cycle data of thesoftware system. The number and variety of tools used inthe design activities throughout a product life cycle makesan integrated homogeneous (i.e., one supplier, one hard-ware platform that does all) environment impossible. In-

stead, tools must have the ability to access data and informa-tion that are created by different tools. In addition to theability to provide active information sharing between tools,information resources for making complex scoping, design,and change management decisions must be supported. Thisimplies the provision of ad hoc search and query supportwith both browsing and user defined presentation generation(reports, hypernotes, illustrations, etc.). However, we mustaccommodate an evolution to this goal. With the integrationservices approach we can initially support design tool inter-facing and, as the demand dictates and the vendor accom-modates, evolve to more functional levels of support. For

example, initially we may have to convert an entire CAD filefrom one system to the other to query for information abouta particular model. If, however, the users only requireanswers to directed questions (such as &dquo;what is the normalvector at a particular point&dquo;), then the vendor could providethis capability as an exported service in latter releases of hisproduct. To accomplish this, support service descriptionsmust be defined for each vendor or legacy tool as well asinformation descriptions for those life cycle artifacts de-veloped or managed outside of a particular tool. These de-scriptions must be used as an active component of the ad-vertisement, planning, and contracting elements of the

service environment. The integration services planningmechanism will then have the ability to use these descrip-tions to support access/control of the data produced by aspecific tool. This mechanism must also have the ability torecognize which object is being accessed so that the appro-priate framework constraint can be applied.This information integration planning support provided

by the integration services component in the EKAMD wasaccomplished using a multi-schema architecture imple-

mentation of the ISO conceptual schema standard as seen inFigure 13. The schemas in addition to the three standard

schemas depicted in that figure are knowledge bases thatdefine the life cycle information managed by the proposedframework programmable platform. They not only specifywhat data exist but also how to access the data, what con-straints exist on the data, and how the data is/can be used.This complete description of the information making up thesystem is a major means of providing the type of control thatthe programmable framework system will give.

Effective integration support depends on the third premiseof Object Level Life Cycle Data Evolution. Previous inte-gration and technical data management/control strategieshave taken one of two approaches:

1. Data translation standards from one format to another2. Object definition and control at the file level

Both of these ideas can be supported by the integrationservices approach. Data translation standards can be set upinitially to enable application/tool interfacing. A preplannedcommunications link between two tools can easily be es-tablished. The result of the traditional integration archi-tectures (which supported such links) was that any tool thatwas to be integrated must have these communication linksset up. Using the planner services of the EKAMD estab-lished communication and translation services will be ableto be combined into powerful new interfaces on demand.This approach delivers both the performance as well as theappearance of integration without radical modifications tothe vendor programs and without a combinatorial growth ininterface program development.

File level control (while an appropriate first step) is not

fine grained enough. For example, in a system design, it is

often useful to refer to a specific requirement in the systemrequirements document. In an integrated system that oper-ates at the file level, this reference could only be made to therequirements document. If this requirements documentwere changed, the entire document would have to be parsedto determine if the change affected the design. However, theservices approach can provide intelligent support to this tra-ditional approach as required.



74

As Life Cycle Data and life cycle engineering knowledgebegin to be represented and controlled at the object level,these two methods would be obsolete. No format translation

methods between tools would be required because the inte-gration services mechanisms would have the ability to ac-cess all versioned objects directly. The second problem ofhaving to parse the entire file would be eliminated becausea notification would be sent only when the specific require-ment object was referenced by the design document whenmodified. Clearly, this is the best way to proceed. However,it requires that the tools and utilities that make up the designsupport environment be based on these premises.The power of the &dquo;services&dquo; approach to integration is bet-

ter illustrated by the introduction of legacy (or existing com-mercial) engineering CAD-based applications into the

EKAMD platform. Figure 14 illustrates the architecture ofsuch a typical application [26]. The view taken in the con-struction of this illustration is that there are core reusablefunctions that are integrated together into the application bythe construction of application specific interface layers ontop of the functional levels. Under the &dquo;services&dquo; approachto integration, the level of integration of such a system willbe largely defined by the level of access to these underlyingfunctional methods that a legacy system provides.

Figure 15 illustrates the assimilation of such a legacysystem into the EKAMD. The primary determiner of thelevel of passive, active, or control services provided by thatsystem is determined by the number of service contracts that

the system can satisfy through the advertised protocols ofthose services. It is clear that initially, a legacy system maynot offer any services whatsoever. Its existence in the systemwill be justified solely on the particular function that it pro-vides to the direct users. In fact, in some cases this may bethe terminal stage of such a package. However, in the

fiercely competitive world of CAD/CAE/CAM applications,such an isolated tool has a low probability of survival. It islikely that at least data access services will be requested ofthe application. The opportunity offered by the EKAMD isthat these integration requests can be handled on a case-by-case basis by modular extensions (essentially additional in-terfaces to the underlying generic functions of the applica-tion).A major task in this work was the further definition and

implementation of this services approach to integration. Asmentioned previously, this approach can build directly off ofthe initiatives and research results of the ISO conceptualschema architecture community.For example, standards such as the evolving PDES and

the ISO STEP would serve as powerful mechanisms forspecification of both service contracts and protocol ontol-ogies.

6. Summary and Conclusions

The proposed EKAMD would be usable as a base concur-rent engineering platform for almost any engineering auto-

Figure 14. Legacy system architecture.



75

Figure 15. Installation of legacy application into services network.

mation effort. It would provide a significant improvementover any available design automation concept available to-day. EKAMD can provide support for design engineers tobetter integrate the trade-off of various design attributessuch as performance, cost, schedule manufacturability, andsupportability. It will also result in significant reduction inthe engineering cycle time and manpower requirements forboth initial product design and sustaining engineering of aproduct. By supporting the knowledge-based delivery ofmanufacturing and maintenance experience to the initial

product designers, an order of magnitude reduction in rede-sign and engineering change requests can be realized.

Acknowledgement

This research was funded by Air Force contract AFHRL-TP-90-81.

References

1. da Silva, R. E. et al. 1991. "An Algebraic Approach to Geo-metric Query Processing CAD/CAM Applications," June.

2. Barwise, J. 1983. Situations and Attitudes. Cambridge, MA:MIT Press.

3. Bunt, H. The Formal Representation of (Quasi-) ContinuousConcepts in Formal Theories of the Commonsense World.

Norwood, NJ: J. Ablex Publishing Corporation.

4. Henderson, M. R. 1985. "Extraction and Organization ofForm Features," in Proceedings of Prolamat, pp. 131-141.

5. Kim, Y. S. 1992. "Recognition of Form Features Using Con-vex Decomposition," Computer Aided Design, 24(9).

6. Woo, T. C. H. 1975. "Computer Understanding of Designs,"Ph.D. Thesis, Urbana-Champaign, IL: University of Illinois.

7. Woo, T. C. 1982. "Feature Extraction by Volume Decomposi-tion," Proc. Conf. CAD/CAM Technol., Mechanical Eng.,MIT.

8. Requicha, A. A. G. and J. H. Vandenbrade. 1989. "FormFeatures for Mechanical Design and Manufacturing," Com-puter in Engineering, Book No. G0502A.

9. Requicha, A. A. G. and J. H. Vandenbrade. 1989. "SpatialReasoning for Automatic Recognition of Interacting FormFeatures," ASME International Computers in EngineeringConference, MA, August.

10. Shah, J. J. and M. T. Rogers. 1988. "Expert Form FeatureModelling," Computer-Aided Design, 20(9), November.

11. Marefat, M. and R. L. Kashyap. 1990. "Geometric Reasoning



76

for Recognition of Three Dimensional Object Features," IEEETransactions on Pattern Analysis and Machine Intelligence,12(10), October.

12. Hiroshi, S. and D. C. Gossard. 1990. "Recognizing ShapeFeatures in Solid Models;’ IEEE Computer Graphics and Ap-plications, September:22-32.

13. Gossard, D. C. et al. 1988. "Representing Dimensions, Toler-ances, and Features in MCAE Systems," IEEE ComputerGraphics & Applications, March.

14. Joshi, S. and T. C. Chang. 1988. "Graph-Based Heuristics forRecognition of Machined Features from a 3D Solid Mode,"Computer Aided Design, 20:58-66.

15. Shah, J. J. 1988. "Current Status of Features Technology,"CAM-I Report R-88-GM-04.1.

16. Duffey, M. R. and J. R. Dixon. 1988. "Automating ExtrusionDesign: A Case Study in Geometric and Topological Reason-ing for Mechanical Design," Computer Aided Design, 20(10),December.

17. 1985. ICAM Project 1701, "Systems Engineering Methodolo-gies," Vol. 1-7, AFWAL/MLTC WPAFB OH December.

18. De Floriani, L. 1989. "Feature Extraction from BoundaryModels of Three Dimensional Objects," IEEE Transactions onPattern Analysis and Machine Intelligence, 11(8), August.

19. Poole, D. 1990. "A Methodology for Using a Default and Ab-ductive Reasoning System," International Journal of Intelli-gent Systems, 5:521-548.

20. Dahshan, K. and J. Bezivin. 1990. "Constraint Propagation inan Object-Oriented Environment: A Mechanical CAD Ex-perience, Technology of Object-Oriented Languages and

Systems," Proceedings of the Second International Con-

ference.

21. Crocker, G. A. and W. F. Reinke. 1991. "An Editable Non-manifold Boundary Representation," IEEE Computer Graph-ics & Applications, March.

22. Kautz, H. A. 1985. "Formalizing Spatial Concepts and SpatialLanguage, in Common Sense Summer, C.S.L.I., Stanford,Summer.

23. Retz-Schmidt, G. 1988. "Various Views on Spatial Preposi-tions," AI Magazine, 9(2), Summer.

24. Hobbs, J. et al. 1987. "The Tacitus Commonsense KnowledgeBase (Rough Draft)," Artificial Intelligence Center, SRI Inter-national, July 12.

25. Serrano, D. 1987. "Constraint Management in ConceptualDesign," Ph.D. Thesis, Massachusetts Institute of Technology.

26. Krause, F.-L., M. Beinert, K. Fortmann, et al. 1989. "SystemArchitecture for CAD/CAM Integration," Final Report, En-gineering Office of Scientific Affairs, Chrysler Motors Cor-poration, Highland Park, MI.

Chuan-Jun Su

Chuan-Jun Su received the B.S.

degree in applied mathematics fromNational Tsing Hua University,Taiwan, in 1978. He received the

Ph.D. degree in industrial engineer-ing from Texas A&M University,College Station, Texas, in 1989.From 1989 to 1994, he was visitingprofessor in the Industrial En-

gineering Department, Texas A&MUniversity. He is currently an assis-tant professor at Industrial En-

gineering Department, Hong Kong University of Scienceand Technology. His research interests include artificial in-telligence applications, system modeling, CAD/CAM, andvirtual reality.

Mitchell M. Tseng

Professor Mitchell Tseng holds aB.S. degree in Nuclear Engineeringfrom the National Tsing Hua

University in Taiwan, a M.Sc.

degree in Industrial Engineeringand a Ph.D. from Purdue Univer-

sity. He joined the HKUST facultyas the founding department head in1993 after working in industry foralmost two decades. He started his

career in industry as a Manufac-turing Engineer and progressed

through several senior technical and management positions,including product development, information technology,and system integration services. He previously held facultypositions at University of Illinois and Massachusetts Insti-tute of Technology. His research interests include processre-engineering, systems design, systems integration, andproduct development.

Richard J. Mayer

Dr. Richard J. Mayer is an associate professor of Indus-trial Engineering Department, Texas A&M University. Hespecializes in knowledge based systems in engineering,manufacturing and business. Current activities include for-mal semantics for process and ontology description lan-guages, non-manifold geometric modeling, shape basedreasoning, and semiconductor manufacturing process simu-lation modeling and cost estimation. He directs the Knowl-edge Based System Laboratory and teaches description rep-resentation, qualitative reasoning and systems engineeringmethods.



Documents

EKAMD--A Knowledge-Based Concurrent Engineering Support System