A structure-function-control paradigm for knowledge-based modeling and design of manufacturing workcells


Material Information

A structure-function-control paradigm for knowledge-based modeling and design of manufacturing workcells
Physical Description:
vii, 138 leaves : ill. ; 28 cm.
Papaconstantinou, Constantinos A., 1961-
Publication Date:


bibliography   ( marcgt )
theses   ( marcgt )
non-fiction   ( marcgt )


Thesis (Ph. D.)--University of Florida, 1991.
Includes bibliographical references (leaves 130-137).
Statement of Responsibility:
by Constantinos A. Papaconstantinou.
General Note:
General Note:

Record Information

Source Institution:
University of Florida
Rights Management:
All applicable rights reserved by the source institution and holding location.
Resource Identifier:
aleph - 001717497
notis - AJC9905
oclc - 25622391
System ID:

Full Text







To my family
for all their
love and support.


I would like to express my deepest gratitude to my advisor, Dr.
Keith L. Doty. His friendship, guidance, support, and encouragement
were invaluable. I thank him for the many hours he spent with me,
discussing and constructively criticizing my work. I have learned a
lot from him.
Special thanks to Dr. Stefano Caselli. The many discussions
with him helped develop some of the ideas in this dissertation.
I would also like to thank the members of my committee, Dr.
Herman Lam, Dr. Douglas Dankel II, Dr. G. Basile, and Dr. S. Yeralan,
for taking the time out of their busy schedules to read and correct
my work. I appreciate their friendship, help, and constructive
I would like to thank the members of MIL: Akram, Eric, Mark,
Pablo, Rana, and Kim. It was a pleasure to work with them. I will
always be their friend.
Finally, I would like to thank my family. I could not have done
it without them. Many thanks to my mom for all the sacrifices she
made so I could be what I am today. Special thanks to my uncle
Andreas and my aunt Caculla for all their love and support
throughout the years.


ACKNO W LEDG M ENTS .................................................................................................i ii

ABSTRA C T.............................................................................................................v i


1 IN T R O D U C T IO N ..................................................................................................1

2 D A TA M O D E LS ....................................................................................................9
Hierarchical Model ............................................................................. 10
N etw o rk M ode l ............................................................................................... 1 0
Relational M odel .................................................................................... 1 1
Semantic and Object-Oriented (0-0) Data Models.......................1 3
The Object-Oriented Semantic Association Model
(O S A M *) ...........................................................................................................1 7

Peculiar Features of the Manufacturing Domain ..........................20
P previous W ork ......................................................................................... 2 2

4 THE STRUCTURE-FUNCTION-CONTROL PARADIGM ..............................2 6

5 THE SEMANTIC DATA MODEL................................ ................................31
S-F-C Object Definitions..................................................................3 2
Structural Knowledge Representation .............................................. 3 6
Example 1. Modeling Parts.......................................................
Example 2. Workcell Components Library..............................4 3
Functional Knowledge Representation ..............................................4 6
Semantic Associations in the Functional Domain......................47
Aggregation and Functional Aggregation.............................47
Functional Generalization ................................................... ....5 4
Iteration Association ........................................................ .....5 6
Provides/Provided_by Association ...................................... 7
The Functional Knowledge Representation............................6......0..

TH EO R Y ...............................................................................................................6 5
The Algebra of Function Sequencing .............................................. 6
The Algebra of Discrete Assembly Operations .............................70
Discrete Assembly Examples ................................................... ........ 4
A Methodological Procedure for Generating Functional
Semantic Schemas Corresponding to Manufacturing
Procedures ...................................... ...................................................... ..........8..

7 THE CONTROL MODEL................................................................................8 8
Introduction to Petri Net Theory............ .................................. ..8 8
What are Petri Nets?...............................................................89
PN Examples..............................................................................9 3
Control Representation.........................................................................9 7
General WC Control Knowledge ...................................... ..9 8
Control Structures.............................. .................................... 9

8 TOP-DOWN WORKCELL DESIGN.................................................................... 01
D esign Procedure ..................................................................................... 1 0 3
Illustrative Example ..................................... .......................................... 105
Product Definition .........................................................................108
Process Selection ..........................................................................108
Equipment Selection ..................................................................... 111
Function Allocation/Transportation Architecture......1...1 14
Workcell Layout .............................................................................. 1 9
Control Synthesis.....................................................................1 20

9 CONCLUSIONS ............................................................................................... 27

REFERENCES.............................................................................................................. 1 30

BIOGRAPHICAL SKETCH ........................................................................................ 8

Abstract of Dissertation Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Doctor of Philosophy


Constantinos A. Papaconstantinou
December 1991

Chairman: Dr. Keith L. Doty
Major Department: Electrical Engineering

This dissertation discusses the integration of structural,
functional and control knowledge in manufacturing workcell
modeling, simulation and design. After an overview of applications
of semantic and object-oriented data models in the manufacturing
domain, issues relating to the control synthesis for manufacturing
workcells are presented. In particular, a data model encompassing
functional and control features, along with application domain
structural knowledge, is developed. This model assists in explicitly
representing the control aspects of engineering design within an
object-oriented data base and supports a task level, functionality
driven, manufacturing workcell design.

Since manufacturing workcells consist of a number of
elements interacting in a complex manner, workcell control design
is one of the most difficult steps in the workcell design procedure.
Message passing, commonly used in object-oriented databases,
provides no explicit modeling of the database behavior. Hence, it
cannot serve as a tool for the design of system control. On the other
hand, Petri nets have proven successful in describing complex
interaction among active agents. This work explores the
incorporation of Petri nets as a basis for describing application
control knowledge within a structure-function-control data model.
A manufacturing workcell design methodology is outlined,
which makes use of the proposed tools and ideas. This methodology
is intended to be used as the skeleton of a software tool that
assists in the manufacturing workcell design process.



During the last few years we have been witnessing a dramatic
change taking place in the field of manufacturing. Due to intensified
foreign competition and the increase in cost of labor and materials,
we see a widespread introduction of programmable automation in
manufacturing. Programmable equipment such as robots,
numerically controlled machines, and sensors provide increased
flexibility with the trade-off of increased complexity. The basic
unit of a manufacturing facility, the manufacturing workcell
consists of an integrated set of programmable devices capable of
performing certain manufacturing functions. Flexibility at the
shop-floor level and factory-wide Computer Integrated
Manufacturing (CIM) are the fundamental paradigms that have been
proposed in order to achieve manufacturing goals such as low
production cost and reduced time-to-market for new products.
Whatever the manufacturing strategy being pursued, its performance
and success are largely dependent on the use of state-of-the-art,
cost-effective manufacturing workcells, optimized for the required
application domain.
In current practice, manufacturing workcell design requires
extensive human effort in terms of time, cost and expertise, thus
preventing full achievement of the potential benefits of automation.


