Uploaded by Rakesh Nadella

Bullers Nof Whinston 1980 Artificial Intelligence in Manufacturing Planning and Control

advertisement
AIIE Transactions
ISSN: 0569-5554 (Print) (Online) Journal homepage: https://www.tandfonline.com/loi/uiie19
Artificial Intelligence in Manufacturing Planning
and Control
William I. Bullers , Shimon Y. Nof & Andrew B. Whinston
To cite this article: William I. Bullers , Shimon Y. Nof & Andrew B. Whinston (1980) Artificial
Intelligence in Manufacturing Planning and Control, AIIE Transactions, 12:4, 351-363, DOI:
10.1080/05695558008974527
To link to this article: https://doi.org/10.1080/05695558008974527
Published online: 06 Jul 2007.
Submit your article to this journal
Article views: 404
View related articles
Citing articles: 2 View citing articles
Full Terms & Conditions of access and use can be found at
https://www.tandfonline.com/action/journalInformation?journalCode=uiie21
Artificial Intelligence in Manufacturing
Planning and Control
WILLIAM I. BULLERS
Anderson School of Management
University of New Mexico
Albuquerque, N.M. 871 31
SHIMON Y. NOF
SENIORMEMBER, AIIE
School of Industrial Engineering
ANDREW 1;. WHINSTON
Krannert School of Management and
Computer Science Department
Purdue University
West Lafayette, Indiana 47907
Abst,-act: This paper explores some of the typical problems in manufacturing systems planning and
control, particularly those pertinent t o the automatic operation, and describes how artificial intelligence
methods can be applied. We demonstrate how predicate logic and theorem proving techniques using
resolution can be used in a manufacturing environment. Assertions of fact and axioms representing the
knowledge required are given in an underlying data base. Illustrative problems demonstrate how user
problems, such as assignment of jobs t o machines when conflicts occur, can be handled by a decision
support system in the fratnework of resolution in a problem reduction approach.
Manufacturing planning and control involves managerial
decision making in three main levels of activities: the
strategic level of production and inventory planning and
control; the tactical level of manufacturing operations planning and control; and the operational level of process and
material flow planning and control. The dynamic nature of
the manufacturing environment stems from the highlyvariable nature of factors such as customer orders influencing
the strategic level; material and capacity constraints in the
tactical level, and machine or work-station availability in the
operational level. In order to'aid manufacturing managers in
achieving productivity goals, various concepts of information
systems and computer control have been developed as
described, for example, in [26, 28, 311.
In more automatic systems, where facilities operate
directly under computer control, managerial supervision
becomes even more critical and complicated. Information
and control aspects of computerized manufacturing were
described in [27]. The high degree of interdependency
among machines, material handling devices, and other
process resources requires a large number of timely decisions
at the various levels of operation to be made. Typically,
these decisions are based on large amounts of information
Received April 1979; revised March 1980. Paper was handled by
Simulation, Gaming and Information Systems Department.
December 1980, AIIE TRANSACTIONS
and under time pressure. Due t o the dynamic nature of the
manufacturing environment, decision problems are often
unstructured, and have to be continuously reviewed in view
of the changing status of the system.
Traditionally, the manufacturing environment has been
controlled by process controllers, shop-floor computer controllers, and other computer aids for production planning.
But process controllers are typically dedicated to well
defined processes which vary within predetermined ranges.
When multi-level, highly variable operations reqvire more
timely, complex controls hierarchical systems of monitoring
and management have to be applied. A major drawback of
such procedures is their limited ability t o cope with unstructured problems, and to be responsive to dynamic variations;
particularly, this stems from time delays in comprehension
of the new circumstances and new problems by human
operators.
While computer technology can rapidly process large
amounts of data by sophisticated logic, many of the
necessary decisions must wait until human operators can
sift through the data, become familiar with the system
status, and select proper actions. This is where artificial
intelligence techniques can provide better planning and
control towards a higher productivity of automatic manufacturing. In simple terms, some of the human intelligence
which is needed t o make decisions will be transferred t o the
computer machinery; many decisions will then either be
0569-5554/80/1200-0351/$2.00/0
1980 AIIE
35 1
made automatically, or information will be prepared for
human operators to minimize delays in their decisions.
Artificial intelligence techniques can be used to develop
decision aids that are capable of handling large streams of
data as well as performing logic manipulation for conflict
resolution, sequencing and resource allocation, etc.
In previous work [I 9, 21) this problem was discussed
and the concept of the Manufacturing Operating System
(MOS) was suggested as a framework for handling the
necessary decision support. Artificial intelligence methods
were indicated as a useful approach to systematically
represent planning and control knowledge in the control
system.
The purpose of this paper is first to explore some of the
typical manufacturing planning and control problems, particularly those pertinent to the automatic environment, and
second, to describe how artificial intelligence methods can
be applied to them.
variable x, y, z or expression f(al=tl, . . . , aj=tj) where f isa
j-ary function symbol, ai is a function attribute identifier,
and ti is a term. Predicate symbols, function symbols, and
variables are any three sets of mutually disjoint symbols. A
constant is any 0-ary function symbol such as a, b, c. To
help minimize the number of symbols used, we permit the
number of attributes to vary for a given predicate or function
symbol. This contrasts with the usual syntax in which predicates and functions are fixed in size. The complement of a
predicate P is denoted -P. Methods for transforming an
arbitrary first-order predicate calculus sentence into clausal
form are shown in Nilsson [ l 7 ] , or Chang and Lee [5] .
The semantics of sentences in clausal form are also simple
[30]. Interpret the sentence{C1, Cz, . . . , C, ) as a conjunction:
C1 and C2 and . . . and C ,
Interpret the clause B1,. . . , B, +A
. . , xk as:
. . ,A, with variables
XI..
Predicate Logic in Artificial Intelligence
Predicate Logic as a Programming Language
A number of question-answering and problem-solving systems
have been developed using first-order predicate logic as a
language for representing knowledge and resolution-type
theorem provers for a deductive mechanism. Predicate logic
is a natural language for describing states or stating problems.
Moreover, predicate logic can be used to express algorithms
in addition t o merely facts. Kowalski 1131 and van Emden
[29] have both given supportive arguments for the use of
predicate logic as a high level programming language. Predicate logic addresses the descriptive aspect of a program by
permitting a specification of what is to be done, not how to
do it. Yet with respect to a given deductive mechanism, a
predicate logic specification has implications for the imperative aspect.
The deductive mechanism most commonly used to make
inferences uses resolution, a theorem-proving technique
developed by Robinson [24]. Theorem-proving procedures
using some adaptation of Kowalski and Kuchner's SLresolution (linear resolution with selection function) [14]
are well suited to heuristic search for efficiency in proving
theorems. In particular, Kowalski's LUSH (Linear resolution
with Unrestricted Selection for Horn clauses) system [13] ,
provides a proof procedure that can solve problems a t least
as complex as those that can be programmed in a high-level
programming language [29].
For automatic deduction, the "clausal form" of firstorder predicate logic has evolved. Its syntax is quite simple.
A sentence in clausal form is a set of clauses. A clause is a
pair of sets of atomic formulas B1, . . . , B,+-A,, . . . , A,.
An atomic formula has the form P(al=tl, . . . , ak=tk)where
P is a k-ary predicate symbol, ai is a predicate attribute
identifier, and ti is a term. An attribute identifier, not
normally a part of the clausal form syntax, is used here as a
notational aid in interpreting predicate terms. A term is a
B1 or
. . . or B, is implied by A l and . . . and A , .
The special cases with n=O and/or m=O have special interpretations:
1. If n=O, then read B1, . . . , B,+ as:
for all x l , . . . , x k : B1 or . . . or B,.
2. If m=O, then read +Al, . . . , A , as:
for no x l , . . . , x k : A1 and . . . and A,.
3. If n=O and m=O, then write the null clause
ted as denoting falsity (or contradiction).
interpre-
The basic framework for interpreting programs in predicate logic is given by Kowalski with his procedural interpretation of Horn clauses [13]. A Horn clause B+A 1,. . . ,An
is interpreted as a procedure declaration with the implication
B equivalent to a procedure name, and the set (A 1, . . . , A,}
equivalent to a procedure body consisting of a set of
procedure calls Ai. The clause, B e , is viewed as an assertion
of fact; the clause, +-A . . . ,A, as a goal statement (procedure with no name) which is the goal of successfully
executing all procedure calls Ai; and the null clause
viewed as a halt statement (satisfied goal statement).
Sentences in predicate logic are interpreted as programs,
derivations as computations, and proof procedures as feasible
executors of predicate logic programs. Computation applied
to Horn clause programs concerns the repeated use of
resolution to derive new goal statements from old ones.
Kowalski views resolution as procedural invocation, operating as follows:
Given (1) a goal statement +A I , . . . , Ai-l, Ai, Ai+l ,
. . . , A , and
AIIE TRANSACTIONS. Volume 12, No. 4
(2) procedure B+Bl, . . . , B, whose name B
"matches" the selected procedure call A i(i.e.,
a general substitution of terms for variables makes A i and B identical),
then resolution derives a new goal statement (with substitution 6 ) :
This matching, called "procedure invocation by pattern
matching" in PLANNER [12], is known as a feature of
several programming languages for A1 research [ I ] . Procedural invocation comprises the LUSH rule of inference. It is
resolution with the goal statement and a Horn clause as
parents. A proof procedure with a selection rule for choosing
A, and a search strategy as components serves to execute
the predicate logic programs.
Predicate Logic in Question-Answering and Problem Solving
Many question-answering systems, such as QA1 [ l o ] , have
used first-order predicate calculus to express the semantic
content of data in the systems. Others, including QA2 [ l o ]
and QA3 [9] have also used a resolution-type theorem
prover as the deductive mechanism as well as first-order
predicate calculus as the system language. More recently,
predicate logic has been used in several deductive query
systems that combine resolution-type theorem proving
techniques with an underlying data base system for knowledge storage and retrieval. These systems use LUSH to
partially prove theorems, then invoke a data base query
system to complete the proof. Chang's DEDUCE system [4]
and Minker's inferential relational system [I 5 , 161 are two
examples. Problem-solving systems have also made use of
predicate logic theorem proving techniques. PROLOG has
been used to perform automatic programming tasks 1297,
while STRIPS [8, 71 and ABSTRIPS [25] formulate plans
to solve robot problems. In this paper we demonstrate how
predicate logic and the LUSH rule of inference can be used
at a high level of control in a manufacturing environment to
solve operations management problems.
Manufacturing Planning and Control Requirements
In all three levels of manufacturing activities defined above,
planning and control are required mainly in order to achieve
efficient, productive utilization of resources to meet a
schedule of production demands. Because of the dynamic
nature of the manufacturing system which is due t o external
and internal forces of change, planning and control decisions
December 1980, AIIE TRANSACTIONS
are critical to the overall performance of the system. In [22]
an extensive survey includes a discussion of literature concerning such decisions. For example, in the strategic level,
planning is needed of the production schedule to satisfy
quantities which are demanded by the market. In parallel,
inventory has to be controlled such that sufficient components, materials, tools are available for the planned production schedule, and such that no excessive quantities are manufactured which necessitate lengthy, costly storage.
In the tactical level the planned production schedule and
inventory have t o be coordinated with machine capacity,
maintenance plans, and with labor availability for the given
period. Physical storage capacities should also be considered
at this level.
Managerial processes in the above two levels have been
traditionally performed quite successfully with the aid of
information systems. At the operational level, an interface
between human managers and machines is lacking, particularly in the automated manufacturing systems. Two recent
works [18, 201 describe several repetitive, typical control
issues in computerized manufacturing, in which parts in
process travel automatically between work stations (usually
numerically controlled machines). Three such issues are the
Part Mix, the Part Entry and Assignment, and the Process
Selection which are representative of many other manufacturing planning and control issues.
The Part Mix problem is to select for sub-periods particular sets of parts out of the larger set of parts scheduled for
production in the whole period. Since different parts require
different manufacturing resources, conflicts between competing parts can be minimized with the proper selection of
part mix.
The Part Entry and Assignment problem is to sequence
individual part entry into the system, including initial entry
into an empty system, general entry into a saturated system,
and assignment of parts to machines when conflicts occur.
The Process Selection problem is to decide which one of
several alternative processes, all producing the same part but
requiring different machines and different times, should be
selected for a given part.
The three problems are intertwined in that the particular
part mix selected for simultaneous production determines
the nature of the part flow, entry and assignment, based on
the balance and conflict in process, machine, and time
requirements. Analysis of these problems and others, and
evaluation of the consequences of following different policy
decisions with regard to overall performance, show that such
planning and control issues are critical. But while off-line,
time-consuming analyses such as digital simulation indicate
the importance of the problem, a different approach is
necessary when decisions have t o be made and implemented
in real-time, and mistakes can be highly costly. In the latter
case some decisions should probably be delegated to an
automatic control mechanism, which must possess knowledge of the manufacturing system as well as its momentary
status. In the following sections this approach is developed
and examples illustrate how some of the issues described
here can be handled.
Use of Predicate Logic in Operations Management
Problem Solving in a Static Time Domain
Many operations management problems deal with a static
time domain. Problems of this type can be adequately
handled by problem-solving techniques utilizing a single
state representation of the computerized manufacturing
system. Predicate logic is a natural language for stating facts
and making inferences in such an environment.Computerized
manufacturing system entities, as well as simple relationships
among these entities, can be modeled by predicates, while
complex relationships among the entities can be defined by
axioms. As we shall illustrate in the next section, a description of the manufacturing system can be given by assertions
of fact in predicate logic.
Problem solving in this domain can be performed using a
problem-reduction approach (see [17]) and a rule of
inference such as LUSH. Combining resolution with data
base retrieval to prove theorems permits us to use a slightly
less restrictive clausal form of predicate calculus than that
introduced earlier. Goal statements and procedure declarations (axioms) are given with explicit quantifiers preceding
the clause. Unlike the clausal form given in the second section (with implicit universal quantifiers for all variables), we
permit both existential (3) and universal(V) quantifiers for
variables. During resolution, however, an existentially quantified variable would be replaced by a Skolem function (see
[17] or [5] for a discussion of replacement technique).
We also eliminate the implication symbol, +, from goal
statements and assertions of fact, retaining it only for
procedure declarations.
Thus the problem reduction representation of the system
is given in predicate logic as follows:
1. A problem description representing a problem to be
solved is given by a goal statement:
consisting of procedure calls (predicates) Ai with
quantifiers Q , , . . . , Q, and variables x l , . . . , x,.
2. Problem reduction operators used to transform a
problem description into a subproblem description are
given by procedure declarations (axioms):
3. Primitive Problem descriptions (the objective of problem reduction) are given by procedures for retrieving
(or otherwise confirming) assertions of fact:
problem reduction operators, is applied to reduce the
initial goal statement to a set of primitive problem
descriptions.
The primitive problems derived are solved by methods
other than resolution. Two methods, both utilizing "built-in
predicates" are used t o evaluate these primitive problems.
We classify the primitive problems by the type of procedure
used t o evaluate the predicate:
1. Primitive data base management system (DBMS) procedures describe primitive problems that are evaluated
using data base retrieval methods. For a primitive
problem such as:
with variablesxl, . . . ,x,, a primitive DBMS procedure
"B" is invoked to retrieve all data explicitly represented
in the data base that satisfies the predicate. The n
assertions of fact retrieved from the data base have the
form:
where the constants (cil, ci2, . . . , cir) represent the
ith data base record satisfying the predicate "B". The
underlying DBMS can be either a relational system [6]
such as in Chang's DEDUCE [4] , Minker's inferential
relational system [16], or a CODASYL network data
base system such as GPLAN [ I l l where predicates
are represented as described in [2] .
2. Primitive subroutine procedures are used to evaluate
predicates such as LESS-THAN (x, y) and return a
"true" value if x < y . This type of procedure is used
in the comparison of characters and numbers, as well
as for other functions.
These methods for evaluating predicates permit us t o vary
the number of attributes for a given predicate symbol. We
define a predicate such as P(al=xl, a2=x2) with two attributes, yet use the predicate symbol "P" to denote a class of
predicates which use various combinations of the two attributes. Thus P(al =xl ), P(a2=x2), and P(al =xl, a2=x2) use
the predicate symbol "P," but each represents a distinct
predicate as qualified by its attribute list. This convention
tends to minimize the number of different predicate symbols
used in the problem representation, and hence minimize the
number of evaluation procedures required.
The problem reduction representation, along with the
LUSH rule of inference and proof procedure, form the basis
for problem solving in the static time domain of operations
management.
B(al = x l , . . . , a, = x,)
where the ai's are attributes and the xi's are variables.
The top-down proof procedure of LUSH, deriving new
goal statements from old ones by application of the
354
Problem Solving in a Dynamic Time Domain
In a computerized manufacturing system, as in many
AIIE TRANSACTIONS.Volume 12, No. 4
environments, the state of the system is not static, however
A multitude of changes continually occur over time: part
orders are entered into the system, machines are scheduled
to produce the parts, a series of operations are performed
on the parts, and completed parts depart from the system.
Even an entity such as a machine, whose existence is static
in the system (i.e., it is always present for the life of an
inference session), undergoes state changes as it goes from
an idle state to an allocated state while machining a part,
then back to idle again. To model the status of an entity
with respect to an attribute that changes we use a predicate
to represent the attribute. Take for example a predicate
such as:
MCH-IDLE(mch=x) .
ment that changes over time, such a representation is not
sufficient. We often wish to know the time of occurrence of
an event (e.g., when the machine last became idle), or the
multiple times of occurrences of events (e.g., what times the
machine became idle during the previous 8 hours). The concept of time in a dynamic environment has been discussed
in the context of planning for robot problem solving as in
STRIPS [7] , as well as with respect to temporal references
in natural language as in a question answering system [3].
To reflect the changing states in manufacturing, we introduce time into all predicates for which assertions of fact are
dynamic. The predicate MCH-IDLE now becomes:
For a machine "Ml" we specify an assertion of fact:
where attribute "t" represents the time this assertion of fact
was stated. Now, however, we can no longer merely use the
absence of the assertion to indicate allocation. To do so
would mean the loss of information as to time of allocation.
Thus, for each predicate involving time we also introduce a
complementary predicate denoting the negation of the original predicate. Such a predicate will always be prefixed by an
"N" to indicate negation as in:
to indicate that "Ml" is idle. (All constant terms will be
preceded by the symbol "#" for ease of identification). The
absence of such an assertion of fact can be interpreted
in one of two ways: either we are uncertain as to whether
"Ml" is idle, or we assume the machine is not idle (i.e., it is
allocated). Reiter [23] has categorized the assumptions
underlying these two interpretations as "open world" and
"closed world" respectively. In deductive question and
answering with an open world assumption, the only facts
which are known for certain to be true are those which can
be explicitly derived from the knowledge base. One recognizes that there might be "gaps" in histher knowledge.
Conversely, under a closed world assumption, a negative fact
is implicitly known if its positive counterpart cannot be
explicitly derived. Thus, if we cannot derive the fact that
"MI is idle," we haveimplicitly shown that "M1 is not idle."
This implicit representation of negative facts presumes total
knowledge about thed domain being modeled.
The closed world assumption is involved in our information system. In doing so, we recognize the concommitant
requirements for a detailed analysis and design of the information system tojustify this presumption of total knowledge
about the environment of a computerized manufacturing
system. Yet this requirement is typical in the design of
any information system or simulation model. The system
designer is responsible for specifying the knowledge base
and logic of system operation in adequate detail to assure
validity of the model and correctness of the information
output. We also note that while the closed world assumption
can lead to inconsistencies in the data base, Reiter has
shown [23] that no such inconsistencies can arise if facts
stored in the data base are restricted to Horn clauses.
Thus, in a static case, we can evaluate the two mutually
exclusive assertions of fact:
MCH-IDLE(mch=#Ml)
-MCH-IDLE(mch=#Ml)
(machine "M 1" is idle)
(machine "MI" is not idle)
to determine if "MI" is idle or allocated. Yet in an environ-
-
--
--
-
December 1980, AIIE TRANSACTIONS
MCH-IDLE(mch=x, t=y) (mch x became idle at time =y)
N-MCH-IDLE(mch=x, t=y)
(mchx became allocated at time
time = y ) .
Using such predicate/complement pairs we can model changing states over time.
The introduction of time in such a manner necessitates
one further construct to permit inferences to be made in a
reasonable manner. Consider alternating MCH-IDLE and
N-MCH-IDLE assertions of fact during the time period "t "
through "t9":
From these assertions we see the machine was idle from t l
until t3, t4 until t7, then from t9 on. To determine if a machine is presently idle (say, at time t 12), or if a machine was
idle at some time in the past (say, at time t8), it is no longer
sufficient to examine solely MCH-IDLE predicates. Retrieval
of one or all MCH-IDLE assertions of fact must be coupled
with retrieval of N-MCH-IDLE assertions. Given a reference
time, we need to determine which assertion, MCH-IDLE or
N-MCH-IDLE, is the most recent with respect to the
reference time.
For any given predicate, B(al = x l ,. . . ,ar =x,, t=x,.+ ),
we introduce a generic predicate:
MRA-B(al =xl,. . ., a, = ~ , t = x , + ref-time
~,
=x,+~)
to denote the "Most Recent Assertion of B." Note that
the attributes of "MRA-B are identical to those of " B
except for the addition of a reference time attribute. For
given variables x l , . . . , x,, assertion time x,+ 1 , and a reference time xr+, , the predicate "MRA-5" is true if (1) the
most recent assertion of "B" with respect to time x,,, was
made at time & + I , and (2) no "N-B" assertion was made
between time x , + ~and time x , + ~(i.e., no assertion was
made for the negation of B between
and x , + ~ ) . In
axiom format the MRA predicate for MCH-IDLE can be
given as follows:
MRA-MCH-IDLE (mch=x, t=y,, ref-time = y,) +
(mch x was most recently idle at time
y, with respect to time y,) if
MCH-IDLE (mch=x, t=yi), (x was idle at times
LEO-Ii, yn),
,...,y i ))
(where y i <y,)
MCH-IDLE(mch=x, t=y,) (x was idle at time y,)
LEbm, yn),
where y, G y,)
GEGm, yi),
b,
is the most recent y i )
N-MCH-IDLE(mch=x, t=zj), ( x was not idle at {z l , . .. , zj ))
LE(zj>~ n , )
(where zj <y,)
N-MCH-IDLE(mch=x, t=z ), (X was not idle at time z )
<y,)
LE(zl, yn)
(where z
GE(z1, zj)
(zl is the most recent zj)
GTbJrn,z l )
('ym>zl, i.e., the last "idle assertion" is more recent that the last
"not idle assertion") .
Using the preceding MCH-IDLE and N-MCH-IDLE assertions
for time period "tl" through "t9," we observe that the following MRA-MCH-IDLE and N-MRA-MCH-IDLEassertions
are all "true" based upon axiom (Al):
MRA-MCH-IDLE(mch= #M2, t = #t 1, ref-time = #t 1)
MRA-MCH-IDLE(mch= #M2, t = #t I , ref-time = #t2)
N-MRA-MCH-IDLE(mch= #M2, t = #t3, ref-time = #t3)
MRA-MCH-IDLE(mch= #M2, t = #t4, ref-time = #4)
etc.
Note that another way of stating the N-MRA-MCH-IDLE assertion above is:
356
That is, for all times y, it is not true that machine "M2"
was idle as of time "t3."
The "most recent assertion predicate" enables dynamic
inference with predicates that have a corresponding complementary predicate. Yet the axiom given above is too unwieldy to be utilized for frequent evaluation ofmost recent
assertion predicates. Fortunately, however. such a generic
predicate, applicable to each predicate utilizing time, can be
efficiently evaluated at the primitive problem level. Data
base retrieval procedures can readily determine the most
recent assertion of a data base fact and compare the time of
that assertion to that of the most recent assertion of that
predicate's complement.
Utilizing (1) a problem reduction representation to model
a system, (2)a time attribute in all dynamic predicates, (3) a
corresponding coinplementary predicate for all dynamic
predicates, and (4) most recent assertion predicates, we can
represent the dynamic state of a computerized manufacturing system (CMS). Given a representation of the system in
predicate logic, we can then utilize the LUSH rule of
inference and proof procedure to solve operations management problems in such an environment.
Operation and Simulation Mode in a Dynamic Time Domain
The preceding approach to representation of a CMS enables
us to model the system and also its operations. This will be
shown in the illustrative operations management problem in
the next section. However, we should note here how the
modes of updating the system state will enable problem
solving associated with past, present, and future states.
Generation of past and present states of the CMS will be
done concurrently with actual operation of the manufacturing system. Assertions of facts in the data base can be accommodated as information pertaining t o system entities
and relationships is processed. We denote this phase of the
decision support system operation as the "operation mode."
Since each dynamic assertion of fact is flagged with a time
attribute, the data base reflects both current and past states
of the system. This data base forms the "operational data
base" of the system. Problem solving using the LUSH rule
of inference and proof procedure can then be used on this
operational data base to solve many operations management
problems.
Problem solving for future states is another matter,
however. To forecast future states of the CMS, we utilize a
"simulation mode" of the decision support system. The
simulation mode updates the system state to some future
time. Axiomatic operators are used with the set of states as
the domain and the range. The operators are applied according to various parameters specifying how the simulated system is to be operated. Each parameter set simulated leads to
a different future state. The assertions of fact generated,
comprising the "simulation data base," can then be used by
the same theorem proving techniques used on the operational data base. Comparison of criterion across the different
simulated states can be used to determine what operational
AIIE TRANSACTIONS. Volume 12, No. 4
parameters should be used in actual operation over the
forecast horizon.
Illustrative Operations Management Problems
Consider a CMS as shown in Fig. 1. A direct numerical
control line (DNC-line) such as this embodies automation of
workpiece flow through a series of machine tools. Assume
this line includes two automatic tool-changer machines
(M2 and M3) and a load/unload station (MI) for palletizing
parts. A bi-directional cart capable of carrying two palletized
parts travels along a track linking the machines. Parts
fuctured in the load/unload station are mounted on pallets,
then shuttled by the cart t o the various machines on the
line. A part routing, detailing the individual operations to be
performed on each part type, governs scheduling of a part
to a machine. Some operations can be performed on either
machine but processing times vary depending upon the
machine assigned. Thus scheduling of parts t o a machine
can be nondeterministic. The optimal schedule to maximize
some performance criterion (e.g., maximize part production,
minimize lateness of parts having due-dates, etc.) is dependent upon the dynamic state changes occurring in the
system. If an operation for a part is scheduled at a machine,
the part is delivered by the cart and shuttled to that
machine's work center if the machine is idle.
Tools
IIm
Table 1 : Predicates.
CMS
Predicate
I
A. Entity Assertions
1. Static Assertions
MCH(mch,mch-type)
CART(cart,cart-speed,part-position)
TOOL(tool,tool-type,tool-use-count)
TRACK(track-loc,next-loc,distance)
PALLET(pallet,pallet-type)
OPERATION(op)
INPUT-BINtbin)
OUTPUT-BIN(bin)
PART (part,part-type,part-due-date,t)
B. Elementary Relationship Assertions
1. Static Assertions
MCH-TOOLING(mch,tool,tool-type)
MCH-OP(mch,op,op-time)
OP-TOOLING(op,tool-type)
PART-ROUTING(part-type,op,next-op)
PART-PALLET(part-type.pallet-type)
LOAD-OP(op)
MCH-TRACK(mch,track-loc,shuttletime)
2. Dynamic Assertions
MCH-PART(mch,part,t)
CART-PART(cart,part-position,part,t)
MCH-PALLETS(mch,pallet,t)
MCH-UP(mch,t)
CART-LOCATION(cart,track-loc,t)
PALLETIZED-PART(part,pallet,t)
INPUT-PART(mch,input-bin,part,t)
OUTPUT-PART(mch,output-bin,part,t)
COMPLETE-PART-OP(part,op,t)
Um
I
Unload
Machine T a b l e
cart
part-position
Fig. 1. A computerized manufacturing system.
A number of predicate logic assertions of fact are needed
to represent the machines, parts, pallets, operations, etc.,
and their relationships in this CMS. Table I shows a list of
such predicates. These assertions of fact, both static and
dynamic, form the underlying data base of the decision
support-system. More complex relationships, represented
by axioms, will be shown in the problems to follow.
To examine how the CMS is represented in predicate
logic and how theorem proving is used in the operations
management environment,, we first consider a static time
domain. Table 2 details two parts and corresponding operations using the predicates defined in Table 1. Part member
"pl" is of type "A" and is due on Julian date 79180. Part
number "p2" is of type " B and is due' 79185. Four
December 1980, AIIE TRANSACTIONS
(machine)
(cart)
(tool)
(cart track location
points)
(pallet)
(operation)
(part input bin)
(part output bin)
2. Dynamic Assertions
Tools
Load/
Interpretation
C. Subroutine Assertions
ADD(addend 1, addend 2, sum)
LE(operand 1,operand 2)
etc.
(part)
(machine tooling)
(machine operations)
(operation tooling)
(part routing)
(part pallet)
(load operation)
(track location of
machine)
(machine has part)
(cart has part)
(machine has pallets)
(machine i s up)
(cart i s at track location)
(part is mounted on pallet)
(part is i n input bin)
(part is in output bin)
(part operation is complete)
(part operation i s
currently in progress
(machine i s idle)
(addendl +addend2=sum)
(operandl < operand2)
operations are defined: "opl", "op2", "opcF", and "op6".
The part routing for a part of type "A" specifies that
operations "opl", "op4", and "op2" are t o be performed
in that sequence. Parts of type "B" require "opl", ''op6':
and "op2". Finally, part "pl" has already had operation
"op 1" performed.
The operations management problems that can be addressed range from elementary ones that can be solved
directly by primitive problem procedures to complex problems requiring complex derivations. We illustrate problems
of both types in order of increasing complexity by showing:
(a) an example problem, (b) the corresponding goal statement expressed in predicate logic, (c) procedure declarations
(i.e., axioms) if theorem proving is required to solve the
problem (d) computation used to derive the solution,
(e) the derived assertions of fact, and (f) the problem
Table 2: Assertlons of fact needed for lllustratlve problem.
1 . Part Assertlons
PART(part=#pl ,part-type=#A,part-due-date=79180,t=to.o)
PART(part=#p2,part-type=#B,part-due-date=79l85,t=to
2. Operation Assertlons
OPERATION(op=#opl)
OPERATION(op=#op2)
OPERATlON(op=#op4)
OPERATION(op=#op6)
3. Part Rout~ngs
PART-ROUTING(part-type=#A,op=@,next-op=#opl )
PART-ROUTING (part-type=#A,op=#opl ,next-op=#op4)
PART-ROUTING(part-type=#A,op=#op4,next-op=#op2)
PART-ROUT1 NG (part-type=#A,op=#op2,next-op=@)
PART-ROUTING(part-type=#B,op=@,next-op=#pl )
PART-ROUTlNGIpart-type=#B, oP=#opl ,next-op=#op6)
PART-ROUT1 NG(part-type=#B,op=#op6,next-op=#op2)
PART-ROUTING(part-type=#B,op=#op2,next-op=@)
I
4. Machine Operat~ons
MCH-OP(mch=#Ml ,op=#opl .op-t1me=2.0)
MCH-OP(mch=#Ml ,op=#op2,op-tlme=2.0)
MCH-OP(mch=#M2,op=#op4,op-time=15.0)
MCH-OPlmch=#M2,op=#op6,op-t1me=40.0)
MCH-OP(mch=#M3,0p=#opG,op-t1me=48.0)
5. Completed Part Operatlons
COMPLETE-PART-OP(part=#pI ,op=#opl , t = t 2 : ~ )
6. incomplete Part Operatlons
N-COMPLETE-PART-OP (part=#pl ,op=#op4, t't0.0)
N-COMPLETE-PART-OP (part=#pl ,op=#op2, t = t ~ . ~ )
N-COMPLETE-PART- OP (part=#p2,op=#opl, t=ts.o)
N-COMPLETE-PART-OP( (part=#p2,op=#op6, t'ts.0)
N-COMPLETE-PART-OP (part=#p2,op=#op2, t't5.0)
procedure PART. For each part returned, invoke
primitive subroutine procedure LESS-THAN until a
part with a due-date less than 79200 is found.
e. Derived assertions of fact satisfying the,goal statement
(i.e., multiple solution):
PART(part=#pl ,part-due-date=#79 180),
LESS-THAN(#79 180,#79200)
PART(part=#p2, part-due-date=#79 185,
LESS-THAN(#79 185, #79200)
f. Problem answer: part=#pl or part=#p2.
The multiple solutions satisfying a goal statement such
as in problem 2 can be easily handled by DBMS procedures and subroutine procedures. Thus the following
query and goal statement can be handled just 7 s
easily as a goal statement using only existentia
quantifiers for the variables.
3. a. Problem: What parts are due before 79200?
b. Goal statement: V x 3 y PART(part=x, part-due-date=
y), LESS-THANe,#79200)
c. Procedure declaration: None
d. Computation: Invoke the primitive DBMS procedure
PART. For each part returned satisfying the PART
predicate, invoke procedure LESS-THAN t o check if
the due-date is less than 79200.
e. Derived assertion of fact: same as (2e).
f. Problem answer: Parts=(#pl , #p2).
Procedure lnvocation o f a U n i q u e A x i o m a t i c Procedure
Problem that requires the invocation of a unique procedure
to reduce the goal statement to a set of primitive problems.
answer. An answer predicate such as that used by Green [9]
can be used to keep track of variable instantiations during
resolution.
Illustrative Problem Solving in a Static CMS Domain
(Present Time)
Primitive Problem procedure lnvocation
Solve a problem by a procedure call to the data base
management system (DBMS) for primitive data base problems, and/or by the invocation of primitive subroutines.
1. a.
b.
c.
d.
Problem: Are there any parts of type B in the system?
Goal statement: 3 x PART(part=x, part-type =#B)
Procedure declarations: None
Computation: Invoke a call to the primitive DBMS
procedure PART.
e. Derived assertion of fact: PART(part=#p2,part-type=
#B)
f. Problem answer: Part=#p2.
2. a. Problem: Are any parts due before 79200?
b. Goal statement: 3x 3 y PART(part=x, part-due-date=y),
LESS-THAN@,#79200)
c. Procedure declarations: None
d. Computation: Invoke a call to the primitive DBMS
358
4. a. Problem: What is the first operation for part p l ?
b. Goal statement: -j y FIRST-PART-OP(part=#pl, op=y)
c. Procedure declaration (Axiom):
(Al) V x V y V z
~ ~ ~ s T - P A R T - o p ( p a r t op=y)
=x, +
PART(part=x, part-type=z),
OPERATION(op=y),
PART-ROUTING (part-type = z, op=A
next -op= y )
The interpretation of this axiom is: (op y is first
for part x) if (part x is of type z), @ is an operation),
( jis~
on type 2's routing with no operation preceding op Y ) .
d. Computation: call procedure FIRST-PART-OP by
invoking axiom (Al). Then solve the conjunction of
primitive problems PART, OPERATION, and PARTROUTING, with "pl" substituted for "x."
e. Derived assertion o i tact: FIRST-PART-OP(part=#pl ,
op=#opl).
f. Problem answer: Part p l ' s first operation is o p l .
Procedure lnvocation of a N o n - u n i q u e A x i o m a t i c Procedure
Problems that require selection of one of many procedures
AIIE TRANSACTIONS. Volume 12, No. 4
with the same name to reduce the goal statement to a set of
primitive problems.
5. a. Problem: What operation is to be done next on part p l ?
b. Goal statement: 3y NEXT-PART-OP(part=$pl ,op=y)
c. Procedure declarations:
(A2) Invoke to determine if the first operation for a
part is next.
Vx V y Qz
NEXT-PART-OP(part=x, op=y)+
PART(part=x, part-type=z),
OPERATION (op=y),
PART-ROUTING(part-type=z, op=@,next-op=y),
N-COMPLETE-PART-OP(part=x,
op=y)
Interpretation: (op y is next for part x) if (part x is
of type z), O, is an operation), (Y is on type z's
routing with no operation preceding op y) and (op y is
incomplete).
(A3) Invoke to determine if a subsequent operation
is next.
Vx Vy Vz 3 w
NEXT-PART-OP(part=x, op=y) +PART(part=x, part-type=~),
OPERATION(op=y),
PART-ROUTING(part-type=z, op=y),
PART-ROUTING(part-type=z, op=w, next-op=y),
COMPLETE-PART-OP(part=x,
op=w) ,
N-COMPLETE-PART-OP(part=x,
op=y) .
Interpretation: (op y is next for part x) if (part x is of
type z), (y is an operation), (y is on type z's routing),
(y succeeds some op w), (op w is complete), and (op
y is incomplete).
d. Computation: Call procedure NEXT-PART-OP by invoking either axiom (A2) or (A3). Suppose axiom (A2)
is invoked. Solving the four primitive problems in the
antecedent (i.e., procedure body) of axiom (A2) we
obtain the following assertions of fact:
PART(part=#p 1, part-type=#A),
OPERATION(op=#op I),
PART-ROUTING(part-type=#A, up=@,next-op=y),
IN-COMPLETE-PART-OP(part=#p
1,op=#op 1).
The first three assertions of fact are compatible with
the assertions of fact in the data base given in Table 1.
However, the last assertion of fact above, N-COMPLETE-PART-OP(part=#pl , op=#opl ), is not true.
This can be determined by attempted data base retrieval, or more likely by a primitive subroutine
procedure operating under the closed world assumption. Such a procedure would confirm that N-COMPLETE-PART-OP(part=#pl , op=#opl) is false since
it is in conflict with COMPLETE-PART-OP(part=#pl,
op=#opl) which is explicitly stored in the data
base. This conflict implies no solution t o the given
goal statement when axiom (A2) is invoked. If, however, axiom (A3) is invoked, the resulting primitive
December 1980. AIIE TRANSACTIONS
problems can be solved. The following assertion of
fact thus satisfies the goal statement.
e. Derived assertion of fact: (from axiom (A3) invocation): NEXT-PART-OP(part=#p 1, opz#op4),
f. Problem answer: Operation op4 is to be done next on
part p l .
6. a. Problem: What operation is to be done next on part
p2? This problem is identical to that preceding except
we are now using part p2 as the argument. However,
this problem leads to a different computation.
b. Goal statement: 3 y NEXT-PART-OP(part=#p2,op=y)
c. Procedure declarations: (A2) and (A3) above
d. Computations: Unlike problem 5, invocation of axiom
(A2) leads to a solution for problem 6 while axiom
(A3) leads t o a contradiction.
e. Derived assertion of fact: (from axiom (A2) invocation): NEXT-PART-OP(part=#p2, op=#opl).
f. Problem answers: Operation opl is to be done next on
part P2.
Procedure Invocation of Multiple, Possibly Non-unique
Axiomatic Procedures
In the most complex problems, solution requires multiple
invocations of axiomatic procedures.
7. a. Problem: On what machine should part p2 be scheduled for its next operation if the part is to be assigned
to the machine which will require the shortest processing time (SPT) to perform that operation.
b. Goal statement: 3 y 3 2 SCHEDULE-MCH-OP(part=
#p2, mch=y, op=z)
c. Procedure declarations: in addition t o axioms (A2)
and (A3) we need:
(A4) Vx Q y Vz
POSSIBLE-SCHEDULE(part=x,mch=y, op=z)+
NEXT-PART-OP(part=x, op=z),
MCH-OP(mch=y, op=z) .
Interpretation: (possible schedule for part x ) if (op z
is the next op for part x), and (mch y can perform op
z).
Interpretation: (schedule part x on rnch y for op z )
if (mch w is any possible rnch), (u is time for rnch w
to perform op z), (mch y is one possible rnch), (v is
time for rnch y to perform op z),(time for rnch y is <
time for rnch w), (part x is of type s), and (SPT
scheduling is in effect for type s). Axiom (AS) determines from all possible machines that can be scheduled
for the next operation the one machine with an operation time v for that operation where v is less than or
equal to all operation times for other machines.
d. Computation: Invoke axiom (AS) for procedure
SCHEDULE-MCH-OP, then invoke axiom (A4) for
each of the two procedure calls of POSSIBLESCHEDULE resulting from the invocation of (AS).
Axioms (A2) and (A3) are then invoked to satisfy
procedure calls to NEXT-PART-OPERATION. The
resulting primitive problems are solved procedurally.
e. Derived assertion of fact: SCHEDULE-MCH-OP(part=
#p2, mch=#M2, op=#op6)
f. Problem answer: Schedule part p2 on machine M2 for
the next operation (which is op6).
Note that axiom (AS) will lead to a successful theorem proof
only if predicate SPT(part-type=s) evaluates to true for the
part type in question. Thus procedure (As) will only be
successfully invoked when shortest processing time scheduling is in effect for the given part type. Alternative
SCHEDULE-MCH-OP procedures could be invoked for
shortest processing time by idle machine, arbitrary scheduling, or any other applicable scheduling algorithm. For a
shortest processing time by idle machine procedure, replace
the SPT(part-type=s) predicate in (AS) by the following
three predicates:
MCH-IDLE(mch=y),
MCH-IDLE(mch=w),
SPT-BY-IDLE-MCH(part-type=s).
Predicates SIT and SPT-BY-IDLE-MCH comprise a set of
mutually exclusive operating parameters, only one of which
should evaluate to true at a given time.
Illustrative Problem Solving in a Dynamic CMS Domain
(Past States)
To illustrate the use of past tense in operations management
problem solving, including invocation of the most recent
assertion predicate, we repeat problem 2 with a reference
to a past state of the system.
8. a. Problem: Were any parts in the system at time t4 due
before 79200?
b. God statement: 3 x 3 w MRA-PART(part=x, part-duedate=w, ref-time=#t4), LESS-THAN(w,#79200)
c. Procedure declaration: None
d. Computation: Invoking the most recent assertion procedure MRA-PART, we obtain through resolution a
new goal statement with the following primitive
problems:
(a) PART(part=x,part-due-date=w,t=yi),
(b) LEOi, #t4),
(c) PART(part=x,part-due-date=w,t=y,),
(4 LEO,, #t4),
Only one PART predicate instantiation from Table 2,
name! y :
solves this conjunction of primitive problems. This of
course assumes that N-PART(part=#pl ,part-due-date=
$79 180,t=#t,)
is true for some time r- preceding
the assertion of any PART facts. This can easily be
handled if the MRA predicate is invoked procedurally
rather than by actual application of a MRA axiom
through resolution. The other PART assertion of fact:
PART(part=#p2,part-due-date=#79185, ~ # t s . o ) ,
fails to satisfy the assertion (b) above, LE(#t5.",#t4).
e. Derived assertion of fact:
MRA-PART(part=#pl ,part-due-date-#79180,
ref-time=#t4), LESS-THAN(#79 180,#79200),
f. Problem answer: part=pl.
Problem 3 , dealing with all parts in the system due before
79200, can be solved for a past state using an "all recent
assertion" predicate very similar to the "most recent assertion" predicate, but retrieving all facts of a particular type
asserted before the reference time.
Illustrative Problem Solving in a Dynamic CMS Domain
(Future States)
Problem solving with respect to future time promises to
provide the most valuable benefits from applying theorem
proving techniques to operations management. Given an
operational data base, we utilize the simulation mode of
the decision supgort system to update the knowledge base
to some future time. A set of operators in axiomatic form
serve to describe the operation of the manufacturing system.
For example to describe the performance of a machine
operation on a part, we define the following four predicates
as procedure declarations:
We had defined SCHEDULE-MCH-OPearlier as axiom (AS).
The remaining procedure declarations follow as axioms(A6)
- (A8):
-
--
AIIE TRANSACTIONS. Volume 12, No. 4
state. Axioms (A5) and (A6) are both complete in this
sense; no assertions are implied other than the assertion
explicitly given. Yet axioms (A7) and (A8) imply new
assertions relevant to the knowledge base that are not
explicitly specified. For example, the application of axiom
(A7) to machine M2 for operation op4 for part p l at time
t,,, implies a new assertion other than just the INIT-MCHOP assertion given. The start of this operation also implies
the assertion that operation op4 is now currently in progress
for part p l , i.e., we need to add assertion:
Interpretation: mchx is ready to operate on part y
for op z as of time t1 if rnch x has part y as of time
t 2 , part y is scheduled on rnch x for operation z as of
time t3 ,op z requires tooling w , rnch x has tooling w,
and t l is the latest time in the set {t2, t3 ).
Interpretation: initiate rnch x operation z for party as
of time tl if rnch x is ready to operate on party for
op z as of t 2 , mch x is up as of t3, and J . ~is the later
time of {t2, t3 ).
Similarly, the application of (A8) to machine M2 for operation op4 for part pl at time tZ5., (assuming an operation
time of 15.0 for op4 on machine M2) also implies additional
assertions:
where N-CURRENT-PART-OP is the negation of the
CURRENT-PART-OP assertion implied by axiom (A7).
These additional implications in the simulation mode operation of the decision support system are handled by an ADD
list similar to that used in STRIPS [8]. Thus axiom (A7)
would have the associated ADD list:
(A7) ADD list: CURRENT-PART-OP(part=y,op=z, t=t 1 )
and axiom (A8) would have:
Interpretation: end rnch x operation z for party as of
time t l if rnch x started op z on party as of time t 2 ,
rnch x op z has an op-time of t g time units, and t l =t2
f3
.
+
Note the relationship between a predicate assertion in one
axiom and a reference to the most recent assertion of that
predicate in a subsequent axiom. For example, consider the
predicate INIT-MCH-OP. Axiom (A7) specifies under what
conditions (preconditions in STRIPS terminology [83 ) we
can enter a new INIT-MCH-OP assertion into the knowledge
base. In axiom (A8), however, we are concerned with
retrieving the most recent such assertion of INIT-MCH-OP
(i.e., MRA-INIT-MCH-OP)to be able to assert END-MCH-OP,
denoting the end of the machine operation. Also observe
the specification of time passage in axiom (A8). The end of
a machine operation follows the start of that operation by a
time span equal to the operation performance time. Axioms
(A5) - (A7) on the other hand do not necessarily imply the
passage of time.
One further distinction among these four axioms involves
the completeness of the axiom in explicitly asserting all
facts that are implied by that axiom's application to an input
December 1980, AIIE TRANSACTIONS
(A8) ADD list: COMPLETE-PART-Op(part=y,op=z,t=tl),
N-CURRENT-PART-OP(part=y
,op=z,t=tl ) .
We do not, however, utilize the DELETE list of STRIPS.
The complementary predicates introduced earlier (those prefixed by the character "N") serve the same purpose as
deleting an assertion but without the cost of lost information pertaining to the time of occurrence.
9. a. Problem: Given the current time tS and an SPT scheduling algorithm, when will part p2 complete its last
operation?
b. Goal statement: 3 y 32
COMPLETE-PART-OP(part=#p2, op=y ,t=z),
LAST-PART-OP(part=#p2,op=y) .
c. Procedure declaration:
(A9) Vx Vy 3 w
LAST-PART-OP(part=x,op=y)+PART(part=x,part-type=w),
OPERATION(op=y),
PART-ROUTING(part-type=w, op=y,next-op=@).
d. Computation: Before attempting to solve the goal
statement, the simulation mode of the decision support system must be invoked. Commands specifying
the time limits for the simulation, as well as the
operating parameters in effect might have the format:
In simulation mode the operational axioms are applied
to the operational data base to update the state of the
system. Axiom (A9) is then invoked and primitive
problems solved using the simulation data base for
data retrieval.
e. Derived assertions of fact: Using the data from Table
2 (which ignores inter-machine shuttle times and
machine to cart shuttle times) we obtain:
COMPLETE-PART-OP(part=#p2,0p=#op2,t=#t59),
LAST-PART-OP(part=#p2,0p=#op2).
References
[I]
(21
[3]
[4]
f. Problem answer: Completion at time t,, .
[5 ]
Simulating the completion time for a number of alternative
scheduling algorithms enables us t o then select that algorithm
for operation that provides the best value of a criterion
measure of performance over the simulation time horizon.
[6]
[7]
Conclusions
[8]
In this paper we have explored the application of predicate
logic and mechanical theorem proving to the management
of a computerized manufacturing system. Predicate logic
permits a descriptive and nonprocedural representation of
knowledge related to the operation of the facility. The
predicate calculus language allows both static and dynamically changing knowledge t o be modeled, while theorem proving permits "new" knowledge to be deduced from the
current knowledge base.
From a decision support viewpoint, the resolution procedure allows the knowledge base to be applied to specific
operations management problems stated by the user. In
more general terms, theorem proving as described by
Kowalski [13] can be interpreted as synthesizing a particular program t o solve a user specified problem. The paper
presents axioms representing knowledge typical in a manufacturing environment and demonstrates how user problems
can be handled in the framework of resolution in a problem
reduction approach.
Further work is needed to implement such a system.
Questions on how axioms should be stored and how
resolution can be effectively carried out must be investigated. From the user point of view, a more natural
English-like problem statement language is needed. Techniques must be found to translate sentences in this natural
language into an equivalent predicate calculus form. In
addition, relationships between the problem solving techniques described here and more classical techniques of
integer programming models of scheduling would be of
interest.
191
Acknowledgment
Mr. W. I. Bullers gratefully acknowledges the fellowship
support made possible by a grant from IBM.
362
[lo]
[ll]
[12]
(131
[14]
(151
[ I 61
[ 17 ]
[18]
[19]
[20]
1211
[22]
Bobrow, D. G. and Raphael, B., "New Programming Languages
for A1 Research," Computing Surveys, 6, 3, 15 3-174 (September 1974).
Bonczek, R., Holsapple, C. and Whinston, A., "The Integration
of Network Data Base Management and Problem Resolution,"
Information Systems, 4 2, 143-154 (1 979).
Bruce, B. C., "A Model for Temporal References and Its
Application in a Question-Answering Program," Artificial
lntMtklligence 3 , 1-25 (1972).
Chang, C. L., "DEDUCE 2: Further Investigations of Deduction in Relational Data Bases." IBM Research Report RJ2147
(29410) (May 1978).
Chang, C., Lee, R. C., Svmbolic Logic and Mechanical Theorem
Proving, Academic Press, New York (1973).
Codd, E. F., "A Relational Model for Large Shared Data
Banks," Comm. o f the ACM, 13,6, 377-387 (June 1970).
Fikes, R. E., Hart, P. E. and Nilsson, N. J., "Some New
Directions in Robot Problem Solving," Machine Intelligence.
7, (Eds. Meltzer, B. and Michie, D.), Halstead Press, New
York, 405-430 (1972).
Fikes, R. E. and Nilsson, N. J., "STRIPS: A New Approach
to the Application of Theorem Proving t o Problem Solving,"
Artificial Intelligence, 2 , 189-208 (1971).
Green, C., "Theorem-Proving by Resolution as a Basis for
Question-Answering Systems," Machinc Intelligence, 4 (Eds.
Meltzer, B. and Michie, D.), American Elsevier, New York,
183-205 (1969).
Green, C. C., Raphael, B., "The Use of Theorem-Proving
Techniques in Question-Answering Systems," Proc. ACM
23rd National Computer Conference, 169-181 (1968).
Haseman, W. D. and Whinston, A. B., Introduction t o Data
Management, Irwin, Homewood, Illinois (1977).
Hewitt, C., "Procedural Imbedding of Knowledge in PLANNER," Proc. Int'l. Joint Conf: on Artificial Intelligence, 2,
London, 167-182 (September 1971).
Kowalski, R., "Predicate Logic as Programming Language,"
Proc. IFIP, 74, 569-574 (1974).
Kowalski, R. and Kuehner, D., "Linear Resolution with
Selection Function,"Artificial Intelligence, 2, 227-260 (1971).
Minker, J., "Set Operations and Inferences Over Relational
Data Bases," Technical Rep. TR-427, University of Maryland,
December 19751, (invited paper for the Fourth Texas Conference on Computing Systems).
Minker, J., "Search Strategy and Selection l'unction for an
Inferential Relational System," ACM Transactions on Database Systems, 3, 1, 1-31 (March 1978).
Nilsson, N. J., Problem-Solvitzg Methods in Artificial Intelligence, McCraw-Hill, New York (1971).
Nof, S. Y., Barash, N. M. and Herald, M. J., "Analysis of
Operating Rules in a Computerized Manufacturing System,"
ASME Paper 78- WAIProd-38, (December 1978).
Nof, S. Y., Whinston, A. B. and Bullers, W. I., "Operations
Management Tools for Automatic Manufacturing Systems,"
20th Annual Canadian Operational Research (COR) Conf.,
Vancouver, B.C., (May 1978).
Nof, S. Y., Barash, M. M. and Solberg, J. J., "Operational
Control of Item Flow in Versatile Manufacturing Systems,"
to appear shortly in the Int. J. of Prod. Rex
Nof, S. Y., Whinston, A. B. and Bullers, W. I., "Control and
Decision Support in Automatic Manufacturing Systems,"
AIIE Transactions, 12 2, 156-169 (June 1980).
Phillips, D. T., Heisterberg, R. J., Backstone, J. and Sathaye.
S., "System Analysis Techniques as Applied to Manufacturing Systems, An Annotated Bibliography," Report No.
GEMS-1-77, Department of Industrial Engineering, Texah
A&M University, September 15, 1977.
AIIE TRANSACTIONS. Volume 12, No. 4
[23] Reiter, R., "On Closed World Data Bases," Logic and Data
Bases, (Eds. Gallaire, H . and Minker, J.), Plenum Press, New
York, 55-76 (1978).
[24] Robinson, J. A., "A Machine-Oriented Logic Based on the
Resolution Principle," Journal of the ACM, 12, 1, 23-41
(January 1965).
[25] Sacerdoti, E. D., "Planning in a Hierarchy of Abstraction
Spaces," Artificial Intelligence, 5, 115-135 (1974).
[26] Snodgrass, B. N., Proceedings of Job-Shop Control Interest
Group Meeting, CAM-I, Arlington, Texas, June 22-23 (1978).
[27] Talavage, J. J. and Barash, M. M., "Information and Control
in Computerized Manufacturing Systems," Proc. Int'l Fed. o f
Automatic Control Conf., Tokyo, Japan (October 1977).
[28] Thierauf, R. M., Systems Analysis and Design o f Real-Time
Management Information Systems, Prentice-Hall, Englewood
Cliffs, New Jersey (1975).
[29] van Emden, M. H., "Programming With Resolution Logic,"
Machine Intelligence, 8, (Eds. Elcock, E. W. and Michie, D.),
Halstead Press, New York, 266-299 (1977).
[30] van Emden, M. H. and Kowalski, R., "The Semantics of
Predicate Logic as a Programming Language," Journal of the
ACM, 23,4,733-742 (October 1976).
[31] Verzijl, J. J., Production Planning and Information Systems,
Wiley, New York (1976).
William I. Butlers, Jr., is an Assistant Professor and the director of
the Computing Center at the Anderson School of Management, University of New Mexico in Albuquerque. He received his BS in Mathe-
December 1980, AIIE TRANSACTIONS
matics from Carnegie Mellon University, MBA from Duquesne
University, and PhD in Management Information Systems from
Krannert Graduate School of Management, Purdue University.
Industrial experience includes systems analysis at Alcoa. Bullers is
a member of ACM, and is a holder of the CDP, Certificate in Data
Processing.
Shimon Y. Nof is an Assistant Professor of Industrial Engineering a t
Purdue University. Formerly, he worked in the R&D Division of
Manufacturing Data Systems, Inc. in Ann Arbor, Michigan, and was
an Assistant Professor of Produciton Management in the University
of Michigan, Dearborn. His research interests include production
systems design, industrial information systems, and computer control of manufacturing systems. Dr. Nof holds a BSc and MSc in
Industrial and Management Engineering from the Technion, Israel
Institute of Technology, and a PhD in Industrial and Operations
Engineering from the University of Michigan, Alrn Arbor. He is a
member of ACM, AIIE, and TIMS
Andrew B. Whinston is a Professor of Management, Economics and
Computer Science at Purdue University, an Associate Editor of
Management Science, a member of the editorial board of Discrete
Mathematics, and Chairman, Technical Committee on SocioEconomic Cybernetics, IEEE Systems, Man and Cybernetics Society.
He received his BA from the University of Michigan, MS and PhD
from the Graduate School of Industrial Administration, Carnegie
Mellon University. Dr. Whinston has published extensively in jourals
of economics, operations research, and computer science. He has coauthored a number of books, among them, Introduction t o Data
Management (Irwin), and Quantitative Planning and Control (Academic Press).
363
Download