A diverse team consisting of individuals from different engineering
areas starts by generating an initial design that satisfies the
manufacturing requirements. Very frequently the workcell has to be
physically built, tested, and further modified if necessary. The team
may need to iterate through this process several times until the
implementation meets the specified requirements. The overall
process is very difficult and time-consuming [Levas and Jayaraman,
1989; Papaconstantinou et al., 1989b]. A 1986 study comparing
Flexible Manufacturing Workcell development times in the U.S. and in
Japan showed figures of 2.5 to 3 years and 1.25 to 1.75 years,
respectively [Jaikumar, 1986]. Similar figures were obtained in
1989 through informal interviews of electronic and mechanical
assembly workcell manufacturers [Fernicola, 1990]. Such a long
development time is convincing proof of the technical difficulties
inherent in manufacturing workcell design. This fact often promotes
a conservative approach to workcell design that largely relies on
minor variations of an established solution and its adaptation to as
many applications as feasible. This results in deterring many
significant design improvements and the timely incorporation of
technological advances as they become available [Caselli et al.,
Even though computer tools have been used for a long time in
specific areas such as Computer-Aided Design (CAD), Numerically
Controlled (NC) machine programming and individual equipment
programming, limited support exists for overall manufacturing
workcell design, especially when compared with highly automated
areas like electronic design.

In recent years, advances in several computer-related
technologies such as speed of computation, graphics interface
capabilities, software engineering, data base systems, artificial
intelligence, as well as the increased worldwide economic
competition, have stimulated efforts towards the development of
new tools for manufacturing workcell design. These new efforts
could be observed in both research laboratories [Levas and
Jayaraman, 1989; Papaconstantinou et al., 1989b] and industry
[Silma, 1989; Tecnomatix, 1989; Deneb, 1990]. Such tools can offer
a very significant payoff, since there is a great potential for
improvement in the workcell design domain. However, the lower
degree of standardization existing in workcell equipment with
respect to other domains (i.e., electronic devices) is an inherent
difficulty. Furthermore, even though the number of devices within
the workcell may be small (i.e., in the 10-20 range), each workcell
component can be very complex (i.e., a robot, or a 5-axes machining
center). Thus, the development of a CAD tool for workcell design
calls for hierarchical modeling and design techniques. As part of the
continuous research effort on this subject at the Machine
Intelligence Laboratory of the University of Florida since 1985,
work has been devoted to the application of advanced data modeling
techniques in the development of support tools for manufacturing
workcell operation, modeling and design [Govindaraj and Doty, 1986;
Desai et al., 1988; Pal, 1988; Papaconstantinou et al., 1989a;
Fernicola, 1990].
Currently, the expertise required for manufacturing workcell
design is large and scattered among many different sources, such as

parts catalogs, human experts and templates from previous designs.
Design productivity can be greatly improved by the integration of
this body of knowledge by means of proper database management
techniques. However, the inadequacy of traditional data models
(relational, network, hierarchical) in the engineering context has
been amply demonstrated [Eastman, 1981].
Recently, advanced data modeling paradigms such as
object-oriented and semantic data models have been proposed as
viable tools for conceptual modeling in the manufacturing domain
[Hull and King, 1987; Spooner et al., 1988; Su, et al., 1989]. These
paradigms can cope with hierarchical and heterogeneous knowledge
as well as support complex data types. These models provide the
Abstraction: Designs can be represented at various levels using
the same model by suppressing unnecessary details.
Semantic Descriptive Mechanisms: The models allow a variety
of building blocks to describe designs or design activities with a
rich, yet machine-processable description.
Integrity Constraints: It is possible to state relationships and
constraints that restrict allowable designs.
Existing object-oriented and semantic data models, although
providing us with useful tools and facilities such as the ones just
mentioned, are designed for general use. This generality in these
data models introduces a problematic concept called semantic
overloading [Hull and King, 1987; Atwood, 1991]. Semantic
overloading in data models refers to the use of a few basic
constructs to convey a wide array of meanings and relationships.

This lack of expressive power prevents full use of semantic
information for more effective data management policies and
integrity enforcement. In order to alleviate this problem, special
semantic associations which are tailored to the manufacturing
domain can be introduced. These additional semantic associations
are fine tuned to the application domain in order to enhance
modeling power. We believe that the trade-off of generality for
modeling power is justifiable in a very specialized domain such as
Furthermore we see a need for an additional semantic layer to
be developed on top of these general purpose data modeling
paradigms in order to support a dynamic activity, such as
manufacturing workcell design, while still exploiting all the
knowledge embedded in the available design specifications.
In particular, it has been pointed out in the literature that the
engineering domain often requires integration of both structural and
functional knowledge [Caselli et al., 1990; Cornelio and Navathe,
1990; Markowitz, 1990]. In manufacturing workcell design, control
knowledge also plays a crucial role. Arguably, since manufacturing
workcells consist of a number of agents interacting in a complex
manner, synthesis of the control logic can be the most difficult step
of the overall design procedure. However, this step is not
adequately supported by the available data and knowledge modeling
paradigms and is typically left to ad-hoc or brute-force development
techniques. The standard object-oriented data base technique for
object interaction modeling, namely, message passing, does not
provide explicit modeling of the database behavior per se.

Therefore, message passing cannot serve either as a system control
design tool or as a document of system behavior. On the other hand,
Petri nets have proven to be successful in describing complex
interaction among active agents [Peterson, 1981; Reisig, 1985;
Murata, 1989; Desrochers, 1990; Teng and Black, 1990]. Chapter 7 of
this dissertation explores the incorporation of Petri nets as the
basis for describing application control knowledge within a
structure-function-control data model.
A data model is proposed and then applied to the workcell
design process in detail. According to this model, functional
knowledge about the manufacturing process is used as the driving
force for the whole design activity. Structural objects
corresponding to workcell components capture the structural
knowledge. Control knowledge is expressed in the form of Petri
nets, which are then combined with constraints derived from the
functional and structural objects. The goal of the latter activity is
to synthesize control programs for the agents in the workcell.
This dissertation specifically investigates the use of object
oriented semantic models and Petri nets as the basis for describing
application knowledge within a Structure-Function-Control
paradigm. In addition it attempts to show their usefulness in the
workcell design process. In particular, some known applications of
semantic models in the Computer Integrated Manufacturing (CIM)
area are reviewed and discussed. These applications are mainly
related to the modeling of existing systems and scarcely address the
support of workcell design activity. A simple data and knowledge
organization for manufacturing workcell design is introduced, which

is expressed by means of semantic associations and formulated
using a subset of the features provided by complex, state-of-the-art
semantic data models [Su et al., 1989; Cornelio and Navathe, 1990].
This simple model is then enhanced by the introduction of semantic
associations which are tailored to the manufacturing domain. Next.
the role of the functional specification of the manufacturing process
as a high-level (task-level) specification driving all the design
activity is examined. The overall design process is illustrated.
emphasizing the use of semantic schemas as the main descriptive
tools capable of capturing much of the design knowledge required
across several stages of the design procedure. Furthermore, the use
of Petri nets as the basis for describing the application control
knowledge is explored. The Petri net representing the workcell
control can be used in order to verify the workcell design, through
simulation. In addition, after verification the same control
structures can be used as the controlling mechanism of the physical
workcell at run-time. The Petri net representation has been proven
to be an intuitive and powerful representation in describing
interrelated, complex and concurrent activities such as workcell
A detailed workcell design procedure is proposed. According
to this procedure functional knowledge about the manufacturing
process is used in the early stage as a high-level specification
driving all the design activity. This functional knowledge is then
used to guide and constrain the workcell equipment selection
(structural components). As a result, of this activity a process plan
is derived within the functional specification. Finally, a

methodology is provided which enables the transition from the
functional specification domain to the Petri net representation


The traditional database models, namely relational,
hierarchical and network, were the dominant data modeling tools of
the 1970s. At that time, computers were not widely available, and
their use was mainly restricted to large corporations such as banks
and government agencies. The data structures used by these models
were relatively close to those used for paper and pencil
representation of the data. These models presented the data as
collections of records with printable values. These models are
generally referred to as record-based models [Hull and King, 1987].
As computer technology became more affordable, these traditional
systems started appearing in engineering, science, statistical and
military domain applications. Application data in these latter
domains are more complex both structurally and semantically. The
use of these systems in increasingly complex domains pointed out
their deficiencies and limitations, in terms of both functionality and
speed [Su et al., 1989].
By the time the engineering domain had evolved to the point
where data management became a real issue, the relational model
had supplanted the other models (i.e., hierarchical and network)
[Atwood, 1991]. As a result of this we see that, of the traditional

models, the relational model [Codd, 1970] and its extensions came to
be the most popular ones in the engineering domain.
A brief description of the so called traditional models is given

Hierarchical Model
A hierarchical database consists of an ordered set of tree
types. A tree type consists of a single root record and an ordered
set of zero or more child records. A child record can itself be a tree
type. In effect the hierarchical database consists of a forest of
trees. A restriction imposed on this structure is that, with the
exception of the root nodes, every node in the database must be the
child of a single parent node. Operations for data manipulation are
at the record level (as opposed to a set of records). Operators are
provided for locating a specific subtree in the database, for moving
from one subtree to the next, for moving from the parent to the child
record and vice versa, and finally for inserting and deleting records
[Date, 1986].

Network Model
The network model, which could be regarded as an extension of
the hierarchical, allows a child record to have any number of parent
records. Specifically, a network database consists of a set of
multiple occurrences of each of several types of record and a set of
multiple occurrences of each of several types of link. Every
occurrence of a given link type involves a single occurrence of the
parent type, together with a set of occurrences of the child record

type. Several operations are provided that can manipulate this
network structure, in order to locate and retrieve, delete and insert
data records. As in the hierarchical model, these operators are at
the record level [Date, 1986].

Relational Model
The relational model captures data in a set of relations
(tables). These relations consist of uniformly formatted records.
Each record consists of an ordered set of attributes. Attributes are
atomic data values like strings, integers, floating point numbers,
dates, etc. Each relation has an attribute (or a combination of
attributes) that uniquely identifies every record in the relation.
This attribute (or combination of attributes) is called the primary
key of the relation. The user perceives the data as a set of tables
and nothing but tables. The data manipulation operators generate
new tables from old. Therefore, these operators are producing sets
of data, not record instances as in the case of the hierarchical and
network models. The simplicity inherent in the relational model
made it very popular in both the business and engineering domains.
When used to model complex engineering data though, the relational
model exhibits some serious problems. Some of these problems are:

1. Only a single primitive (the relation) is provided for handling
both real-world objects and their interrelations [Atwood,
1991]. This phenomenon is commonly known as semantic
overloading [Hull and King, 1987]. Whatever semantics are
not captured by the model need to be represented and

enforced by the application programmer [Su et al., 1989;
Atwood, 1991].

2. The regular record structure consisting of atomic attribute
values is incapable of explicitly modeling repeating groups
and hierarchically structured information [Haskin and Lorie,
1982; Lorie and Plouffe, 1983].

3. The disjoint tabular structure, in most cases, cannot store
close together all data belonging to a single object.
Therefore when working with complex objects, performance
is poor [Guttman and Stonebraker, 1982; Vbase, 1988]. (A
complex object is a collection of semantically related tuples
from different relations into a single database entity [Haskin
and Lorie, 1982].)

4. Long, variable length fields are not fully supported. This
generates problems when the application calls for the
storage and manipulation of data objects like digital images,
Computer Aided Design (CAD) documents, etc., data types
commonly found in the engineering domain.

5. There is poor separation between the high-level conceptual
organization of the database and its physical implementation.

Realization of the limitations exhibited by the relational
model generated a significant amount of research in the area of

engineering databases. Improvements and/or extensions of the
relational model have been reported in the literature. For example,
the INGRES relational DBMS (from the University of California,
Berkeley) and the System R relational database (from IBM), were
extended [Astrahan et al., 1976; Stonebraker et al., 1984;
Stonebraker and Rowe, 1986; Row and Stonebraker, 1987;
Stonebraker et al., 1987a; Stonebraker et al., 1987b]. Both systems
now incorporate complex objects, abstract data types, procedures
and rules. These additions were attempts to enhance the relational
model in such a way as to make it a sophisticated database tool for
the engineering domain.

Semantic and Object-Oriented (0-0) Data Models
In the database domain, semantic models refer to data models
which provide a set of modeling constructs capable of explicitly
representing the semantics of the application domain. These models
generally provide a set of modeling constructs which closely
parallel the types of relationships typically arising in database
application areas.
Historically, semantic database models were developed to
support the conceptual design (early stages of the database design)
of databases. By providing higher levels of abstraction, these
models allow the designer to think and manipulate data in ways that
correlate more directly to how data arise in the real world [Hull and
King, 1987; Gupta et al., 1989].
Some of the best facilities provided by semantic models are
the following [Hull and King, 1987]:

1. Separation of the conceptual and physical components of data.
2. Decreased semantic overloading of relationship types.
3. Availability of abstraction mechanisms.
4. The explicit representation of objects and object attributes.
5. The explicit representation of relationships among objects
6. Type constructors for building complex objects.
7. Derived schema components.

The most common data modeling facilities provided by
semantic models are reviewed next. At the end of this section,
OSAM*, a powerful object oriented semantic association model, is
reviewed. This model, originally proposed in Su's work [Su et al.,
1989], is under development at the the Database Research and
Development Center of the University of Florida. The model proposed
in this dissertation borrows from and relies heavily on the OSAM*
Most semantic models distinguish between abstract and
printable (or representable) data-types. Abstract types are usually
used for modeling physical objects such as robots or conceptual
objects such as manufacturing plans. These abstract types are
usually assigned a unique internal object identifier (OID). Printable
data types are typically character strings, floating point numbers,
integers, etc.
In addition, most semantic models provide mechanisms to
represent atomic and constructed data types. Atomic types are non
aggregate objects and usually draw their values from a domain
which is of the printable type. Constructed data types are types

which result from an association (a grouping) of either atomic
and/or constructed types [Hull and King, 1987].
Semantic models provide several powerful modeling concepts.
The most common ones are reviewed below [Elmasri and Navathe,

Classification and Instantiation: These two operations are the
inverse of each other. Classification is the process of classifying
similar objects into object classes. In effect, it defines an
abstraction which hides the individual objects. We could, therefore,
manipulate the abstraction instead of the individual objects
themselves. Instantiation is the opposite of classification in that
from a general description we generate a particular object instance.

Identification: Identification refers to the concept of being
distinguishable. Unlike the relational model that uses an attribute
(or set of attributes) as a unique identifier (i.e., the key), most
semantic models represent objects using an internal identifier
called the object identifier (OID).

Generalization and Specialization: Virtually all semantic
models provide the ability to represent subclass/superclass (Isa)
relationships. Given an object class, sometimes it may be useful to
define subgroupings subclassess) of this class. For example, the
class workcell equipment may be further subdivided into


Transportation Process Auxiliary
equipment equipment equipment

Figure 1. An example of a Generalization (Is_a) hierarchy.

transportation, process and auxiliary equipment (see Figure 1). The
class workcell equipment represents more general properties of
objects than any of its subclasses. Every object that belongs to any
of the subclasses has to belong to the superclass also, therefore
satisfying the Is_a relationship. This relationship can be viewed
from two different perspectives. At first, consider a set of similar
object classes. By factoring out all commonalities from these
classes and placing these commonalities in a different class, we can
generate a superclass. This newly defined superclass could be
viewed as the generalization of its subclasses. Another way of
viewing the same relationship is by starting at a class and forming a
set of subclasses based on some distinguishing characteristics of
each one of the subclasses (i.e., the subclasses are more specialized

than the superclass). For example, the workcell equipment class is
partitioned into three subclasses as in Figure 1.

Aggregation Association: Aggregation is the concept of
building composite (complex) objects by combining other objects.
This association captures the semantics of the is a part of
relationship. For example the robot class in Figure 2 is defined by
combining the class manipulator and the class controller. Therefore
every instance of the class robot is made up of a manipulator and a


Robot A


Figure 2. An example of an Aggregation association.

The Object-Oriented Semantic Association Model (OSAM*)
The OSAM* model provides a conceptual basis for uniformly
capturing the semantics and interrelations among objects in an
application. It possesses most of the concepts and features of the

object-oriented paradigm such as classification, encapsulation and
multiple inheritance. In addition OSAM* allows for the definition of
rules and methods as a part of an object class. In OSAM* there are
two types of object classes:
Entity object class (E-class): This class models objects in the
application that are accessed independently. It is represented as a
rectangle in the Semantic diagrams (See Figure 1).
Domain object class (D-class): This class models the domain
(e.g., the type of data, the permissible range of values, etc.) that may
be used by some other class. Therefore, it could be thought as an
abstract data type. A D-class is represented as a circle in the
semantic diagrams.
An object class may contain:

1. A set of associations: An association defined on a class
captures the semantic and structural relationship between
this class and other classes (its constituent classes). There
are five semantic associations defined in OSAM*. They are:
Aggregation (A), Interaction (I), Composition (C), Cross
product (X) and Generalization (G).
2. A set of methods: These operations provide high level access
and manipulation of the class and its objects.
3. Rules and constraints: The rules are used to derive new
information and the constraints are used to maintain
knowledge base consistency.

Of the above semantic associations, the ones adopted for use
in this dissertation are described below.
Aggregation Association (A): An E-class can have an
aggregation association with other classes. This association
defines a set of attributes for the defined E-class. The constituent
object classes serve as domains for these attributes and can be
either D or E classes. The attributes correspond to the instance
variables of object oriented languages.

Generalization Association (G): An E-class can represent more
general properties of objects than any of its constituent classes. In
this case, if each object in its constituent classes is also an object
of this class, then this E-class is called the superclass, and its
constituent classes are its subclasses. A superclass can be itself a
subclass of some other E-class. The OSAM* model supports multiple
inheritance, therefore, allowing a class to have more than one

Interaction Association (I): An E-class can be used to model
some action or relationship between two or more constituent
E-classes in an Interaction association. The links connecting the
E-class with its constituent E-classes represent attributes of the
E-class. The cardinality of the links may be one-one, one-many or
A detailed description of the OSAM* model as well as formal
definitions of all the semantic associations are given in the paper by
Su [Su et al., 1989].


Application of advanced data models in the manufacturing
domain has been discussed by several researchers [Eastman, 1981;
Nackman, 1985; Spooner et al., 1985; Su, 1986; Hull and King, 1987;
Wedekind and Zoerntlein, 1987; Jablonski et al., 1988; Ketcham et
al., 1988; Spooner et al., 1988; Staley and Boudreaux, 1988].
Actually, the manufacturing domain itself has motivated much of the
work on semantic models, stemming from the perceived inadequacy
of Data Base Management Systems (DBMS) based on traditional,
record-oriented data models (relational, network, hierarchical) in
such a context.

Peculiar Features of the Manufacturing Domain
The manufacturing domain exhibits peculiar features, when
compared to other classical application fields of DBMS that prevent
a profitable use of the more traditional data models [Su, 1986;
Jablonski et al., 1988]. Some of these peculiarities are listed below.

1. In manufacturing there exists an explicit hierarchical
structure of the application, with strong data-locality
properties. This structure is usually known in advance
[Jablonski et al., 1988]. Often, this a priori knowledge cannot

be fully exploited in the relational model. The "flat" data
surface and customized user access policies developed by a
relational DBMS are better suited to the business domain.

2. The computer architectures supporting CIM not only are
distributed and hierarchical by nature, but are also invariably
characterized by heterogeneity in the processing elements
and equipment they encompass. The latter characteristic
follows from the fact that CIM is often implemented on top
of existing manufacturing and computing facilities. Even for
new plants, computer-controlled manufacturing requires
specialized equipment typically not available from a single

3. Manufacturing workcell devices are generally viewed by the
designer as entities which have some "state" and are able to
exhibit some "behavior." This is due to the fact that these
abstract models simplify the designer's interaction with the
device, by eliminating unimportant device implementation
details. Object oriented techniques could be used to build
such abstract component models in a natural way--natural in
the sense that the resulting design pieces are closely
identified with the real world objects which they model
[Korson and McGregor, 1990].

4. The manufacturing domain encompasses many different
activities, from business-related raw parts purchase,

product sales and cost accounting to highly technical
tool-wear measurements and dynamic production scheduling.
Support for complex data types, such as engineering drawings
of parts or Numerically Controlled (NC) machine programs, is
also required.

Previous Work
This section reviews some of the previous work in the field
and highlights those issues more directly relevant to manufacturing
workcell design.
Advanced data modeling techniques, such as semantic data
models, have been proposed in the manufacturing domain, especially
to support the Computer Integrated Manufacturing (CIM) concept.
Integration of the many diverse factory activities, particularly
data-driven manufacturing, requires a substantial amount of data to
be created, manipulated and shared or exchanged among several
decision centers. These decision centers are usually located on
autonomous processing nodes within a distributed computing
architecture. Data-driven manufacturing refers to the methodology
within CIM for automating the information flow between product
design and manufacturing (CAD/CAM) and between production
planning and manufacturing (CAPP/CAM). Flexible manufacturing
further increases the amount of data to be processed to account for
on-line production switches, tools and fixture management policies
and flexible exception handling. Therefore, innovative automation
paradigms, especially CIM, require support of a full-fledged DBMS
[Jablonski et al., 1988].

Semantic data models seem to offer an answer to at least
some of these problems (although some researchers question their
capability to fully address the issues involved in the manufacturing
domain [Papachristidis and Deen, 1988; Spooner at al., 1988].)
Semantic models not only provide a common reference model for
data sharing across heterogeneous processing elements, but also can
reflect the underlying hierarchical structure of the application. In
addition, by providing a semantically rich model, they can help in the
integration of factory activities. A recent development in the
advanced database field is that of object-oriented (0-0) semantic
data models [Hull and King, 1987; Spooner et al., 1988; Su et al.,
1989]. These models, while sharing with the semantic models the
capability to express complex data interrelationships, also provide
mechanisms for encapsulation of complex functions within the
database objects. Thus, object-oriented models are capable of
specifying local behavior as well as allowing access to dynamically
created and/or derived information.
Semantic models have been mainly applied to describe the
information flows and local data at different machine locations so
as to integrate factory activities in a CIM environment. Less
consideration has been given to the potential application of these
same advanced data models to the design process of manufacturing
workcells and equipment.
Existing work on procedural guidelines [Alami and Chochon,
1985], decision support systems [Suri and Whitney, 1984], expert
systems [Fisher, 1985] and graphical modeling and animation driven
by simulation [Dombre et al., 1986] can be profitably combined with

advanced data modeling and a corresponding DBMS for the design of
manufacturing workcells.
As with any other design activity, the design of manufacturing
workcells consists of the creation and manipulation of data objects.
This exactly matches the approach of the object-oriented paradigm,
as pointed out by Spooner [Spooner et al., 1988]. Meanwhile, the
semantic data modeling capabilities provide features for the
construction of the complex objects typical of this domain, by
utilizing the relationships between objects as a fundamental part of
the system architecture [Korson and McGregor, 1990]. Some of the
issues relevant to manufacturing workcell design and 0-0 semantic
models are the following:

1. Currently, the expertise required for manufacturing workcell
design is large and scattered among many different sources.
These sources include parts catalogs, human experts and
templates from previous designs. Design productivity can be
greatly improved by the integration of this body of knowledge
using proper database techniques.

2. The hierarchical and heterogeneous nature of such knowledge,
as well as support for complex data types, calls for an
object-oriented approach.

3. Object-oriented semantic models provide the means for
integrity enforcement, richer semantic mechanisms to

support the design activity and a wider set of abstraction

Achievement of the potential benefits offered by
object-oriented and semantic data models in workcell design
requires a suitable organization of the domain-specific knowledge
according to the selected model.


In any application domain, knowledge can be split between
structural knowledge (the objects and physical entities) and
functional knowledge (how the objects behave and interact) [Walker
and Thomas, 1985; Caselli et al., 1992]. This separation of function
and structure is more obvious with design in general and
particularly engineering design.
In most object-oriented data models, two approaches are
typically available to represent the functional components of the
domain. One approach is closer to the original object-oriented
philosophy. Functionalities are merely owned or hidden by the
structural objects. This approach, however, while providing strong
encapsulation properties, fails to capture, in a satisfactory way, the
functional abstraction hierarchy. The functional hierarchy is usually
not isomorphic with the hierarchy defined by the structural
components [Walker and Thomas, 1985; Caselli et al., 1992]. In many
engineering contexts the functional abstraction is often as
important as the structural one [Blackburn and Thomas, 1985]. To
fragment and hide it in an inconsistent way results in a significant
loss of application domain knowledge.
An alternate approach is to explicitly model both structural
and functional components as individual objects, using the same

object syntax. This latter approach, however, suffers a significant
drawback as well. Only generic associations, characterized by
limited semantic expressiveness, are available to represent a
relationship between functional and structural objects. We term
these associations as semanticallyy weak" [Caselli et al., 1990]. For
example, in the object-oriented data model, OSAM* [Su et al., 1989],
a single, semantically overloaded association, the interaction
association, is typically used to relate functional and structural
objects. Users often resort to "labeling" this association in order to
enhance the readability of the resulting schemas with descriptive
names or additional attributes. However, the additional semantics
implicit in the labeling action are not enforced in any way by the
model itself. As a result the burden of enforcing these semantics
falls on the applications programmer. This problem cannot be easily
solved in models, such as OSAM*, that are designed to be general
purpose. In specific domains this problem can be relieved by
providing a richer set of domain-dependent primitives in addition to
the single interaction association.
Recognizing the modeling problems previously discussed,
recent research in the field of semantic and object-oriented data
models applied to process modeling [Carswell and Navathe, 1986;
Cornelio et al., 1990a; Markowitz, 1990; Caselli et al., 1992] has led
to modeling paradigms where an additional semantic layer is defined
on top of a standard object-oriented model. This new layer
distinctly represents functional and structural components and their
relationships. In particular, this is the basic rationale underlying

the Structure-Function (S-F) paradigm proposed by Cornelio
[Cornelio et al., 1990; Cornelio and Navathe, 1990].
The S-F paradigm appears to successfully represent complex
static designs in the manufacturing domain at a high level of
abstraction (e.g., for CIM databases). However, whenever the
knowledge base is used in a dynamic way for design purposes, a
large gap, both practical and conceptual, exists between the S-F
specification and an implementation satisfying that specification as
a constraint. Functionalities represent complex behaviors whose
achievement implies the realization of suitable control strategies.
Many different control implementations can be developed for the
same high-level specification. Since the scope of the S-F paradigm
is restricted to high-level modeling, virtually no support is provided
for what we deem a fundamental issue in manufacturing workcell
design, namely, the development of an implementation whose
correctness and compliance with the specification are guaranteed a
priori by the design methodology itself.
These are the basic motivations leading to the proposal of a
data modeling paradigm oriented to the manufacturing domain where
proper consideration is given to control in the early modeling stages.
To express the semantics of control we use Petri nets. They have
adequate expressiveness capabilities and represent a formal model
allowing correctness properties to be demonstrated [Peterson, 1981;
Reisig, 1985]. Petri nets have also gained wide acceptance as a tool
for modeling and control in the area of manufacturing [Kamath and
Viswanadham,1986], and have already been shown to be a useful tool
for automatically synthesizing and programming the control of

multi-agent manufacturing systems [Crockett et al., 1987; Caselli
and Faldella, 1988; Kasturia et al., 1988; Krogh et al., 1988; Thomas
and McLean, 1988]. An extensive list of papers describing Petri net
applications in manufacturing can be found in a paper by Desrochers
[Desrochers, 1990]. In addition, Petri nets have been shown to be a
useful tool for automatically synthesizing and programming the
control of multi-agent manufacturing systems [Courvoisier et al.,
1983; Martinez et al., 1986; Murata et al., 1986; Crockett et al.,
1987; Krogh and Sreenivas, 1987; Caselli and Faldella, 1988;
Kasturia et al., 1988; Thomas and McLean, 1988; Willson and Krogh,
1990]. As will be exemplified later, we extend the graphical
formalism of semantic schemas to represent dynamic behavior. A
relationship can then be established between the schema
representing functional knowledge and Petri net constructs which
will enable us to make the transition from one representation to the
The Structure-Function-Control (S-F-C) paradigm, an
extension of the S-F paradigm, states that to represent engineering
knowledge in a manner conducive to complex design synthesis,
physical, functional and control objects are modeled individually.
An object-level, many-to-many (N:M) mapping, also called
provides/provided_by link, relates the structural and functional
abstraction hierarchies. This mapping is fully exploited in the
synthesis procedure for manufacturing workcell design to be
outlined in chapter 7. A many-to-many mapping, called
controls/controled_by link, relates some of the objects within the
structural hierarchy with objects within the control knowledge

base. A structural object is called an active device if it requires
the existence of a control object to completely define its behavior.
There are two types of active devices: programmable (e.q. robots ana
numerically controlled (NC) machines) and nonprogrammable (e.a.
part-feeding devices). Programmable devices exhibit flexible
control provided by a program. Nonprogrammable devices have fixeo
control, usually invoked by the occurrence of some event. Robot
behavior, for example, is determined by a program, where as the
behavior of a gravity feeder is always the same and initiated by an
event, namely the removal of the first part from the feeder. Active
devices instantiated from the structural knowledge base also
require an instantiation of a control object governing its activities.
A pair (active device, control object) is termed an active agent.
In summary, the Structure-Function-Control (S-F-C) paradigm
is an extension to OSAM*, a powerful object-oriented semantic
model. We start with OSAM* as our base model and then introduce
domain specific knowledge in terms of special semantic
associations. These additional associations enable this model to
better satisfy the complicated needs of the manufacturing domain.
At the same time the model remains simple and intuitive. The model
allows the manufacturing engineer to concentrate on the design
issues themselves and relieves the burden of dealing with the
details of data modeling.
The next two chapters present the Structure-Function-Control
paradigm in more detail.


The S-F-C paradigm defines a conceptual level semantic layer
made of the three knowledge bases and the mapping constructs
among them. At the logical level, the knowledge bases and their
classes can be described in terms of a data model providing a
common set of primitive associations. In this section we describe
this set of associations which allow representation and
manipulation of structural and functional knowledge. Within the
knowledge bases, the data model makes use of a few semantically
rich, domain-oriented constructs not typically available elsewhere,
along with a subset of the features provided by several complex
object-oriented semantic data models [Smith and Smith, 1977; Hull
and King, 1987].
As previously mentioned, our model treats structural,
functional and control objects individually. Following the
object-oriented paradigm, we generalize (collect together) the
different objects into classes. Consequently, all object are
instances of some class. For example, all structural objects are
defined as instances of some structural class, all functional objects
are instances of some functional class and all control objects are
instances of some control class.

S-F-C Obiect Definitions
Formal definitions of the structural, functional and control
classes are given below.

Structural class definition: A structural class can be formally
defined as a 9 tuple as shown below:
SC = (S.N, S.1, S.A, S.CC, S.CA, S.IA, S.R, S.LM, S.PM)

name of the class

{il, i2, *.., in), a set of instances
proper subset of the semantic associations {G, A, I, P, C}
where: G is the Generalization association
A is the Aggregation association
I is the Interaction association
P is the Provides association
C is the controlled_by association
{cl, c2,..., cm} a set of constituent classes
{scai,sca2,..., scak) a set of class attributes, such that
S.CA = (La U Pa)
where La = (lai ,la2,..., lap) is a set of local attributes
and Pa = (pal, pa2,..., paq) is a set of public attributes
{sial,sia2,..., siak} a set of instance attributes, such that
S.IA = (LA U PA)
where LA = (LA1 ,LA2,..., LAp) is a set of local attributes
and PA = (PAI, PA2,..., PAq) is a set of public attributes.
{sri, sr2,..., srt) a set of rules for specifying knowledge
associated with this class. These rules specify

S.N =
S.I =
S.A =

S.CC =
S.CA =

S.IA =

S.R =

constraints on the values for the SCA (class attributes)
and SIA (instance attributes). In effect, these rules
specify the legal (acceptable) values of the attributes
for a class.
S.LM = {simi, slm2,.., sims} a set of methods (operations) that
can manipulate and change the local and public attributes
of the class. These operations are local to the class and
are visible only within the class.
S.PM = {spml, spm2,.., spmk} a set of methods (operations) that
can manipulate and change the local and public attributes
of the class. These operations are visible to the public.
These methods along with the public class attributes and
public instance attributes constitute the interface to the

Functional class definition: A functional class can be formally
defined as a 9 tuple as shown below:
FC = (F.N, F.I, F.A, F.SF, F.CA, F.IA, F.R, F.LM, F.PM)
F.N = name of class
F.I = {il, i2, ..., in}, a set of instances
F.A = a proper subset of the semantic associations:

{G, A, F, H, R:S)
where: G is the Functional Generalization association
A is the Aggregation association
F is the Functional Aggregation association
H is the Provided_by association

R:S is the Iteration association
F.SF = {fl, f2,..., fm} a set of subfunctions
F.CA = {fcai,fca2,..., fcak} a set of class attributes, such that
F.CA = (La U Pa)
where La= (lal ,la2,..., lap) is a set of local attributes
and Pa = (pal, pa2,..., paq) is a set of public attributes
F.IA = {fiai,fia2,..., fiak} a set of instance attributes, such that
where LA = (LA1 ,LA2,..., LAp) is a set of local attributes
and PA = (PA1, PA2,..., PAq) is a set of public attributes
F.R = {fri, fr2,..., frt} a set of rules for specifying knowledge
associated with this class. These rules specify
constraints on the values for the SCA (class attributes)
and SIA (instance attributes). In effect, these rules
specify the legal (acceptable) values of the attributes
for a class.
F.LM = {flmi, flm2,.., fflms} a set of methods (operations) that
can manipulate and change the local and public attributes
of the class. These operations are local to the class and
are visible only within the class.
F.PM = {fpmi, fpm2,.., fpmk} a set of methods (operations) that
can manipulate and change the local and public attributes
of the class. These operations are visible to the public.
These methods along with the public class attributes and
public instance attributes constitute the interface to the

Control class definition: A control class can be formally
defined as a 9 tuple as shown below:
FC = (C.N, C.I, C.A, C.CC, C.CA, C.IA, C.R, C.LM, C.PM)
C.N = name of class
C.I = {il, i2, ..., in}, a set of instances
C.A = a proper subset of the semantic associations:
{G, A, I, C}
where: G is the Generalization association
A is the Aggregation association
I is the Interaction association
r is the Controls association
C.CC = {cl, c2,..., Cm} a set of constituent classes
C.CA = {scal,sca2,..., scak} a set of class attributes, such that
CCA = (La U Pa)
where La = (lal ,la2,..., lap) is a set of local attributes
and Pa = (pal, pa2,..., paq) is a set of public attributes
C.IA = {sial,sia2,..., siak} a set of instance attributes, such that
where LA = (LA1 ,LA2,..., LAp) is a set of local attributes
and PA = (PA1, PA2,..., PAq) is a set of public attributes.
C.R = {srl, sr2,..., srt} a set of rules for specifying knowledge
associated with this class. These rules specify
constraints on the values for the SCA (class attributes)
and SIA (instance attributes). In effect, these rules
specify the legal (acceptable) values of the attributes
for a class.

C.LM = {slmi, slm2,.., sims} a set of methods (operations) that
can manipulate and change the local and public attributes
of the class. These operations are local to the class and
are visible only within the class.
C.PM = {spml, spm2,.., spmk} a set of methods (operations) that
can manipulate and change the local and public attributes
of the class. These operations are visible to the public.
These methods along with the public class attributes and
public instance attributes constitute the interface to the

Structural Knowledge Representation
The structural knowledge data model makes use of
Generalization (G or Is_a relationship), Aggregation (A or Part_of
relationship) and Interaction (I) semantic associations among
classes as defined in the OSAM* data model [Su et al., 1989]. We
found that by using these semantic associations we could model any
kind of structural knowledge. Informal definitions of A, G and /
were given in chapter 2. Formal definitions of these associations
can be found in a paper by Su [Su et al., 1989].
Two examples are given below that illustrate the utility of
these associations in describing structural aspects. The first
example illustrates the recursive definition of classes, as well as
the use of G, A and / associations. The second example illustrates
how structural knowledge can be organized in a hierarchical
structure, using the G and A associations.

Example 1. Modeling Parts
The first example involves a workcell that manufactures a product
from a given set of parts. The goal is to design a database which
will store data about parts and their relationships. Parts can be
simple or composite. Simple parts are parts which can not be
decomposed into other parts. Composite parts can always be
decomposed into subparts. These subparts may in turn be either
simple or composite. Therefore, in general the definition of a part
is recursive. Other information about parts that needs to be
captured includes:

Physical properties of a part:
1. Geometry of the part.
2. Material properties and manufacturing constraints:
Information about the material of the part is needed when
deciding about the manufacturing processes. For example, the
welding process depends on the material properties of the
parts involved in the welding operation.
3. Inertia properties of a part: This information may be needed
for grasping and robot dynamic analysis.
4. Status of the part: The status is a boolean property. It is
false if the part is defective, otherwise it is true.
5. Pose of the part in the workcell: The location and orientation
of a part in three dimensional space can be represented by a
4-by-4 homogeneous matrix with respect to a universal

6. A part number: Every part is uniquely identified by its part

Part relationships: Besides information about individual parts,
the system must keep information on a variety of relationships
among parts.

1. Composite part/simple part relation: At some time, the
workcell may contain composite as well as simple parts. On
the one hand, the system should be able to distinguish
between simple and composite parts. On the other hand, it
should be able to refer to a composite part as a unit, since a
composite part is still a part. In addition, when two parts are
joined together, they no longer exist as separate parts.
Therefore, a new part is generated while the parent parts are
removed from the database.
2. Liaisons between parts: A liaison is defined to be an
operation for joining two parts (screw, weld, etc.).
3. Relative positions of parts: For a composite part, the position
and orientation of each subpart is specified by a 4-by-4
homogeneous transformation matrix. This matrix defines the
position and orientation of the local coordinate system for the
subpart (body attached frame) with respect to a frame local
to the composite part.

The semantic diagram of the parts database is shown in
Figure 3. We define an object class called PART. This object class

models the general notion of composite part. The class
SIMPLE_PART is a subclass of PART. Through this generalization
hierarchy we model real world objects (simple or composite parts).
For every real world object, there must exist a corresponding
instance of either the PART or SIMPLE_PART classes. Note that a
simple part is a special case of composite part, in that its
"parent_part" and subpartss" attributes are null. In addition, it has
an extra attribute which models its geometry, namely, "CAD_model."
The object class PART, defines a set of attributes which are
inherited by its subclass. These attributes are:

1. Part name: Gives a name to a part instance. This attribute
together with Part_number serves as the key.
2. Part number: Distinguishes among the part instances with the
same Partname.
3. Status: States if the part is defective or not.
4. Pose: Is a 4-by-4 homogeneous transformation matrix.

The object class CAD_MODEL defines the geometry, color,
visibility, etc. of simple parts. It acts as a domain for the attribute
"Has_model" of the class SIMPLE_PART. The attribute "Has_model"
cannot be null, which implies that every simple part must have a
geometric description. Notice that the mapping between the
instances of SIMPLE_PART and CAD_MODEL is not necessarily













Figure 3. Parts/Liaisons knowledge base (S-diagram).

one-to-one. This means that simple parts with the same physical

properties have the same value for the "Has_model" attribute (i.e.,

point to the same CAD_MODEL instance).

Figure 4 shows the CAD_MODEL class in more detail. As seen
from the semantic diagram, the geometry of a simple part is defined
by a set of faces (3D polygons). In turn, the faces are described by a
set of edges (3D lines). Edges are represented by 3D points.
In our design the geometry of a composite part is defined
recursively through the geometry of its subparts and some
additional information on the positional relationship of its
sub-parts. Positional relationships are captured by the "Pose"
attribute of the SIMPLE_PART class and are discussed below.
Note that the attribute "Pose," defined in the class PART and
inherited by the class SIMPLE_PART, has different interpretations
depending on the particular part.

1. For an instance of SIMPLE_PART which is not a subpart of
some composite part, the pose refers to the location and
orientation of the part with respect to the world coordinate

2. For an instance of the class SIMPLE_PART, which is a subpart
of some composite part, the attribute "Pose" refers to the
location and orientation of the part with respect to the
composite part coordinate frame.

These semantics are enforced by rules defined in the




Figure 4. The Parts geometric model.

The PART object class participates in an interaction
association. This interaction association class ASSEMBLEDWITH,
models the following three relationships among parts:

1. Any number of simple parts can be joined together to form a
composite part.
2. Any number of composite parts can be joined with any number
of simple parts to form a composite part.
3. Any number of composite parts can be joined to any number of
composite parts to form a composite part.

The ASSEMBLED_WITH class defines the attribute "Assembly
operation." This new attribute draws its values from the object
class ASSEMBLY_OPERATION. In turn, the object class
ASSEMBLY_OPERATION defines a generalization hierarchy which
provide additional information about the different kinds of assembly

Example 2. Workcell Components Library
This second example presents the design of a database which we use
as our manufacturing workcell components library. This database
stores information that is usually available in numerous workcell
devices manufacturing catalogs.
In Figure 5 an example of structural knowledge, the
components library, is shown. This figure is not intended to provide
a comprehensive classification of the components found in
manufacturing workcells, but merely to serve as illustration for the

purpose of this example. The notation used in the semantic schemas
throughout this dissertation is based on the OSAM* S-diagrams [Su
et al., 1989], with some extensions and minor modifications. Using a
Generalization (G) association the workcell equipment is initially
classified as transportation equipment, process equipment or
auxiliary equipment. Transportation equipment is further classified
into robots, mobile robots and conveyors. Continuing the traversal
of the G hierarchy, a robot can belong to one of the Puma, C. Milacron
or Adept families. As a last refinement, the particular robot models
are given at the leaf nodes of the G hierarchy. Similar G hierarchies
are shown for the process equipment and auxiliary equipment
classes. The components library, expressed as a semantic schema,
provides a taxonomy of equipment with multiple abstraction layers
(the so-called Is_a hierarchy) and conveys structural information
about the entity objects at the leaves of the schema. For example, a
robot, whatever its manufacturer and its model, is an aggregation of
a controller and a manipulator. This information is captured through
the Aggregation (A) association on the robot class and is inherited
downwards through the G hierarchy. Entity objects also embody a
number of methods and attributes, not illustrated in Figure 5, such
as the geometrical and dimensional attributes and the graphical and
kinematics methods required to display and simulate the objects
The construction of the structural hierarchy is clearly the job
of a knowledge engineer. All the information captured by the
structural hierarchy is readily available from the different

Figure 5. An example of a structural knowledge schema.

descriptions of
computer aided

in workcell component catalogs. The geometric
workcell components need to be created using a
design tool. Developing the kinematics and dynamics

methods for the workcell components may be problematic since
many manufacturers consider such things as company secrets. In
these cases, the kinematics and dynamics routines need to be
redeveloped based on the available information found in a variety of
excellent textbooks and papers on the subject.
A final note on this subject is that the dynamics and
kinematics routines for the different workcell components, although
themselves describing dynamic activities, could be stored as static
attributes. These routines, stored in the form of executable code,
can be retrieved from the database and executed at simulation time.
Only at this time do they exhibit their dynamic behavior.

Functional Knowledge Representation
To express the dynamic information inherent in the functional
description, additional semantic mechanisms, besides the static
Generalization and Aggregation associations, are required. In
particular, in the functional domain we need to be able to capture
the following semantics:

Functional decomposition: In general, a function, H, can be
decomposed into a set of subfunctions SH = {fl, f2, ..., fn}, which
describe H in a greater detail.

Sequencing of subfunctions: In general, ordering constraints need
to be specified among subfunctions, fl, f2, ..., fn, of a function, H.

This is necessary so that the ordered execution of the
subfunctions, fl, f2, ..., fn, is equivalent to the execution of H.

Optional subfunctions: Manufacturing processes may include
required and optional steps. This means that given a function, H,
and its subfunctions, SH = {fl, f2, ..., fn}, a member of SH, say fi,
could be the NULL function.

Semantic Associations in the Functional Domain.
In order to capture the above semantics we introduce the
following semantic associations:

Aggregation and Functional Agaregation
The Aggregation association in the functional domain carries
special semantics. It is defined as follows:

Definition: Given a set, SH, of subfunctions of a function, H
(functions relating to H with the Part_of relation), such that SH =

{fi, f2,...,fn}, then this set defines an Aggregation association iff
the function H can be carried out by executing fl, f2, ..., fn in any

Note that the definition of the Aggregation association
imposes no constraints on the order of subfunction execution.
Therefore, the Aggregation association allows for the possibility of

The Aggregation association, as defined above does not
explicitly provide any sequencing information. The so-called
Functional Aggregation (F), originally proposed by Cornelio [Cornelio
et al., 1990; Cornelio and Navathe, 1990], seems to fulfill this need.
Cornelio proposed the Functional Aggregation which he defines
as a set of subfunctional objects together with a functional
interconnection network (FIN). The functional interconnection
network is basically a directed graph which fully specifies the
execution ordering of the participating subfunctions. In effect, the
FIN represents one particular manufacturing plan out of a set of
valid manufacturing plans. For our purposes the Functional
Aggregation as defined by Cornelio is a bit restrictive. It requires
that a strict ordering of subfunction execution be specified, thus
eliminating the possibility of representing many alternative
manufacturing plans using the Functional Aggregation association.
It is our opinion that the functional schema should be a
repository of functional knowledge. Therefore, our goal is to define
the functional schema so it captures knowledge about a set of valid
(or recommended) manufacturing plans. It should then be the
manufacturing engineers responsibility to select one or more of
these plans for evaluation and/or implementation. This selection
process is discussed in greater detail in a later chapter.
For the above reasons we define the Functional Aggregation (F)
as follows:

Definition: Given an ordered set, SH, of subfunctions of a
function, H (relating to H with the Part_of relation), such that

SH = {fi, f2,...,fn}, then this set defines a Functional aggregation iff
the function, H, is carried out by executing fl, f2, ..., fn in the given

Note the following:
1. A strict sequential ordering is defined on all subfunctions
of a Functional Aggregation. This makes the Functional
Aggregation a very simple and unambiguous association

2. The Functional Aggregation can be explicitly represented
on the semantic diagrams. As a convention, the execution
of the sub-functions follows a left to right ordering.

3. The total participation constraint is not imposed on
subfunctions in a Functional Aggregation. This means that
the manufacturing engineer can eliminate subfunctions.
This, by itself, suggests that the functional semantic
schema can represent a set of possible manufacturing

4. Partial orderings of any complexity can be defined with
subfunctions. These partial orderings can be expressed
using an arbitrary combination of Aggregation and
Functional Aggregation associations. (A proof of this
claim is presented later). As discussed by Fox and Kempf
[Fox and Kempf, 1987], partial orderings are capable of
representing a set of manufacturing plans.

The observation about the total participation constraints
needs a little clarification. In OSAM* and many other models,
integrity constraints can be imposed on an Aggregation association.
These constraints can take several forms. One such constraint
which is of great importance here, is the so called total
participation constraint. This constraint, when imposed on an
aggregate, restricts its value to be non-null.
The total participation constraint, when defined on an
aggregate (i.e., subfunction) of an A or F association, forces this
subfunction to be non-null. Therefore, the total participation
constraint captures the semantics of a mandatory subfunction. In
addition, a subfunction without any constraints, is considered to be
an optional subfunction and can, therefore, be omitted from the final
manufacturing plan (i.e., instantiated with the null function).
In general, manufacturing procedures usually contain a large
number of mandatory subfunctions and only a few optional ones.
This is in contradistinction with other database domains where
total participation constraints are rare. For this reason, as a
convention in a semantic diagram we only mark the optional
subfunctions. This keeps the semantic diagram uncluttered and
requires less work from the user. On the semantic diagram an
optional function is marked with a capital '0' which is an
abbreviation for optional.
The observation about partial orderings needs a little more
clarification, also. Consider the function "Populate PCB" in Figure 6.
This function can be accomplished by executing its subfunctions,
which are Feed components, Feed board, Populate board and Unload

board. Notice that more than one valid execution ordering can exist
among these subfunctions. In fact, there is a set of three possible
such orderings which are as follows:

1. "Feed components"
followed by "Feed board"
followed by "Populate board"
followed by "Unload board,"

2. "Feed board"
followed by "Feed components"
followed by "Populate board"
followed by "Unload board" or

3. "Feed board" and "Feed components" done concurrently
followed by "Populate board"
followed by "Unload board."

In order to be able to represent all three valid subfunction
orderings in the functional schema diagram, we make use of a
combination of A and F associations. A combination of A's and F's
can explicitly represent the ordering constraints among these
subfunctions and, therefore, can capture the semantics of a partial
order (PO). The definition of a partial order is given below:

Definition [Berztiss. 19751: A reflexive, antisymetric and
transitive relation in a set A is a partial ordering) in the set A. If R

is a partial order in A, the ordered pair is a partially ordered
A relation R is reflexive if for any a e A, aRa is true.

A relation R is antisymetric if for any a, b e A, aRb and bRa
imply a=b for all a, b e A.

A relation R is transitive if for any a,b,c e A, aRb and bRc
imply aRc for all a, b, c e A.

Populate PCB


Feed Populate
Feed board Unload board
components board

Figure 6. Functional semantic schema capturing a partial order

Another example is given here in order
case of the use of the semantic diagrams.
decomposition of a function H calls for

to clarify a special

Assume that the
the execution of

subfunctions si followed by s2 followed by si again. In order to
emphasize that si consists of a single operation, the representation
shown in Figure 7 can be used. The subfunctions sl and s2 are drawn
only once. Then following our convention that calls for left to right
execution, we draw three links leaving H. The leftmost ends at si,
the middle ends at s2 and the rightmost crosses the middle link and
ends back at sl.



s1 s2

Figure 7. Semantic diagram showing sequence si-s2-sl.

Summarizing, an Aggregation association describes a function
in terms of its subfunctions, while it imposes no constraints on the
ordering of its subfunction execution. On the other hand, the
Functional Aggregation, besides describing a function in terms of its
sub-functions (thus capturing the Part_of semantics), also express a

sequential ordering constraint on subfunction execution. The
ordering constraint is determined by the nature of the described
function. In order to explicitly represent a set of manufacturing
plans in the functional semantic schema, a set of arbitrary
combinations of Aggregations and Functional Aggregations can be
used. On the semantic diagram functions marked with '0' are
considered to be optional (i.e., no participation constraint is

Functional Generalization
In a highly dynamic domain such as manufacturing, a function
(manufacturing operation), may take different forms at different
times. For example, the prepare component function of Figure 8, may
take the form of either prepare radial, prepare axial or prepare IC,
depending on the kind of electrical component to be processed. From
the above discussion we see that there is a need for some
association that can express the semantics of selection. This
association should capture and/or enforce the following semantics:

1. Constituent functions provide the same kind of functionality
as the original function, but maybe in a more specialized
form. Therefore, the constituent functions are Is_a related
to the original function.

2. The constituent functions (selection alternatives) should be
distinct (i.e., satisfying set exclusion).
3. Some selection criteria should be defined.

A closer look at the selection semantic association reveals
some similarities with the Generalization association as defined in
the structural domain. In fact, from the database point of view, the
selection association, as defined here, can be viewed as a


Prepr cl: part = radial
G c3: part = IC
G c3: part = IC

cl c2 c3

Prepare Prepare Prepare IC
radial a4xia Prepare I

Figure 8. Functional generalization association.

Generalization association satisfying the set exclusion, plus some
other constraints. These additional constraints are a) the
association is defined on functions and b) the instantiation of the
class corresponding to this association is guided by the selection
Due to the many similarities of selection and the
Generalization association, the Generalization association will

serve as a starting point. The semantics of the Generalization
association are then augmented to satisfy the selection semantics.
Within the functional knowledge data structure, the modified
Generalization association captures additional special semantics. It
expresses alternatives and conditional execution of subfunctions.
This new semantic association we call Functional Generalization.
On the semantic diagram the Functional Generalization is denoted
with the symbol G as in Figure 8.

Iteration Association
A new construct, called Iteration Association (R:S), is provided
within the functional knowledge data model for notational
conciseness and abstraction purposes. The mnemonic R (for repeat)
is used here instead of I to avoid any confusion with the Interaction
association / provided by OSAM*. The Iteration association imposes
an ordering with respect to time on all the instances of a functional
class and calls for the repeated instantiation of identical
subfunctions at a lower abstract level. This association enhances
the modeling power by providing an equivalent to the looping
primitive of programming languages. For instance, the function
populate printed circuit board is related to the function process
component by an Iteration association since the repeated execution
of the latter function is required to accomplish the former one. The
Iteration set S is defined to be an arbitrary ordering relation on the
set of all the instances of the participant functional class. In our
particular example let us assume that the instances of the
functional class prepare component are the following: Prepare R1,

prepare R2, prepare IC1 and prepare C1 (where R is a resistor, IC is
an integrated circuit and C is a capacitor). Under the assumption
that the same tool could be used to process both the resistors and
capacitors, but a tool change is required to process the ICs, an
efficient assembly plan may call for the following sequencing:
S = (Prepare R1, Prepare R2, Prepare C1, Prepare IC1). This sequence
consists of the Iteration set S associated with the Iteration
association (see Figure 9). As a convention, on the semantic
diagram, the Iteration association is represented by a link labeled as
R:S where R denotes the Iteration association and S is the iteration

Provides/Provided by Association
Finally, the Provides/Provided_by association is introduced to
support the integration of the structural and functional knowledge.
This association consists of explicitly named links that represent
relationships as in the E-R model [Chen, 1976] and connects the
structural and functional knowledge descriptions. These
bidirectional one-to-many links are represented on the semantic
diagram by using two distinct labels. The symbol P labels links that
point away from a structural class (see Figure 5) and terminate on
one or more functional classes. P links capture the semantics: "An
instance of a structural object belonging to this class may be able
to provide the following classes of functions." This relationship is
"one-to-many" since one structural device may be able to provide
more than one function. The n labeled links point away from a
functional class (see Figure 10) and terminate on one or more

structural classes with the semantics: "A function within this class
is provided by the instances of the following classes of structural
objects." Again this relationship is "one-to-many," since this
function could possibly be provided by more than one structural

-I Pua S (Iteration set:
board S= (Prepare R1,
r Prepare R2,
S Prepare C1,
Prepare IC1)


Figure 9. Iteration association.

The Provides/Provided_by association not only integrates the
structural and functional knowledge, but also provides a powerful
foundation for an intelligent suggestion system. This system could
act as an "Intelligent Assistant" to the workcell designer by
providing relevant information that is otherwise available only
through numerous component catalogs. The "Intelligent Assistant"

system would make use of the Provides/Provided_by links to
retrieve and present the workcell designer with a list of functions
that particular workcell components can provide.

A formal definition of the P, n links is given below:
Given: S = {si, s2, ..., sn}, a set of structural objects, and
F = {fi, f2, *.., fm}, a set of functional objects,
then the Provides/Provided_by association defines two
functions between S and F as follows:

Provides is a mapping P,
P : S -4 2F and

Provided by is a mapping n,
n : F 2S.

In other words, P(si) = {fn,..,fp}, which means that the Provides
function applied on structural object si returns a set of functions
{fn,..,fp}. These are functions that the workcell device si is capable
of providing. On the other hand, n(fj) = {sk,..,Sq}, which means that
the Provided_by function applied on fj returns a set of structural
objects (workcell devices) {Sk,..,Sq}. This set of structural objects
specifies the workcell devices that can provide the function fj.
Based on the above definitions a constraint for a design to be
complete is the following:

Design constraint: If fi e F then there should exist an sj such
that P(sj) = Uf, Uf c 2F and fi E Uf.

A design constraint, therefore, dictates that for each function,
fi. included in the design specification, there exist some workcell
component, sj, that can provide this function.

The Functional Knowledge Representation
We distinguish two kinds of functional knowledge. First, there
is knowledge about individual atomic manufacturing functions.
These are functions that could be accomplished by a single workcell
device. An example of an atomic function is Tin resistor leads. We
term these as atomic functions. The second kind of functional
knowledge is knowledge about manufacturing procedures. A
manufacturing procedure is an ordered set of atomic functions which
when executed produces some desired result (usually the
manufacture of some product). An example of a manufacturing
procedure is Prepare and insert IC into PCB. Information describing
manufacturing procedures can be represented using a semantic
functional schema, as previously discussed.
Product creation, in general, consists of two substeps. These
are 1) design of the product itself and 2) design of the
manufacturing process that can produce the product. Usually several
iterations of these substeps are necessary in order to achieve a
satisfactory solution (i.e., an acceptable product and an acceptable
manufacturing process). The two substeps, in general, are not
independent since changes in one necessitate changes in the other.
For example, to simplify some manufacturing procedure required to
produce a part may require that the original part design be modified.

This section discusses step 2, namely the generation of the
manufacturing procedure given a product design specification.
Initially, a high level specification of the manufacturing
process needs to be formulated. This may be a very general
statement such as: "Prepare electrical components for insertion into
PCB." We call this general statement the primary function of the
manufacturing process. To develop a detailed manufacturing plan we
start with this primary function and recursively decompose
functions into a set of subfunctions. When decomposing a function
into subfunctions the following constraint should be satisfied: the
execution of the subfunctions should result in accomplishing the
decomposed function. According to our model, the decomposition is
captured using either the Aggregation, Functional Aggregation,
Functional Generalization or Iteration association. This recursive
functional decomposition procedure results in a functional schema
which in fact captures knowledge about a set of manufacturing plans
capable of providing the original function. The functional
decomposition terminates when all leaf nodes correspond to atomic
The semantic network shown in Figure 10 is an example of a
functional knowledge schema. In this schema the function Populate
Printed Circuit Board is expressed in terms of its subfunctions. As
previously discussed, within the functional knowledge domain the
Generalization association expresses alternatives and conditional
execution of subfunctions. The Aggregation association describes
functions in terms of the required subfunctions without ordering
constraints. The Functional Aggregation adds ordering semantics to

Populate PCB

A \~l~C I

SL: Straighten Leads
SCL: Shape/Cut Leads
CL: Clean Leads
TL: Tin Leads
ETO: Electrical Test Others
ET: Electrical Test IC
OT: Orientation Test IC
INS: Component Insertion
BLB: Bend Leads Below

Figure 10. An example of a functional knowledge schema.

the Aggregation. In our graphical notation, a left-to-right execution
ordering is assumed as a convention. Functional Aggregations and
Aggregations can be nested in any way, thus providing the means for
expressing complex partial ordering relationships.
Referring to the example illustrated in Figure 10 the Iteration
association fulfills the goal of isolating the abstraction at the
individual component level from the abstraction at the board level.
The Functional Aggregation association, according to our experience,
appears to significantly enhance the overall semantic modeling
power in the functional knowledge modeling domain, such that its
role cannot be replaced by other constructs or combination of them
as defined in the most common semantic data models.
One of our goals is to provide the workcell designer with a tool
that simplifies the equipment selection. This tool should act as an
Intelligent Assistant (IA) to the workcell designer during the
equipment selection process. The IA should be able to suggest
particular workcell components that satisfy functional
requirements of the design. For example, if the designer is
considering the transportation of the different parts inside the
workcell he should be able to ask the IA for a list of equipment that
can perform this function. Recall that the nodes of the functional
schema have links to a library of workcell components. Specifically,
nodes in the functional semantic schema point to workcell
component models (which are stored in the workcell component
library), that are capable of providing the particular function
specified by the functional node.

The creation of a functional subschema is the job of a
knowledge engineer. The knowledge engineer may need to consult
with manufacturing engineers that are experts in the field,
investigate the literature (research papers and reports) and consult
manufacturing procedures handbooks and probably other sources, in
order to be able to design a functional subschema corresponding to
some manufacturing procedure. Note that the development of a
functional subschema is not an exact scientific process. It relies
heavily on the collection of heuristic knowledge and past experience
of the manufacturing experts. In spite of this, tools may be
developed that can help and/or augment these experts. Chapter 6
presents a theory which is intended to be used as the basis for one
such tool. This tool will automate the generation of manufacturing
procedure plans.


In the previous chapter we discussed the functional domain
schema and mentioned that its construction is the knowledge
engineer's job. From a practical point of view, the functional
semantic schema should be a repository of knowledge about
manufacturing functions and procedures that we wish to recommend
for practice by our users. This knowledge comes from different
sources such as engineering design handbooks, human experts,
research, experimental findings, etc., and represents expertise and
experience acquired throughout the years. The functional schema
ideally should capture knowledge which has been proven correct and
reliable. As such, it should be used as a 'How to' guide.
On the other hand, the idea of automatically generating this
functional schema is an interesting one. This idea has been
researched for many years and consists of the well known and
classical problem of task planning.
The two most difficult problems that arise in task planning
are: a) the combinatorial explosion of task alternatives and b) the
task-sequence representation problem. Combinatorial explosion is a
classical problem in the field of artificial intelligence. It refers to
a phenomena in which the number of alternatives to be investigated
(in this case, candidate manufacturing plans) grows exponentially

with respect to the number of states (parts) involved. The task
sequence representation problem received a lot of attention by many
researchers. Different methods have been proposed in the literature
for solving this problem such as AND/OR graphs [De Mello and
Sanderson, 1986], partially ordered set diagrams [Fox and Kemph,
1987], DTP trees [Ayoub et al., 1988] and a template based graphical
representation [De Fazio and Whitney, 1987].
In this chapter we present a different approach to this
problem. We develop an new axiomatic theory which we call the
Algebra of Function Sequencing. This algebra establishes a method
for representing task sequences (an attempt to solve the
representation problem) and defines the rules which allow us to
manipulate these sequences.

The Algebra of Function Sequencing
We first present a few definitions and clarification notes with
respect to our representation. We then proceed to formally define
the proposed algebra.
In the definitions that follow below, we use the square bracket
symbols, '[' and ']', to group functions together. The use of these
symbols carry special semantics. For instance, the use of the
brackets in an expression such as fl U [f2 E f3], defines the way the
expression is pictorially represented in a functional diagram. By no
means does it imply that the subexpression inside the brackets
should be evaluated first. The order of execution is dictated by the
axioms (which are presented later) and not by the way the

expression is written. Figure 11 presents different examples in an
attempt to further clarify the use of square brackets.




fl F

f2 f3



fl f 2

[fl f2] [f2 f3]


f3 f4

Figure 11. Usage of the square brackets


[f f ] f

f [f2 f3]

We now give the formal definition of what we call the Algebra
of Functions Sequencing.

Definition: The algebra of function sequencing D =
is defined as follows:

H -a finite set of functions, such that H = {x I x is a function}.
-a strictly left-associative sequence binary operator which

expresses the semantics of a sequential function execution
e -a commutative, associative binary operator which
expresses expresses the semantics where no particular order
of function execution is required.
0 -the null function; a function which, when executed,
performs no task.
X -the exception function; a function which, when executed,
signals an error condition.

Assume that H is a finite set of functions. Then the notion of
an inverse function is defined as follows:

Definition: f-r e H is the right inverse of f iff f f-r = 0 where
0 is the null function.

The above says that if the execution of a function, f, is
immediately followed by the execution of its right inverse function,

then the right inverse function cancels out the results of f. This in
effect is the same as if f were never executed. A right inverse may
or may not exist for any function, f. For example, f = "Drill a hole"
may have no right inverse available in H.


1. fl f2 = f2 fl

E is commutative

2. Square bracket placement (not order of expression evaluation)
fl [f2 e f3] = [fl E f2] E f3 = fl e f2 E f3
fl [f2 f3] = [f1 f2] f3 = fl f2* f3

3. Identity law: 3 0 in H su
0 )f=f 0
0 f = f 0 f 0

4. The exception function X:
3 X eH such that
.X f = X,
X*f =and
f* =h .

ch that,
identity for e
identity for *

acts as a zero on F under e and *

5. If f f-r = 0 then,
f-r f = X and f-r f =

Observation: is not commutative, therefore, in general
ft f2 f2 fl.

The Algebra of Discrete Assembly Operations
An interesting variation of the above algebra is what we call
the Algebra of Discrete Assembly Operations. This algebra applies
to a more restricted domain and, as a consequence, exhibits more
structure. The more structure an algebra possesses, the richer its
stock of theorems and the more closely it can model the application
domain [Berztiss, 1975].
An assembly operation, A, is uniquely identifiable by the type,
t, of operation involved and the set of participant parts, P. A can
therefore be defined as a two tuple:

A = , where t T, T is the set of all types of discrete
join operations, and P is the set of participant parts.

For discrete assembly operations we make the following
important observation: A appears only once in any assembly
sequence. This is due to the fact that at the time a set of parts are
assembled, the parts no longer exist as individual parts. It is
therefore impossible that they participate in the same assembly
operation again. This fact is captured with the laws shown below.

Definition: The Algebra of Discrete Assembly Operations
V' = is defined as follows:

H -a finite set of functions, such that H = {x I x is a function}.
-a strictly left-associative sequence binary operator which

expresses the semantics of sequential function execution
@ -a commutative, associative, binary operator which
expresses expresses the semantics where no particular order
of function execution is required.
O -the null function; a function which, when executed,
performs no task.
X -the exception function; a function that, when executed,
signals an error condition.

Axioms 1 through 5 from algebra D.

6. Idempotent laws:
f*f= f

7. [fl 1 f2] [f2 f3] = [If1 f2] f3
[fl f2] [f2 f3] = fl f2* f3

8. [fl f2] 9 [fl f31 = fl [f2 E f3] Left distributive law

of over e

9. [f f2] [fl f3] = [fl f3] e [f2 f3] = [fl f2] f3
Theorem 1:
[fl E f3] [f2 @ f3] = [fl f2] E f3 Right distributive law
of ( over *

Proof: Using axiom 1 the left hand side can be rewritten as:
[fl ( f3] [f2 ) f3] = [fl f31 .* [f3 ( f2] which by axiom 7 is
equal to: [fl f [f [f3 f2] = [f f2 f3

Axiom 1.
Am 2A

f, f, f2 1

Axiom 2.

Figure 12a. Semantic schemas for some of the axioms.

Axiom 7.

Axiom 8.

Axiom 9.

Figure 12b. Semantic schemas for some of the axioms.

Figure 12 graphically illustrates most of the axioms presented
here. Note the one-to-one correspondence of algebraic expressions
and the functional diagrams. The utility of the Algebra of Discrete
Assembly Operations is illustrated below through some examples.

Discrete Assembly Examples

Example 1: In this example we develop a set of discrete
assembly sequences capable of assembling a ball point pen. We
attempt to generate the "optimal" sequences, with respect to
maximum parallelism. The idea is to break the assembly sequence
into many smaller sequences that can execute concurrently. This is
the same as trying to place as many A associations as possible
higher towards the root of the functional semantic schema (i.e., try
to push Fas low as possible).
As a first step, we specify the assembly operations that need
to be performed. Figure 13 shows the different parts involved in the
assembly, plus the assembly operations.
In step 2 of this process we collect all the assembly
constraints that are imposed on the assembly operations. These
constraints are usually imposed by factors such as the space
occupancy laws (you cannot join something to a part that is hidden
by some other part) or simply, user imposed constraints. A user
constraint may be specified in order to force a particular sequence
of operations. For example, we may want to avoid the difficult
operation of attaching the ink-tube to the head if we have already
attached the head to the body (see Figure 13). For this particular

example we decide on the following assembly constraints: f3 fl

and f2 f3. The first constraint, in accordance to a space occupancy

laws, simply states that joining the head to the body will be an

impossible operation if we already joined the cap with the body. The

second constraint is a user constraint which says that we should

connect the ink-tube to the head before we join the head to the body

in order to avoid the undesired operation mentioned above.

SHead Ink Tube


Body Button

Assembly Operations: Assembly rules:

f : Cap-Body f f,

f2 :Head- Ink Tube 2 f3

f3 :Head- Body

f4 : Body Button

Figure 13. Discrete assembly of a ball point pen

In step 3 we form a set, C, containing all constraints from

step 2 plus all remaining assembly operations that do not

participate in any of the constraints. For our example this set is as
follows: C = {f4, f3 fl, f2 f3}.
Step 4 calls for forming what we call the manufacturing
process characteristic equation, E. This equation is formed by
combining all elements of the set, C, using the e operator. For the
equation, C, above we have: E= f4 9 f3 fl f2 f3.
Step 5 calls for simplification of the manufacturing process
characteristic equation (if any simplification is possible) using the
axioms and theorems of the Algebra of Discrete Assembly
Operations. In our case we have the following equation: f4 9 [f3 *
fl] [f2 f3] which by axiom 1 we could rearrange as : f4 E [f2 f31
( [f3 fl]. Finally, using axiom 7a we get the final expression
which is: f4 e [f2 f3 fl]. The corresponding functional schema is
shown in Figure 14.


f4 [ f2 f ] 31f f4 F

f2 f3 f,

Figure 14. Functional schema corresponding to assembly of
Figure 13.

Example 2: Example 2 deals with the assembly of a flashlight.

The parts, as well as the manufacturing operations involved, are

shown in Figure 15. The assembly constraints are as follows:

1) fl f3
3) f5 f6


2) f2 f3

4) f3 *f4

Spring Back

Reflector Barrel

Assembly Operations:

fl : Front Lens

f2 : Reflector Lamp

f3 : Reflector Front

f4 : Front Barrel

f5 : Spring Back

Assembly rules:

fl* f3

f2 f3

f5* f6

f3* f4

: Back Barrel

Figure 15. Discrete assembly of a flashlight.


The manufacturing process characteristic equation is as
follows: E = [fl f3] [f2 f31 ) [f5 f6] [f3 f4]. Combining
terms 1 and 2 using axiom 9, we get: [[fl f2] f3] E [f5 f61 [f3 *
f4]. By letting fl E f2 = f, this equation can be rewritten as: [f fs]
[f5 f6 ( f3 f4]. Now if we apply axiom 1 we get: [f f3] e [f3
f4] [f5 f6]. Again combining terms 1 and 2 using axiom 7, we
get: [f f3 f4] [f5 f6]. As a final step we substitute t for [fl (
f2] to get the final expression: [[fl f2] f3 f4] E [f5 f6]. Figure
16 shows the corresponding functional schema.


A N / \

/3 f4 f5 f6

fl f2

Figure 16. Functional schema corresponding to assembly of
Figure 15.

A Methodological Procedure for Generating Functional Semantic
Schemas Corresoonding to Manufacturing Procedures
In the previous section we presented the Algebra of Function
Sequencing and illustrated its utility by means of few simple
examples. In this section we present a more methodological
approach to the generation of a functional semantic schema capable

of describing a set of implementation alternatives for a
manufacturing procedure. A detailed procedure is presented which
accepts as input a set of subfunction sequencing constraints in the
form of a partially ordered set (POSET) and generates a functional
semantic schema. This semantic schema explicitly represents all
valid manufacturing plans that satisfy the sequencing constraints
and are consistent with the manufacturing procedure they describe.
First, some background information is presented. This
information deals with some useful properties of POSETS. As
previously discussed (see Chapter 5), function sequencing
constraints can be described by a POSET. A POSET can be
represented by a POSET diagram [Berzitiss, 1975]. The procedure
presented here derives a functional semantic schema starting with a
POSET diagram.
Note that the definition of the F association is similar to the
partial order relation '<.' The difference between them is that F is
not reflexive. For functions fi, fj, fi < fj => fi < fj, if i j.
Therefore, an expression of the form fi < fj can be written as fi fj,
which means that the execution of the function fi directly precedes
the execution of fj.
Given a POSET diagram, we could define different levels on
this diagram as follows:

* All maximal nodes on the POSET diagram are assigned to level 0.
* All nodes directly connected to nodes of level 0 are assigned as
nodes of level 1. In particular node fi is assigned to level 1 if
fi < fj, i j where fj is a node of level 0.

* In general, node fi is assigned to level K if there exists fi < fj and

fj is already assigned to level K-1.
* All single disconnected nodes are assigned to level zero.

Consider the diagram shown in Figure 17 as an example. This
diagram has one maximal element namely, fg. Therefore, layer zero
consists of only node fg. Layer one consists of nodes f7 and f8 since
both nodes are < related to f9 (i.e., f7 < f9 and f8 < f9). Similarly,


f7 f8

f4 f6

Figure 17. Example of a rather complex POSET diagram

nodes f4, f5, and f6 belong to layer 2, nodes f2 and f3 belong to layer
3 and, finally, node fi belongs to the last layer, which is layer 4.
Note that functions at the lower part of the diagram need to be
executed before functions higher in the diagram. For example, node
f9 in Figure 17 could only be executed after the execution of both
functions f7 and f8 has completed. Similarly, execution of function
f4 requires that execution of function f2 is completed.

The above discussion leads to the following observations:

1. The execution of a function on level K depends only on the
execution of functions of level K-1.

2. All functions that belong to the same level exhibit no
dependencies to each other. Therefore these functions can
potentially be executed concurrently (i.e., they are A

3. Given a function fi belonging to level K, and fj and fl of level
K-1 such that fj e fi and fl fi, we could write the following
expression [fj fi] e [fl fi] which by axiom 9 reduces to
[fj E fl] fi. This last expression confirms observation 2
above, in that it states that fi needs to execute after both fj
and fl, but fj and fl can execute concurrently, since they both
belong to the same level .

We now present a methodology which enables us to generate a
functional semantic schema describing a manufacturing procedure

starting with the set of sequencing constraints among the
subfunctions of that procedure.

1. Given a set of function sequencing constraints, build a POSET
diagram. See [Berzitiss, 1975] for a detailed procedure for
accomplishing this.

2. Assign levels on the POSET diagram using the method
discussed above.

3. For all levels K, where K = 0 to N and N is the maximal level.
write expressions describing the < relations (or equivalently
the F associations) among nodes of levels K and K-1. The
expressions are of the form fi fj where fi belongs to level K
and fj belongs to level K-1. Use the axioms presented in
Chapter 6 to simplify the expressions if possible. Note that
only simplifications that factor out functions belonging to
level K-1 are done.

4. If more than one expression exists for level zero, combine
these expressions with an A association.

5. Starting at level zero and working towards level N, replace
function fj of level K-1 with the (fn ...) fj expression of
level K, if such an expression exists. Continue until the
maximal level N is reached. The result is a functional

semantic diagram describing the different ways the original
manufacturing process can be implemented.

To clarify the above procedure an example is presented below.

Level 0


X Level 1

Level 2


Level 3

Level 4

Figure 18. Example of a POSET diagram with defined layers

Assume that the POSET diagram of Figure 17 represents the
ordering constraints among the subfunctions of a discrete assembly
manufacturing procedure. The assignment of the levels is shown in
Figure 18. According to this figure, no expressions can be written
for Level 0. The expressions f7 fs and f8 f9 are written for Level

1. These expressions are then simplified to [f7 e fs] f9. For Level
2 the expressions are as follows: f4 f7, f5 f7, f5 f8, and f6 f8.
Keeping in mind that we are trying to get simpler expressions which

9 Level 0

----~---) ---
f9 Level 1
f7 f8

--- -----

'7 f Level 2
/f\ f8
'5 f4 f5 f6

A/ / / Level 3
2 f2 4 3

f f/ Level 4
f'1 '2 1f 3

Figure 19. Building the functional semantic schema.

factor out functions that belong to Level 1, we simplify as follows:
[f4 f51 f7 and [f5 E f61 f8. For Level 3 we have: f2 fs, f3 f5,
f2 f4 and f3 f6, which can simplify to: [f2 fs] fs, f2 f4 and
f3 f6. Finally, for Level 4 the expressions are: fl f2 and fi f3,
which do not further simplify. As a final step, we construct the
diagram by substituting nodes of higher levels with the expressions
of those nodes derived in the next lower level. This is graphically
illustrated in Figure 19.
Notice that function fi can be factored out, since both subnets
of Level 4 require that fi be executed first. Figure 20 shows the
resulting functional semantic schema after this simplification.


Figure 20. Resulting functional semantic schema.

Previously we made the claim that any partial ordering can be
represented using a combination of A and F associations. Proof of
this claim is provided below:

Theorem: Any partial ordering can be represented by a
semantic diagram using a combination of A and F associations.
Proof: By induction on n, the number of elements in the
partially ordered set.
1. Basis: The only ordering on a set {fl} can be fi < fi and can
be represented in the semantic diagram by a single node.
2. Induction step: Assume the claim is true for a partially
ordered set of n-1 elements.
Let H be an n element partially ordered set. Since H is finite,
it has at least a minimal element, say fm. If fm is omitted, then the
set {H-fm) having n-1 elements is still an ordered set and, by the
induction hypothesis, has a semantic diagram representation.
Therefore, incorporate fm in this semantic diagram as follows:

a. Determine the level on which fm should be inserted. Notice that
since fm is a minimal element, it could be an isolated node. If
it is an isolated node (which means that fm could be executed
concurrently with any other function), place fm in an A
association with all maximal nodes currently in the diagram. If
fm is not an isolated node, then it can only be inserted into
either the last Level N or in a new Level N+1. The later case
means that a new level is created. Recall that elements of
some level, say I, can be F related only with elements of Level

I-1. If we assume that N is currently the maximal level, and
fm is F related to elements of this level, then fm should be
inserted into a new Level N+1. On the other hand, if fm is F
related to elements of Level N-1, then fm should be inserted
into Level N and no new level is created.

b. If fm is to be inserted in a new level (i.e., N+1), write
expressions describing the < relations (or equivalently the F
associations) among fm and nodes of Level N. These
expressions are of the form fm fi where fi belongs to Level N.
Then merge Levels N and N+1 by replacing links pointing to
function fi of Level N, with links pointing to fm fi of level

c. If fm is to be inserted in Level N (the currently minimal level),
write expressions describing the < relations (or equivalently
the F associations) among fm and nodes of Level N-1. These
expressions are of the form fm fi where fi belongs to Level
N-1. Every such node, fi, of Level N-1 can either be a leaf node
on the semantic diagram or it can correspond to a subnet. If it
is a leaf node, then replace links pointing to function, fi, with
links pointing to the expression fm fi of Level N. In the case
that fi corresponds to a subnet, this subnet being of the form
[fn 9 fp ...] fi needs to be combined with the expression
fm fi. The resulting expression is [fn E fp E ... 9 fm] fi and
replaces the original subnet. The result is a semantic diagram
for H.


This chapter starts with a brief introduction to Petri net
theory. We then discuss the organization of the control knowledge
base. The chapter concludes by presenting a simple methodology
which allows the transition from the functional semantic net
representation (i.e., the manufacturing plan captured by the
functional schema) to a corresponding Petri net representation. The
Petri net resulting from this transformation, as will be discussed
further, constitutes the skeleton for the workcell control.

Introduction to Petri Net Theory
This section is a brief introduction to Petri net theory. Only
the basic ideas are presented here. A more comprehensive study of
Petri nets can be found in the book by Peterson [Peterson, 1981].
Petri nets consist of a graphical and mathematical tool with
great potential in modeling systems which are characterized as
being concurrent, asynchronous, parallel, non-deterministic and/or
stochastic. As a mathematical tool, it allows building mathematical
models that describe the system's behavior [Murata, 1989].

What are Petri Nets?
A Petri net is a directed, weighted, bipartite graph consisting
of two kinds of nodes called places and transitions. Directed arcs
connect a place to a transition or a transition to a place.
Graphically, we draw places as circles and transitions as bars (see
Figure 21). Arcs can be labeled with a weight, which is a positive
integer, such that a k-weighted arc is equivalent to drawing k
parallel arcs. The label for an arc with weight of one is usually

Figure 21. A Petri net.

A marking, M, on a Petri net is a mapping, M: P -> I, where P is
the set of places and I is the set non-negative integers. M assigns
tokens to each place in the net. If a marking assigns to place p a
non-negative integer, k, we say that p is marked with k tokens.
Graphically, we place k dots (representing the tokens) in the circle
representing place p. Sometimes it is convenient to view M as an
m-element vector (where m is the total number of places) whose ith
component, denoted as M(i), is the number of tokens in place pi.
A formal definition of a Petri net is as follows [Murata, 1989]:

A Petri net is a 5-tuple, Pn = where:
P = {pi,P2, ...,pm} is a finite set of places,
T = {ti, t2, ..., tn} is a finite set of transitions,
F c (P x T) u (Tx P) is a set of arcs,
W: F -* {1, 2, 3, ...} is a weight function,
Mo: P {0, 1, 2, 3, ...} is the initial marking and
PnT = 0 and Pu T 0.

We present below a few more definitions which are necessary
for understanding the material in the rest of this chapter.

1. The set of input places for a transition, t, is given by
I(t) = {p I (p, t) E F} and the set of output places of a
transition, t, is given by O(t) = {p I (t, p) e F}. Figure 22
illustrates this for transition ti.

P / I(t ) = (p Lp

/(t) = {p pj
t I I tl I
2 tp2 is a source,
p4 is a sink.

P30 Q

Figure 22. Illustrating Petri net concepts.

2. A transition without an input place is called a source
transition and is always enabled.
3. A transition without any output place is called a sink
transition. The firing of a sink transition consumes tokens
but does not produce any.
4. A transition, t, is said to be enabled if every place, p E I(t),
is marked with at least W(p, t) tokens, where W(p, t) is the
weight of the arc from p to t. In other words, for t to be
enabled every input place p of t has to have at least as many
tokens as arcs from p to t (see Figure 23a).
5. Firing an enabled transition, t, removes W(p, t) tokens
from each input place, p e I(t) and places W(t, p) tokens to
each output place, p E O(t), (see Figures 23a and 23b).

6. A finite capacity Petri net is a Petri net in which each
place, p, has an associated capacity, K(p), which is defined as
the maximum number of tokens that p can hold at any time. A
finite capacity Petri net is used when modeling systems that
contain finite buffers, etc.

Marking before firing.
tI is an enabled transition

Marking after firing.
Transition t is not
enabled any more

Figure 23. Illustrating the firing mechanism.

Petri nets have been used to model and simulate a wide variety
of problems. These include operating systems and parallel machines
[Lautenbach and Schmid, 1974; Baer and Ellis, 1977], chemical
reactions, and manufacturing [Lipp, 1983; Martinez et al.: 1986;
Caselli et al., 1992].
According to the application domain, the Petri net entities
(namely the transitions, places and tokens) are given a meaning or
interpretation. In the manufacturing domain we usually have the
following interpretation: Transitions represent manufacturing
processes, places represent buffers or decision points and tokens
represent parts or information units.
Petri nets can be used to represent the manufacturing WC
control in a top-down fashion at various levels of abstraction and
detail. For example, a single transition at a higher level such as
"place part into buffer" may be expanded at a lower level into a
sequence of transitions. This sequence may be "locate part."
"pick-up part," "locate buffer" and "place part." The use of different
levels of abstraction allows the manufacturing engineer to work at a
particular level, without having to worry about the implementation
of all lower levels.

PN Examples
Below, several examples of Petri nets are presented. These
Peri net constructs, as discussed later, are very useful in developing
control models for structural objects, as well as combining a set of
control models to build complex and comprehensive workcell control
algorithms. The simple Petri nets presented here enable us to model